From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Daniel Berlin Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Add support for tracking/evaluating dwarf2 location expressions Date: Tue, 22 May 2001 12:46:00 -0000 Message-id: References: <87heye17ck.fsf@dynamic-addr-83-177.resnet.rochester.edu> X-SW-Source: 2001-05/msg00414.html 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. 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. 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 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. 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.