Red Hat Bugzilla – Bug 191318
LTC23983 ltrace sigsegvs traced process on fc5+
Last modified: 2015-05-04 21:32:24 EDT
Description of problem: ltrace sigsegvs child on ppc64 Version-Release number of selected component (if applicable): 0.4 How reproducible: always Steps to Reproduce: 1. x.c: "int main(void){return 0;}" 2. gcc x.c 2. ltrace a.out Actual results: sigsegv Expected results: smooth run Additional info: Binaries built on older machines (e.g. RHEL3/4) (maybe with older gcc?) will let themselves trace just fine, so it's something with the way the binary on fc5+ is generated. There is i686 bug that could be related: #168490.
It all boils down to changes in /usr/lib/crti.o. This is fc5 linkage: $ ld -dynamic-linker /lib/ld.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc/ppc64-redhat-linux/4.1.0/crtbegin.o x.o /usr/lib/gcc/ppc64-redhat-linux/4.1.0/crtsavres.o /usr/lib/gcc/ppc64-redhat-linux/4.1.0/crtend.o /usr/lib/crtn.o -lc $ ./a.out; echo $? 4 $ ./ltrace ./a.out --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ (x.o is the minimal program from comment#1, compiled with gcc -c x.c on fc5) Now let's use crti.o from fc4: $ ld -dynamic-linker /lib/ld.so.1 /usr/lib/crt1.o ~/fc4/crti.o /usr/lib/gcc/ppc64-redhat-linux/4.1.0/crtbegin.o x.o /usr/lib/gcc/ppc64-redhat-linux/4.1.0/crtsavres.o /usr/lib/gcc/ppc64-redhat-linux/4.1.0/crtend.o /usr/lib/crtn.o -lc $ ./a.out; echo $? 4 $ ./ltrace ./a.out __libc_start_main(1, -5372, -5364, -5268, 0xf7fde740 <unfinished ...> +++ exited (status 4) +++
IBM hit the same problem on rawhide. Hence connecting (or mirroring) the two reports. Changing the version to 'devel' and severity=high to match ibm bug. Thanks.
in essence: fc5 binaries contain adresses, not instruction in PLT (so called secure PLTs). ltrace secure PLT branch contains the code necessary for handling, but few issues have to be solved for it to work. I have a strawman in hand, it more or less works, but testsuite doesn't pass yet. I will post a patch later today, and will work on testsuite passing then.
Created attachment 132295 [details] first take on fixing this Testsuite still won't run with this patch. Basic tests run, but there are few mysterious failures I'm yet to look on. Besides this, it's still hacky in places. In particular: * wait_for_something.c contains delayed initialization of breakpoints * sysdeps/linux-gnu/breakpoint.c contains explicit check if breakpoint is already set. This isn't particularly clean, I would be better if this property arose naturally from the way the insert_breakpoint is called.
The problem is that ltrace isn't able to extract return address from PT_LNK register in sysdeps/linux-gnu/ppc/regs.c. It gets NULL, to be correct, the call won't end with an error. But because of that NULL, ltrace doesn't notice when library call ends, displays <unfinished...> message, and won't include the call in final statistics (in case of -c option). Other than that I'm getting a lot of __gmon_start__ calls. No idea if they are legal or not. The weak-symbol detection code was wrong, but fixing didn't get rid of these calls.
----- Additional Comments From gilliam@us.ibm.com 2006-07-13 12:55 EDT ------- I Thought that the secure PLT brance was merged into the main line. See: http://lists.alioth.debian.org/pipermail/ltrace-devel/2006-June/000066.html
Yes, that work is done on top of trunk. As is, the trunk still sigsegvs the traced process on fc5+ ppc32.
I just did a built of svn trunk with few patches applied (ltrace-0.5-1.0.45svn.5). It contains the bugfix.
(In reply to comment #7) > Yes, that work is done on top of trunk. As is, the trunk still sigsegvs the > traced process on fc5+ ppc32. Oh, it didn't sigsegv, it just didn't trace at all.
changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |OPEN ------- Additional Comments From shenlinf@cn.ibm.com 2006-10-10 07:24 EDT ------- Test ltrace in fc6-test3 and it works fine. ------------- [root@auroralp2 ~]# uname -a Linux auroralp2.upt.austin.ibm.com 2.6.17-1.2630.fc6 #1 SMP Wed Sep 6 17:17:26 EDT 2006 ppc64 ppc64 ppc64 GNU/Linux [root@auroralp2 ~]# rpm -q ltrace ltrace-0.5-6.45svn.fc6 [root@auroralp2 ~]# ltrace ls WARNING: Using e_entry from elf header (0x10002a10) for address of "_start" unexpected breakpoint at 0xf7fc6400 _start(1, 0xf874fd04, 0xf874fd0c, 0xf874fd5c, 0xf7fbea00 <unfinished ...> __libc_start_main(1, 0xf874fd04, 0xf874fd0c, 0xf874fd5c, 0xf7fbea00 <unfinished ...> setlocale(6, "") = "en_US.UTF-8" bindtextdomain("coreutils", "/usr/share/locale") = "/usr/share/locale" textdomain("coreutils") = "coreutils" __cxa_atexit(0x10009e00, 0, 0, 0xff218b8, 4) = 0