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

[Jim Blandy <jimb at zwingli dot cygnus dot com>]

Hey, everyone.  If folks think the general direction we're going here
(explained in my first post to this thread) is not a good idea, speak
now.  Stuff is happening.

Daniel Berlin <dan@cgsoftware.com> writes:
> void init_locexpr (locexpr *);
> void destroy_locexpr (locexpr *);
> void locexpr_push_op  (locexpr, enum locexpr_opcode, const char *, ...);
> void locexpr_get_op (locexpr, unsigned int,  enum locexpr_opcode *);
> void locexpr_get_longest (locexpr, unsigned int, LONGEST *);
> void locexpr_get_ulongest (locexpr, unsigned int, ULONGEST *);
> void locexpr_get_uchar (locexpr, unsigned int, unsigned char *);
> value_ptr evaluate_locexpr (struct symbol *, struct frame_info *, locexpr, struct type *);

GDB tends not to use typedefs, which I think is a good thing.  I think
`struct locexpr' would be better.

There should be a way to efficiently build locexprs in obstacks.

How big are your stack elements?  I think it's very important that the
semantics of a particular string of bytecodes be independent of word
size issues.  That is, if I construct a particular string, I want it
to compute the same values no matter what sort of host I'm running on.
Have you thought about how to ensure that architecturally?  Think
about right shifts, divides, comparisons --- anything that can bring
information down from the upper bits.

> I kept bregx only because we already have a location type for based
> registers, so it seemed to make sense (Admittedly, all it does is take
> us from two opcodes to one for this).

I think it should be deleted.

> fbreg we can't get rid of, we don't necessarily know the frame
> register at debug reading time (it may itself be using a location list
> to say where it is).

Yep, it's its own animal.

> We could get rid of the "default" opcodes deref and xderef, and just
> always use xderef_size and deref_size with an explicit size.

I think we should do that.

> If everyone agrees, i'll write up the docs on these opcodes, and the
> functions to manipulate location expressions.

Yeah, the interface isn't clear to me.  I'm especially curious about
that constructor.  Varargs give me the heebie-jeebies.  I think Andrew
has said he feels the same way.

> Eventually, I'll get rid of all the other location types, but this can
> be done incrementally, so it's no rush at all.

Right, that's where I want to go with this too.  Note that if we do
that, the LOC_* enum encodes information about whether something is an
argument or not (i.e., LOC_ARG vs. LOC_LOCAL, LOC_REGISTER
vs. LOC_REGPARM).  We'll need to encode that information otherhow.