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

[Daniel Jacobowitz <drow at mvista dot com>]

On Sun, Feb 15, 2004 at 04:36:50PM -0500, Andrew Cagney wrote:
> But why should the architecture be supplying it to gdbarch, when it is 
> the dwarf2 frame code that needs it?

By this explanation nothing belongs in gdbarch at all.  Gdbarch is not
a thing which can need other things.  It has producers and consumers
but is neither.

It sounds like we're moving away from gdbarch as the repository of
target-specific code in favor of each subsystem parametrizing itself. 
Is that a good summary?

> Um, actually, why is this case different?  Neither Mark nor I are doing 
> anything new here.  frame-unwind, libunwind-frame, user-regs, 
> frame-base, reggroups, regcache, v3abi, ... all, already use 
> gdbarch_data.  The general trend of decomposing gdbarch into more 
> digestable chunks has been going on for years.

Some of those at least are not good examples, because they are either
orthogonal to the OS/ABI - c++ ABI (v3abi) - or not one-to-one with the
ABI (frame unwind, frame base).  Whereas this method describes a
property of the ABI.  That's how it's different.

> While existing code continues to add to gdbarch.sh, new more modular 
> code is using gdbarch_data.

I guess the above is a good summary, then.  Should it be written down
somewhere?  I find the step from module-specific per-architecture data
(created by the module) to module-specific per-architecture
configuration hooks (provided, maybe optionally, by the architecture)
to be a bit confusing.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer