GDBARCH vs frame vs stacks

GDBARCH vs frame vs stacks

[Andrew Cagney]

Hello,

Dan recently put forward a suggestion that the gdbarch code be changed 
to be stackable so that a problem with the way GDB analizes frames. At 
the time my gut reaction was ``no''. Given that part of the reaction was 
based on gut feeling I should probably review and expand my comments - 
it really felt like using an R.V. (1) for a road trip because someone 
might want to BBQ a srimp. (Everyone knows that you use the exaust 
manafold to BBQ things on road trips right? :-)

Having had some more time to think about it I still think stacking 
gdbarch to solve this problem is indeed wrong. In the below I'll try to 
outline my rationale.


The architecture:

The GDB architecture object carries with it a number of different pieces 
of, sometimes orthongonaly, information: the ISA, the ABI, the SOLIBS, 
debug/register info, ... Within these, all sorts of different 
combnations are possible.

For the GDBARCH vector, it was decided that, while many different 
combinations are possible - a mesh - few at any would be active. It it 
was also noted that, over time, sub components, would bubble to the 
surface and be separated out. With this in mind, the gdbarch object was 
made flat.

In hindsite this was indeed the correct decision. It as facilitated a 
relatively painless multi-arch conversion. It has also allowed 
individual components, to indeed separate out - shlibs come to mind.


The frame:

GDB's concept of a frame was deveoped back when the only thing of 
interest was a VAX. Over time it has evolved and now some aspects of its 
design are clearly showing their age - FP_REGNUM/READ_FP for instance.

Examining the target code reveals, like you suggest, a very interesting 
trait. Many targets, such as the prologue analysis functions, go through 
a sequence like: try analysis using debug info; try analysis using 
instructions; try analysis using tea leaves; punt (and not necessarily 
in that order). When looking at such code, the reaction would indeed be 
- hey stack!


Should GDBARCH therefor be stacked?

The thing to remember is that, just because the frame code uses some 
sort of ordered sequence (or is it an acyclic graph - that isn't even 
clear) when doing its analysis, that sequence doesn't necessarily apply 
to the entire GDBARCH vector. Per the above, the GDBARCH vector is 
really a mesh.

I think imposing a frame centric view on GDBARCH's mesh is wrong. The 
the frame code, through re-design, should handle that.

Rather than dumping the problem on gdbarch, I think the thing to do is 
review the way that core-gdb interacts with a frame and determine an 
interaction model that accomodates both existing abi and abi's based 
around dwarf2 info. In doing this, the end result should be a good clean 
understandable (and not dwarf2 centric) design.

Andrew


(1) An R.V. is like a campervan but far more grand. Think of a seriously 
oversize bus. Typically seen towing a large 4wd (S.R.V.) towing a small 
car ....

Re: GDBARCH vs frame vs stacks

[Daniel Berlin]

On Sun, 13 May 2001, Andrew Cagney wrote:

> Hello,
>
> Dan recently put forward a suggestion that the gdbarch code be changed
> to be stackable so that a problem with the way GDB analizes frames. At
> the time my gut reaction was ``no''. Given that part of the reaction was
> based on gut feeling I should probably review and expand my comments -
> it really felt like using an R.V. (1) for a road trip because someone
> might want to BBQ a srimp. (Everyone knows that you use the exaust
> manafold to BBQ things on road trips right? :-)
>
> Having had some more time to think about it I still think stacking
> gdbarch to solve this problem is indeed wrong. In the below I'll try to
> outline my rationale.
>
>
> The architecture:
>
> The GDB architecture object carries with it a number of different pieces
> of, sometimes orthongonaly, information: the ISA, the ABI, the SOLIBS,
> debug/register info, ... Within these, all sorts of different
> combnations are possible.
>
> For the GDBARCH vector, it was decided that, while many different
> combinations are possible - a mesh - few at any would be active. It it
> was also noted that, over time, sub components, would bubble to the
> surface and be separated out. With this in mind, the gdbarch object was
> made flat.
>
> In hindsite this was indeed the correct decision. It as facilitated a
> relatively painless multi-arch conversion. It has also allowed
> individual components, to indeed separate out - shlibs come to mind.
>
>
> The frame:
>
> GDB's concept of a frame was deveoped back when the only thing of
> interest was a VAX. Over time it has evolved and now some aspects of its
> design are clearly showing their age - FP_REGNUM/READ_FP for instance.
>
> Examining the target code reveals, like you suggest, a very interesting
> trait. Many targets, such as the prologue analysis functions, go through
> a sequence like: try analysis using debug info; try analysis using
> instructions; try analysis using tea leaves; punt (and not necessarily
> in that order). When looking at such code, the reaction would indeed be
> - hey stack!
>
>
> Should GDBARCH therefor be stacked?
>
> The thing to remember is that, just because the frame code uses some
> sort of ordered sequence (or is it an acyclic graph - that isn't even
> clear) when doing its analysis, that sequence doesn't necessarily apply
> to the entire GDBARCH vector. Per the above, the GDBARCH vector is
> really a mesh.
>
> I think imposing a frame centric view on GDBARCH's mesh is wrong. The
> the frame code, through re-design, should handle that.
>

> Rather than dumping the problem on gdbarch, I think the thing to do is
> review the way that core-gdb interacts with a frame and determine an
> interaction model that accomodates both existing abi and abi's based
> around dwarf2 info. In doing this, the end result should be a good clean
> understandable (and not dwarf2 centric) design.

Sure. I just didn't want to resdesign the frame ATM, to be honest, because
it would open up a can of worms since i'm sure everyone has *something*
they want frames to be able to do, that they don't do now, and thus, i'd
be getting myself into too much ATM.  There was nothing dwarf2 specific
about my current interjection into *_get_saved_register, in actuality. I
had added a symbol file hook (well two) for getting and evaluating call frame
info, and made the elf reader (which is where these hooks are acutally
used) call through to dwarf2's getting and evaluating routines (because no
other formats we currently support support it).  All i had added to the
actual *_get_saved_register routines was the code to get the objfile for
the frame function, and call through to it's hook.

However, it does bother me that you keep brining up a dwarf2 centric view
whenever i mention using dwarf2 for this or that.  I only talk about it
because it's the only thing that is very widely used, and supports
optimized debugging to a very large extent.  I don't believe i've ever
proposed anything that I planned to implement in a way that other debug
formats couldn't use it (even the location list stuff isn't dwarf2
specific, i just only implemented support in the dwarf2 reader. There
really isn't another way to decribe the location of something in a way
you can evaluate at runtime  other than some kind of stack machine and
opcodes.), nor would I.
It really bothers me how much of the symbol table stuff is completely
designed to be an in memory structure for, well, stabs (or some
equivalent but not using strings format), rather than designed to be a
good symbol table interface.
Things like partial symbols being required, when >1 debug format we
support not only doesn't need them, but they waste time and memory to use
them. It's a complete lose.  I am very careful and try to not make the
same type of mistake.

I wouldn't even have to complain so much if the symbol table stuff didn't
force things onto debug format readers.  Heck, most formats these days
actually have almost no need for a real, honest to god symbol table
somewhere in  memory. I know of at least three debuggers that just lookup
the symbol direct in the debug info (since most formats have the indexes
necesary),  and read it into whatever symbol structure on the fly.  They
then just have some cache to retain some x megabytes of last used symbols.

I was, however, planning to look at frames in a few months, since I want
to be able to fake frames for inline functions, etc.
--Dan
 > > Andrew
>
>
> (1) An R.V. is like a campervan but far more grand. Think of a seriously
> oversize bus. Typically seen towing a large 4wd (S.R.V.) towing a small
> car ....
>

Re: GDBARCH vs frame vs stacks

[Daniel Berlin]

On Mon, 14 May 2001, Daniel Berlin wrote:

>
>
> On Sun, 13 May 2001, Andrew Cagney wrote:
>
> > Hello,
> >
> > Dan recently put forward a suggestion that the gdbarch code be changed
> > to be stackable so that a problem with the way GDB analizes frames. At
> > the time my gut reaction was ``no''. Given that part of the reaction was
> > based on gut feeling I should probably review and expand my comments -
> > it really felt like using an R.V. (1) for a road trip because someone
> > might want to BBQ a srimp. (Everyone knows that you use the exaust
> > manafold to BBQ things on road trips right? :-)
> >
> > Having had some more time to think about it I still think stacking
> > gdbarch to solve this problem is indeed wrong. In the below I'll try to
> > outline my rationale.
> >
> >
> > The architecture:
> >
> > The GDB architecture object carries with it a number of different pieces
> > of, sometimes orthongonaly, information: the ISA, the ABI, the SOLIBS,
> > debug/register info, ... Within these, all sorts of different
> > combnations are possible.
> >
> > For the GDBARCH vector, it was decided that, while many different
> > combinations are possible - a mesh - few at any would be active. It it
> > was also noted that, over time, sub components, would bubble to the
> > surface and be separated out. With this in mind, the gdbarch object was
> > made flat.
> >
> > In hindsite this was indeed the correct decision. It as facilitated a
> > relatively painless multi-arch conversion. It has also allowed
> > individual components, to indeed separate out - shlibs come to mind.
> >
> >
> > The frame:
> >
> > GDB's concept of a frame was deveoped back when the only thing of
> > interest was a VAX. Over time it has evolved and now some aspects of its
> > design are clearly showing their age - FP_REGNUM/READ_FP for instance.
> >
> > Examining the target code reveals, like you suggest, a very interesting
> > trait. Many targets, such as the prologue analysis functions, go through
> > a sequence like: try analysis using debug info; try analysis using
> > instructions; try analysis using tea leaves; punt (and not necessarily
> > in that order). When looking at such code, the reaction would indeed be
> > - hey stack!
> >
> >
> > Should GDBARCH therefor be stacked?
> >
> > The thing to remember is that, just because the frame code uses some
> > sort of ordered sequence (or is it an acyclic graph - that isn't even
> > clear) when doing its analysis, that sequence doesn't necessarily apply
> > to the entire GDBARCH vector. Per the above, the GDBARCH vector is
> > really a mesh.
> >
> > I think imposing a frame centric view on GDBARCH's mesh is wrong. The
> > the frame code, through re-design, should handle that.
> >
>
> > Rather than dumping the problem on gdbarch, I think the thing to do is
> > review the way that core-gdb interacts with a frame and determine an
> > interaction model that accomodates both existing abi and abi's based
> > around dwarf2 info. In doing this, the end result should be a good clean
> > understandable (and not dwarf2 centric) design.
>
> Sure. I just didn't want to resdesign the frame ATM, to be honest, because
> it would open up a can of worms since i'm sure everyone has *something*
> they want frames to be able to do, that they don't do now, and thus, i'd
> be getting myself into too much ATM.  There was nothing dwarf2 specific
> about my current interjection into *_get_saved_register, in actuality. I
> had added a symbol file hook (well two) for getting and evaluating call frame
> info, and made the elf reader (which is where these hooks are acutally
> used) call through to dwarf2's getting and evaluating routines (because no
^^^^^
I meant defined here, not used.
Since we don't support dwarf2 encapsulated in non-ELF right now anyway,
and none of the non-ELF object file readers support a format that does
have the kind of info we want,  the hooks for other objfile readers do
nothing.

--Dan

Re: GDBARCH vs frame vs stacks

[Andrew Cagney]

> Rather than dumping the problem on gdbarch, I think the thing to do is
>> review the way that core-gdb interacts with a frame and determine an
>> interaction model that accomodates both existing abi and abi's based
>> around dwarf2 info. In doing this, the end result should be a good clean
>> understandable (and not dwarf2 centric) design.
> 
> 
> Sure. I just didn't want to resdesign the frame ATM, to be honest, because
> it would open up a can of worms since i'm sure everyone has *something*
> they want frames to be able to do, that they don't do now, and thus, i'd
> be getting myself into too much ATM.  There was nothing dwarf2 specific
> about my current interjection into *_get_saved_register, in actuality. I
> had added a symbol file hook (well two) for getting and evaluating call frame
> info, and made the elf reader (which is where these hooks are acutally
> used) call through to dwarf2's getting and evaluating routines (because no
> other formats we currently support support it).  All i had added to the
> actual *_get_saved_register routines was the code to get the objfile for
> the frame function, and call through to it's hook.


What I have in mind is rationalization of the frame object so that it 
does less not more.  To me the problem is that the frame abstraction is 
confused - not suprising given it has evolved over time.

The recent proposals to sort out the register interface is an example. 
It actually ends up with a smaller simpler interface.

Hopefully it is possible to look at the dwarf2 abstraction model and 
find something that is common to both it and the other debug systems.

	Andrew