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

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

[Andrew Cagney]

Hello,

(For all two of you that haven't figured it out, I'm back at working on
multi-arch :-)

This e-mail first discusses multi-arch and some of its requirements.  It
then goes on to propose a number of significant but related structural
changes to GDB that help it take a step closer to being multi-arch.

----

Multi-arch is the grand plan that one day GDB will be able to do things
like debug a target that contains several different architectures.  The
classic embedded example would be the Play Station 2 while the UNIX
example is for platforms like Solaris where both 32 and 64 bit binaries
are present.

Several steps in this plan were identified (with any long term project,
the more distant the work, the more vague the details :-):

	o	Replace hardwired macros with run-time
		tests/calls to an architecture vector.

	o	Modify GDB's configury so that
		different architectures could
		be incorporated into a single GDB.

	o	Modify GDB so that it can debug
		a system that contains several
		different architectures.

		This was identified as the tricky bit.

Right now, I think things are about ready for step two (hopefully fairly
straight forward) so it is time to plan for step three.

Hmm.

----

When multi-arch was first discussed it was fairly clear that GDB was
going to need to be parameterize with something.  At the time, it was
thought that during stage three everything would be parameterized with
either a large architecture vector or an even larger merged architecture
/ target vector.

Hmm.

----

In the mean time, Kevin B has been looking at TPID, that global integer
which is used to identify the current thread.  A pretty logical chain of
thought leads to the conclusion that, since each thread can have a
different architecture, each thread should have an arcitecture bound to
it.

So rather than parameterize everything with the architecture, why not
instead parameterize everything with a thread object.

Hmm.

----

One of the very long term goals of GDB is to be able to debug RPC code. 
Looking at what appears to be a simple debugging example:

	(gdb) step
	10	do_rpc_to_machine_foo();
	(gdb) step
	do_rpc_to_machine_foo() at foo.c:50
	50	printf ("Hello world\n");
	(gdb)

Examing the stack frame, and remembering the idea is that this is RPC
code:

	(gdb) where
	#0  do_rpc_to_machine_foo() at foo::foo.c:50
	#1  0x804883d in main () at blah::blah.c:10
	(gdb) info architecture
	The architecture is foo.
	(gdb) up
	#1  0x804883d in main () at blah::blah.c:10
	10	do_rpc_to_machine_foo();
	(gdb) info architecture
	The architecture is blah

The architecture is clearly bound to the frame rather than the thread. 
A thread has a frame,  a frame has an architecture.  So why not pass the
frame around everywhere?

Hmm.

----

Looking at the existing code base,I think it is clear that much it isn't
worried about threads or architectures.  Rather it is worried about
frames.  To do a stack backtrack, you need a frame.  To list the current
source, you (often - PIC) need a frame. To examine variables you need a
frame.  To do an inferior function call, you need a frame.

In fact, when the target stops, the second thing GDB does (after
checking that the stop is for real) is to create a frame.  On a target
that doesn't have a frame, GDB fakes it.  If GDB can't fake a frame,
things get pretty sick.

In a way, this shouldn't be unexpected.  GDB is a debugger designed for
debugging procedural languages that, in some way resemble C.  Much of a
procedural language revolves around the stack frame.

Hmm.

----

A number of GDB's existing targets have limited runtime support for
architecture variants (THUMB/ARM and MIPS16/MIPS).  For these targets
the ISA may change between stack frames.  At present this is implemented
by wrapping all architecture specific code in ``if (ISA_A) ... else
...;''.  Such code would clearly immediatly benefit from a change that
bound the architecture to the frame.

Hmm.

----

Given all this, I'd like to propose the following structural changes to
GDB.

	o	The frame have an architecture
		attached to it.

		As an intermediate hack, current
		architecture and current frame would
		remain as globals.

	o	All the functions that apply to
		the frame be parameterized with a
		frame argument and modified to
		use the frame's architecture.

	o	(Per previous e-mail)
		The frame and its registers be more
		clearly separated from the target
		(in particular the regcache).

		Most calls that go directly to the
		regcache will instead go via the
		current frame.

		A consequence of this is that the
		current need for the RAW / PSEUDO
		/ NATURAL register mess will be
		eliminated.  Yessss!

While looking simple, these changes are certainly everything but.  Every
frame / regcache / memcache access will need to be examined / modified. 
Fortunately, most of these uses can be examined independently so the
work can be carried out incrementally.

Clearly this change, on its own, won't be sufficient to make GDB
multi-arch.  I would argue, however, that like the initial multi-arch
work, it is a clear step in the right direction.

With that in mind, I'm looking for comments, questions and suggestions.  

----

Finally.  I'd like to thank Jim Blandy, David Taylor, Fernando Nasser,
Kevin Buettner, Elena Zannoni and Michael Snyder (who else? Red Hat) for
providing the support and suggestions needed to develop this idea.

	Andrew

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

[Nick Duffek]

On 23-Feb-2001, Andrew Cagney wrote:

>	o	The frame have an architecture
>		attached to it.

Yes, this seems like the right thing to do.

>		As an intermediate hack, current
>		architecture and current frame would
>		remain as globals.

So eventually, current_gdbarch and selected_frame will be deprecated in
favor of passing gdbarch and/or frame pointers as parameters?

I wonder if that's really beneficial.  Global variables should be used
sparingly, but they're appropriate for values shared across large expanses
of code, as current_gdbarch and selected_frame are.

Keeping those values in global variables could make the code more
maintainable rather than less.  We'd need to add explicit context switches
at frame boundary crossings, but that seems lees onerous to me than adding
extra parameters to hundreds (thousands?) of function calls.

Nick

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

[Kevin Buettner]

On Feb 26,  4:20pm, Nick Duffek wrote:

> Keeping those values in global variables could make the code more
> maintainable rather than less.  We'd need to add explicit context switches
> at frame boundary crossings, but that seems lees onerous to me than adding
> extra parameters to hundreds (thousands?) of function calls.

Personally, I'd prefer to see one extra parameter added to those
functions which are already getting one (or more) parameters
implicitly via globals.

Kevin

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

[Nick Duffek]

On 26-Feb-2001, Kevin Buettner wrote:

>Personally, I'd prefer to see one extra parameter added to those
>functions which are already getting one (or more) parameters
>implicitly via globals.

That's at least every function that calls any macro in gdbarch.sh, plus
all possible ancestors of those functions.  I'll bet we're talking about a
big majority of the functions in GDB.

Nick

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

[Kevin Buettner]

On Feb 26,  6:36pm, Nick Duffek wrote:

> >Personally, I'd prefer to see one extra parameter added to those
> >functions which are already getting one (or more) parameters
> >implicitly via globals.
> 
> That's at least every function that calls any macro in gdbarch.sh, plus
> all possible ancestors of those functions.  I'll bet we're talking about a
> big majority of the functions in GDB.

I think that's why Andrew suggested approaching it incrementally.

Kevin

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

[Andrew Cagney]

Nick Duffek wrote:
> 
> On 23-Feb-2001, Andrew Cagney wrote:
> 
> >       o       The frame have an architecture
> >               attached to it.
> 
> Yes, this seems like the right thing to do.
> 
> >               As an intermediate hack, current
> >               architecture and current frame would
> >               remain as globals.
> 
> So eventually, current_gdbarch and selected_frame will be deprecated in
> favor of passing gdbarch and/or frame pointers as parameters?

Eventually, something kind of like that will happen - target code might
have a target object; thread code might have a thread object; ...

Here I'm just focusing on one object and its methods - the frame or
``struct frame_info *'' and making plans for fixing it.

> I wonder if that's really beneficial.  Global variables should be used
> sparingly, but they're appropriate for values shared across large expanses
> of code, as current_gdbarch and selected_frame are.

There is, in a sense, a ``secret agenda'' going on.  A recognized
problem with GDB is that it assumes it is debugging a single threaded,
single architectured, single languaged, single targeted, single framed,
VAX application.  When reviewing or proposing change I try to keep in
mind the long term objective of breaking each of those implicit
assumptions.  I think parameterising all frame methods with their frame
is consistent with that.

	enjoy,
		Andrew

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

[Kevin Buettner]

On Feb 23,  7:32pm, Andrew Cagney wrote:

[Big picture snipped]
> Given all this, I'd like to propose the following structural changes to
> GDB.
> 
> 	o	The frame have an architecture
> 		attached to it.
> 
> 		As an intermediate hack, current
> 		architecture and current frame would
> 		remain as globals.
> 
> 	o	All the functions that apply to
> 		the frame be parameterized with a
> 		frame argument and modified to
> 		use the frame's architecture.
> 
> 	o	(Per previous e-mail)
> 		The frame and its registers be more
> 		clearly separated from the target
> 		(in particular the regcache).
> 
> 		Most calls that go directly to the
> 		regcache will instead go via the
> 		current frame.
> 
> 		A consequence of this is that the
> 		current need for the RAW / PSEUDO
> 		/ NATURAL register mess will be
> 		eliminated.  Yessss!
> 
> While looking simple, these changes are certainly everything but.  Every
> frame / regcache / memcache access will need to be examined / modified. 
> Fortunately, most of these uses can be examined independently so the
> work can be carried out incrementally.
> 
> Clearly this change, on its own, won't be sufficient to make GDB
> multi-arch.  I would argue, however, that like the initial multi-arch
> work, it is a clear step in the right direction.
> 
> With that in mind, I'm looking for comments, questions and suggestions.  

Andrew,

The big picture that you painted certainly looks reasonable.  But even
if it didn't, I think the structural changes that your propose above
make sense even when considered on a much smaller scale...

It makes sense to associate an architecture with a frame so that we
can cleanly implement support for targets with mixed architectures
like ARM/THUMB or IA-64/IA-32.

Also, from a software engineering standpoint, I think it makes sense
to eliminate as many of the globals as possible and pass parameters
instead.  Any time one or more of the parameters to a function are
passed implicitly via a global, you're just asking for trouble later
on.

Kevin

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

[Jim Ingham]

Andrew,

This sounds like a very interesting idea.  The notion of treating Frames 
as entities that"know what they are" independent of their surroundings 
brings to mind another similar problem - that of debugging both sides of 
an interpreted or byte complied language, Java, Tcl, Python, Guile...

It would be cool if whatever determines the architecture of a frame 
could also fake the language so that when you found a "bytecode execute" 
call in a frame, gdb could translate this into the equivalent frame in 
the interpreted language.  This is a little harder than it seems, 
because in most cases the execute operation is several C stack frames.  
So to make the illusion complete, you would have to scarf up a couple of 
stack frames & convert them into a single frame in the interpreted 
language.

But if you could do that then having the "architecture" for the combined 
frames be, say, the JVM, would give you an agent that could grub around 
and present the VM's registers, locals, etc in a fairly intelligent way.

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

> Hello,
>
> (For all two of you that haven't figured it out, I'm back at working on
> multi-arch :-)
>
> This e-mail first discusses multi-arch and some of its requirements.  It
> then goes on to propose a number of significant but related structural
> changes to GDB that help it take a step closer to being multi-arch.
>
> ----
>
> Multi-arch is the grand plan that one day GDB will be able to do things
> like debug a target that contains several different architectures.  The
> classic embedded example would be the Play Station 2 while the UNIX
> example is for platforms like Solaris where both 32 and 64 bit binaries
> are present.
>
> Several steps in this plan were identified (with any long term project,
> the more distant the work, the more vague the details :-):
>
> 	o	Replace hardwired macros with run-time
> 		tests/calls to an architecture vector.
>
> 	o	Modify GDB's configury so that
> 		different architectures could
> 		be incorporated into a single GDB.
>
> 	o	Modify GDB so that it can debug
> 		a system that contains several
> 		different architectures.
>
> 		This was identified as the tricky bit.
>
> Right now, I think things are about ready for step two (hopefully fairly
> straight forward) so it is time to plan for step three.
>
> Hmm.
>
> ----
>
> When multi-arch was first discussed it was fairly clear that GDB was
> going to need to be parameterize with something.  At the time, it was
> thought that during stage three everything would be parameterized with
> either a large architecture vector or an even larger merged architecture
> / target vector.
>
> Hmm.
>
> ----
>
> In the mean time, Kevin B has been looking at TPID, that global integer
> which is used to identify the current thread.  A pretty logical chain of
> thought leads to the conclusion that, since each thread can have a
> different architecture, each thread should have an arcitecture bound to
> it.
>
> So rather than parameterize everything with the architecture, why not
> instead parameterize everything with a thread object.
>
> Hmm.
>
> ----
>
> One of the very long term goals of GDB is to be able to debug RPC code.
> Looking at what appears to be a simple debugging example:
>
> 	(gdb) step
> 	10	do_rpc_to_machine_foo();
> 	(gdb) step
> 	do_rpc_to_machine_foo() at foo.c:50
> 	50	printf ("Hello world\n");
> 	(gdb)
>
> Examing the stack frame, and remembering the idea is that this is RPC
> code:
>
> 	(gdb) where
> 	#0  do_rpc_to_machine_foo() at foo::foo.c:50
> 	#1  0x804883d in main () at blah::blah.c:10
> 	(gdb) info architecture
> 	The architecture is foo.
> 	(gdb) up
> 	#1  0x804883d in main () at blah::blah.c:10
> 	10	do_rpc_to_machine_foo();
> 	(gdb) info architecture
> 	The architecture is blah
>
> The architecture is clearly bound to the frame rather than the thread.
> A thread has a frame,  a frame has an architecture.  So why not pass the
> frame around everywhere?
>
> Hmm.
>
> ----
>
> Looking at the existing code base,I think it is clear that much it isn't
> worried about threads or architectures.  Rather it is worried about
> frames.  To do a stack backtrack, you need a frame.  To list the current
> source, you (often - PIC) need a frame. To examine variables you need a
> frame.  To do an inferior function call, you need a frame.
>
> In fact, when the target stops, the second thing GDB does (after
> checking that the stop is for real) is to create a frame.  On a target
> that doesn't have a frame, GDB fakes it.  If GDB can't fake a frame,
> things get pretty sick.
>
> In a way, this shouldn't be unexpected.  GDB is a debugger designed for
> debugging procedural languages that, in some way resemble C.  Much of a
> procedural language revolves around the stack frame.
>
> Hmm.
>
> ----
>
> A number of GDB's existing targets have limited runtime support for
> architecture variants (THUMB/ARM and MIPS16/MIPS).  For these targets
> the ISA may change between stack frames.  At present this is implemented
> by wrapping all architecture specific code in ``if (ISA_A) ... else
> ...;''.  Such code would clearly immediatly benefit from a change that
> bound the architecture to the frame.
>
> Hmm.
>
> ----
>
> Given all this, I'd like to propose the following structural changes to
> GDB.
>
> 	o	The frame have an architecture
> 		attached to it.
>
> 		As an intermediate hack, current
> 		architecture and current frame would
> 		remain as globals.
>
> 	o	All the functions that apply to
> 		the frame be parameterized with a
> 		frame argument and modified to
> 		use the frame's architecture.
>
> 	o	(Per previous e-mail)
> 		The frame and its registers be more
> 		clearly separated from the target
> 		(in particular the regcache).
>
> 		Most calls that go directly to the
> 		regcache will instead go via the
> 		current frame.
>
> 		A consequence of this is that the
> 		current need for the RAW / PSEUDO
> 		/ NATURAL register mess will be
> 		eliminated.  Yessss!
>
> While looking simple, these changes are certainly everything but.  Every
> frame / regcache / memcache access will need to be examined / modified.
> Fortunately, most of these uses can be examined independently so the
> work can be carried out incrementally.
>
> Clearly this change, on its own, won't be sufficient to make GDB
> multi-arch.  I would argue, however, that like the initial multi-arch
> work, it is a clear step in the right direction.
>
> With that in mind, I'm looking for comments, questions and suggestions.
>
> ----
>
> Finally.  I'd like to thank Jim Blandy, David Taylor, Fernando Nasser,
> Kevin Buettner, Elena Zannoni and Michael Snyder (who else? Red Hat) for
> providing the support and suggestions needed to develop this idea.
>
> 	Andrew
>

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

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

[Nick Duffek]

On 26-Feb-2001, Jim Ingham wrote:

>It would be cool if whatever determines the architecture of a frame could also
>fake the language so that when you found a "bytecode execute" call in a frame,
>gdb could translate this into the equivalent frame in the interpreted
>language.

That would be really neat.

We'd have to have a way to disable it, of course, to allow for debugging
the bytecode engine.  But it would be terrific to be able to debug
embedded language code with GDB.

Nick

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

[Jim Ingham]

Yes, the worst part of doing extensions for a scripting language is that 
there is no common debugger...  I agree that you need to be able to turn 
this on & off, however.

Given that you could do that, and if you could have some nice way to 
scan the frames listing (like if this were implemented in gdbtk), and 
query each one for its type, you could also construct the embedded stack 
off to one side.  It would be really neat to have a stack view kind of 
like those side-by-side diff viewers, where the elements in the embedded 
stack flow into the elements in the interpreter stack that implement 
them...  That would be really sweet.

Jim

> On 26-Feb-2001, Jim Ingham wrote:
>
>> It would be cool if whatever determines the architecture of a frame 
>> could also
>> fake the language so that when you found a "bytecode execute" call in 
>> a frame,
>> gdb could translate this into the equivalent frame in the interpreted
>> language.
>
> That would be really neat.
>
> We'd have to have a way to disable it, of course, to allow for debugging
> the bytecode engine.  But it would be terrific to be able to debug
> embedded language code with GDB.
>
> Nick

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

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

[Per Bothner]

Nick Duffek <nsd@redhat.com> writes:

> We'd have to have a way to disable it, of course, to allow for debugging
> the bytecode engine.

Maybe "set lang c" should disable the interpreter-frame feature.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

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

[Andrew Cagney]

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 :-)

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.

Again, I don't think my proposed change precludes this model.

	Andrew

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

[Jim Ingham]

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

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

[Andrew Cagney]

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

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

[Jim Ingham]

Andrew,

>
>
>> 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 :-)

I don't think this is really that much of a problem.  In the scheme I 
was sketching, given an ordering of the "frame recognizers" the previous 
frame will always be unique.  But if you switch the ordering, then the 
previous frame will change.  You will need this in your RPC example too, 
since I would definitely want the ability to turn off tracing across the 
RPC, and in this case the frame ordering will change as well.

This is a pretty heavyweight thing to do, however, so it is probably 
safe to blow away the frame cache and start all over if you do this...  
So as long as cleaning up all your state and starting over is easy to 
do, then this will fall out.

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