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: [2/2] Reducing the overhead of dwarf2 location tracking


On Fri, Mar 4, 2011 at 3:49 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Mar 04, 2011 at 03:30:34PM +0100, Richard Guenther wrote:
>> On Fri, Mar 4, 2011 at 2:56 PM, Richard Sandiford
>> > Jakub confirms that this indeed the intended behaviour, and I haven't
>> > seen any problem with the output.
>>
>> Hm, but isn't it incorrect debug info? ?I would have expected this
>> non-localized var to be the abstract origin of a copy for location
>> list purposes.
>
> I thought we've discussed that on IRC. ?For -fcompare-debug reasons
> the decision on what decl is localized and what goes into
> BLOCK_NONLOCALIZED_VARS can't take into account debug stmts (otherwise
> there would be -fcompare-debug failures).
> Thus, we sometimes decide to have some BLOCK_NONLOCALIZED_VARS vars
> referenced in debug stmts.
> The way this works is we do normal var-tracking against those, and then
> at dwarf2out.c time just pick their locations up.
> See e.g.
> http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00445.html
> for some of the details.

Sure.

But then location lists for those variables depend on the function context
and cannot be shared for different callers.  Am I missing something?
Likewise I don't see how they could be shared for multiple inline instances
in the same function.

Richard.

> ? ? ? ?Jakub
>


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