[PATCH] -stack-info-frame/-stack-list-frames

[PATCH] -stack-info-frame/-stack-list-frames

[Nick Roberts]

Here's a patch to add the frame address to the output of -stack-info-frame and
-stack-list-frames and async output when execution stops.  It also outputs the
source language for -stack-info-frame, these change making it more like "info
frame":

-exec-run
^running
(gdb) 
*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",thread-id="1",frame={addr="0x08048539",frame_addr="0xbfa67af0",func="mysquare",args=[{name="x",value="8"}],file="myprog.c",fullname="/home/nickrob/myprog.c",line="67"}
(gdb) 
-stack-list-frames
^done,stack=[frame={level="0",addr="0x08048539",frame_addr="0xbfa67af0",func="mysquare",file="myprog.c",fullname="/home/nickrob/myprog.c",line="67"},frame={level="1",addr="0x08048753",frame_addr="0xbfa68ba0",func="main",file="myprog.c",fullname="/home/nickrob/myprog.c",line="176"}]
(gdb) 
-stack-info-frame
^done,frame={level="0",addr="0x08048539",frame_addr="0xbfa67af0",func="mysquare",file="myprog.c",fullname="/home/nickrob/myprog.c",line="67"},lang="c"
(gdb) 


I'll provide test and documentation patches when this change is approved in
principle.


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


2008-04-23  Nick Roberts  <nickrob@snap.net.nz>

	* mi/mi-cmd-stack.c (mi_cmd_stack_info_frame): Add "lang" field
	for source language of frame.

	* stack.c (print_frame_info): Add field for frame address.

	* Makefile.in (stack.o): Add dependency on language.h.


*** mi-cmd-stack.c.~1.35.~	2008-01-10 01:45:14.000000000 +1300
--- mi-cmd-stack.c	2008-04-23 15:35:28.000000000 +1200
***************
*** 29,34 ****
--- 29,35 ----
  #include "stack.h"
  #include "dictionary.h"
  #include "gdb_string.h"
+ #include "language.h"
  
  static void list_args_or_locals (int locals, int values, struct frame_info *fi);
  
*************** mi_cmd_stack_select_frame (char *command
*** 335,343 ****
  enum mi_cmd_result
  mi_cmd_stack_info_frame (char *command, char **argv, int argc)
  {
    if (argc > 0)
      error (_("mi_cmd_stack_info_frame: No arguments required"));
    
!   print_frame_info (get_selected_frame (NULL), 1, LOC_AND_ADDRESS, 0);
    return MI_CMD_DONE;
  }
--- 336,352 ----
  enum mi_cmd_result
  mi_cmd_stack_info_frame (char *command, char **argv, int argc)
  {
+   struct frame_info *fi;
+   struct symtab *s;
+   
    if (argc > 0)
      error (_("mi_cmd_stack_info_frame: No arguments required"));
    
!   fi = get_selected_frame (NULL);
!   print_frame_info (fi, 1, LOC_AND_ADDRESS, 0);
! 
!   s = find_pc_symtab (get_frame_pc (fi));
!   ui_out_field_string (uiout, "lang", language_str (s->language));
! 
    return MI_CMD_DONE;
  }


*** stack.c.~1.165~	2008-04-23 15:49:32.000000000 +1200
--- stack.c	2008-04-23 15:32:09.000000000 +1200
*************** print_frame_info (struct frame_info *fra
*** 482,487 ****
--- 482,488 ----
            annotate_frame_address ();
            ui_out_field_core_addr (uiout, "addr", get_frame_pc (frame));
            annotate_frame_address_end ();
+ 	  ui_out_field_core_addr (uiout, "frame_addr", get_frame_base (frame));
          }
  
        if (get_frame_type (frame) == DUMMY_FRAME)
*************** print_frame_info (struct frame_info *fra
*** 546,551 ****
--- 547,555 ----
  	      if (addressprint && mid_statement)
  		{
  		  ui_out_field_core_addr (uiout, "addr", get_frame_pc (frame));
+ 		  if (ui_out_is_mi_like_p (uiout))
+ 		    ui_out_field_core_addr (uiout, "frame_addr",
+ 					    get_frame_base (frame));
  		  ui_out_text (uiout, "\t");
  		}
  
*************** print_frame (struct frame_info *frame, i
*** 670,675 ****
--- 674,681 ----
  	annotate_frame_address ();
  	ui_out_field_core_addr (uiout, "addr", get_frame_pc (frame));
  	annotate_frame_address_end ();
+ 	if (ui_out_is_mi_like_p (uiout))
+ 	  ui_out_field_core_addr (uiout, "frame_addr", get_frame_base (frame));
  	ui_out_text (uiout, " in ");
        }
    annotate_frame_function_name ();

*** Makefile.in.~1.1002.~	2008-04-19 18:03:52.000000000 +1200
--- Makefile.in	2008-04-23 15:39:52.000000000 +1200
*************** stack.o: stack.c $(defs_h) $(value_h) $(
*** 2867,2873 ****
  	$(target_h) $(source_h) $(breakpoint_h) $(demangle_h) $(inferior_h) \
  	$(annotate_h) $(ui_out_h) $(block_h) $(stack_h) $(dictionary_h) \
  	$(exceptions_h) $(reggroups_h) $(regcache_h) $(solib_h) \
! 	$(valprint_h) $(gdb_assert_h) $(gdb_string_h)
  std-regs.o: std-regs.c $(defs_h) $(user_regs_h) $(frame_h) $(gdbtypes_h) \
  	$(value_h) $(gdb_string_h)
  symfile.o: symfile.c $(defs_h) $(bfdlink_h) $(symtab_h) $(gdbtypes_h) \
--- 2867,2873 ----
  	$(target_h) $(source_h) $(breakpoint_h) $(demangle_h) $(inferior_h) \
  	$(annotate_h) $(ui_out_h) $(block_h) $(stack_h) $(dictionary_h) \
  	$(exceptions_h) $(reggroups_h) $(regcache_h) $(solib_h) \
! 	$(valprint_h) $(gdb_assert_h) $(gdb_string_h) $(language_h)
  std-regs.o: std-regs.c $(defs_h) $(user_regs_h) $(frame_h) $(gdbtypes_h) \
  	$(value_h) $(gdb_string_h)
  symfile.o: symfile.c $(defs_h) $(bfdlink_h) $(symtab_h) $(gdbtypes_h) \

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Vladimir Prus]

Nick Roberts wrote:

> 
> Here's a patch to add the frame address to the output of -stack-info-frame and
> -stack-list-frames and async output when execution stops.  It also outputs the
> source language for -stack-info-frame, these change making it more like "info
> frame":

Could you first clarify that is the purpose of said fields -- especially
frame address?

- Volodya

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Nick Roberts]

 > > Here's a patch to add the frame address to the output of -stack-info-frame
 > > and -stack-list-frames and async output when execution stops.  It also
 > > outputs the source language for -stack-info-frame, these change making it
 > > more like "info frame":
 > 
 > Could you first clarify that is the purpose of said fields -- especially
 > frame address?

The frame address is probably of more interest than the pc address, at least
for frames other than the current one.  If the call stack includes the frame
address for each frame and the watch window gives the variable's address
then it is possible to infer to which frame that variable belongs.  In any
case, the extra field comes at almost no cost and a frontend can choose to
ignore it.

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

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Vladimir Prus]

On Wednesday 23 April 2008 09:03:10 Nick Roberts wrote:
>  > > Here's a patch to add the frame address to the output of -stack-info-frame
>  > > and -stack-list-frames and async output when execution stops.  It also
>  > > outputs the source language for -stack-info-frame, these change making it
>  > > more like "info frame":
>  > 
>  > Could you first clarify that is the purpose of said fields -- especially
>  > frame address?
> 
> The frame address is probably of more interest than the pc address, at least
> for frames other than the current one.  If the call stack includes the frame
> address for each frame and the watch window gives the variable's address
> then it is possible to infer to which frame that variable belongs.

What do you mean by "watch window" here, and how the information about frame a variable
belongs to is useful? 

> In any 
> case, the extra field comes at almost no cost and a frontend can choose to
> ignore it.

I supposed you don't plan to write documentation that say "these fields are just
in case you need them, feel free to ignore"? I'm trying to understand what is
*your* intended use of this information, so that I can make up my mind as to best
way to do that. We talked about frame ids before, I think Dan prefers frame ids,
if exposed, to be totally opaque. You appear to suggest some smart uses of 
frame addresses, on the other hand, and I don't understand exactly what uses.

- Volodya

 

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Nick Roberts]

 > > The frame address is probably of more interest than the pc address, at
 > > least for frames other than the current one.  If the call stack includes
 > > the frame address for each frame and the watch window gives the variable's
 > > address then it is possible to infer to which frame that variable belongs.
 > 
 > What do you mean by "watch window" here, and how the information about frame
 > a variable belongs to is useful?

I mean the window showing a variable's value (represented in Gdb as a variable
object).

 > > In any case, the extra field comes at almost no cost and a frontend can
 > > choose to ignore it.
 > 
 > I supposed you don't plan to write documentation that say "these fields are
 > just in case you need them, feel free to ignore"? 

Not really because that applies equally to all the other fields, already
present, that a front end might not use.

 >                                                  I'm trying to understand
 > what is *your* intended use of this information, so that I can make up my
 > mind as to best way to do that. We talked about frame ids before, I think
 > Dan prefers frame ids, if exposed, to be totally opaque. You appear to
 > suggest some smart uses of frame addresses, on the other hand, and I don't
 > understand exactly what uses.

I'm just intending to present the frame address to the user to help him
understand what he's looking at, not use it as a frame id in any rigorous way.
I see that the Totalview debugger presents this information in their call stack
(which they call stack trace) window and I think this would be useful, for the
reason, I've given too.

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

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Vladimir Prus]

On Wednesday 23 April 2008 12:52:52 you wrote:
>  > > The frame address is probably of more interest than the pc address, at
>  > > least for frames other than the current one.  If the call stack includes
>  > > the frame address for each frame and the watch window gives the variable's
>  > > address then it is possible to infer to which frame that variable belongs.
>  > 
>  > What do you mean by "watch window" here, and how the information about frame
>  > a variable belongs to is useful?
> 
> I mean the window showing a variable's value (represented in Gdb as a variable
> object).

Does that window shows:

1. Value of variable named XXX in the frame where that variable was
added to the window?
2. Value of variable named XXX in the current frame
3. Something else?

> 
>  > > In any case, the extra field comes at almost no cost and a frontend can
>  > > choose to ignore it.
>  > 
>  > I supposed you don't plan to write documentation that say "these fields are
>  > just in case you need them, feel free to ignore"? 
> 
> Not really because that applies equally to all the other fields, already
> present, that a front end might not use.

Well, for other frames I know what they are used for.

>  >                                                  I'm trying to understand
>  > what is *your* intended use of this information, so that I can make up my
>  > mind as to best way to do that. We talked about frame ids before, I think
>  > Dan prefers frame ids, if exposed, to be totally opaque. You appear to
>  > suggest some smart uses of frame addresses, on the other hand, and I don't
>  > understand exactly what uses.
> 
> I'm just intending to present the frame address to the user to help him
> understand what he's looking at, not use it as a frame id in any rigorous way.
> I see that the Totalview debugger presents this information in their call stack
> (which they call stack trace) window and I think this would be useful, for the 
> reason, I've given too.

Well, I still fail to see what further "understanding" the user might get
from that information, but I'd be happy to be told :-)
My biggest worry about this is that we'll be providing some information which
is highly compiler dependent and which we cannot document in any way other that
"it is hex number". I don't think a random frontend author knows what DWARF CFI
is :-)

- Volodya

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Nick Roberts]

 >...
 > > I mean the window showing a variable's value (represented in Gdb as a
 > > variable object).
 > 
 > Does that window shows:
 > 
 > 1. Value of variable named XXX in the frame where that variable was
 > added to the window?
 > 2. Value of variable named XXX in the current frame
 > 3. Something else?

It doesn't really matter how it was created.


 > >  > > In any case, the extra field comes at almost no cost and a frontend
 > >  > > can choose to ignore it.
 > >  > 
 > >  > I supposed you don't plan to write documentation that say "these fields
 > >  > are just in case you need them, feel free to ignore"?
 > > 
 > > Not really because that applies equally to all the other fields, already
 > > present, that a front end might not use.
 > 
 > Well, for other frames I know what they are used for.

(by frames you mean fields?)

Really?  In the output of -stack-list-frames what are the pc address field for
the outer frames used for?

 >...
 > Well, I still fail to see what further "understanding" the user might get
 > from that information, but I'd be happy to be told :-)

I've already given a reason why I think it would be useful.

 > My biggest worry about this is that we'll be providing some information
 > which is highly compiler dependent and which we cannot document in any way
 > other that "it is hex number". I don't think a random frontend author knows
 > what DWARF CFI is :-)

If it was just a hex number, the concept of frame address presumably wouldn't
exist.  To me, it refers to the start of the frame and if a variable has an
address below that value, it belongs to that frame or a higher one.  Maybe on
some architectures, the stack grows in the other direction, and maybe there are
other anomalies, but a user could understand this and interpret such numbers.

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

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Daniel Jacobowitz]

On Thu, Apr 24, 2008 at 12:47:41AM +1200, Nick Roberts wrote:
>  > My biggest worry about this is that we'll be providing some information
>  > which is highly compiler dependent and which we cannot document in any way
>  > other that "it is hex number". I don't think a random frontend author knows
>  > what DWARF CFI is :-)
> 
> If it was just a hex number, the concept of frame address presumably wouldn't
> exist.  To me, it refers to the start of the frame and if a variable has an
> address below that value, it belongs to that frame or a higher one.  Maybe on
> some architectures, the stack grows in the other direction, and maybe there are
> other anomalies, but a user could understand this and interpret such numbers.

My concern about this has been, and still is, that front ends will
assign more meaning to it than it really has.  This is one of the
trickiest parts of GDB.  We already use frame addresses (specifically
$fp) to create varobjs in non-current frames; this is basically the
only thing the entire complicated frame_base machinery is used for
when not using stabs and it really should go away.

How about we call it the stack address of the frame instead of the
frame address?  Then it can come from the unwound $sp, which will
be at the other end of the frame and is better defined.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Vladimir Prus]

On Wednesday 23 April 2008 16:47:41 Nick Roberts wrote:
>  >...
>  > > I mean the window showing a variable's value (represented in Gdb as a
>  > > variable object).
>  > 
>  > Does that window shows:
>  > 
>  > 1. Value of variable named XXX in the frame where that variable was
>  > added to the window?
>  > 2. Value of variable named XXX in the current frame
>  > 3. Something else?
> 
> It doesn't really matter how it was created.

Of course it does, because for 2 (which are those floating varobjs), the
concept of frame varobj belongs is fairly moot.

>  > >  > > In any case, the extra field comes at almost no cost and a frontend
>  > >  > > can choose to ignore it.
>  > >  > 
>  > >  > I supposed you don't plan to write documentation that say "these fields
>  > >  > are just in case you need them, feel free to ignore"?
>  > > 
>  > > Not really because that applies equally to all the other fields, already
>  > > present, that a front end might not use.
>  > 
>  > Well, for other frames I know what they are used for.
> 
> (by frames you mean fields?)

Yes.
 
> Really?  In the output of -stack-list-frames what are the pc address field for
> the outer frames used for?

It's there so that you can know where you function is called from, in case the
caller is assembler and there's no other information about location.
 
>  >...
>  > Well, I still fail to see what further "understanding" the user might get
>  > from that information, but I'd be happy to be told :-)
> 
> I've already given a reason why I think it would be useful.

You've said "it is possible to infer to which frame that variable belongs" but did 
not explain neither how it's possible, nor why it's useful.

>  > My biggest worry about this is that we'll be providing some information
>  > which is highly compiler dependent and which we cannot document in any way
>  > other that "it is hex number". I don't think a random frontend author knows
>  > what DWARF CFI is :-)
> 
> If it was just a hex number, the concept of frame address presumably wouldn't
> exist.  To me, it refers to the start of the frame and if a variable has an 
> address below that value, it belongs to that frame or a higher one.  Maybe on 
> some architectures, the stack grows in the other direction, and maybe there are
> other anomalies, but a user could understand this and interpret such numbers.

Yes, stack surely grows in the other directions on other architectures. But that's
probably not the main issue. What is the case when a user wants to know which frame a
variable having address XXX belongs to? If that variable is varobj, GUI probably
already recorded the association between varobj and frame and is in position to
show that directly.

- Volodya

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Nick Roberts]

 > My concern about this has been, and still is, that front ends will
 > assign more meaning to it than it really has.  This is one of the
 > trickiest parts of GDB.  We already use frame addresses (specifically
 > $fp) to create varobjs in non-current frames; this is basically the
 > only thing the entire complicated frame_base machinery is used for
 > when not using stabs and it really should go away.

I thought there was sometimes an eight byte offset as Mark Kettenis so
eloquently described in:

http://sourceware.org/ml/gdb/2006-04/msg00218.html

But thats a good cas in point.  If the frontend end is to operate in a
stateless manner, as Vladimir has suggested, and varobjs are created in
non-selected frames, it needs to know the frame addresses:

-var-create - FRAME-ADDR EXPRESSION

 > How about we call it the stack address of the frame instead of the
 > frame address?  Then it can come from the unwound $sp, which will
 > be at the other end of the frame and is better defined.

I don't care what it's called.  If value this is different from
get_frame_base (fi) how is it computed?

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

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Nick Roberts]

 > >  > Does that window shows:
 > >  > 
 > >  > 1. Value of variable named XXX in the frame where that variable was
 > >  > added to the window?
 > >  > 2. Value of variable named XXX in the current frame
 > >  > 3. Something else?
 > > 
 > > It doesn't really matter how it was created.
 > 
 > Of course it does, because for 2 (which are those floating varobjs), the
 > concept of frame varobj belongs is fairly moot.

Floating varobjs are evaluated in the selected frame and that's the (changing)
frame to which it belongs.
 
 > >  > Well, for other frames I know what they are used for.
 > > 
 > > (by frames you mean fields?)
 > 
 > Yes.
 >  
 > > Really?  In the output of -stack-list-frames what are the pc address field
 > > for the outer frames used for?
 > 
 > It's there so that you can know where you function is called from, in case
 > the caller is assembler and there's no other information about location.

I mean it's not interesting to see the pc addresses for all the frames in the
call stack simultaneously.  Only the pc address of the selected frame is really
of interest.

 >...
 > Yes, stack surely grows in the other directions on other architectures. But
 > that's probably not the main issue. What is the case when a user wants to
 > know which frame a variable having address XXX belongs to? If that variable
 > is varobj, GUI probably already recorded the association between varobj and
 > frame and is in position to show that directly.

Gdb knows with which frame the varobj is associated but two frames might
have the same variable name, and with recursion they might have the same
procedure name.  Then the user could only work out which was which (if he
forgets when they were created) by comparing the frame addresses with the
memory locations of the variable.

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

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Daniel Jacobowitz]

On Thu, Apr 24, 2008 at 10:15:07AM +1200, Nick Roberts wrote:
> But thats a good cas in point.  If the frontend end is to operate in a
> stateless manner, as Vladimir has suggested, and varobjs are created in
> non-selected frames, it needs to know the frame addresses:
> 
> -var-create - FRAME-ADDR EXPRESSION

No, it doesn't.  We need to kill that interface.  It needs to go away.

You gave a perfect example in your other reply, just now, of why front
ends should not have a frame address.  If you are ever in the position
of dealing with a recursive function and you want to know which
instance a variable comes from, the frame address is insufficient.
For instance IA-64 can have stackless recursive functions; they
use only the separate register stack.

If you want to know which frame the varobj is associated with GDB
should supply some unique opaque identifier, and then the IDE can
use that to show the frame number in a tooltip or wherever.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Bob Rossi]

On Wed, Apr 23, 2008 at 06:24:14PM -0400, Daniel Jacobowitz wrote:
> On Thu, Apr 24, 2008 at 10:15:07AM +1200, Nick Roberts wrote:
> > But thats a good cas in point.  If the frontend end is to operate in a
> > stateless manner, as Vladimir has suggested, and varobjs are created in
> > non-selected frames, it needs to know the frame addresses:
> > 
> > -var-create - FRAME-ADDR EXPRESSION
> 
> No, it doesn't.  We need to kill that interface.  It needs to go away.
> 
> You gave a perfect example in your other reply, just now, of why front
> ends should not have a frame address.  If you are ever in the position
> of dealing with a recursive function and you want to know which
> instance a variable comes from, the frame address is insufficient.
> For instance IA-64 can have stackless recursive functions; they
> use only the separate register stack.
> 
> If you want to know which frame the varobj is associated with GDB
> should supply some unique opaque identifier, and then the IDE can
> use that to show the frame number in a tooltip or wherever.

I've got a good idea, how about the frame number?

Bob Rossi

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Nick Roberts]

 > You gave a perfect example in your other reply, just now, of why front
 > ends should not have a frame address.  If you are ever in the position
 > of dealing with a recursive function and you want to know which
 > instance a variable comes from, the frame address is insufficient.
 > For instance IA-64 can have stackless recursive functions; they
 > use only the separate register stack.

Well you understand the internals much better than I do, but whenever I've
looked at the frame addresses on i386 they've appeared meaningful.  Are
"stackless recursive functions" special to IA-64 or a consequence of
optimisation?  If the values are meaningful "most of the time" then I think
it's OK to have this field, if not then I guess it might just confuse.

 > If you want to know which frame the varobj is associated with GDB
 > should supply some unique opaque identifier, and then the IDE can
 > use that to show the frame number in a tooltip or wherever.

Do you mean use something like uuidgen to associate a key with a frame
and output that as a field for a variable object?

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

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Nick Roberts]

 > > If you want to know which frame the varobj is associated with GDB
 > > should supply some unique opaque identifier, and then the IDE can
 > > use that to show the frame number in a tooltip or wherever.
 > 
 > I've got a good idea, how about the frame number?

The frame number changes when a new frame is created, i.e., if the current
frame is used it's always "0", but it doesn't stay that way.

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

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Nick Roberts]

 >  > If you want to know which frame the varobj is associated with GDB
 >  > should supply some unique opaque identifier, and then the IDE can
 >  > use that to show the frame number in a tooltip or wherever.
 > 
 > Do you mean use something like uuidgen to associate a key with a frame
 > and output that as a field for a variable object?

Actually it just needs to be a non-zero value for frames in which a varobj is
created.  Perhaps a member of struct frame_id, int varobj_frame say, which
increments when a varobj is created in a new frame.  This could also then be
used to see if a varobj has gone out of scope to avoid the ambiguities Jim
Blandy talked about from using frame_find_by_id.

Perhaps this is what you are suggesting, anyway.

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

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Daniel Jacobowitz]

On Thu, Apr 24, 2008 at 11:23:08AM +1200, Nick Roberts wrote:
> Well you understand the internals much better than I do, but whenever I've
> looked at the frame addresses on i386 they've appeared meaningful.  Are
> "stackless recursive functions" special to IA-64 or a consequence of
> optimisation?  If the values are meaningful "most of the time" then I think
> it's OK to have this field, if not then I guess it might just confuse.

It's an IA-64 thing.  This is the original reason that frame IDs had a
third member, the "special address" field.

I've actually got patches to add several more items to the frame ID.
I hope I'll be submitting them soon.  That's inlined function support,
where the stack address really becomes not useful to identify the
scope.

On Thu, Apr 24, 2008 at 12:40:12PM +1200, Nick Roberts wrote:
> Actually it just needs to be a non-zero value for frames in which a varobj is
> created.  Perhaps a member of struct frame_id, int varobj_frame say, which
> increments when a varobj is created in a new frame.  This could also then be
> used to see if a varobj has gone out of scope to avoid the ambiguities Jim
> Blandy talked about from using frame_find_by_id.
> 
> Perhaps this is what you are suggesting, anyway.

Right, this is basically what I had in mind.  It may not solve the
going out of scope bit, because we don't usually backtrace all the
way up - and how do we avoid having to save an unbounded number of
these things so we can map them, so maybe a hash is better than
a counter.  I haven't thought about the details yet.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Nick Roberts]

 > > Well you understand the internals much better than I do, but whenever I've
 > > looked at the frame addresses on i386 they've appeared meaningful.  Are
 > > "stackless recursive functions" special to IA-64 or a consequence of
 > > optimisation?  If the values are meaningful "most of the time" then I think
 > > it's OK to have this field, if not then I guess it might just confuse.
 > 
 > It's an IA-64 thing.  This is the original reason that frame IDs had a
 > third member, the "special address" field.

So it's really an exceptional case rather than the rule.

 > I've actually got patches to add several more items to the frame ID.
 > I hope I'll be submitting them soon.  That's inlined function support,
 > where the stack address really becomes not useful to identify the
 > scope.

Maybe Gdb could somehow identify the cases where the address isn't useful.

 > On Thu, Apr 24, 2008 at 12:40:12PM +1200, Nick Roberts wrote:
 > > Actually it just needs to be a non-zero value for frames in which a varobj
 > > is created.  Perhaps a member of struct frame_id, int varobj_frame say,
 > > which increments when a varobj is created in a new frame.  This could also
 > > then be used to see if a varobj has gone out of scope to avoid the
 > > ambiguities Jim Blandy talked about from using frame_find_by_id.
 > > 
 > > Perhaps this is what you are suggesting, anyway.
 > 
 > Right, this is basically what I had in mind.  It may not solve the
 > going out of scope bit, because we don't usually backtrace all the
 > way up - and how do we avoid having to save an unbounded number of
 > these things so we can map them, so maybe a hash is better than
 > a counter.  I haven't thought about the details yet.

I don't think the number need be that unbounded, it's not needed for each
frame, only those in which a varobj is created.  But it appears that the
linked list of frames gets destroyed and recreated each time execution
occurs, in which case any id information is also lost (I was looking at
using an extra member in struct frame_info).

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

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Daniel Jacobowitz]

On Fri, Apr 25, 2008 at 11:03:52AM +1200, Nick Roberts wrote:
> Maybe Gdb could somehow identify the cases where the address isn't useful.

If there are known cases where the address isn't useful, I (like
Vladimir) do not understand why we should export it.

> I don't think the number need be that unbounded, it's not needed for each
> frame, only those in which a varobj is created.  But it appears that the
> linked list of frames gets destroyed and recreated each time execution
> occurs, in which case any id information is also lost (I was looking at
> using an extra member in struct frame_info).

Right, that's the whole problem.  It has to last as long as the
frame_id, not the frame_info.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] -stack-info-frame/-stack-list-frames

[Nick Roberts]

Daniel Jacobowitz writes:
 > > Maybe Gdb could somehow identify the cases where the address isn't useful.
 > 
 > If there are known cases where the address isn't useful, I (like
 > Vladimir) do not understand why we should export it.

For the cases where it is useful?

 > > I don't think the number need be that unbounded, it's not needed for each
 > > frame, only those in which a varobj is created.  But it appears that the
 > > linked list of frames gets destroyed and recreated each time execution
 > > occurs, in which case any id information is also lost (I was looking at
 > > using an extra member in struct frame_info).
 > 
 > Right, that's the whole problem.  It has to last as long as the
 > frame_id, not the frame_info.

It looks pretty intractable.  It looks like the only place to store the
identifier is in the stack itself, perhap through some compile option,
-fframe-id, say.  I don't know if compilers are allowed to create local
variables and I guess it's all getting too complicated.

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