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

Daniel Jacobowitz
2004-02-15T22:54:40Z

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