Comparing `ltrace /bin/ls` output on f23 and rawhide shows significant difference. With ltrace-0.7.91-17.fc23.x86_64 I see couple of useful things when running ltrace /bin/ls on my f23 workstation. ======= io # ltrace /bin/ls |& head __libc_start_main([ "/bin/ls" ] <unfinished ...> strrchr("/bin/ls", '/') = "/ls" setlocale(LC_ALL, "") = "en_US.UTF-8" bindtextdomain("coreutils", "/usr/share/locale") = "/usr/share/locale" textdomain("coreutils") = "coreutils" __cxa_atexit(0x55ee608fb720, 0, 0x55ee60b0cfc0, 0) = 0 isatty(1) = 0 getenv("QUOTING_STYLE") = nil getenv("COLUMNS") = nil ioctl(1, 21523, 0x7ffda867fd00) = -1 io # io # io # ltrace -D77 /bin/ls |& grep PLT | head -n 2 DEBUG: ltrace-elf.c:704: /proc/21357/exe 112 PLT relocations DEBUG: ltrace-elf.c:704: /lib64/libselinux.so.1 161 PLT relocations io # ======= But doing the same on rawhide (having ltrace-0.7.91-19.fc24.x86_64 and coreutils-8.25-5.fc25.x86_64) doesn't give any useful output: ======= fc25 x86_64 # ltrace /bin/ls |& head +++ exited (status 0) +++ fc25 x86_64 # fc25 x86_64 # fc25 x86_64 # ltrace -D77 /bin/ls |& grep PLT | head -n 2 DEBUG: ltrace-elf.c:668: /proc/15974/exe has no PLT relocations DEBUG: ltrace-elf.c:704: /proc/15974/exe 0 PLT relocations fc25 x86_64 # ======= Here is the dwarf producer record comparison for the ls binaries in question: ======= f23 ls producer (GNU_strp_alt) "GNU C11 5.1.1 20150618 (Red Hat 5.1.1-4) -m64 -mtune=generic -march=x86-64 -g -O2 -fexceptions -fstack-protector-strong -fno-strict-aliasing -fpic --param ssp-buffer-size=4" rawhide ls producer (GNU_strp_alt) "GNU C11 6.0.0 20160302 (Red Hat 6.0.0-0.14) -m64 -mtune=generic -march=x86-64 -g -O2 -fexceptions -fstack-protector-strong -fno-strict-aliasing -fpic --param ssp-buffer-size=4" ======= Jakub and Carlos think it's a rawhide binutils issue: (Maybe an optimization because of BIND_NOW? That breaks ltrace). Please check.
I am not familiar with how ltrace works, but if it needs PLT relocs then this could indeed be the problem. It looks like the bug starts here: https://sourceware.org/ml/binutils-cvs/2015-05/msg00106.html An H.J. patch that: Don't generate PLT relocations for now binding There is no need for PLT relocations with -z now. We can use GOT relocations, which take less space, instead and replace 16-byte .plt entres with 8-byte .plt.got entries. It was later updated because of PR 18458: https://sourceware.org/bugzilla/show_bug.cgi?id=18458 but I presume that this fix was insufficient for ltrace. Can ltrace be modified to work with the binaries now being produced by the F24 linker ? If not then I can try to produce a patch that will revert H.J.'s change. Cheers Nick
ltrace certainly relies on extracting stuff out of the PLT, so if binutils is optimizing a PLT access into a GOT access it's likely that ltrace is going to stop working. I would not recommend crippling binutils to keep ltrace happy. Instead we just have to wait for DJ or the upstream project to tackle this bug (assuming ltrace can somehow be taught how to extract stuff out of the GOT as well as the PLT). Given ltrace's low priority nature, this could take a while.
Any update on this? ltrace on F24 is unusable.
No, no significant updates. As I noted in c#2, ltrace is very low on the priority list.
ftr, i've reported this upstream: http://lists.alioth.debian.org/pipermail/ltrace-devel/2016-May/001378.html
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
$ rpm -q binutils binutils-2.26.1-1.fc25.x86_64 I see that it is possible to ltrace binaries built oneself on fedora 25? `ltrace /bin/ls` outputs nothing, while this does work: `ltrace git/coreutils/src/ls` My binutils is currently binutils-2.26.1-1.fc25.x86_64 The ltracing works also if I `strip git/coreutils/src/ls`
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
The problem is still there in Fedora 26.
FYI This is not a bug in ltrace. This problem is caused by an optimization in binutils which elides references to the PLT for library calls. ltrace relies on the PLT access to "hook" such calls, so cannot work with this optimization in place.
That sounds like closing with notabug or wontfix would be appropriate, doesn't it?
Well, three options... 1. Close it and live with the problem 2. Assign it to binutils so they can remove the optimization 3. Keep it in case ltrace can find a way to work around the optimization I don't know which is "best" but closing it as wontfix is certainly easiest.
Arguably we should push the binutils tweak that we use for RHEL to prevent plt elision into Fedora. The mis-guided elision of plt entries breaks LD_AUDIT which is a fairly big deal.
Assigning to binutils to evaluate that option, then.
OK - I will open a FESco change request for the "new" feature of the linker and prepare a patch locally....
Fixed in: binutils-2.29.1-5.fc28
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.