This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: WIP fix for PR 12997
- From: Mark Wielaard <mjw at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: systemtap at sourceware dot org
- Date: Fri, 16 Mar 2012 22:13:53 +0100
- Subject: Re: WIP fix for PR 12997
- References: <87sjh8qyea.fsf@fleche.redhat.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