This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Fix has_section_at_zero for separate debug files


>>>>> "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.  To me this implies that on Darwin
you ought to relocate the separate debug objects.

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.

Tristan> No regression on GNU Linux i386.

I wonder whether this code path is tested there.
I don't know.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]