can valgrind read LLD's debug info?

Project Infrastructure LLVM Dev List Archives
1

I just filed https://bugs.llvm.org/show_bug.cgi?id=37021

There was another bug that seems related to this which is https://bugs.llvm.org/show_bug.cgi?id=35032 but that one is marked fixed. But this seems to be an issue in trunk.

Is this a known issue?

2

It’s more of a valgrind issue than an LLD issue, but you can work around it by linking with --no-rosegment

3

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?

4

Confirmed that -no-rosegment worked around the issue.

However, a valgrind developer says that perhaps LLD is generating strange object files:

I suspect that is some extra ro segment in addition to the normal rodata
so without it you have two
but I know nothing about lld
but without an executable to examine/test it’s hard to be sure
the not working elf file has only 1 .rodata section
here’s the difference between bad and good headers: https://clbin.com/vvB8O
ah I see it’s because it’s a mapped ro segment in the phdrs
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
s/have/map/

5

–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.

6

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.

7

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!