Bug 191318 - LTC23983 ltrace sigsegvs traced process on fc5+
LTC23983 ltrace sigsegvs traced process on fc5+
Product: Fedora
Classification: Fedora
Component: ltrace (Show other bugs)
ppc64 Linux
medium Severity high
: ---
: ---
Assigned To: Petr Machata
Depends On:
  Show dependency treegraph
Reported: 2006-05-10 15:07 EDT by Petr Machata
Modified: 2015-05-04 21:32 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-14 20:53:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
first take on fixing this (4.41 KB, patch)
2006-07-12 07:27 EDT, Petr Machata
no flags Details | Diff

  None (edit)
Description Petr Machata 2006-05-10 15:07:15 EDT
Description of problem:
ltrace sigsegvs child on ppc64

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. x.c: "int main(void){return 0;}"
2. gcc x.c
2. ltrace a.out

Actual results:

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
There is i686 bug that could be related: #168490.
Comment 1 Petr Machata 2006-05-12 08:10:56 EDT
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/crtend.o /usr/lib/crtn.o -lc
$ ./a.out; echo $?
$ ./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/crtend.o /usr/lib/crtn.o -lc
$ ./a.out; echo $?
$ ./ltrace ./a.out __libc_start_main(1, -5372, -5364, -5268, 0xf7fde740
<unfinished ...>
+++ exited (status 4) +++
Comment 2 IBM Bug Proxy 2006-06-08 16:23:26 EDT
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.
Comment 3 Petr Machata 2006-07-12 06:25:43 EDT
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.
Comment 4 Petr Machata 2006-07-12 07:27:24 EDT
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.
Comment 5 Petr Machata 2006-07-12 16:43:30 EDT
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.
Comment 6 IBM Bug Proxy 2006-07-13 12:51:19 EDT
----- 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.

Comment 7 Petr Machata 2006-07-13 13:34:05 EDT
Yes, that work is done on top of trunk.  As is, the trunk still sigsegvs the
traced process on fc5+ ppc32.
Comment 8 Petr Machata 2006-07-14 20:53:35 EDT
I just did a built of svn trunk with few patches applied
(ltrace-0.5-1.0.45svn.5).  It contains the bugfix.
Comment 9 Petr Machata 2006-07-17 07:35:15 EDT
(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.
Comment 10 IBM Bug Proxy 2006-10-10 07:26:48 EDT

           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
[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 

Note You need to log in before you can comment on or make changes to this bug.