[RFC] Prints the frame id when target stops

[RFC] Prints the frame id when target stops

[Denis PILAT]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

We are optimizing the usage of MI commands into our Eclipse based UI.
In some cases, it could take a while (and sometime more!) to refresh the 
thread list and the stack frame, and Eclipse does it very often.

We'd like to avoid refreshing the thread and the frame view when the 
user perform a step (or a next) and when the program stops in the same 
thread and in the same frame.
In the stop reason we got the current thread id, but we are missing 
something to identify the frame.
That patch lets gdb emits on the MI output a string that could be used 
to easily identify the current frame.
If you are ok with this approach then I'll update the testsuite.

-- 
Denis PILAT / STMicroelectronics



[-- Attachment #2: stack.c.patch --]
[-- Type: text/plain, Size: 1210 bytes --]

Index: stack.c
===================================================================
--- stack.c	(revision 549)
+++ stack.c	(working copy)
@@ -516,6 +516,8 @@ print_frame (struct frame_info *frame, i
   enum language funlang = language_unknown;
   struct ui_stream *stb;
   struct cleanup *old_chain, *list_chain;
+  struct frame_id this_frame_id;
+  char *frame_id_str = NULL;
 
   stb = ui_out_stream_new (uiout);
   old_chain = make_cleanup_ui_out_stream_delete (stb);
@@ -674,6 +676,16 @@ print_frame (struct frame_info *frame, i
 	}
     }
 
+  /* Print a string that represents the frame_id. This could be used by the UI
+     for comparison with the previous frame_id.  */
+  this_frame_id= get_frame_id (frame);
+  frame_id_str = xstrprintf ("%s,%s,%s",
+    (this_frame_id.stack_addr_p ? paddr (this_frame_id.stack_addr) : "!stack"),
+    (this_frame_id.code_addr_p ? paddr (this_frame_id.code_addr) : "!code"),
+    (this_frame_id.special_addr_p ? paddr (this_frame_id.special_addr) : "!special"));
+  ui_out_field_string (uiout, "frame_id", frame_id_str);
+  xfree (frame_id_str);
+
   /* do_cleanups will call ui_out_tuple_end() for us.  */
   do_cleanups (list_chain);
   ui_out_text (uiout, "\n");

Re: [RFC] Prints the frame id when target stops

[Nick Roberts]

 > We are optimizing the usage of MI commands into our Eclipse based UI.
 > In some cases, it could take a while (and sometime more!) to refresh the 
 > thread list and the stack frame, and Eclipse does it very often.
 > 
 > We'd like to avoid refreshing the thread and the frame view when the 
 > user perform a step (or a next) and when the program stops in the same 
 > thread and in the same frame.
 > In the stop reason we got the current thread id, but we are missing 
 > something to identify the frame.
 > That patch lets gdb emits on the MI output a string that could be used 
 > to easily identify the current frame.



  frame_id_str = xstrprintf ("%s,%s,%s",
                             ^^^^^^^^^^

"%x,%x,%x" ?  (Except this would break when paddr returned 0, so it
needs a bit more detail).

(this_frame_id.stack_addr_p ? paddr (this_frame_id.stack_addr) : "!stack"),
                                                                   ^^^^^^
(this_frame_id.code_addr_p ? paddr (this_frame_id.code_addr) : "!code"),
                                                                 ^^^^^
(this_frame_id.special_addr_p ? paddr (this_frame_id.special_addr) : "!special"
                                                                      ^^^^^^^^
"false" ?

Why not include it in the frame field e.g

*stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x08048520",id="0xbfd4e620,0x08048509,!special",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbf8a5854"}],file="myprog.c",fullname="/home/nickrob/myprog.c",line="79"}

Or even

*stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x08048520",id={stack="0xbfd4e620,code=0x08048509,special="false"},func="main",args=[{name="argc",value="1"},{name="argv",value="0xbf8a5854"}],file="myprog.c",fullname="/home/nickrob/myprog.c",line="79"}

If this field is included in other output e.g -stack-info-frame, then maybe
a separate function would be a good idea.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFC] Prints the frame id when target stops

[Nick Roberts]

 >   frame_id_str = xstrprintf ("%s,%s,%s",
 >                              ^^^^^^^^^^
 > 
 > "%x,%x,%x" ?  (Except this would break when paddr returned 0, so it
 > needs a bit more detail).

I mean this_frame_id.*_p is 0.

 >...
 > If this field is included in other output e.g -stack-info-frame, then maybe
 > a separate function would be a good idea.

Forget this, I see these functions use print_frame anyway.

Also it looks like you can't use ui_out_field_string as it prints CLI output
also (when execeution stop, "info threads" etc).  Perhaps ui_out_field_stream
does what you need.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFC] Prints the frame id when target stops

[Nick Roberts]

 > Also it looks like you can't use ui_out_field_string as it prints CLI output
 > also (when execeution stop, "info threads" etc).  Perhaps ui_out_field_stream
 > does what you need.

Or, more likely, wrap it in:

      if (ui_out_is_mi_like_p (uiout))
        {
          ...
        }

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFC] Prints the frame id when target stops

[Denis PILAT]

Nick Roberts wrote:
>  > Also it looks like you can't use ui_out_field_string as it prints CLI output
>  > also (when execeution stop, "info threads" etc).  Perhaps ui_out_field_stream
>  > does what you need.
>
> Or, more likely, wrap it in:
>
>       if (ui_out_is_mi_like_p (uiout))
>         {
>           ...
>         }
>
>   
You're right, my patch do much more printing than I expected.
I don't want to modify behavior of too much commands.

According to last discussion it seems to be hard to cache information 
returned by -stack-list-frame, may be we could print this frame id 
information
when the program stop only if stop reason is step or next.
Then it's up to the front end to be clever not refreshing the stack frame.

Denis

Re: [RFC] Prints the frame id when target stops

[Vladimir Prus]

Denis PILAT wrote:

> We are optimizing the usage of MI commands into our Eclipse based UI.
> In some cases, it could take a while (and sometime more!) to refresh the
> thread list and the stack frame, and Eclipse does it very often.
> 
> We'd like to avoid refreshing the thread and the frame view when the
> user perform a step (or a next) and when the program stops in the same
> thread and in the same frame.
> In the stop reason we got the current thread id, but we are missing
> something to identify the frame.
> That patch lets gdb emits on the MI output a string that could be used
> to easily identify the current frame.
> If you are ok with this approach then I'll update the testsuite.

Would not a better approach be to modify -stack-list-frames and friends,
so that they check frame id internally, and it has not changed, just
return the same result? Such approach will uniformly help all frontends,
and won't expose new concepts in the interface.

- Volodya

Re: [RFC] Prints the frame id when target stops

[Nick Roberts]

 > > We'd like to avoid refreshing the thread and the frame view when the user
 > > perform a step (or a next) and when the program stops in the same thread
 > > and in the same frame.  In the stop reason we got the current thread id,
 > > but we are missing something to identify the frame.  That patch lets gdb
 > > emits on the MI output a string that could be used to easily identify the
 > > current frame.  If you are ok with this approach then I'll update the
 > > testsuite.
 > 
 > Would not a better approach be to modify -stack-list-frames and friends,
 > so that they check frame id internally, and it has not changed, just
 > return the same result? Such approach will uniformly help all frontends,
 > and won't expose new concepts in the interface.

It would change the behviour of those commands but I guess it could be added
as an option.  I started looking at the frame ID to detect when the stack
changed in:

http://sourceware.org/ml/gdb/2006-06/msg00162.html

but Daniel J said:

  DJ> You can encounter the same frame ID for two consecutive stops
  DJ> but have a different backtrace, e.g. if you continued and then
  DJ> hit a breakpoint near the same function.

More recently I looked at Apple's approach which seems to just add a hook
in select_frame:

http://sourceware.org/ml/gdb-patches/2007-01/msg00037.html

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFC] Prints the frame id when target stops

[Vladimir Prus]

On Wednesday 17 January 2007 00:12, Nick Roberts wrote:
>  > > We'd like to avoid refreshing the thread and the frame view when the user
>  > > perform a step (or a next) and when the program stops in the same thread
>  > > and in the same frame.  In the stop reason we got the current thread id,
>  > > but we are missing something to identify the frame.  That patch lets gdb
>  > > emits on the MI output a string that could be used to easily identify the
>  > > current frame.  If you are ok with this approach then I'll update the
>  > > testsuite.
>  > 
>  > Would not a better approach be to modify -stack-list-frames and friends,
>  > so that they check frame id internally, and it has not changed, just
>  > return the same result? Such approach will uniformly help all frontends,
>  > and won't expose new concepts in the interface.
> 
> It would change the behviour of those commands but I guess it could be added
> as an option.  

It actually won't. If -stack-list-frames is changed to return cached result
when it's absolutely clear that the stack did not change, you have no behaviour
change, just better performance.

- Volodya

Re: [RFC] Prints the frame id when target stops

[Daniel Jacobowitz]

On Wed, Jan 17, 2007 at 02:34:34AM +0300, Vladimir Prus wrote:
> On Wednesday 17 January 2007 00:12, Nick Roberts wrote:
> >  > > We'd like to avoid refreshing the thread and the frame view when the user
> >  > > perform a step (or a next) and when the program stops in the same thread
> >  > > and in the same frame.  In the stop reason we got the current thread id,
> >  > > but we are missing something to identify the frame.  That patch lets gdb
> >  > > emits on the MI output a string that could be used to easily identify the
> >  > > current frame.  If you are ok with this approach then I'll update the
> >  > > testsuite.
> >  > 
> >  > Would not a better approach be to modify -stack-list-frames and friends,
> >  > so that they check frame id internally, and it has not changed, just
> >  > return the same result? Such approach will uniformly help all frontends,
> >  > and won't expose new concepts in the interface.
> > 
> > It would change the behviour of those commands but I guess it could be added
> > as an option.  
> 
> It actually won't. If -stack-list-frames is changed to return cached result
> when it's absolutely clear that the stack did not change, you have no behaviour
> change, just better performance.

But Nick is right - it is very hard to determine whether two frames
with the same frame ID are the same frame across an operation.  It'd be
nice if that weren't the case.  The hard case for this is unfortunately
very hard - but if the front end knows that it did a single step, then
it's very unlikely to be wrong if the ID is unchanged.  I really don't
know what the right thing to do here is.  Guessing based on what the
last execution was (step, next, vs continue or C-c) might be the best
we can do :-(

Here's how it can happen:

int foo()
{
  return 1;
}

int bar()
{
  char buf[SIZE1];
  return foo();
}

int bar2()
{
  char buf[SIZE2];
  return foo();
}

int bar3()
{
  char buf[SIZE3];
  return bar2();
}

int main()
{
  bar();
  bar3();
}

The backtrace is different in an interesting way here if you set a
breakpoint on foo and continue twice, but if you choose your buffer
sizes just right, then you can get the two calls to foo to have the
same ID.  If your IDE doesn't refresh its stack display, you're
going to have a stale call trace.

Apple implemented a very high performance, light weight unwinder that
just does frame IDs - on PPC this happens to be quite easy.  We could
make other targets do the same thing.  That probably helps here.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Prints the frame id when target stops

[Vladimir Prus]

Daniel Jacobowitz wrote:

>> > It would change the behviour of those commands but I guess it could be
>> > added as an option.
>> 
>> It actually won't. If -stack-list-frames is changed to return cached
>> result when it's absolutely clear that the stack did not change, you have
>> no behaviour change, just better performance.
> 
> But Nick is right - it is very hard to determine whether two frames
> with the same frame ID are the same frame across an operation.  

Yes. But:
1. We can regenerate stack frames list when not sure.
2. It's not easier for frontend than it is for gdb.

> It'd be 
> nice if that weren't the case.  The hard case for this is unfortunately
> very hard - but if the front end knows that it did a single step, then
> it's very unlikely to be wrong if the ID is unchanged.  

Oh, if the frontend knows it did just a single "-exec-step", then
gdb knows it too.

> I really don't 
> know what the right thing to do here is.  Guessing based on what the
> last execution was (step, next, vs continue or C-c) might be the best
> we can do :-(
> 
> Here's how it can happen:
> 
> int foo()
> {
>   return 1;
> }
> 
> int bar()
> {
>   char buf[SIZE1];
>   return foo();
> }
> 
> int bar2()
> {
>   char buf[SIZE2];
>   return foo();
> }
> 
> int bar3()
> {
>   char buf[SIZE3];
>   return bar2();
> }
> 
> int main()
> {
>   bar();
>   bar3();
> }
> 
> The backtrace is different in an interesting way here if you set a
> breakpoint on foo and continue twice, but if you choose your buffer
> sizes just right, then you can get the two calls to foo to have the
> same ID.  If your IDE doesn't refresh its stack display, you're
> going to have a stale call trace.

Yes, that's an obvious problem. What makes you think a frontend
is in better position to fix it?

> Apple implemented a very high performance, light weight unwinder that
> just does frame IDs - on PPC this happens to be quite easy.  We could
> make other targets do the same thing.  That probably helps here.

Just to clarify -- you mean you don't get any function names or
code lines so you don't have to look in the symbol tables? And
if this backtrace changes you can get the full backtrace.

- Volodya

Re: [RFC] Prints the frame id when target stops

[Daniel Jacobowitz]

On Thu, Jan 18, 2007 at 12:46:11AM +0300, Vladimir Prus wrote:
> > The backtrace is different in an interesting way here if you set a
> > breakpoint on foo and continue twice, but if you choose your buffer
> > sizes just right, then you can get the two calls to foo to have the
> > same ID.  If your IDE doesn't refresh its stack display, you're
> > going to have a stale call trace.
> 
> Yes, that's an obvious problem. What makes you think a frontend
> is in better position to fix it?

I don't.  Sorry if I was unclear.

> > Apple implemented a very high performance, light weight unwinder that
> > just does frame IDs - on PPC this happens to be quite easy.  We could
> > make other targets do the same thing.  That probably helps here.
> 
> Just to clarify -- you mean you don't get any function names or
> code lines so you don't have to look in the symbol tables? And
> if this backtrace changes you can get the full backtrace.

Well, you might have to look in the symbol table anyway - I'm not sure
how many shortcuts they take, but normally you'd still need to know
where the start of functions were.  But you don't need line numbers or
other saved registers.  I suspect they just rely on the PPC ABI frame
convention, which is very quick to unwind.  You can do the same thing
more flexibly by caching the result of a prologue analyzer, too.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Prints the frame id when target stops

[Mark Kettenis]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Wed, 17 Jan 2007 02:34:34 +0300
> 
> On Wednesday 17 January 2007 00:12, Nick Roberts wrote:
> >  > > We'd like to avoid refreshing the thread and the frame view when the user
> >  > > perform a step (or a next) and when the program stops in the same thread
> >  > > and in the same frame.  In the stop reason we got the current thread id,
> >  > > but we are missing something to identify the frame.  That patch lets gdb
> >  > > emits on the MI output a string that could be used to easily identify the
> >  > > current frame.  If you are ok with this approach then I'll update the
> >  > > testsuite.
> >  > 
> >  > Would not a better approach be to modify -stack-list-frames and friends,
> >  > so that they check frame id internally, and it has not changed, just
> >  > return the same result? Such approach will uniformly help all frontends,
> >  > and won't expose new concepts in the interface.
> > 
> > It would change the behviour of those commands but I guess it could be added
> > as an option.  
> 
> It actually won't. If -stack-list-frames is changed to return cached
> result when it's absolutely clear that the stack did not change, you
> have no behaviour change, just better performance.

Unforunately, making absolutely sure the stack did not change may not
be possible.

Mark

Re: [RFC] Prints the frame id when target stops

[Vladimir Prus]

Mark Kettenis wrote:

>> From: Vladimir Prus <ghost@cs.msu.su>
>> Date: Wed, 17 Jan 2007 02:34:34 +0300
>> 
>> On Wednesday 17 January 2007 00:12, Nick Roberts wrote:
>> >  > > We'd like to avoid refreshing the thread and the frame view when
>> >  > > the user perform a step (or a next) and when the program stops in
>> >  > > the same thread
>> >  > > and in the same frame.  In the stop reason we got the current
>> >  > > thread id,
>> >  > > but we are missing something to identify the frame.  That patch
>> >  > > lets gdb emits on the MI output a string that could be used to
>> >  > > easily identify the
>> >  > > current frame.  If you are ok with this approach then I'll update
>> >  > > the testsuite.
>> >  > 
>> >  > Would not a better approach be to modify -stack-list-frames and
>> >  > friends, so that they check frame id internally, and it has not
>> >  > changed, just return the same result? Such approach will uniformly
>> >  > help all frontends, and won't expose new concepts in the interface.
>> > 
>> > It would change the behviour of those commands but I guess it could be
>> > added as an option.
>> 
>> It actually won't. If -stack-list-frames is changed to return cached
>> result when it's absolutely clear that the stack did not change, you
>> have no behaviour change, just better performance.
> 
> Unforunately, making absolutely sure the stack did not change may not
> be possible.

Are you sure? For example, if the only command since previous 
-stack-list-frames was -exec-step, then the stack is the same.

For the cases where we're not sure, gdb can discard cached value
and produce new.

The thing is, if the frontend tries to compare old frame id to
new frame id, and skip -stack-list-frames if they are equal,
it's not going to be any more reliable than doing similar check
in gdb. And in gdb, we can have better checks.

- Volodya

Re: [RFC] Prints the frame id when target stops

[Frédéric Riss]

Le jeudi 18 janvier 2007 à 00:37 +0300, Vladimir Prus a écrit :
> >> It actually won't. If -stack-list-frames is changed to return cached
> >> result when it's absolutely clear that the stack did not change, you
> >> have no behaviour change, just better performance.
> > 
> > Unforunately, making absolutely sure the stack did not change may not
> > be possible.
> 
> Are you sure? For example, if the only command since previous 
> -stack-list-frames was -exec-step, then the stack is the same.
> 
> For the cases where we're not sure, gdb can discard cached value
> and produce new.
> 
> The thing is, if the frontend tries to compare old frame id to
> new frame id, and skip -stack-list-frames if they are equal,
> it's not going to be any more reliable than doing similar check
> in gdb. And in gdb, we can have better checks.

Have you an idea how you would like the caching to work? Do you mean not
discarding the frame cache, or caching the returned string?

If you want the first approach (keep the frame cache), then this is
quite an intrusive change. It would also require keeping a frame cache
per-thread and not as a global like it's done now.

If you just want to cache the result of -stack-list-frames, then you'd
have to edit out the addr field which contains the frame's PC for the
top frame... not very nice.

Also, I don't see how we could have better checks within GDB than within
the frontend. The only reliable check is IMHO to compare frame ids after
steps and nexts. Any other execution control command requires to
re-unwind the whole stack. This check seems to be as reliable in the
frontend as in GDB.

I agree with your point though: making -stack-list-frames as fast as
possible would benefit all frontends. However, it seems hard to modify
GDB's frame handling to handle that correctly.

Fred.

Re: [RFC] Prints the frame id when target stops

[Vladimir Prus]

On Thursday 18 January 2007 00:59, Frédéric Riss wrote:
> Le jeudi 18 janvier 2007 à 00:37 +0300, Vladimir Prus a écrit :
> > >> It actually won't. If -stack-list-frames is changed to return cached
> > >> result when it's absolutely clear that the stack did not change, you
> > >> have no behaviour change, just better performance.
> > > 
> > > Unforunately, making absolutely sure the stack did not change may not
> > > be possible.
> > 
> > Are you sure? For example, if the only command since previous 
> > -stack-list-frames was -exec-step, then the stack is the same.
> > 
> > For the cases where we're not sure, gdb can discard cached value
> > and produce new.
> > 
> > The thing is, if the frontend tries to compare old frame id to
> > new frame id, and skip -stack-list-frames if they are equal,
> > it's not going to be any more reliable than doing similar check
> > in gdb. And in gdb, we can have better checks.
> 
> Have you an idea how you would like the caching to work? Do you mean not
> discarding the frame cache, or caching the returned string?
> 
> If you want the first approach (keep the frame cache), then this is
> quite an intrusive change. It would also require keeping a frame cache
> per-thread and not as a global like it's done now.

No, I don't have the slightest inclination to touch that.

> If you just want to cache the result of -stack-list-frames, then you'd
> have to edit out the addr field which contains the frame's PC for the
> top frame... not very nice.

Or introduce 'struct cached_result_of_stack_list_frames' that
can contain whatever I like and which can be conveniently edited.

You've actually pointed a nice problem -- if frontend avoid -stack-list-frames
when frame id did not change, it will have stale address of the top frame too.

> Also, I don't see how we could have better checks within GDB than within
> the frontend. The only reliable check is IMHO to compare frame ids after
> steps and nexts. Any other execution control command requires to
> re-unwind the whole stack. This check seems to be as reliable in the
> frontend as in GDB.

GDB always knows that it does a step. A frontend might be sending
a command typed by the user, and that might be user-defined command,
and there's no way to tell if there's step in that command.

> I agree with your point though: making -stack-list-frames as fast as
> possible would benefit all frontends. However, it seems hard to modify
> GDB's frame handling to handle that correctly.

I think there are some simple optimizations we might make.

- Volodya

Re: [RFC] Prints the frame id when target stops

[Frederic RISS]

On Thu, 2007-01-18 at 01:14 +0300, Vladimir Prus wrote:
> On Thursday 18 January 2007 00:59, Frédéric Riss wrote:
> > If you just want to cache the result of -stack-list-frames, then you'd
> > have to edit out the addr field which contains the frame's PC for the
> > top frame... not very nice.
> 
> Or introduce 'struct cached_result_of_stack_list_frames' that
> can contain whatever I like and which can be conveniently edited.
> 
> You've actually pointed a nice problem -- if frontend avoid -stack-list-frames
> when frame id did not change, it will have stale address of the top frame too.

Well, the frontend might not care about the exact PC (which it'll get
anyway in the stop reason? can't remember), or it can request only the
top frame which is basically free.

Fred.

Re: [RFC] Prints the frame id when target stops

[Daniel Jacobowitz]

On Wed, Jan 17, 2007 at 10:59:13PM +0100, Frédéric Riss wrote:
> Have you an idea how you would like the caching to work? Do you mean not
> discarding the frame cache, or caching the returned string?

How much do we know about why it takes a long time?

For instance:
  - We can speed up the psymtab lookup which currently shows up in
    profiles.  A coworker of mine gave me some clever ideas on how
    to do this if anyone wants to try it :-)

  - We can speed up prologue analyzers by judicious use of caching,
    in a way that's completely reliable.  DWARF2 CFI is already pretty
    speedy.

If these sorts of things are enough to help...

> Also, I don't see how we could have better checks within GDB than within
> the frontend. The only reliable check is IMHO to compare frame ids after
> steps and nexts.

I suspect you can only do this in stepi, really - step/next can end up
in strange places...

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Prints the frame id when target stops

[Frederic RISS]

On Wed, 2007-01-17 at 17:17 -0500, Daniel Jacobowitz wrote:
> On Wed, Jan 17, 2007 at 10:59:13PM +0100, Frédéric Riss wrote:
> > Have you an idea how you would like the caching to work? Do you mean not
> > discarding the frame cache, or caching the returned string?
> 
> How much do we know about why it takes a long time?

Very good question :-) In Denis' case, he's using a JTAG link driven by
a probe which is in turn connected through ethernet to the workstation
where GDB is running.

I'm quite sure that the latencies at each memory access are what's
taking time, because the unwinding doesn't require any complex handling
other than retrieving the saved frame pointer (and there's no prolog
analysis going on). IIRC, -stack-list-frames was taking an average of
half a second to complete.

> For instance:
>   - We can speed up the psymtab lookup which currently shows up in
>     profiles.  A coworker of mine gave me some clever ideas on how
>     to do this if anyone wants to try it :-)

Hehe. What's the idea? maybe someone will pick it up.

>   - We can speed up prologue analyzers by judicious use of caching,
>     in a way that's completely reliable.  DWARF2 CFI is already pretty
>     speedy.
> 
> If these sorts of things are enough to help...
> 
> > Also, I don't see how we could have better checks within GDB than within
> > the frontend. The only reliable check is IMHO to compare frame ids after
> > steps and nexts.
> 
> I suspect you can only do this in stepi, really - step/next can end up
> in strange places...

... and end up in a frame with the same frame id? Seems unlikely, but
then GDB isn't the place where you'd want to trade accuracy for a very
small speedup.

Fred.

Re: [RFC] Prints the frame id when target stops

[Jim Blandy]

Frederic RISS <frederic.riss@st.com> writes:
>> I suspect you can only do this in stepi, really - step/next can end up
>> in strange places...
>
> ... and end up in a frame with the same frame id? Seems unlikely, but
> then GDB isn't the place where you'd want to trade accuracy for a very
> small speedup.

Yeah --- I'd be very concerned about GDB performance optimizations
that would cause GDB to not notice, say, corruptions of the stack by
buffer overruns.

If it's common for memory reads to be so expensive, you should buy a
better JTAG unit^W^W^W^W^W^W^W I'd rather we work on minimizing memory
accesses by unwinders than make assumptions which may not hold in
buggy programs.

Could you enable 'debug remote' while it's doing the unwinding, and
figure out what it's actually fetching?

Re: [RFC] Prints the frame id when target stops

[Denis PILAT]

Jim Blandy wrote:
> Frederic RISS <frederic.riss@st.com> writes:
>   
>>> I suspect you can only do this in stepi, really - step/next can end up
>>> in strange places...
>>>       
>> ... and end up in a frame with the same frame id? Seems unlikely, but
>> then GDB isn't the place where you'd want to trade accuracy for a very
>> small speedup.
>>     
>
> Yeah --- I'd be very concerned about GDB performance optimizations
> that would cause GDB to not notice, say, corruptions of the stack by
> buffer overruns.
>
> If it's common for memory reads to be so expensive, you should buy a
> better JTAG unit^W^W^W^W^W^W^W I'd rather we work on minimizing memory
> accesses by unwinders than make assumptions which may not hold in
> buggy programs.
>
> Could you enable 'debug remote' while it's doing the unwinding, and
> figure out what it's actually fetching?
>
>   
Our configuration does not use remote protocol, but our own protocol.
If we talk about enhancing memory access, yes we'll try to reduce the 
number of memory accesses done by our unwinders, Fred is working on that.
 
As there is no consensus to modify the -stack-list-frames to perform 
cache in a safe way, putting the frame_id (like discussed before) in the 
MI output allows the front end to make a compromise that isn't possible 
in GDB, and for some cases, the front end will be able to not get the 
stack list frame at all.

-- 
Denis

Re: [RFC] Prints the frame id when target stops

[Daniel Jacobowitz]

On Fri, Jan 19, 2007 at 03:27:44PM +0100, Denis PILAT wrote:
> As there is no consensus to modify the -stack-list-frames to perform 
> cache in a safe way, putting the frame_id (like discussed before) in the 
> MI output allows the front end to make a compromise that isn't possible 
> in GDB, and for some cases, the front end will be able to not get the 
> stack list frame at all.

I understand that front end authors may want to make compromises that
we, the GDB developers, don't (in order to improve performance). 
However, I don't want to provide an interface that looks simple
but carries these kinds of pitfalls if I can avoid it.

Maybe you can use Nick's MI timings patch, or a system profiler like
oprofile / vtune, to get some better idea of where time is being spent.
If we can make things fast enough, we should.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Prints the frame id when target stops

[Daniel Jacobowitz]

On Thu, Jan 18, 2007 at 08:57:40AM +0100, Frederic RISS wrote:
> > For instance:
> >   - We can speed up the psymtab lookup which currently shows up in
> >     profiles.  A coworker of mine gave me some clever ideas on how
> >     to do this if anyone wants to try it :-)
> 
> Hehe. What's the idea? maybe someone will pick it up.

Rouhly speaking, recording all of the intervals covered by psymbols
on a per objfile basis.  If you avoid using the faster lookup mechanism
in the presence of overlays, you can assume a single best symbol
covering each address and roughly non-overlapping (but not quite).

It's just going to be a matter of slogging through it.  I expect we'd
get a bunch of splay trees.

On Thu, Jan 18, 2007 at 10:34:39AM -0800, Jim Blandy wrote:
> Yeah --- I'd be very concerned about GDB performance optimizations
> that would cause GDB to not notice, say, corruptions of the stack by
> buffer overruns.

Absolutely.  As fast as possible, but no faster :-)

> Could you enable 'debug remote' while it's doing the unwinding, and
> figure out what it's actually fetching?

Yes please.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Prints the frame id when target stops

[Daniel Jacobowitz]

On Wed, Jan 17, 2007 at 10:12:40AM +1300, Nick Roberts wrote:
> More recently I looked at Apple's approach which seems to just add a hook
> in select_frame:
> 
> http://sourceware.org/ml/gdb-patches/2007-01/msg00037.html

I think that's actually their solution to a different problem than this
one.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Prints the frame id when target stops

[Nick Roberts]

 > > More recently I looked at Apple's approach which seems to just add a hook
 > > in select_frame:
 > > 
 > > http://sourceware.org/ml/gdb-patches/2007-01/msg00037.html
 > 
 > I think that's actually their solution to a different problem than this
 > one.

They have two hooks; the above one is just to see if the frame has changed and
tells you if the locals window needs updating, for example.  In the example you
give, I think the frame has not changed but the stack has.  They have another
hook for detecting when the stack has changed which gets set in return_command
and normal_stop.  This latter location uses frame_id_eq so maybe it will fail
for your example (Perhaps it works for Apple, if they have their own unwinder,
although at this point I don't really know what I'm talking about).


-- 
Nick                                           http://www.inet.net.nz/~nickrob