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] Let dwarf2 CFI's execute_stack_op be used outside of CFI



Daniel Berlin <dan@dberlin.org> writes:
> I didn't want to deal with the issue of whether we want to return a struct 
> value, and the issue of how best to keep track of whether it's in memory 
> or a register, without getting an opinion first.

I spoke with Andrew on the phone yesterday, and he and I have
different ideas about how things should go.  I don't think I
understood the path of changes he wanted to see.

My personal inclination is to make the Dwarf 2 location expression
interpreter as independent from GDB as possible.  It can use the
CORE_ADDR type for stack elements, but it should take arguments
specifying:
- the expression as a simple char * pointer and length,
- the architecture's address size,
- function pointers for reading memory and registers that simply hand
  back a CORE_ADDR value (thus keeping the interpreter innocent of
  endianness issues), and
- the frame base address (for DW_OP_fbreg)

It should return a structure that says whether the location expression
specified a particular register (i.e., DW_OP_reg0 and friends) or an
address.  Actually, the return value should be a list of pieces, each
of which gives a byte length and then a register or address.

But I tend to think it shouldn't take a struct frame_info or struct
context, and it shouldn't return a struct value.  Sure, you'll need
more glue code than you would if it took just the right arguments for
the use we have in mind, but keeping it as innocent of GDB as possible
makes the interface easier to understand: you don't need to wonder how
it interacts with a frame's saved registers, how it finds the frame
base, and so on.  You can look at the code and say, "Ah, this doesn't
worry about any of that."  There's a simple test for the module
boundaries: if a behavior is described in the Dwarf spec chapter on
location expressions, it should be inside; otherwise, it should be
outside.  And once you've written frame/struct value glue code,
everyone can use that and nobody minds.

What a lot of hand-waving.  Sorry.  Hopefully you'll see what I'm
getting at.


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