From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Jim Blandy Cc: Daniel Berlin , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Add support for tracking/evaluating dwarf2 location expressions Date: Tue, 22 May 2001 13:51:00 -0000 Message-id: <87n1852jnf.fsf@dynamic-addr-83-177.resnet.rochester.edu> References: <87heye17ck.fsf@dynamic-addr-83-177.resnet.rochester.edu> X-SW-Source: 2001-05/msg00415.html Jim Blandy writes: > Daniel Berlin writes: > > However, IMHO, the location expression language that dwarf2 uses is > > self-contained, and suited for GDB's needs. Perfectly in fact. It > > provides no more or less than necessary to describe our locations, > > except where it saved a little space in real use (see below) and > > it's trivial to convert other expression languages into it. and The > > location list is simply a list of ranges and location expressions, > > which is what we would have come up with anyway, judging from GDB structures. > > > > In fact, I'd wager if we tried, we'd come up with something almost > > exactly like d2 location expressions: > > > > We would want some kind of simple, stack based language. > > Normal binary and unary arithmetic operations, and normal stack > > operations (rotate, pop, drop, etc). > > Past these, we'd want a way of: > > dereferencing the value on top of the stack as if it was a memory address. > > A way to load constant values onto the stack > > A way to load register values onto the stack > > An efficient encoding, able to handle differing sizes for data types > > on different platforms. > > Yes, you're right --- what we'd come up with would be very similar to > Dwarf 2 location expressions. > > > Why bother not just using something we already have a standard for, > > if it's going to 99.9% the same? > > There's nothing technically wrong with using Dwarf 2 location > expressions and location lists internally in GDB. We could do a > perfectly correct implementation that would work fine. When I say > `self-contained', I'm not talking about the implementation; I'm more > concerned with modularity, and who has control of the definition. Okey dokey. But then agian, remember, the people who have control of the dwarf2 location expression definition are those who know what they need to be able to represent, and be able to read. Namely, the compiler writers and debugger writers. That's all the dwarf2 committee is made up of. Compiler and debugger vendors. However, if it helps make you feel we have more control over it, i'll happily rewrite the location expression section of the dwarf2 doc, replacing DWARF2 with GDB, throw it in the docs dir as a decription of our location expression format, and we can use it as a starting point, and not be beholden to anyone at all, or even feel the slightest twinge of guilt about adding/removing/changing opcodes. > > I'm not sure how to put this convincingly. Let me try to draw an > analogy with another problematic area. GDB stores the machine's > registers as a big block of bytes. The layout of GDB's register file > is the same as the layout of the 'G' packet. While there's nothing > technically wrong with this, it's ended up being a technical > nightmare, because whenever we want to do something reasonable with > GDB's internal register file, we have to worry about the remote > protocol. Okey, but the solution to this, IMHO, is to make the structures opaque, and provide accessor routines, so that the only thing that can touch them is a few routines in a file that knows the actual internal format, and how to do the various ops we want to do (like adding a dereference to the top of the stack, etc). Then, we aren't dependent in the debug readers on the actual format involved, and the only thing that is dependent on the format is the actual evaluator for location expressions. > > Using a common structure there simplified the remote protocol code, > but it also introduced a binding (in the mechanical sense, of things > rubbing against each other in a way that prevents the machine from > operating smoothly) between the remote protocol and GDB's internals > that has been a pain in the neck. I believe the binding was introduced because of an assumption about internal structure. If you can't make these assumptions (attempts to indirect through the opaque structure would give you compiler errors, because it would have an incomplete type, or be a void *, or something, depending on how you went about making it opaque), then you are forced to do it the right way. > > I don't want to introduce this sort of binding between GDB's debug > readers and its expression evaluator, by requiring that they use the > same representation for location expressions. There is no such binding introduced, the expression evaluator language has always been seperate, and will continue to be. Unless you mean the symbol expression evaluator we would be implementing, in which case, it would just use the accessor functions itself to get the opcodes and arguments. By doing this, the actual gdb internal representation could be different from what the language says as well. The accessors would just transform it on the fly to the language we have defined for the symbol expressions. > > I admit that this is a very touchy-feely argument. If the other > maintainers don't share my sense of unease with using Dwarf 2 location > expressions directly in GDB, then I'll drop the objection. I don't think it should be *visible* that they are d2 location expressions, to anything but a small number of routines that deal with the internal gdb representation of a symbol location expression. I'll happily make the necessary accessors and opaque types and whatnot to enforce this. -- "There's a pizza place near where I live that sells only slices. in the back you can see a guy tossing a triangle in the air. "-Steven Wright