Rui Ueyama via llvm-dev
2018-Apr-05 22:21 UTC
[llvm-dev] can valgrind read LLD's debug info?
--rosegment puts read-only data and executable text in a single segment and make it executable, so your read-only code becomes executable. I think that shouldn't be a default behavior. If valgrind needs that, we can't fix it by changing the default. On Thu, Apr 5, 2018 at 2:50 PM Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Confirmed that -no-rosegment worked around the issue. > > However, a valgrind developer says that perhaps LLD is generating strange > object files: > > <tomhughes> I suspect that is some extra ro segment in addition to the > normal rodata > <tomhughes> so without it you have two > <tomhughes> but I know nothing about lld > <tomhughes> but without an executable to examine/test it's hard to be sure > <andrewrk> the not working elf file has only 1 .rodata section > <andrewrk> here's the difference between bad and good headers: > https://clbin.com/vvB8O > <tomhughes> ah I see it's because it's a mapped ro segment in the phdrs > <tomhughes> don't think it's the problem but this file is quite odd - the > ro segment in the phdrs doesn't seem to have to any section listed in the > shdrs > <tomhughes> s/have/map/ > > Is this something where LLD can be reasonably changed to be compatible > with valgrind without this workaround? > > Thanks, > Andrew > > On Thu, Apr 5, 2018 at 5:28 PM, Andrew Kelley <superjoe30 at gmail.com> > wrote: > >> As a frontend, what are the downsides of enabling --no-rosegment by >> default? >> >> So far the pro list is: >> * valgrind debug info will work by default >> >> What's on the con list? >> >> On Thu, Apr 5, 2018 at 5:16 PM, Shoaib Meenai <smeenai at fb.com> wrote: >> >>> It's more of a valgrind issue than an LLD issue, but you can work around >>> it by linking with --no-rosegment >>> >>> >>> >>> *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Andrew >>> Kelley via llvm-dev <llvm-dev at lists.llvm.org> >>> *Reply-To: *Andrew Kelley <superjoe30 at gmail.com> >>> *Date: *Thursday, April 5, 2018 at 2:14 PM >>> *To: *LLVM Dev <llvm-dev at lists.llvm.org> >>> *Subject: *[llvm-dev] can valgrind read LLD's debug info? >>> >>> >>> >>> I just filed https://bugs.llvm.org/show_bug.cgi?id=37021 >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D37021&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=LOIzu9sn31pmykUwYH1_wAigCpxv33qUDNdmOrmGop4&s=2_EmscX6fjQZR0pF1CQWKUPDgpBLCJhFfnOvlkivJBE&e=> >>> >>> There was another bug that seems related to this which is >>> https://bugs.llvm.org/show_bug.cgi?id=35032 >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D35032&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=LOIzu9sn31pmykUwYH1_wAigCpxv33qUDNdmOrmGop4&s=c8bjnWV_NwOLITc1Tc5dCjJC88BhCt86girLjAbXTbk&e=> >>> but that one is marked fixed. But this seems to be an issue in trunk. >>> >>> Is this a known issue? >>> >> >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180405/d9675edd/attachment.html>
Rui Ueyama via llvm-dev
2018-Apr-05 22:30 UTC
[llvm-dev] can valgrind read LLD's debug info?
But I can't think of a reason that valgrind needs executable data segment. It is likely that valgrind assumes some specific segment layout that the GNU linker creates and can't handle other layout even if it is valid. On Thu, Apr 5, 2018 at 3:21 PM Rui Ueyama <ruiu at google.com> wrote:> --rosegment puts read-only data and executable text in a single segment > and make it executable, so your read-only code becomes executable. I think > that shouldn't be a default behavior. If valgrind needs that, we can't fix > it by changing the default. > > On Thu, Apr 5, 2018 at 2:50 PM Andrew Kelley via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Confirmed that -no-rosegment worked around the issue. >> >> However, a valgrind developer says that perhaps LLD is generating strange >> object files: >> >> <tomhughes> I suspect that is some extra ro segment in addition to the >> normal rodata >> <tomhughes> so without it you have two >> <tomhughes> but I know nothing about lld >> <tomhughes> but without an executable to examine/test it's hard to be sure >> <andrewrk> the not working elf file has only 1 .rodata section >> <andrewrk> here's the difference between bad and good headers: >> https://clbin.com/vvB8O >> <tomhughes> ah I see it's because it's a mapped ro segment in the phdrs >> <tomhughes> don't think it's the problem but this file is quite odd - the >> ro segment in the phdrs doesn't seem to have to any section listed in the >> shdrs >> <tomhughes> s/have/map/ >> >> Is this something where LLD can be reasonably changed to be compatible >> with valgrind without this workaround? >> >> Thanks, >> Andrew >> >> On Thu, Apr 5, 2018 at 5:28 PM, Andrew Kelley <superjoe30 at gmail.com> >> wrote: >> >>> As a frontend, what are the downsides of enabling --no-rosegment by >>> default? >>> >>> So far the pro list is: >>> * valgrind debug info will work by default >>> >>> What's on the con list? >>> >>> On Thu, Apr 5, 2018 at 5:16 PM, Shoaib Meenai <smeenai at fb.com> wrote: >>> >>>> It's more of a valgrind issue than an LLD issue, but you can work >>>> around it by linking with --no-rosegment >>>> >>>> >>>> >>>> *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Andrew >>>> Kelley via llvm-dev <llvm-dev at lists.llvm.org> >>>> *Reply-To: *Andrew Kelley <superjoe30 at gmail.com> >>>> *Date: *Thursday, April 5, 2018 at 2:14 PM >>>> *To: *LLVM Dev <llvm-dev at lists.llvm.org> >>>> *Subject: *[llvm-dev] can valgrind read LLD's debug info? >>>> >>>> >>>> >>>> I just filed https://bugs.llvm.org/show_bug.cgi?id=37021 >>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D37021&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=LOIzu9sn31pmykUwYH1_wAigCpxv33qUDNdmOrmGop4&s=2_EmscX6fjQZR0pF1CQWKUPDgpBLCJhFfnOvlkivJBE&e=> >>>> >>>> There was another bug that seems related to this which is >>>> https://bugs.llvm.org/show_bug.cgi?id=35032 >>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D35032&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=LOIzu9sn31pmykUwYH1_wAigCpxv33qUDNdmOrmGop4&s=c8bjnWV_NwOLITc1Tc5dCjJC88BhCt86girLjAbXTbk&e=> >>>> but that one is marked fixed. But this seems to be an issue in trunk. >>>> >>>> Is this a known issue? >>>> >>> >>> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180405/86d29f7f/attachment-0001.html>
Andrew Kelley via llvm-dev
2018-Apr-05 22:59 UTC
[llvm-dev] can valgrind read LLD's debug info?
This makes sense. I'm now convinced this is a bug in valgrind and I will work with the valgrind developers to get it resolved. Thanks! On Thu, Apr 5, 2018, 6:31 PM Rui Ueyama <ruiu at google.com> wrote:> But I can't think of a reason that valgrind needs executable data segment. > It is likely that valgrind assumes some specific segment layout that the > GNU linker creates and can't handle other layout even if it is valid. > > On Thu, Apr 5, 2018 at 3:21 PM Rui Ueyama <ruiu at google.com> wrote: > >> --rosegment puts read-only data and executable text in a single segment >> and make it executable, so your read-only code becomes executable. I think >> that shouldn't be a default behavior. If valgrind needs that, we can't fix >> it by changing the default. >> >> On Thu, Apr 5, 2018 at 2:50 PM Andrew Kelley via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Confirmed that -no-rosegment worked around the issue. >>> >>> However, a valgrind developer says that perhaps LLD is generating >>> strange object files: >>> >>> <tomhughes> I suspect that is some extra ro segment in addition to the >>> normal rodata >>> <tomhughes> so without it you have two >>> <tomhughes> but I know nothing about lld >>> <tomhughes> but without an executable to examine/test it's hard to be >>> sure >>> <andrewrk> the not working elf file has only 1 .rodata section >>> <andrewrk> here's the difference between bad and good headers: >>> https://clbin.com/vvB8O >>> <tomhughes> ah I see it's because it's a mapped ro segment in the phdrs >>> <tomhughes> don't think it's the problem but this file is quite odd - >>> the ro segment in the phdrs doesn't seem to have to any section listed in >>> the shdrs >>> <tomhughes> s/have/map/ >>> >>> Is this something where LLD can be reasonably changed to be compatible >>> with valgrind without this workaround? >>> >>> Thanks, >>> Andrew >>> >>> On Thu, Apr 5, 2018 at 5:28 PM, Andrew Kelley <superjoe30 at gmail.com> >>> wrote: >>> >>>> As a frontend, what are the downsides of enabling --no-rosegment by >>>> default? >>>> >>>> So far the pro list is: >>>> * valgrind debug info will work by default >>>> >>>> What's on the con list? >>>> >>>> On Thu, Apr 5, 2018 at 5:16 PM, Shoaib Meenai <smeenai at fb.com> wrote: >>>> >>>>> It's more of a valgrind issue than an LLD issue, but you can work >>>>> around it by linking with --no-rosegment >>>>> >>>>> >>>>> >>>>> *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of >>>>> Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> >>>>> *Reply-To: *Andrew Kelley <superjoe30 at gmail.com> >>>>> *Date: *Thursday, April 5, 2018 at 2:14 PM >>>>> *To: *LLVM Dev <llvm-dev at lists.llvm.org> >>>>> *Subject: *[llvm-dev] can valgrind read LLD's debug info? >>>>> >>>>> >>>>> >>>>> I just filed https://bugs.llvm.org/show_bug.cgi?id=37021 >>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D37021&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=LOIzu9sn31pmykUwYH1_wAigCpxv33qUDNdmOrmGop4&s=2_EmscX6fjQZR0pF1CQWKUPDgpBLCJhFfnOvlkivJBE&e=> >>>>> >>>>> There was another bug that seems related to this which is >>>>> https://bugs.llvm.org/show_bug.cgi?id=35032 >>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D35032&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=LOIzu9sn31pmykUwYH1_wAigCpxv33qUDNdmOrmGop4&s=c8bjnWV_NwOLITc1Tc5dCjJC88BhCt86girLjAbXTbk&e=> >>>>> but that one is marked fixed. But this seems to be an issue in trunk. >>>>> >>>>> Is this a known issue? >>>>> >>>> >>>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180405/6a3ade61/attachment.html>