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

[Andrew Cagney <cagney@gnu.org>]

> 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).

But why should the architecture be supplying it to gdbarch, when it is 
the dwarf2 frame code that needs it?

 >  It's no more a marginal method than (to pick an
> example at random) PC_IN_SIGTRAMP.

Er: Use get_frame_type() == SIGTRAMP_FRAME instead of PC_IN_SIGTRAMP
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=1159

> 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.

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.

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

> 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.

MarkK is equally free to do something like replace

     frame-unwind::add_frame_sniffer
         (gdbarch, dwarf2-frame::dwarf2_frame_sniffer);

with:

     dwarf2-frame::add_dwarf2_frame_sniffer
         (gdbarch, <the arches optional CFI init function>);

In fact, Mark, I'd highly recommend it - it will screw down the 
interface further.

enjoy,
Andrew