[llvm-dev] can valgrind read LLD's debug info?

Andrew Kelley via llvm-dev llvm-dev at lists.llvm.org
Thu Apr 5 15:59:35 PDT 2018


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>


More information about the llvm-dev mailing list