From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Ingham To: Nick Duffek Cc: gdb@sources.redhat.com Subject: Re: [multi-arch] The frame as the global parameter (long, important) Date: Mon, 26 Feb 2001 13:27:00 -0000 Message-id: <200102262127.NAA19525@scv3.apple.com> References: <200102262125.f1QLPPg00564@rtl.cygnus.com> X-SW-Source: 2001-02/msg00380.html 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