public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* dwarf2read.c doesn't produce LOC_COMPUTED_ARG
@ 2003-04-10  4:26 Jim Blandy
  2003-04-10 12:33 ` Daniel Jacobowitz
  2003-04-10 13:30 ` Daniel Berlin
  0 siblings, 2 replies; 6+ messages in thread
From: Jim Blandy @ 2003-04-10  4:26 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: gdb


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?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dwarf2read.c doesn't produce LOC_COMPUTED_ARG
  2003-04-10  4:26 dwarf2read.c doesn't produce LOC_COMPUTED_ARG Jim Blandy
@ 2003-04-10 12:33 ` Daniel Jacobowitz
  2003-04-10 22:15   ` Jim Blandy
  2003-04-10 13:30 ` Daniel Berlin
  1 sibling, 1 reply; 6+ messages in thread
From: Daniel Jacobowitz @ 2003-04-10 12:33 UTC (permalink / raw)
  To: Jim Blandy; +Cc: gdb

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dwarf2read.c doesn't produce LOC_COMPUTED_ARG
  2003-04-10  4:26 dwarf2read.c doesn't produce LOC_COMPUTED_ARG Jim Blandy
  2003-04-10 12:33 ` Daniel Jacobowitz
@ 2003-04-10 13:30 ` Daniel Berlin
  1 sibling, 0 replies; 6+ messages in thread
From: Daniel Berlin @ 2003-04-10 13:30 UTC (permalink / raw)
  To: Jim Blandy; +Cc: Daniel Jacobowitz, gdb


On Thursday, April 10, 2003, at 12:27  AM, 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.
>
Correct.

> Is there any reason for this, or was it just an oversight?
>
The reason was that it was something that would be done *after* the 
initial patch was in (in order to keep the initial patch smaller).
You know, like, say, now.
:)
--Dan

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dwarf2read.c doesn't produce LOC_COMPUTED_ARG
  2003-04-10 12:33 ` Daniel Jacobowitz
@ 2003-04-10 22:15   ` Jim Blandy
  2003-04-10 22:32     ` Daniel Berlin
  2003-04-11  2:18     ` Andrew Cagney
  0 siblings, 2 replies; 6+ messages in thread
From: Jim Blandy @ 2003-04-10 22:15 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: gdb

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dwarf2read.c doesn't produce LOC_COMPUTED_ARG
  2003-04-10 22:15   ` Jim Blandy
@ 2003-04-10 22:32     ` Daniel Berlin
  2003-04-11  2:18     ` Andrew Cagney
  1 sibling, 0 replies; 6+ messages in thread
From: Daniel Berlin @ 2003-04-10 22:32 UTC (permalink / raw)
  To: Jim Blandy; +Cc: Daniel Jacobowitz, gdb


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dwarf2read.c doesn't produce LOC_COMPUTED_ARG
  2003-04-10 22:15   ` Jim Blandy
  2003-04-10 22:32     ` Daniel Berlin
@ 2003-04-11  2:18     ` Andrew Cagney
  1 sibling, 0 replies; 6+ messages in thread
From: Andrew Cagney @ 2003-04-11  2:18 UTC (permalink / raw)
  To: Jim Blandy; +Cc: Daniel Jacobowitz, gdb

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

frame-base.[hc], which was only added two weeks ago, should out live 
stabs and mdebug read?

Andrew


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2003-04-11  2:18 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-10  4:26 dwarf2read.c doesn't produce LOC_COMPUTED_ARG Jim Blandy
2003-04-10 12:33 ` Daniel Jacobowitz
2003-04-10 22:15   ` Jim Blandy
2003-04-10 22:32     ` Daniel Berlin
2003-04-11  2:18     ` Andrew Cagney
2003-04-10 13:30 ` Daniel Berlin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).