This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Symbol Separation - Debugging
On Wed, Jul 02, 2003 at 11:35:42PM -0400, Jason Merrill wrote:
> 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.
You are, of course, right. I'm having a reading deficiency week.
> > 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.
Yes, we can make that work.
> 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?
Well, there's:
(2) MyHeader.cinfo : Context info file to validate MyHeader.h.o. It
will be
created in /my_ss/ directory.
But the checksum written to that file has comments referencing using
the inode number, and actually uses st_mtime. I imagine it could be
fixed to use something more reliable.
>
> Jason
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer