Re: dwarf2read.c doesn't produce LOC_COMPUTED_ARG

[Daniel Berlin <dberlin@dberlin.org>]

On Thursday, April 10, 2003, at 06:16  PM, Jim Blandy wrote:

> Daniel Jacobowitz <drow@mvista.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 
>> about
>> this too.  After I check in the location lists patch I'll try to do
>> LOC_COMPUTED_ARG.
>
> Okay.
>
> I'm glad to hear there wasn't some horrible reason it was going to be
> impossible.

Nope
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...