This is the mail archive of the gcc-patches@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: [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


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