Frame handling

Frame handling

[Jafa]

Hi all,

I am bringing the ip2k port back in sync with the trunk and I need to check
my (limited) understanding of the new scheme...

This email is mostly a ramble about my understanding of the new frame
handling that I would like a sanity check on.

frame_base_set_default (gdbarch, &avr_frame_base) registers a set of
function handlers:
this_base - given a frame, figure out the base address of the caller frame
(caller's FP)... usually this means doing some analysis to figure everything
out about the frame and populating the port-specific cache for this new
frame.
this_locals - given a frame, figure out the address of the local variables
of the callers frame (usually caller's FP as debug info already allows for
the offset).
this_args - given a frame, figure out the address of the args passed to the
callers frame (usually caller's FP as debug info already allows for the
offset).

Port specific implementation... The first time one of these functions is
called the port-specific cache will be a NULL pointer... the code should
allocate memory to hold the useful frame variables and figure out the frame
information. Subsequent calls will receive the cache back and can return the
values from the cache.

frame_base_set_default also sets the unwind options...
type - always NORMAL_FRAME?
this_id - Given a frame, return a unique identifier for the caller's frame
based on the caller's frame base address and the calling functions entry
point.
prev_register - Given a frame, return the value of a specified register as
it was on entry to this function (registers that are known to be saved on
the stack)

Question - what registers is gdb expecting prev_register to give reasonable
results for? Just PC? Or SP and FP as well?

Question - reading through this again I think the goal of call these
functions is to work with the current frame and the function get passed the
child frame so they can do a backtrace if it hasn't already been done... why
not call a function to do a 1 level backtrace and then eliminate the
next_frame parameter? It would recduce confusion and most ports will have an
internal unwind function anyway.

frame_unwind_append_predicate (gdbarch, d10v_frame_p) - this seams to
register the same unwind options as above?

I think this makes sense but I would appreciate a sanity check :-)

Thanks

Nick

Nick Kelsey
Senior Software Engineer
Ubicom

Re: Frame handling

[Daniel Jacobowitz]

On Mon, Jun 30, 2003 at 06:18:33PM -0700, Jafa wrote:
> Hi all,
> 
> I am bringing the ip2k port back in sync with the trunk and I need to check
> my (limited) understanding of the new scheme...
> 
> This email is mostly a ramble about my understanding of the new frame
> handling that I would like a sanity check on.
> 
> frame_base_set_default (gdbarch, &avr_frame_base) registers a set of
> function handlers:
> this_base - given a frame, figure out the base address of the caller frame
> (caller's FP)... usually this means doing some analysis to figure everything
> out about the frame and populating the port-specific cache for this new
> frame.
> this_locals - given a frame, figure out the address of the local variables
> of the callers frame (usually caller's FP as debug info already allows for
> the offset).
> this_args - given a frame, figure out the address of the args passed to the
> callers frame (usually caller's FP as debug info already allows for the
> offset).
> 
> Port specific implementation... The first time one of these functions is
> called the port-specific cache will be a NULL pointer... the code should
> allocate memory to hold the useful frame variables and figure out the frame
> information. Subsequent calls will receive the cache back and can return the
> values from the cache.

You're good so far.

> frame_base_set_default also sets the unwind options...

No, it doesn't.  That unwind member is used for comparison purposes
only.  See the "Sneaky" comment in get_frame_base_address, and all of
"frame-unwind.h".  Esp. frame_unwind_append_predicate.

> type - always NORMAL_FRAME?

For a target's unwinders, probably.

> this_id - Given a frame, return a unique identifier for the caller's frame
> based on the caller's frame base address and the calling functions entry
> point.
> prev_register - Given a frame, return the value of a specified register as
> it was on entry to this function (registers that are known to be saved on
> the stack)
> 
> Question - what registers is gdb expecting prev_register to give reasonable
> results for? Just PC? Or SP and FP as well?

As many as possible.  This _completely_ replaces all other unwinding,
for instance frame_chain and the extra_info/saved_registers data. 
Might want to take a look at the ARM conversion I just posted; I don't
promise it's right...

> Question - reading through this again I think the goal of call these
> functions is to work with the current frame and the function get passed the
> child frame so they can do a backtrace if it hasn't already been done... why
> not call a function to do a 1 level backtrace and then eliminate the
> next_frame parameter? It would recduce confusion and most ports will have an
> internal unwind function anyway.

Because it doesn't make much difference, I think.  The key is that the
info generated when doing the backtrace is target specific, and opaque.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Frame handling

[Andrew Cagney]

>> this_id - Given a frame, return a unique identifier for the caller's frame
>> based on the caller's frame base address and the calling functions entry
>> point.
>> prev_register - Given a frame, return the value of a specified register as
>> it was on entry to this function (registers that are known to be saved on
>> the stack)
>> 
>> Question - what registers is gdb expecting prev_register to give reasonable
>> results for? Just PC? Or SP and FP as well?
> 
> 
> As many as possible.  This _completely_ replaces all other unwinding,
> for instance frame_chain and the extra_info/saved_registers data. 
> Might want to take a look at the ARM conversion I just posted; I don't
> promise it's right...

Yes.  GDB now relies on the prev_register method when popping a frame so 
unless it works well, things fail pretty quick.

>> Question - reading through this again I think the goal of call these
>> functions is to work with the current frame and the function get passed the
>> child frame so they can do a backtrace if it hasn't already been done... why
>> not call a function to do a 1 level backtrace and then eliminate the
>> next_frame parameter? It would recduce confusion and most ports will have an
>> internal unwind function anyway.


> Because it doesn't make much difference, I think.  The key is that the
> info generated when doing the backtrace is target specific, and opaque.

I'm not sure I understand the question.

Andrew

Re: Frame handling

[Jafa]

Hi Andrew,

>>> Question - what registers is gdb expecting prev_register to give
reasonable
>>> results for? Just PC? Or SP and FP as well?
>>
>> As many as possible.  This _completely_ replaces all other unwinding,
>> for instance frame_chain and the extra_info/saved_registers data.
>> Might want to take a look at the ARM conversion I just posted; I don't
>> promise it's right...
>
>Yes.  GDB now relies on the prev_register method when popping a frame so
>unless it works well, things fail pretty quick.

Ok

The ABI states that everything is callee clobbered so the only things I can
recover will be the PC, SP, and FP. There is no FP register so FP and SP are
search-calculated.

I will clean up the ip3k (aka ip4k) frame_handling next so should be able to
recover the saved address registers (all data registers are callee
clobbered).

BTW - Sorry I missed the branch, management didn't pay any attention to my
recomendation 3 weeks ago... and *now* they decide we need to fix gdb and
merge up to the trunk :-)

Thanks

Nick

Re: Frame handling

[Andrew Cagney]

>>>> Question - reading through this again I think the goal of call these
>>>> functions is to work with the current frame and the function get passed the
>>>> child frame so they can do a backtrace if it hasn't already been done... why
>>>> not call a function to do a 1 level backtrace and then eliminate the
>>>> next_frame parameter? It would recduce confusion and most ports will have an
>>>> internal unwind function anyway.
> 
> 
>> 
>>> Question - reading through this again I think the goal of call these
>>> functions is to work with the current frame and the function get passed the
>>> child frame so they can do a backtrace if it hasn't already been done... why
>>> not call a function to do a 1 level backtrace and then eliminate the
>>> next_frame parameter? It would recduce confusion and most ports will have an
>>> internal unwind function anyway.
> 
>> 
>> I'm not sure I understand the question.

> I agree, and I don't think it will make much difference eitehr way, however
> I was just thinking that it would be a whole lot easier to explain these
> functions...
> 

Um, this is still dangling.  Can you please express your question using 
terminology consistent with the frame unwind code.

Andrew

Re: Frame handling

[Daniel Jacobowitz]

On Tue, Jul 01, 2003 at 08:58:46AM -0400, Andrew Cagney wrote:
> >>>>Question - reading through this again I think the goal of call these
> >>>>functions is to work with the current frame and the function get passed 
> >>>>the
> >>>>child frame so they can do a backtrace if it hasn't already been 
> >>>>done... why
> >>>>not call a function to do a 1 level backtrace and then eliminate the
> >>>>next_frame parameter? It would recduce confusion and most ports will 
> >>>>have an
> >>>>internal unwind function anyway.
> >
> >
> >>
> >>>Question - reading through this again I think the goal of call these
> >>>functions is to work with the current frame and the function get passed 
> >>>the
> >>>child frame so they can do a backtrace if it hasn't already been done... 
> >>>why
> >>>not call a function to do a 1 level backtrace and then eliminate the
> >>>next_frame parameter? It would recduce confusion and most ports will 
> >>>have an
> >>>internal unwind function anyway.
> >
> >>
> >>I'm not sure I understand the question.
> 
> >I agree, and I don't think it will make much difference eitehr way, however
> >I was just thinking that it would be a whole lot easier to explain these
> >functions...
> >
> 
> Um, this is still dangling.  Can you please express your question using 
> terminology consistent with the frame unwind code.

I think Nick's question is: why does every architecture implement the
cache lazily, instead of GDB instructing the architecture when to
create the cache.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Frame handling

[Andrew Cagney]

> Um, this is still dangling.  Can you please express your question using 
>> terminology consistent with the frame unwind code.
> 
> 
> I think Nick's question is: why does every architecture implement the
> cache lazily, instead of GDB instructing the architecture when to
> create the cache.

(I'm honestly not so sure, I think there is more).

For this question, it's a case of learning from past mistakes.  See 
legacy_get_prev_frame.

The old code tried to do do this - INIT_FRAME_SAVED_REGS but failed. 
General confusion over what was ment to happen when quickly exploded 
into INIT_FRAME_EXTRA_INFO, INIT_FRAME_SAVED_REGS, INIT_FRAME_PC, 
INIT_FRAME_PC_FIRST, FRAME_CHAIN, FRAME_SAVED_PC all trying to 
initialize the cache[s] (there ended up being three!) but many, such as 
FRAME_CHAIN and FRAME_SAVED_PC, found that they couldn't because they 
didn't even have access to the cache).

The new code takes the oposite approach.  Only specify interfaces that 
are absolutly needed and make the unwinder 100% responsible for all 
cache management, populating it based on the immediate demand.

One of Apple's hacks is to do a light weight FRAME_CHAIN (it avoid doing 
prologue analysis).  It may be possible to implement this in the new 
unwinders - id_unwind would only create/populate what was immediatly 
necessary and avoid a full prologue analysis (something that is 
considered expensive).

Andrew

Re: Frame handling

[Jafa]

Hi Andrew

>>> I'm not sure I understand the question.

>> I agree, and I don't think it will make much difference eitehr way,
however
>> I was just thinking that it would be a whole lot easier to explain these
>> functions...
>>

>Um, this is still dangling.  Can you please express your question using
>terminology consistent with the frame unwind code.

Sorry, it was a bit of a ramble :-)

Avr and d10v ports both have function avr/d10v_frame_unwind_cache which
figure out everything about a frame but are internal functions.

The frame-base and frame-unwind APIs provides a machanism to register
functions -

struct frame_base
{
  ...
  frame_this_base_ftype *this_base;
  frame_this_locals_ftype *this_locals;
  frame_this_args_ftype *this_args;
};

struct frame_unwind
{
  ...
  frame_this_id_ftype *this_id;
  frame_prev_register_ftype *prev_register;
};

All five of these functions work on the principle of "given this frame,
figure out xxx information of the caller's frame" and are passed a pointer
to the next_frame (child frame). For example, "given this frame, figure out
where the arguments start of the caller's frame."

I would like to suggest the following:
- <port>_frame_unwind_cache functions to be registered as part of the
frame-unwind API.
- GDB to call <port>_frame_unwind_cache once each time it wants to go back
one frame.
- next_frame parameter removed from all five functions above.
- remove call to <port>_frame_unwind_cache function from the port-specific
implementations of the five functions above.

At a minimum the <port>_frame_unwind_cache function could store the
next_frame parameter and the five functions above could get next_frame from
this_base_cache parameter.

In practice many (most?) ports will do a <port>_frame_unwind_cache function
that figures out everything about the frame in one step and the five
fucntions above will simply read out of the this_base_cache.

Advantages:
- Eliminates some common code from all ports. (call to
<port>_frame_unwind_cache inside each function).
- Eliminates next_frame parameter to these functions.
- Easier to explain/understand the API because you only have to think about
one frame level.
- If a particular port wants the next_frame parameter to search within each
of the five functions then they can save the next_frame parameter themselves
(1 line of code) and it is exactly the same.

I would be happy to provide a patch to look at if that would help explain
and fuel the discussion.

Thanks

Nick

Re: Frame handling

[Jafa]

Hi Andrew,

>The old code tried to do do this - INIT_FRAME_SAVED_REGS but failed.
>General confusion over what was ment to happen when quickly exploded
>into INIT_FRAME_EXTRA_INFO, INIT_FRAME_SAVED_REGS, INIT_FRAME_PC,
>INIT_FRAME_PC_FIRST, FRAME_CHAIN, FRAME_SAVED_PC all trying to
>initialize the cache[s] (there ended up being three!) but many, such as
>FRAME_CHAIN and FRAME_SAVED_PC, found that they couldn't because they
>didn't even have access to the cache).

Yeah, that was a bit of a mess :-)

>The new code takes the oposite approach.  Only specify interfaces that
>are absolutly needed and make the unwinder 100% responsible for all
>cache management, populating it based on the immediate demand.
>
>One of Apple's hacks is to do a light weight FRAME_CHAIN (it avoid doing
>prologue analysis).  It may be possible to implement this in the new
>unwinders - id_unwind would only create/populate what was immediatly
>necessary and avoid a full prologue analysis (something that is
>considered expensive).

Makes sense.... the trick is to leave this power to the port-specific code.

The proposal in my last email still allows the port-writer to implement a
light-weight frame_chain but I have to admit that it doesn't point them in
that direction.

Thanks for your time BTW - My view of the world is pretty small.

Nick

Re: Frame handling

[Andrew Cagney]

> Hi Andrew
> 
> 
>>>> I'm not sure I understand the question.
> 
> 
>>> I agree, and I don't think it will make much difference eitehr way,
> 
> however
> 
>>> I was just thinking that it would be a whole lot easier to explain these
>>> functions...
>>>
> 
> 
>>Um, this is still dangling.  Can you please express your question using
>>terminology consistent with the frame unwind code.
> 
> 
> Sorry, it was a bit of a ramble :-)
> 
> Avr and d10v ports both have function avr/d10v_frame_unwind_cache which
> figure out everything about a frame but are internal functions.
> 
> The frame-base and frame-unwind APIs provides a machanism to register
> functions -
> 
> struct frame_base
> {
>   ...
>   frame_this_base_ftype *this_base;
>   frame_this_locals_ftype *this_locals;
>   frame_this_args_ftype *this_args;
> };
> 
> struct frame_unwind
> {
>   ...
>   frame_this_id_ftype *this_id;
>   frame_prev_register_ftype *prev_register;
> };
> 
> All five of these functions work on the principle of "given this frame,
> figure out xxx information of the caller's frame" and are passed a pointer
> to the next_frame (child frame). For example, "given this frame, figure out
> where the arguments start of the caller's frame."

(To clarify something, they work on the basis of ``given the next 
frame''.  They must assume that ``this frame'' does not exist - an 
attept to call get_prev_frame (next_frame) would be wrong)
(See my e-mail to daniel)

Anyway, the old code did similar to what you suggest.

Because the cache initialize was disconnected from the specific request, 
people were never sure how much to initialize and when.  As a 
consequence, it was done randomly, using random techniques.  GDB (core, 
target and architecture) is littered with calls like:

	if (!frame->extra_info)
	  INIT_FRAME_EXTRA_INFO

and

	if (!frame->saved_regs)
	  INIT_FRAME_SAVED_REGS

So while the line:
	cache = get_frame_cache (next_frame, this_cache);
might seem a pain, its far less of a pain than the old code that had 
very complicated cache initialization rules.

At least it is clear where the buck stops - the entire problem falls 
squarely on the sholders of the unwinder.

> I would like to suggest the following:
> - <port>_frame_unwind_cache functions to be registered as part of the
> frame-unwind API.

BTW, two, and not one initialize methods would need to be added: one for 
frame-unwind, and one for frame-base.  A problem from the old code was 
the plithera of unwind methods, hmm.

> - GDB to call <port>_frame_unwind_cache once each time it wants to go back
> one frame.

> - next_frame parameter removed from all five functions above.

Zero benefit.

Every init frame cache method will have (not could) to store next_frame 
in the cache.  Without it, the frame code couldn't access memory or 
registers.

Burrying the frame (hiding it in a cache) would make debugging gdb a 
royal pain.  At present the applicable frame is made explicit as it is a 
parameter.

Andrew

libgdb

[jacques]

Hello,
I'm currently working on a new debugger, and I want to base it on 
libgdb. However, finding documentation about libgdb, or even finding 
libgdb itself, has proved a daunting task. My understanding is that 
libgdb is simply a library containing all the high level functions of 
gdb, but let's me call them inside my code. Is libgdb rebuilt everytime 
a new gdb comes out? where can i find more information about 
libgdb(google gives me 2 manuals, both very very sparse on any 
information), and where would I get the latest libgdb?
--Jacques

Re: libgdb

[Stan Shebs]

Matthew Hall wrote:
> I've seen references to a libgdb project.
>   
An idea left over from ancient days, never got off the ground. The 
theory was that one could link it into both the traditional command-line 
frontend and into various GUIs. Lots of technical difficulties, two 
chief ones being that 1) it would have had to be a very "wide" API in 
order to be sufficient to cover all of GDB functionality, and 2) the 
library would have to be able to hand control back to the UI on demand, 
difficult when inferior control uses blocking system calls. In practice, 
it seems to work well enough to have the GUI be a separate program that 
communicates with GDB, whether via command line or MI (machine 
interface) syntax, and there is some advantage to the "firewalling" 
inherent in a two-program scheme, so there's not much motivation to do a 
libgdb anymore.

Stan

Re: libgdb

[Daniel Jacobowitz]

On Fri, Nov 02, 2007 at 04:45:45PM +0000, Matthew Hall wrote:
> I've seen references to a libgdb project.
> Can anyone tell me if libgdb is still active?

No.

> Is it complete?

No.

> Is it used internally by gdb itself?

No clear answer to this.  There was a "libgdb interface"; some bits of
GDB use it, other bits do not.  It's all linked in together.

-- 
Daniel Jacobowitz
CodeSourcery

libgdb

[Matthew Hall]

I've seen references to a libgdb project.
Can anyone tell me if libgdb is still active?
Is it complete?
Is it used internally by gdb itself?

Thanks for any info or links to useful documentation.

Re: libgdb

[Elena Zannoni]

Smita writes:
 > Where can I get libgdb from?
 > 

there is no libgdb entity per se. The Mi interface is included with the
regular gdb sources.

 > Thanks!
 > Smita
 > 
 > On Wed, 16 Apr 2003, Elena Zannoni wrote:
 > 
 > > Smita writes:
 > >  > Hi,
 > >  >  I am new to libgdb. Could someone please give me a pointer to its usage
 > >  > documentaion?
 > >  > Thanks
 > >  > Smita
 > >  >
 > >
 > >
 > > http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC207
 > >

Re: libgdb

[Smita]

Where can I get libgdb from?

Thanks!
Smita

On Wed, 16 Apr 2003, Elena Zannoni wrote:

> Smita writes:
>  > Hi,
>  >  I am new to libgdb. Could someone please give me a pointer to its usage
>  > documentaion?
>  > Thanks
>  > Smita
>  >
>
>
> http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC207
>

Re: libgdb

[Elena Zannoni]

Smita writes:
 > Hi,
 >  I am new to libgdb. Could someone please give me a pointer to its usage
 > documentaion?
 > Thanks
 > Smita
 > 


http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC207

libgdb

[Smita]

Hi,
 I am new to libgdb. Could someone please give me a pointer to its usage
documentaion?
Thanks
Smita

Re: libgdb

[Joel Brobecker]

> 1) Invoke GDB and parse the command line (emacs does this)
> 2) Invoke GDB's MI interpreter and write yourself an MI parser (Eclipse 
> and Apple's tools for MacOS X do this)
> 3) Write your GUI using GDB's hooks and events (Insight does this)
> 
> Obviously, #2 is the most desirably way to isolate yourselves from GDB 
> changes. Unfortunately, MI is still a work in progress. (Of course, I'm 
> still partial to #3 for speed.. ;-)

One advantage of method #1 or #2, used by GVD, is that GDB is a separate
process. This GDB process does not need to run on the same host as GVD.
Even if I'm debugging on a distant machine, I can run GVD on my local
machine, reducing tremendously the network traffic. Given that I live in
the west coast, and that most machines I work on are located in NY and
Paris, this is a definite plus.

I think GVD uses method #1, but I would recommend method #2 as the
output is most probably easier to parse.

-- 
Joel

Re: libgdb

[Keith Seitz]

On Fri, 22 Nov 2002 a2782@dis.ulpgc.es wrote:

> I am involved in a project of making a educational graphic interface 
> and we are thinking about putting it over GDB. My question is: Has 
> anybody worked with libgdb? My first approximation is invoking gdb as 
> Emacs does, but using libgdb. I hope someone has worked with libgdb and 
> can help and advise me.

Sadly, libgdb is a pipedream, and still quite a ways off (but it's 
getting closer almost every day).

There are three ways to commonly interface some sort of GUI application 
top of GDB:

1) Invoke GDB and parse the command line (emacs does this)
2) Invoke GDB's MI interpreter and write yourself an MI parser (Eclipse 
and Apple's tools for MacOS X do this)
3) Write your GUI using GDB's hooks and events (Insight does this)

Obviously, #2 is the most desirably way to isolate yourselves from GDB 
changes. Unfortunately, MI is still a work in progress. (Of course, I'm 
still partial to #3 for speed.. ;-)

Keith

libgdb

[a2782]

Hi to all!

I am involved in a project of making a educational graphic interface 
and we are thinking about putting it over GDB. My question is: Has 
anybody worked with libgdb? My first approximation is invoking gdb as 
Emacs does, but using libgdb. I hope someone has worked with libgdb and 
can help and advise me.

Thanks in advance!

libgdb

[Satya]

Hi,
  I am new to libgdb.Can some one tell me how I can use libgdb to
construct an object containing the result of the gdb command.

Thanks,
Satya