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

[Andrew Cagney <ac131313@cygnus.com>]

> 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...

Hmm, GDB currently assumes that, given a frame, there is only one
possible next frame.  I'll be leaving that assumption alone :-)

> > 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.

Hmm, we're thinking of different approaches - this is good.

I was thinking that the JVM might be re-constructed by using an instance
of GDB (yes several in the one program) grub around in the JVM
interpreter's (written in C?) data structures.

For instance (and I'm totally making this up cause I know nothing about
a JVM :-), say the JVM's address space is implemented using a hash table
called jvm_memory[].  The target could use ``gdb - hardware'' to find
``jvm_memory[]'' and do the hash operation.

Another example might be trying to debug a unix environment given a jtag
interface.  There would be two layers.

	gdb-unix
	    |
	unix-target
	    +
	gdb-hardware
	    |
	hardware-target

the unix-target would re-construct things like VM and process tables
using the gdb able to control the hardware target.

	Andrew

PS: It has been suggested that the entire upper layer of both these
examples should be written in a scripting language .....