This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: Debug info for comdat functions


> This seems clearly wrong to me. ?A reference to a symbol in a discarded
> section should not resolve to an offset into a different section. ?I thought
> the linker always resolved such references to 0, and I think that is what we
> want.

Even resolving to 0 can cause problems. In the Gnu linker, all
references to a discarded symbol get relocated to 0, ignoring any
addend. This can result in spurious (0,0) pairs in range lists. In
Gold, we treat the discarded symbol as 0, but still apply the addend,
and count on GDB to recognize that the function starting at 0 must
have been discarded. Neither solution is ideal. That's why debug info
for COMDAT functions ought to be in the same COMDAT group as the
function...

>> When discussed on IRC recently Jason preferred to move the
>> DW_TAG_subprogram
>> describing a comdat function to a comdat .debug_info DW_TAG_partial_unit
>> and just reference all DIEs that need to be referenced from it
>> using DW_FORM_ref_addr back to the non-comdat .debug_info.
>
> I played around with implementing this in the compiler yesterday; my initial
> patch is attached. ?It seems that with normal DWARF 4 this can work well,
> but I ran into issues with various GNU extensions:

Nice -- I've been wanting to do that for a while, but I always thought
it would be a lot harder. I see that you've based this on the
infrastructure created for -feliminate-dwarf2-dups. I don't think that
will play nice with -fdebug-types-section, though, since I basically
made those two options incompatible with each other by unioning
die_symbol with die_type_node.

In the HP-UX compilers, we basically put a complete set of .debug_*
sections in each COMDAT group, and treated the group as a compilation
unit of its own (not a partial unit). That worked well, and avoided
some of the problems you're running into (although clearly is more
wasteful in terms of object file size). Readelf and friends will need
to be taught how to find the right auxiliary debug sections, though --
they currently have a built-in assumption that there's only one of
each.

-cary


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