GDB Documentation and Request for Help

GDB Documentation and Request for Help

[Michael Eager]

I'm trying to move a proprietary target from an old version
of gdb (5.3) to the latest version.  Based on seeing that
there was no clear way to translate the existing target support
to the current gdb architecture (and with a little advice from
the mailing list) I decided to create a new port for the target.

So that's coming along, but I'm having trouble figuring out
frame handling, in particular, when and where the current target
registers are read into the current frame.  After stumbling around
tracing the code for a while, I decided to take the plunge and
actually (re-)read the gdb internals document.

So I found the description of frames and the sentinel frame.
Not where I had been looking, under the chapter titled Target
Architecture Definition, but by accident, under Algorithms.
Under the former section, I found what I was looking for:
FRAME_INIT_SAVED_REGISTERS, now renamed DEPRECATED_.  But when
I look in the code, I find that this was removed in 2004.

So the gdb internals document comes close to being useless,
IMO.  There are several sections which are empty, others which
declare themselves to be obsolete, parts which are more-or-less
unclear, and worse, parts which appear to explain the internals
but are several years out of date.

If someone would volunteer to spend an hour or two helping me
understand frame handling and what parts of the Architecture
Definition section are (as the politicos say) no longer
operative, and what they should say, I'll update the document
to incorporate those changes.  I won't rewrite the gdb internals
document, although it really needs this, but even removing
misleading text would be an improvement.

Thanks in advance!

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: GDB Documentation and Request for Help

[Jim Blandy]

Michael Eager <eager@eagercon.com> writes:
> So that's coming along, but I'm having trouble figuring out
> frame handling, in particular, when and where the current target
> registers are read into the current frame.

This is a tricky part; welcome to the club.  :)

> So I found the description of frames and the sentinel frame.
> Not where I had been looking, under the chapter titled Target
> Architecture Definition, but by accident, under Algorithms.
> Under the former section, I found what I was looking for:
> FRAME_INIT_SAVED_REGISTERS, now renamed DEPRECATED_.  But when
> I look in the code, I find that this was removed in 2004.
>
> So the gdb internals document comes close to being useless,
> IMO.  There are several sections which are empty, others which
> declare themselves to be obsolete, parts which are more-or-less
> unclear, and worse, parts which appear to explain the internals
> but are several years out of date.

The internals document functions more as a repository of explanations
that get written from time to time.  It certainly doesn't meet the
usual standards for reference works.

> If someone would volunteer to spend an hour or two helping me
> understand frame handling and what parts of the Architecture
> Definition section are (as the politicos say) no longer
> operative, and what they should say, I'll update the document
> to incorporate those changes.  I won't rewrite the gdb internals
> document, although it really needs this, but even removing
> misleading text would be an improvement.

If you post here, I think people would be happy to explain what's
current and what isn't.  I'll watch for your messages.

Re: GDB Documentation and Request for Help

[Michael Eager]

Jim Blandy wrote:

> If you post here, I think people would be happy to explain what's
> current and what isn't.  I'll watch for your messages.

Thanks.  I think that my questions are not very specific and
it would be better to go through the Target Arch chapter
and mark it up.

But here goes:  what did FRAME_INIT_SAVED get replaced by?

Or, the much more general question:  when the target hits a
breakpoint, where are the registers read and how does the
current frame get initialized with a frame pointer?  (I've
stepped thru normal_stop, and I know it must be somewhere
nearby, but I've not found it.)

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: GDB Documentation and Request for Help

[Daniel Jacobowitz]

On Fri, Mar 30, 2007 at 11:26:39AM -0700, Michael Eager wrote:
> Jim Blandy wrote:

> >If you post here, I think people would be happy to explain what's
> >current and what isn't.  I'll watch for your messages.

> Thanks.  I think that my questions are not very specific and
> it would be better to go through the Target Arch chapter
> and mark it up.

> But here goes:  what did FRAME_INIT_SAVED get replaced by?

It got replaced by an entirely demand driven system.  There's only two
entry points: this_id and prev_register.  Every registered unwinder
provides both.

> Or, the much more general question:  when the target hits a
> breakpoint, where are the registers read and how does the
> current frame get initialized with a frame pointer?  (I've
> stepped thru normal_stop, and I know it must be somewhere
> nearby, but I've not found it.)

The old model required explicitly setting up the frame, but nowadays
that isn't true.  What happens is that the frame cache is cleared by a
call to reinit_frame_cache.  The next time someone says
get_current_frame (), they get two things:

  - A sentinel frame at "level -1".  This has no particularly useful
    ID, and a prev_register method that reads from the current
    register cache.

  - An all new frame at level 0.  This doesn't have an unwinder yet;
    it's just a shell.

When you ask for a register belonging to the current frame, frame.c
goes up to the next frame (the sentinel frame) and uses its
prev_register method.  When you ask for the current frame's ID, or
for something below it, then frame.c finds a registered unwinder that
knows how to handle that frame.

Usually this_id and prev_register share a common cache, and the first
time either of them is called they call a cache initialization
function which does whatever necessary.  For instance, parsing the
prologue, or reading DWARF unwind tables.

(Of course, doing less work up front is OK too and that's something I
plan to look into - along with better caching.  The whole
infrastructure is designed to be lightweight, but it isn't always.)

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB Documentation and Request for Help

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:
> On Fri, Mar 30, 2007 at 11:26:39AM -0700, Michael Eager wrote:
>> Jim Blandy wrote:
>
>> >If you post here, I think people would be happy to explain what's
>> >current and what isn't.  I'll watch for your messages.
>
>> Thanks.  I think that my questions are not very specific and
>> it would be better to go through the Target Arch chapter
>> and mark it up.
>
>> But here goes:  what did FRAME_INIT_SAVED get replaced by?
>
> It got replaced by an entirely demand driven system.  There's only two
> entry points: this_id and prev_register.  Every registered unwinder
> provides both.

Michael, your question suggests that you're looking at some code in
your old port, and trying to figure out where it goes in your new
port.  I would find that a very hard question to answer if I were in
your shoes.  Instead, start by reading frame-unwind.h and having your
foo_gdbarch_init function call frame_unwind_append_sniffer with a
structure containing appropriate functions, written from scratch.

In other words, you may be able to use the old port to understand how
your target works, but you'll need to decide afresh how to express
that understanding in the new arch description framework.

(Having worked on both, I think the new frame system is *much* nicer
to work with, and more reliable.  So your efforts won't be wasted.)

Re: GDB Documentation and Request for Help

[Michael Eager]

Jim Blandy wrote:
> Daniel Jacobowitz <drow@false.org> writes:
>> On Fri, Mar 30, 2007 at 11:26:39AM -0700, Michael Eager wrote:
>>> Jim Blandy wrote:
>>>> If you post here, I think people would be happy to explain what's
>>>> current and what isn't.  I'll watch for your messages.
>>> Thanks.  I think that my questions are not very specific and
>>> it would be better to go through the Target Arch chapter
>>> and mark it up.
>>> But here goes:  what did FRAME_INIT_SAVED get replaced by?
>> It got replaced by an entirely demand driven system.  There's only two
>> entry points: this_id and prev_register.  Every registered unwinder
>> provides both.
> 
> Michael, your question suggests that you're looking at some code in
> your old port, and trying to figure out where it goes in your new
> port.  I would find that a very hard question to answer if I were in
> your shoes.  Instead, start by reading frame-unwind.h and having your
> foo_gdbarch_init function call frame_unwind_append_sniffer with a
> structure containing appropriate functions, written from scratch.
> 
> In other words, you may be able to use the old port to understand how
> your target works, but you'll need to decide afresh how to express
> that understanding in the new arch description framework.

That's exactly the approach I'm taking.

> (Having worked on both, I think the new frame system is *much* nicer
> to work with, and more reliable.  So your efforts won't be wasted.)

I'm sure that it is.  It's just not documented.  Reading code from
other targets to figure out what's needed is, well, challenging.

I'll take another look at frame-unwind.h.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: GDB Documentation and Request for Help

[Eli Zaretskii]

> Date: Fri, 30 Mar 2007 14:14:47 -0700
> From: Michael Eager <eager@eagercon.com>
> CC:  gdb@sources.redhat.com
> 
> > (Having worked on both, I think the new frame system is *much* nicer
> > to work with, and more reliable.  So your efforts won't be wasted.)
> 
> I'm sure that it is.  It's just not documented.

Yes, unfortunately.  However, if, after you figure that out, you
publish your findings and understandings, I promise to make a manual
section out of what you write and add that to gdbint.texinfo.

Thanks in advance.

RE: GDB Documentation and Request for Help

[Dave Korn]

On 30 March 2007 22:15, Michael Eager wrote:

> Jim Blandy wrote:

>> Michael, your question suggests that you're looking at some code in
>> your old port, and trying to figure out where it goes in your new
>> port.  I would find that a very hard question to answer if I were in
>> your shoes.  Instead, start by reading frame-unwind.h and having your
>> foo_gdbarch_init function call frame_unwind_append_sniffer with a
>> structure containing appropriate functions, written from scratch.
>> 
>> In other words, you may be able to use the old port to understand how
>> your target works, but you'll need to decide afresh how to express
>> that understanding in the new arch description framework.
> 
> That's exactly the approach I'm taking.
> 
>> (Having worked on both, I think the new frame system is *much* nicer
>> to work with, and more reliable.  So your efforts won't be wasted.)
> 
> I'm sure that it is.  It's just not documented.  Reading code from
> other targets to figure out what's needed is, well, challenging.
> 
> I'll take another look at frame-unwind.h.

  I stumbled across a fairly useful document some time ago: "Porting GDB (1) arch and frame v0.4", at 

http://teawater.googlepages.com/epgdb1.pdf

(there's also a .txt equivalent if you'd prefer).  Although it's far from complete, and English is not teawater's first language, it's pretty clear and comprehensible, and has much more up-to-date information than gdbint.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....