Re: DW_OP_piece coming in gcc 3.4

Re: DW_OP_piece coming in gcc 3.4

[Fred Fish]

I've been tasked with fixing this problem, or at least deciding if it
can be fixed in the amount of time I have available to work on it.

I've scanned most of the prior messages on the gdb@sources.redhat.com
and gdb-patches@sources.redhat.com mailing lists which can be found by
searching for DW_OP_piece.  I intend to go back today and study them
in detail to get some history on what has been discussed about this
problem.

If you have contributed to this topic in the past and have some new
suggestions and/or ideas, or want to contribute, I'd appreciate any
additional relevant input.

Thanks.

-Fred

Re: DW_OP_piece coming in gcc 3.4

[Daniel Jacobowitz]

On Fri, Feb 06, 2004 at 09:30:34AM -0700, Fred Fish wrote:
> I've been tasked with fixing this problem, or at least deciding if it
> can be fixed in the amount of time I have available to work on it.

Great!

> I've scanned most of the prior messages on the gdb@sources.redhat.com
> and gdb-patches@sources.redhat.com mailing lists which can be found by
> searching for DW_OP_piece.  I intend to go back today and study them
> in detail to get some history on what has been discussed about this
> problem.
> 
> If you have contributed to this topic in the past and have some new
> suggestions and/or ideas, or want to contribute, I'd appreciate any
> additional relevant input.

At this point, I believe the correct fix will be mostly contained to
the dwarf2-expr and dwarf2-loc code.  A _complete_ fix will be quite
complicated; enough to print variables will not be too hard, since we
can read them in the LOC_COMPUTED read method, and mark them as
not_lval.

The problem I see with being able to write and fully use such variables
is that we need to audit uses of SYMBOL_VALUE_ADDRESS to find which are
used for full symbols.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: DW_OP_piece coming in gcc 3.4

[Andrew Cagney]

> I've been tasked with fixing this problem, or at least deciding if it
> can be fixed in the amount of time I have available to work on it.

Fred, did you get anywhere with this?

Andrew

Re: DW_OP_piece coming in gcc 3.4

[Fred Fish]

On Monday 16 February 2004 12:25, Andrew Cagney wrote:
> > I've been tasked with fixing this problem, or at least deciding if it
> > can be fixed in the amount of time I have available to work on it.
>
> Fred, did you get anywhere with this?

Only to the extent of determining that it was going to take more time
that I had immediately available to fix it in the general case, but
that Keith's patch could be adapted to fix the immediate problem and
then I could revisit this issue after some more urgent work was done.
I would expect that to be sometime in the next few weeks.

-Fred

Re: DW_OP_piece coming in gcc 3.4

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

Fred Fish <fnf@ninemoons.com> writes:

> On Monday 16 February 2004 12:25, Andrew Cagney wrote:
>> > I've been tasked with fixing this problem, or at least deciding if it
>> > can be fixed in the amount of time I have available to work on it.
>>
>> Fred, did you get anywhere with this?
>
> Only to the extent of determining that it was going to take more time
> that I had immediately available to fix it in the general case, but
> that Keith's patch could be adapted to fix the immediate problem and
> then I could revisit this issue after some more urgent work was done.
> I would expect that to be sometime in the next few weeks.

Which patch by Keith?  Can you mail the URL?  I couldn't find it
myself...

thanks,
Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: DW_OP_piece coming in gcc 3.4

[Daniel Jacobowitz]

On Tue, Feb 17, 2004 at 08:39:17AM +0100, Andreas Jaeger wrote:
> Fred Fish <fnf@ninemoons.com> writes:
> 
> > On Monday 16 February 2004 12:25, Andrew Cagney wrote:
> >> > I've been tasked with fixing this problem, or at least deciding if it
> >> > can be fixed in the amount of time I have available to work on it.
> >>
> >> Fred, did you get anywhere with this?
> >
> > Only to the extent of determining that it was going to take more time
> > that I had immediately available to fix it in the general case, but
> > that Keith's patch could be adapted to fix the immediate problem and
> > then I could revisit this issue after some more urgent work was done.
> > I would expect that to be sometime in the next few weeks.
> 
> Which patch by Keith?  Can you mail the URL?  I couldn't find it
> myself...

I'm guessing Fred meant Kevin's patch:

Date: Thu, 22 May 2003 10:00:39 -0700
From: Kevin Buettner <kevinb@redhat.com>  
Subject: [RFA] Limited DW_OP_piece support

I asked him to do it in dwarf2_evaluate_loc_desc instead, but neither
of us had time to revisit the issue.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: DW_OP_piece coming in gcc 3.4

[Fred Fish]

> > Which patch by Keith?  Can you mail the URL?  I couldn't find it
> > myself...
> 
> I'm guessing Fred meant Kevin's patch:

Ah yes, sorry.  I did mean Kevin's patch.

I've been on the road the last couple days and just now getting a
chance to respond to inbound email.

-Fred

Re: DW_OP_piece coming in gcc 3.4

[Daniel Jacobowitz]

On Thu, Jan 29, 2004 at 10:51:53PM -0700, Kevin Buettner wrote:
> On Fri, 30 Jan 2004 00:27:57 -0500 (EST)
> mec.gnu@mindspring.com (Michael Elizabeth Chastain) wrote:
> 
> > I'm getting this with gcc-3_4-branch -gdwarf-2:
> > 
> >   (gdb) PASS: gdb.base/store.exp: up print old l - longest
> >   print r^M
> >   Unhandled dwarf expression opcode 0x93^M
> >   (gdb) FAIL: gdb.base/store.exp: up print old r - longest
> > 
> > We need a strategic decision:
> > 
> > (1) Implement DW_OP_piece in time for gdb 6.1.
> > (2) Ask gcc to not emit DW_OP_piece in gcc 3.4.
> > (3) File a PR (or tag onto PR gdb/1312 but that's not really right),
> >     KFAIL the tests, add a note to PROBLEMS.
> > 
> > I don't know which strategy is good for gdb.
> > 
> > What will it be?
> 
> The "right" thing is to get DW_OP_piece support into gdb (#1).  I'm
> firmly against #2.  #3 may be an acceptable as a short term solution,
> but I'm none too fond of it either.
> 
> So, I vote for #1.

I agree.  I think that adding it to LOC_COMPUTED, especially in an
initial form that does not allow changing piecewise values (not_lval)
will be pretty simple.  Adding it as a first-class citizen all over GDB
is a little trickier, since it means checking every use of
SYMBOL_VALUE_ADDRESS on non-minsyms.

One cleanup I've been meaning to do for ages, but not had time, is to
break SYMBOL_VALUE_ADDRESS into three macros.  One for minimal symbols,
one for partial symbols, and one for full symbols.  That would let us
get a much better feel for the scope of the problem.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: DW_OP_piece coming in gcc 3.4

[Kevin Buettner]

On Fri, 30 Jan 2004 00:27:57 -0500 (EST)
mec.gnu@mindspring.com (Michael Elizabeth Chastain) wrote:

> I'm getting this with gcc-3_4-branch -gdwarf-2:
> 
>   (gdb) PASS: gdb.base/store.exp: up print old l - longest
>   print r^M
>   Unhandled dwarf expression opcode 0x93^M
>   (gdb) FAIL: gdb.base/store.exp: up print old r - longest
> 
> We need a strategic decision:
> 
> (1) Implement DW_OP_piece in time for gdb 6.1.
> (2) Ask gcc to not emit DW_OP_piece in gcc 3.4.
> (3) File a PR (or tag onto PR gdb/1312 but that's not really right),
>     KFAIL the tests, add a note to PROBLEMS.
> 
> I don't know which strategy is good for gdb.
> 
> What will it be?

The "right" thing is to get DW_OP_piece support into gdb (#1).  I'm
firmly against #2.  #3 may be an acceptable as a short term solution,
but I'm none too fond of it either.

So, I vote for #1.

Kevin

DW_OP_piece coming in gcc 3.4

[Michael Elizabeth Chastain]

I'm getting this with gcc-3_4-branch -gdwarf-2:

  (gdb) PASS: gdb.base/store.exp: up print old l - longest
  print r^M
  Unhandled dwarf expression opcode 0x93^M
  (gdb) FAIL: gdb.base/store.exp: up print old r - longest

We need a strategic decision:

(1) Implement DW_OP_piece in time for gdb 6.1.
(2) Ask gcc to not emit DW_OP_piece in gcc 3.4.
(3) File a PR (or tag onto PR gdb/1312 but that's not really right),
    KFAIL the tests, add a note to PROBLEMS.

I don't know which strategy is good for gdb.

What will it be?

Michael C