frame cache

frame cache

[Michael Eager]

I have a couple questions about the <target>_frame_cache
structure and functions.

1)  This appears to be a single-entry cache.  Why not keep
     multiple entries?

2)  The data in the frame cache seems to be of two different
     types:
     a)  Fixed, based on analyzing the code: register offsets,
         stack alignment, framelessness, etc.
     b)  Variable, based on the call: return pc, frame base

     It looks to me that the object code is analyzed repeatedly
     and this fixed information is discarded along with the
     variable information.

     Why not keep a persistent cache of function specific fixed
     data and only discard the call-specific data when the frame
     cache is cleared?

Is there any documentation about what target-specific data
the frame cache is supposed to contain or how the functions are
supposed to work?


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: frame cache

[Michael Eager]

Michael Eager wrote:
> I have a couple questions about the <target>_frame_cache
> structure and functions.
> 
> 1)  This appears to be a single-entry cache.  Why not keep
>     multiple entries?
> 
> 2)  The data in the frame cache seems to be of two different
>     types:
>     a)  Fixed, based on analyzing the code: register offsets,
>         stack alignment, framelessness, etc.
>     b)  Variable, based on the call: return pc, frame base
> 
>     It looks to me that the object code is analyzed repeatedly
>     and this fixed information is discarded along with the
>     variable information.
> 
>     Why not keep a persistent cache of function specific fixed
>     data and only discard the call-specific data when the frame
>     cache is cleared?
> 
> Is there any documentation about what target-specific data
> the frame cache is supposed to contain or how the functions are
> supposed to work?

And one more question:

3)  In <target>_skip_prologue(), an dummy <target>_frame_cache is
     created to be passed to <target>_analyze_prologue().  This
     dummy cache entry is discarded.   Why not retain this info?


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: frame cache

[Daniel Jacobowitz]

On Tue, Jul 24, 2007 at 10:08:25AM -0700, Michael Eager wrote:
> And one more question:
> 
> 3)  In <target>_skip_prologue(), an dummy <target>_frame_cache is
>     created to be passed to <target>_analyze_prologue().  This
>     dummy cache entry is discarded.   Why not retain this info?

I think the answers to your other two questions should clarify this.
We don't have anywhere to keep it, and the information is not quite
the same because it depends how far into the function we're allowed to
analyze (the PC "limit").  Also, many targets don't do it this way.

-- 
Daniel Jacobowitz
CodeSourcery

Re: frame cache

[Michael Eager]

Daniel Jacobowitz wrote:
> On Tue, Jul 24, 2007 at 10:08:25AM -0700, Michael Eager wrote:
>> And one more question:
>>
>> 3)  In <target>_skip_prologue(), an dummy <target>_frame_cache is
>>     created to be passed to <target>_analyze_prologue().  This
>>     dummy cache entry is discarded.   Why not retain this info?
> 
> I think the answers to your other two questions should clarify this.
> We don't have anywhere to keep it, and the information is not quite
> the same because it depends how far into the function we're allowed to
> analyze (the PC "limit").  Also, many targets don't do it this way.

This seems odd.  The function is <target>_analyze_prologue()
not <target>_analyze_part_of_a_prologue().  The prologue isn't going
to change depending on where the program stopped.  <target>_skip_prologue()
can return a pc based on whatever a complete analysis reveals.

In i386, for example, the "pc limit" (called current_pc) passed
to i386_analyze_prologue() is 0xffffffff.  Sparc is similar.
Neither seem to restrict how far the analyze_prologue function scans.

I do see that some targets merge skip_prologue and analyze_prologue.
Are there other methods?  It would seem to me that for any function
that has DWARF data, one can locate the end of the prologue without
reading data from the target.  I don't see any target which does this.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: frame cache

[Daniel Jacobowitz]

On Tue, Jul 24, 2007 at 11:10:01AM -0700, Michael Eager wrote:
> This seems odd.  The function is <target>_analyze_prologue()
> not <target>_analyze_part_of_a_prologue().  The prologue isn't going
> to change depending on where the program stopped.  <target>_skip_prologue()
> can return a pc based on whatever a complete analysis reveals.
> 
> In i386, for example, the "pc limit" (called current_pc) passed
> to i386_analyze_prologue() is 0xffffffff.  Sparc is similar.
> Neither seem to restrict how far the analyze_prologue function scans.

Yes.  But when you are analyzing the prologue for a frame cache, it is
important to restrict it to the current PC.  Otherwise obviously bad
things happen when you're stopped on the first or second instruction
of the function.  So the result of that analysis is not always the
same for a given function.

> I do see that some targets merge skip_prologue and analyze_prologue.
> Are there other methods?  It would seem to me that for any function
> that has DWARF data, one can locate the end of the prologue without
> reading data from the target.  I don't see any target which does this.

Some targets found it easier to have two separate methods.  Others use
line number info, or some combination - e.g. mips_skip_prologue ->
skip_prologue_using_sal.  Nothing tries to use the .debug_line
prologue flag, since GCC doesn't generate it yet.

-- 
Daniel Jacobowitz
CodeSourcery

Re: frame cache

[Mark Kettenis]

> Date: Tue, 24 Jul 2007 11:10:01 -0700
> From: Michael Eager <eager@eagercon.com>
> 
> I do see that some targets merge skip_prologue and analyze_prologue.
> Are there other methods?  It would seem to me that for any function
> that has DWARF data, one can locate the end of the prologue without
> reading data from the target.  I don't see any target which does this.

Because GCC doesn't emit the proper DWARF info to do this.

Re: frame cache

[Daniel Jacobowitz]

On Tue, Jul 24, 2007 at 10:01:05AM -0700, Michael Eager wrote:
> I have a couple questions about the <target>_frame_cache
> structure and functions.
> 
> 1)  This appears to be a single-entry cache.  Why not keep
>     multiple entries?

No, it isn't single-entry.  The common code in frame.c is responsible
for passing a pointer to the correct place to store the cache for the
current frame.

> 2)  The data in the frame cache seems to be of two different
>     types:
>     a)  Fixed, based on analyzing the code: register offsets,
>         stack alignment, framelessness, etc.
>     b)  Variable, based on the call: return pc, frame base
> 
>     It looks to me that the object code is analyzed repeatedly
>     and this fixed information is discarded along with the
>     variable information.
> 
>     Why not keep a persistent cache of function specific fixed
>     data and only discard the call-specific data when the frame
>     cache is cleared?

No good reason.  I have thought about doing this before.  It's not
fundamentally different from the way the DWARF unwinder works; the
persistent part of the cache would be approximately an FDE.  It's a
little tricky to implement, since we still need to detect stopping
within the prologue, but not too tricky.  I suppose bonus points would
be awarded for constructing an actual FDE :-)

> Is there any documentation about what target-specific data
> the frame cache is supposed to contain or how the functions are
> supposed to work?

Not really, because it's completely up to the target what goes in
them; it varies quite a bit between targets.

Vlad, didn't you say a week or two ago that you'd been working on some
frame docs?

-- 
Daniel Jacobowitz
CodeSourcery

Re: frame cache

[Michael Eager]

Thanks for the quick reply.

Daniel Jacobowitz wrote:
> On Tue, Jul 24, 2007 at 10:01:05AM -0700, Michael Eager wrote:
>> I have a couple questions about the <target>_frame_cache
>> structure and functions.
>>
>> 1)  This appears to be a single-entry cache.  Why not keep
>>     multiple entries?
> 
> No, it isn't single-entry.  The common code in frame.c is responsible
> for passing a pointer to the correct place to store the cache for the
> current frame.

I don't see any links to the <target>_frame_cache in frame_info.
I don't see anything in frame.c which looks like it searches
for the correct <target>_frame_cache.  Can you point me at the
right place?

>> 2)  The data in the frame cache seems to be of two different
>>     types:
>>     a)  Fixed, based on analyzing the code: register offsets,
>>         stack alignment, framelessness, etc.
>>     b)  Variable, based on the call: return pc, frame base
>>
>>     It looks to me that the object code is analyzed repeatedly
>>     and this fixed information is discarded along with the
>>     variable information.
>>
>>     Why not keep a persistent cache of function specific fixed
>>     data and only discard the call-specific data when the frame
>>     cache is cleared?
> 
> No good reason.  I have thought about doing this before.  It's not
> fundamentally different from the way the DWARF unwinder works; the
> persistent part of the cache would be approximately an FDE.  It's a
> little tricky to implement, since we still need to detect stopping
> within the prologue, but not too tricky.  I suppose bonus points would
> be awarded for constructing an actual FDE :-)

I don't know about creating FDEs, but keeping persistent data
like frame pointer and size should be simple.

When I put debugging code in <target>_analyze_prologue(), I see
that it is called over and over while executing a "next" command.
All those bits going back and forth over the serial line to the
target.

>> Is there any documentation about what target-specific data
>> the frame cache is supposed to contain or how the functions are
>> supposed to work?
> 
> Not really, because it's completely up to the target what goes in
> them; it varies quite a bit between targets.
> 
> Vlad, didn't you say a week or two ago that you'd been working on some
> frame docs?

I'd appreciate anything, naturally.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: frame cache

[Daniel Jacobowitz]

On Tue, Jul 24, 2007 at 10:35:59AM -0700, Michael Eager wrote:
> I don't see any links to the <target>_frame_cache in frame_info.
> I don't see anything in frame.c which looks like it searches
> for the correct <target>_frame_cache.  Can you point me at the
> right place?

Sure:

  /* The frame's low-level unwinder and corresponding cache.  The
     low-level unwinder is responsible for unwinding register values
     for the previous frame.  The low-level unwind methods are
     selected based on the presence, or otherwise, of register unwind
     information such as CFI.  */
  void *prologue_cache;
  const struct frame_unwind *unwind;

> When I put debugging code in <target>_analyze_prologue(), I see
> that it is called over and over while executing a "next" command.
> All those bits going back and forth over the serial line to the
> target.

I like to use GDB's built in data caching and/or set
trust-readonly-sections.  I hope we can make the data caching more
aggressive by default at some point.


-- 
Daniel Jacobowitz
CodeSourcery

Re: frame cache

[Michael Eager]

Daniel Jacobowitz wrote:
> On Tue, Jul 24, 2007 at 10:35:59AM -0700, Michael Eager wrote:
>> I don't see any links to the <target>_frame_cache in frame_info.
>> I don't see anything in frame.c which looks like it searches
>> for the correct <target>_frame_cache.  Can you point me at the
>> right place?
> 
> Sure:
> 
>   /* The frame's low-level unwinder and corresponding cache.  The
>      low-level unwinder is responsible for unwinding register values
>      for the previous frame.  The low-level unwind methods are
>      selected based on the presence, or otherwise, of register unwind
>      information such as CFI.  */
>   void *prologue_cache;
>   const struct frame_unwind *unwind;

I missed that prologue_cache ==> <target>_frame_cache.
I only saw that it was set by sentinel_frame_cache, but
now I see that it is passed to frame_unwind_find_by_frame()
and on from there.  (Bad void pointer, bad, bad.)

>> When I put debugging code in <target>_analyze_prologue(), I see
>> that it is called over and over while executing a "next" command.
>> All those bits going back and forth over the serial line to the
>> target.
> 
> I like to use GDB's built in data caching and/or set
> trust-readonly-sections.  I hope we can make the data caching more
> aggressive by default at some point.

Perhaps you or someone could write some documentation for this?  :-)

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: frame cache

[Mark Kettenis]

> Date: Tue, 24 Jul 2007 10:35:59 -0700
> From: Michael Eager <eager@eagercon.com>
> 
> When I put debugging code in <target>_analyze_prologue(), I see
> that it is called over and over while executing a "next" command.
> All those bits going back and forth over the serial line to the
> target.

If that's the case, there's something wrong; prologue analysis should
only be done as a last resort, i.e. when proper debug information is
not available.

Your effort might be better spent on determining why proper debug info
is not present instead of optimizing <target>_analyze_prologue().

Re: frame cache

[Michael Eager]

Mark Kettenis wrote:
>> Date: Tue, 24 Jul 2007 10:35:59 -0700
>> From: Michael Eager <eager@eagercon.com>
>>
>> When I put debugging code in <target>_analyze_prologue(), I see
>> that it is called over and over while executing a "next" command.
>> All those bits going back and forth over the serial line to the
>> target.
> 
> If that's the case, there's something wrong; prologue analysis should
> only be done as a last resort, i.e. when proper debug information is
> not available.
> 
> Your effort might be better spent on determining why proper debug info
> is not present instead of optimizing <target>_analyze_prologue().

Perhaps so, I don't see where other targets check for debug
info before calling analyze_prologue().  For example, on i386,
i386_analyze_prologue() is called each and every time that
i386_skip_prologue() is called.

I don't see where there is any test in symtab.c or infrun.c
which tests for debug info before calling SKIP_PROLOGUE which
calls <target>_skip_prologue.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: frame cache

[Paul Koning]

>>>>> "Michael" == Michael Eager <eager@eagercon.com> writes:

 Michael> Mark Kettenis wrote:
 >>  If that's the case, there's something wrong; prologue analysis
 >> should only be done as a last resort, i.e. when proper debug
 >> information is not available.
 >> 
 >> Your effort might be better spent on determining why proper debug
 >> info is not present instead of optimizing
 >> <target>_analyze_prologue().

 Michael> Perhaps so, I don't see where other targets check for debug
 Michael> info before calling analyze_prologue().  For example, on
 Michael> i386, i386_analyze_prologue() is called each and every time
 Michael> that i386_skip_prologue() is called.

I've run into other cases, with assembly language code in kernels.  It
may be that this could be cured by throwing in more magic assembly
language pseudo-ops.  Then again, I have a modified GDB that usees
prologue analysis to handle not just function calls, but also
interrupts and exceptions; this is quite handy in RTOS work.

	   paul

Re: frame cache

[Wenbo Yang]

Michael Eager wrote:

> Perhaps so, I don't see where other targets check for debug
> info before calling analyze_prologue().  For example, on i386,
> i386_analyze_prologue() is called each and every time that
> i386_skip_prologue() is called.

It depends on target . If you register dwarf2 frame sniffers to gdbarch, and 
your compiler can emit proper debugging information, gdb will not call 
analyze_prologue(). At least for our target(I did the porting), it works as 
Mark Kettenis said:
"prologue analysis should only be done as a last resort, i.e. when proper 
debug information is not available. "

> I don't see where there is any test in symtab.c or infrun.c
> which tests for debug info before calling SKIP_PROLOGUE which
> calls <target>_skip_prologue.

Because if you want to use debugging information to skip prologue, you write 
the code in this function. So, test should be place here in this function.

Wenbo
-- 
Wenbo Yang

The State Key Lab. of Information Security
Graduate School of CAS, 19A Yuquan Road, Beijing, China
Homepage: http://solrex.cn

SimpLight Nanoelectronics Ltd. 6 Zhichun Road, 10th Floor, Beijing, China
Phone: +86-10-5126-6989   ---  Email: wenbo.yang@simplnano.com

Re: frame cache

[Michael Eager]

Wenbo Yang wrote:
> Michael Eager wrote:
> 
>> Perhaps so, I don't see where other targets check for debug
>> info before calling analyze_prologue().  For example, on i386,
>> i386_analyze_prologue() is called each and every time that
>> i386_skip_prologue() is called.
> 
> It depends on target . If you register dwarf2 frame sniffers to gdbarch, 
> and your compiler can emit proper debugging information, gdb will not 
> call analyze_prologue(). At least for our target(I did the porting), it 
> works as Mark Kettenis said:
> "prologue analysis should only be done as a last resort, i.e. when 
> proper debug information is not available. "

Which target?

>> I don't see where there is any test in symtab.c or infrun.c
>> which tests for debug info before calling SKIP_PROLOGUE which
>> calls <target>_skip_prologue.
> 
> Because if you want to use debugging information to skip prologue, you 
> write the code in this function. So, test should be place here in this 
> function.

As I mentioned, in x86 or PowerPC there is no code to bypass analyzing
the prologue, even if there is debug info.  If prologue analysis is
truly to be done "only as a last resort", and I agree that this should
be the case, then this seems not to be represented in the gdb code.

If I've missed where this is done, feel free to point me at the correct
code.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: frame cache

[Mark Kettenis]

> Date: Mon, 30 Jul 2007 14:17:36 -0700
> From: Michael Eager <eager@eagercon.com>
> 
> >> I don't see where there is any test in symtab.c or infrun.c
> >> which tests for debug info before calling SKIP_PROLOGUE which
> >> calls <target>_skip_prologue.
> > 
> > Because if you want to use debugging information to skip prologue, you 
> > write the code in this function. So, test should be place here in this 
> > function.
> 
> As I mentioned, in x86 or PowerPC there is no code to bypass analyzing
> the prologue, even if there is debug info.  If prologue analysis is
> truly to be done "only as a last resort", and I agree that this should
> be the case, then this seems not to be represented in the gdb code.

In the context of the the frame cache, prologue analysis *is* only
done as a last resort for all targets that have DWARF CFI.  We have a
stack of unwinders, and run down that stack until we find an unwinder
that can handle a particular frame.  The unwinder that does the
prologue analysis comes last in that stack, after the DWARF unwinder.
So if there is DWARF CFI debug info for a frame, the prologue analysis
is never done.  Of course in practice you're probably running lots of
code that doesn't have debug info because many vendors install
stripped libraries.

Now on some targets we also do prologue analysis when placing a
breakpoint on a function.  In theory this should also be possible
using DWARF debug info, except that GCC doesn't (yet) provide that
information.  We used to do this using line number information (and on
some targets we still do that), but that became unreliable when the
compiler started to agressively reschedule prologue instructions.  And
then there were issues with the line number information generated by
GCC being wrong.  However, this is only done when setting breakpoints,
so it shouldn't really be happening that much, and therefore isn't
very performance critical.  It also doesn't really have anything to do
with the frame cache.

So I'm not really sure under which conditions you're observing the
excessive prologue analysis.  If you're seeing it during frame
unwinding, it might be worth investigating why the DWARF frame
unwinder doesn't handle things.  Perhaps you should consider
installing unstripped libraries, or seperate debug info for the
libraries on your system.  If you are seeing it when breakpoints get
set, it is probably worth working on getting GCC to emit the proper
debug info and implementing support for it in GDB.

Mark

Re: frame cache

[Wenbo Yang]

 > Michael Eager Wrote:
>> It depends on target . If you register dwarf2 frame sniffers to 
>> gdbarch, and your compiler can emit proper debugging information, gdb 
>> will not call analyze_prologue(). At least for our target(I did the 
>> porting), it works as Mark Kettenis said:
>> "prologue analysis should only be done as a last resort, i.e. when 
>> proper debug information is not available. "
> 
> Which target?

Our chip is still under development, so no target name published.

>> Because if you want to use debugging information to skip prologue, you 
>> write the code in this function. So, test should be place here in this 
>> function.
> 
> As I mentioned, in x86 or PowerPC there is no code to bypass analyzing
> the prologue, even if there is debug info.  If prologue analysis is
> truly to be done "only as a last resort", and I agree that this should
> be the case, then this seems not to be represented in the gdb code.
> 
> If I've missed where this is done, feel free to point me at the correct
> code.

I'm sorry I didn't find it too in x86. But x86 has many files, I'm not sure I 
have read through them. In mips-tdep.c, in mips_skip_prologue() , this 
function "skip_prologue_using_sal()" is using the debugging information, i.e. 
skip prologue using symbol and line. If x86 doesn't use debugging information, 
maybe it has some universal consideration on using it, e.g. some compiler 
can't emit proper debugging information. From my experience, if your compiler 
can't give all right debugging information, your debugging will encounter 
strange problems, what is worse than not using them(exclude the base info as 
symbols).

Regards,
Wenbo
-- 
Wenbo Yang

The State Key Lab. of Information Security
Graduate School of CAS, 19A Yuquan Road, Beijing, China
Homepage: http://solrex.cn

SimpLight Nanoelectronics Ltd. 6 Zhichun Road, 10th Floor, Beijing, China
Phone: +86-10-5126-6989   ---  Email: wenbo.yang@simplnano.com