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]

Re: [PATCH] Add support for tracking/evaluating dwarf2 location expressions


Andrew Cagney <ac131313@cygnus.com> writes:

> Dan, just some things to tweek,
> 
> State machines are normally implemented using a switch and not a chain
> of ifs.  Check dwarf2read.c:decode_locdesc() as an example (hmm, slight
> dejavu :-).

I actually just ripped mine, and copied the one from gcc's
unwind-dw2.c, and modified it to use the right gdb functions instead.
It's implemented as a switch.

It would be nice to just directly share it with gcc, but i doubt
that's feasible.

> Don't forget ``a = b'' not ``a=b''.
> 
> Just use ``struct value *'', I've every intention of zapping
> ``value_ptr''! :-)

I just turned it into a shell around execute_stack_op (see
unwind-dw2.c in the gcc source, it just does what i did, without using
values, just pointers), which uses a stack of CORE_ADDR's. We then
take whatever it gives us, and turn it into a value, once, and return that.

> 
>   value_ptr stack[64];
> Is there a constant for this?  A quick glance at decode_locdesc() and it
> has the same hardwired constant.
Nobody has ever produced location expressions that need more.

I wouldn't worry too much about it, the dwarf2 unwinder in gcc used to
handle exceptions has the exact same limitation. So if they aren't
worried about mission critical/ multi-threaded code that tries to catch/throw
exceptions breaking, i'm not to worried about the debugger used to
debug them breaking. :)

I can't think of anything that needs more than 64 stack slots to
describe in dwarf2 location expressions. I'm pretty sure i could
implement some pretty useful *real* programs in that limit, let alone
simple descriptions of locations.
> 
> >From memory, the dwarf2 state machine doco states that you should return
> the top-of-stack when the machine has finished executing.  This means
> that the stack may not be empty and that the code could potentially leak
> ``struct value *''s.

This is fixed by the change to a stack of CORE_ADDR's.

> 
> 	enjoy,
> 		Andrew

-- 
The other night I came home late, and tried to unlock my house
with my car keys.  I started the house up.  So, I drove it
around for a while.  I was speeding, and a cop pulled me over.
He asked where I lived.  I said, "right here, officer".  Later,


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