Re: [multi-arch] The frame as the global parameter (long, important)

[Jim Ingham <jingham@apple.com>]

Andrew,

> Jim Ingham wrote:
>
>> This is probably a one-step-further, but since it seemed a natural
>> extension to your ideas, and would be really cool (I know the Java 
>> folks
>> here would kill for it, as I would have back when I was working on
>> gdbtk) I thought I would mention it as a thing to keep in the back of
>> your mind as you implement this...
>
> Yes, good point.  I've definitly got that in the back of my mind as
> possible ``further work'' :-)  JimB among others remind me of the same
> thing.
>
> I think the main thing to decide at this point is, does the change I
> proposing in any way preclude this ``further work''?  From your e-mail I
> gather that you don't see any problems :-)
>

I was trying to picture how you would do what you are suggesting in 
practice.  I guess that you will have to have a bag full of "frame type 
identifiers" of some sort. Then when gdb stops, you will trot the 
current program state in front of each of these till one says "Ah, that 
is my kind of frame".  Then it becomes the agent that you ask to get 
things like the variables currently visible, the memory, etc...

If you are doing a backtrace, then you ask this agent where to look for 
the next frame, and then again run that  by your cast o' frame types...

The complication added by doing what I was suggesting (and, no surprise, 
JimB as well) is that you now have several frame recognizers that can 
potentially match a given frame.  Moreover, depending on which one you 
ask, you will get a different answer to questions like "Where is the 
next stack frame?".  And as Nick points out, you want to dynamically 
switch among the duplicates in a given gdb session.

So, yeah, it seems like this should work, provided you make sure you 
don't assume that there is only one valid result of a backtrace, and 
make switching the order fairly easy...

> The reason I'm trying to keep my proposal separate from idea's such as
> yours is that I'd like to see it finished.  Hopefully someone else will,
> independantly take on your proposal.
>
> At a more wishy/washy level.  Have you considered viewing GDB as:
>
> 	gdb
> 	  \
> 	 context - java
> 	    \
> 	    frame
> 	      \
> 	     target
> 	        \
> 	        gdb - hardware
> 	          \
> 	          ....
>
> That is, a target that allows the debugging of the JVM might be
> implemented using an GDB instance that understands how to access the raw
> data.

Not sure how you mean this.  One thing to note is that the JVM context 
only understands some bits of the stack.  The native implemented methods 
are unknown to it.  OTOH, being able to trace from the Java side INTO 
the native side is the whole point of doing this.  There are already 
good Java debugging tools.  What I really want this for is when my 
native method goes awry, I want to be able to view the Java context in 
which my C code is running.  Seems like this maps naturally onto 
reconstructing the program stack in this mixed context.

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer