GDB Documentation and Request for Help

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	 eagereagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

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	 eagereagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

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

Daniel Jacobowitz <drowfalse.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.)

Jim Blandy wrote:
> Daniel Jacobowitz <drowfalse.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	 eagereagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

> Date: Fri, 30 Mar 2007 14:14:47 -0700
> From: Michael Eager <eagereagercon.com>
> CC:  gdbsources.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.

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://tea
water.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....