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

[Jim Ingham <jingham at apple dot com>]

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