This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]