|
From: Andrew K. <sup...@gm...> - 2018-04-09 15:18:13
|
One more piece of information: This issue can be reproduced with gcc and gold: gcc -g -c test.c; ld.gold -g --rosegment -o test test.o ==13437== at 0x400140: ??? (in /home/andy/tmp/test) Tom's patch fixes this: ==13441== at 0x400140: _start (test.c:9) So it's a step in the right direction. I'm still interested in the Clang and LLD combination, which is not fixed by the patch. On Fri, Apr 6, 2018 at 1:05 PM, Andrew Kelley <sup...@gm...> wrote: > > > On Fri, Apr 6, 2018, 1:01 PM Tom Hughes <to...@co...> wrote: > >> On 06/04/18 17:07, John Reiser wrote: >> >> I had a look at readelf output and the layout of the lld-linked object >> >> file looks sane to me. >> > >> > Well then, _you_ can fix it. >> > >> > If you want help, then please show the output from >> > readelf --headers ./test >> > both with and without -fuse-ld=lld . >> > [Especially because lld is not readily available: not packaged in >> > Fedora, for instance.] >> >> I debugged it with him on IRC last night - the issue is that it >> has a third segment that is RO and which contains the eh_frame >> section. >> >> I knocked up a patch last night that seemed to fix it for me >> though apparently not for Andrew. >> > > The patch fixes this use case: > gcc -c test.c -g; ld.lld -o test test.o > > However not this use case: > clang -c test.c -g; ld.lld -o test test.o > > > >> Tom >> >> -- >> Tom Hughes (to...@co...) >> http://compton.nu/ >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers >> > |