From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Ingham To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: [multi-arch] The frame as the global parameter (long, important) Date: Mon, 26 Feb 2001 14:52:00 -0000 Message-id: <200102262251.OAA17343@scv1.apple.com> References: <3A9ACF21.CAC89545@cygnus.com> X-SW-Source: 2001-02/msg00390.html 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