[RFC] Symbol Separation - Debugging

Jason Merrill jason@redhat.com
Thu Jul 3 03:40:00 GMT 2003


On Wed, 2 Jul 2003 23:21:43 -0400, Daniel Jacobowitz <drow@mvista.com> wrote:

> On Wed, Jul 02, 2003 at 03:00:55PM -0400, Jason Merrill wrote:
>> On Wed, 2 Jul 2003 14:54:46 -0400, Daniel Jacobowitz <drow@mvista.com> wrote:
>> 
>> > On Wed, Jul 02, 2003 at 02:45:41PM -0400, Jason Merrill wrote:
>> 
>> >> Sure.  My point is that with both my scheme and Devang's, you need to use
>> >> DW_FORM_ref_addr to refer to the debug info for the header from files that
>> >> include it.
>> >> 
>> >> The only difference is between emitting the info everywhere and then
>> >> throwing away all but one copy vs. only emitting it once.
>> >
>> > OK, I think I see.  Doesn't this mean we need to emit some new symbols
>> > in .debug_info, if we want to reference it from a different object?
>> 
>> Yes.  The -feliminate-dwarf2-dups code does that; see assign_symbol_names.
>
> That goes through ASM_GENERATE_INTERNAL_LABEL.

Not when comdat_symbol_id is set, as it is for header CUs.

> I don't see any way around reading the object in order to locate die
> offsets or label names.

The existing code generates label names based on a hash of the entire debug
info for the header plus an index.  Certainly that doesn't work unless
we've generated the debug info for each object file; we'd need to come up
with some sort of name mangling to use instead.  But that's certainly a
solvable problem.

BTW, the reason I used a hash before was to avoid problems with conflicts
between different versions of the header; if there are differences, the
hash won't match, so we get two different versions of the header debug
info.  Does Devang's work make any attempt to verify that the debug info
matches the current header?

Jason



More information about the Gcc-patches mailing list