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


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

(Tuesday .CA) The bulk of the discussion was about:
http://sources.redhat.com/ml/gdb/2002-03/msg00154.html
and its implications.

However, implementation details on the bit of code below did come up. 
 From memory JimB was proposing that the code be in two parts: a 
completly separate 100% parameterized engine; a wrapper function s(one 
for CFI one for Dan's needs).  I was more for a single function and a 
``struct frame_info *'' parameter.  Given I'm not likely to be the one 
implementing it, it probably doesn't matter to me :-)

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

I suspect a function call here might be a good idea as well - to ensure 
that the value isn't used when it hasn't been computed or to delay its 
computation.

Andrew



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