Re: [PATCH/RFC] Per-architecture DWARF CFI register state initialization hooks

[Daniel Jacobowitz <drow@mvista.com>]

On Sun, Feb 15, 2004 at 02:49:16PM -0500, Andrew Cagney wrote:
> >
> >Since I am obviously not getting it, could someone explain to me what
> >the modularity advantage is?
> 
> Are you asking why modularity, in general, is advantage, or why here 
> specifically this is more modula and hence an advantage?

The latter, of course.  With a nod towards the former, see below.

> The dwarf2-frame is able to locally, and opaquely (to other components) 
> implement the per-architecture mechanisms that it needs.  No need to 
> bloat that architecture vector with yet another global interface that 
> nothing, other than dwarf2-frame requires.  No need to publish anything 
> other than what is specificly relevant to dwarf2-frame's clients - the 
> dwarf2 initialize routine.

This is what I don't understand.  Almost every architecture supported
by GDB will eventually support dwarf2-frame.  It is to the
architecture's advantage to supply this method, and in fact my
understanding was that many architectures will want to use it to
indicate which registers are considered call-clobbered and thus no
longer available (barring the issue of optimizations which change
calling convention).  It's no more a marginal method than (to pick an
example at random) PC_IN_SIGTRAMP.

Why is this different?  Are you saying that it would be preferable for
many of the methods currently in the architecture vector to move
outside of it into more modular pieces, e.g. function calling,
type-related, et cetera?  When you have that many pieces, I'm not sure
that you've gained any clarity.

So the architecture initialization functions will change into a lot of
set_dwarf2_frame_foo_func, set_infcall_bar_func instead of
set_gdbarch_foo_func and set_infcall_bar_func.

> 
> >All I see is a function pointer, with a default value or overridden by
> >the architecture initialization, used to parametrize a module's
> >behavior.  That is the same niche as every existing member of the
> >gdbarch vector.
> 
> Andrew
> 
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer