[Bug binutils/26841] objcopy --extract-dwo silently drops relocation

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26841

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Nick Clifton from comment #1)
> Created attachment 12944 [details]
> Proposed patch
> 
> Hi Tom,
> 
>   It seems to me that we ought to keep the relocations.
> 
>   So please could you try out this patch and let me know if it works for you.
> 

I've tried this out.  It works in the sense that:
- readelf a-hello.dwo now correctly reads the the dwarf
- gdb a.out manages to read the info, and do a successful "ptype main"
However, lldb already hangs when doing "b main".

I'm not sure if this is the best solution.

It's trivial to resolve these relocations once at objcopy time, so why pass
them on to be resolved at load/run-time more than once?  That looks
unnecessary, and it requires readers to handle this correctly (which,
apparently lldb doesn't).

Furthermore, mentioning dwarf 5 standard bit @ "7.3.2.2 Second Partition
(Unlinked or in a .dwo File)":
...
Split DWARF object files do not get linked with any other files, therefore
references between sections must not make use of normal object file relocation
information. As a result, symbolic references within or between sections are
not
possible.
...

So, AFAIU it's already questionable that labels are allowed in a dwo section in
the first place.  If we assume that they're not allowed, we can still allow
labels in the pre-split dwo section to make things easier to emit for the
compiler, but after objcopy --extract-dwo the labels should be resolved into
constants.

-- 
You are receiving this mail because:
You are on the CC list for the bug.