This is the mail archive of the gdb-patches@sources.redhat.com 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: [RFC] Dont skip DW_TAG_member in load_partial_dies()


On Wed, Feb 16, 2005 at 11:08:24AM -0800, Joel Brobecker wrote:
> Hello Daniel,
> 
> > > Just FYI: Here is the change we've made so far in gdb-6.3.

[BTW: A bug report would have been nice... this'll do :-)]

> > > 
> > >        if (abbrev->tag == DW_TAG_subprogram
> > >           || abbrev->tag == DW_TAG_variable
> > >           || abbrev->tag == DW_TAG_namespace
> > > +          || abbrev->tag == DW_TAG_enumeration_type
> > > +          || abbrev->tag == DW_TAG_structure_type
> > 
> > That's a very different problem - you're at the other interesting if in
> > this function.  Please show me an example of debug information which
> > requires this - and see the comment above which talks about why most of
> > these checks are only for buggy compilers...
> 
> It's a long story :).
> 
> In Ada, we allow nested functions. In order to be able to break inside
> a nested function, using "break nested_function", we need to scan the
> DIEs inside subprogram DIEs and build partial symbols for them. That's
> the first local change we did. Something like: if ada and then
> subprogram, then do not skip to sibling.
> 
> And next, we face something a bit out of the ordinary: We had a function
> that was inlined. That caused GCC to create a nameless subprogram DIE,
> with an AT_specification attribute pointing to the original procedure.
> The tricky part was that there was inside that procedure a nameless
> enumeration DIE that also had an AT_specification. We failed on that
> second AT_specification during the lookup in the hash-table.
> 
> I hope this makes sense. I'm trying to be short as I'm busier than
> I have ever been right now. Don't hesitate to let me know if I'm not,
> though.  It may take a bit of time for me to answer, but I will answer.

This sounds like a case that's too complicated for the heuristics to
handle.  I have a patch under test which implements a more thorough
fallback when lookup in the hash table fails.  That allows the
heuristics to be relatively quick, and work for the common case, but
still support more complex cases like this one.

The example I developed it for (this morning) was a C++ function-local
class, like gdb.cp/local.exp, which had an out-of-line definition of
the member function.  That also would have required recursing into
subprograms, and therefore also recursing into lexical blocks, which
defeats the point of the heuristics entirely.

I'm not done testing these patches, but if I don't post it soon, nag me
about it!

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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