Re: [RFA] Fix has_section_at_zero for separate debug files

Tristan Gingold
2010-01-12T08:55:45Z

On Jan 11, 2010, at 10:28 PM, Tom Tromey wrote:

>>>>>> "Tristan" == Tristan Gingold <gingold@ACT-Europe.FR> writes:
>
> Tristan> this patch reconsiders the approach taken in
> Tristan> http://sourceware.org/ml/gdb-patches/2009-06/msg00116.html
>
> Tristan> The new problem is that has_section_at_zero is now wrongly
> Tristan> cleared. This happens when the separate debug file is a
> Tristan> relocatable file (such as on Darwin) which may have a function
> Tristan> at address 0. If its backlink (ie the executable) has no
> Tristan> section at 0 (which is the rule), one or more symbols disappear
> Tristan> in the symtab.
>
> This seems strange to me. My mental model is that the separate debug
> objfile describes the parent objfile.

That's correct.

> To me this implies that on Darwin
> you ought to relocate the separate debug objects.

Currently we don't relocate it (ie we don't apply relocs), we simply set offsets. But the code doesn't
tests offsets.
Of course not relocating is somewhat wrong, because of common symbols. But that's how it works now, and
I am working on using relocations.

> Tristan> Because a separate debug file may be completely unrelated (in
> Tristan> terms of mapping) from its backlink, we shouldn't try to copy
> Tristan> the has_section_at_zero. Instead, we also consider SEC_ALLOC
> Tristan> sections to set has_section_at_zero. This makes sense because
> Tristan> you may perfectly have the bss at zero.
>
> This also seems a little weird, given that has_section_at_zero is only
> used to determine whether PC ranges are valid in some situations.

Argh, you're right. I thought it was also used to check wether variables exists or not.

> Tristan> No regression on GNU Linux i386.
>
> I wonder whether this code path is tested there.
> I don't know.

I think so. I tested the little example with gdb unpatched, with the code removed in the patch (failure)
and with the full patch.

Tristan.