This is the mail archive of the
mailing list for the GDB project.
Re: dwarf2read.c doesn't produce LOC_COMPUTED_ARG
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: Daniel Jacobowitz <drow at mvista dot com>,gdb at sources dot redhat dot com
- Date: Thu, 10 Apr 2003 18:32:15 -0400
- Subject: Re: dwarf2read.c doesn't produce LOC_COMPUTED_ARG
On Thursday, April 10, 2003, at 06:16 PM, Jim Blandy wrote:
Daniel Jacobowitz <drow at mvista dot com> writes:
On Wed, Apr 09, 2003 at 11:27:27PM -0500, Jim Blandy wrote:
I just realized that dwarf2read.c will produce LOC_COMPUTED symbols,
but not LOC_COMPUTED_ARG symbols. The case for
DW_TAG_formal_parameter in new_symbol doesn't call
var_decode_location; it does what it's always done.
Is there any reason for this, or was it just an oversight?
It was just a lack of time, really. We've just recently got a PR
this too. After I check in the location lists patch I'll try to do
I'm glad to hear there wasn't some horrible reason it was going to be
In fact, it's not that it's never been tried, either. I actually had
code around to make LOC_COMPUTED_ARG in dwarf2 just to test the
interface, it was simply omitted from the patches that went to
gdb-patches (and to DanJ) to make them smaller.
That said, I never regression tested that part of the patch, it was
more of a "doesn't seem anything is egregiously wrong here" type thing
to make sure i caught all the blatantly obvious cases.
So don't be surprised if it breaks something subtle, but don't be
worried it can't be done.
I just had a rude awakening regarding why frame-base.[ch]
will be with us for at least as long as STABS and mdebug are...