Re: WIP fix for PR 12997

[Mark Wielaard <mjw at redhat dot com>]

On Fri, Mar 16, 2012 at 10:54:53AM -0600, Tom Tromey wrote:
> I tried stap on an executable that uses the new DWARF 4 .debug_types
> section.  This failed, but the appended patch seems sufficient to make
> it work for me.

Thanks! I think the patch is correct, but I would like to think a bit
more on this. The patch makes it so that we always go over all compile
units and all type units. Which is good. But I think we can do something
a bit smarter. dwflpp::iterate_over_cus () is used in a couple of cases
some aren't interested in types, like when used with the
function_caching_callback, then iterating over all the TU DIEs seems like
a waste. But the other way around, when callbacks are interested in types
then we must scan both CUs and TUs, since CUs can still contain type DIEs.

I am not against committing your patch as is. But then lets make sure
to file a new PR for the optimisation.
 
> I didn't try to solve the ET_REL case pointed out in the PR.

That has to be solved in elfutils/libdw. And for systemtap that would
only happen with kernel modules.

> I wasn't sure if there are other code paths that are important to test.
> This fixed the simple initial case I came up with; details in the commit
> message.  Are there other things I should look at?
>
> I did look at the other places mentioning DW_TAG_compile_unit, and of
> these, only dwflpp::cache_die_parents seemed like it might possibly need
> to also mention DW_TAG_type_unit.  I didn't look into making a test case
> for this.

Yes, seems so. Although I haven't yet looked at where that is then
used in the code.

Some of the tests use testsuite/lib/compile_flags.exp to make a testcase
go over various permutations of compiler flags. Maybe we could expand
that to also make sure -g-dwarf4 -fdebug-types/-gfno-debug-types gets
tested in more cases.

Cheers,

Mark