var_tracking question

var_tracking question

[DJ Delorie]

My m32c port is generating tracking notes that look like this:

(var_location 0x2a95758dd0 (parallel [
            (expr_list:REG_DEP_TRUE (reg/v:SI 0 r0 [orig:123 remainder_size ] [123])
                (const_int 0 [0x0]))
            (expr_list:REG_DEP_TRUE (reg:HI 1 r2 [ remainder_size+2 ])
                (const_int 2 [0x2]))
        ]))

Note that registers are HI natively, and r2 is the upper half of the
[r2:r0] pair.  In other words, the location given above describes an
overlap between the two pieces.  The code itself refers to the
variable in both SI (full) and HI (part) modes.

The dwarf2 location lists generated from this are bogus.

So, my question is - is the var_location correct?  Do I need to debug
the var tracking code, or the dwarf2 output code?

Re: var_tracking question

[Jakub Jelinek]

On Thu, Jun 30, 2005 at 09:25:47PM -0400, DJ Delorie wrote:
> 
> My m32c port is generating tracking notes that look like this:
> 
> (var_location 0x2a95758dd0 (parallel [
>             (expr_list:REG_DEP_TRUE (reg/v:SI 0 r0 [orig:123 remainder_size ] [123])
>                 (const_int 0 [0x0]))
>             (expr_list:REG_DEP_TRUE (reg:HI 1 r2 [ remainder_size+2 ])
>                 (const_int 2 [0x2]))
>         ]))
> 
> Note that registers are HI natively, and r2 is the upper half of the
> [r2:r0] pair.  In other words, the location given above describes an
> overlap between the two pieces.  The code itself refers to the
> variable in both SI (full) and HI (part) modes.
> 
> The dwarf2 location lists generated from this are bogus.

Even on mainline?  See PR debug/21946 and
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00312.html.
Var-tracking is very broken in that it doesn't care about register modes,
but what I have comitted should at least prevent bogus dwarf2 location
list generation.

	Jakub

Re: var_tracking question

[Daniel Berlin]

On Fri, 2005-07-01 at 11:50 +0200, Jakub Jelinek wrote:
> On Thu, Jun 30, 2005 at 09:25:47PM -0400, DJ Delorie wrote:
> > 
> > My m32c port is generating tracking notes that look like this:
> > 
> > (var_location 0x2a95758dd0 (parallel [
> >             (expr_list:REG_DEP_TRUE (reg/v:SI 0 r0 [orig:123 remainder_size ] [123])
> >                 (const_int 0 [0x0]))
> >             (expr_list:REG_DEP_TRUE (reg:HI 1 r2 [ remainder_size+2 ])
> >                 (const_int 2 [0x2]))
> >         ]))
> > 
> > Note that registers are HI natively, and r2 is the upper half of the
> > [r2:r0] pair.  In other words, the location given above describes an
> > overlap between the two pieces.  The code itself refers to the
> > variable in both SI (full) and HI (part) modes.
> > 
> > The dwarf2 location lists generated from this are bogus.
> 
> Even on mainline?  See PR debug/21946 and
> http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00312.html.
> Var-tracking is very broken in that it doesn't care about register modes,
> but what I have comitted should at least prevent bogus dwarf2 location
> list generation.

It's not so much broken as "much more inaccurate than it could be".
:)

Remember that we are just trying to divine what has happened in the
optimizations using a simple dataflow equation.  Sometimes you get the
right answers, sometimes you don't.

Re: var_tracking question

[DJ Delorie]

> Even on mainline?

No, one of our branches.

> See PR debug/21946 and
> http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00312.html.
> Var-tracking is very broken in that it doesn't care about register
> modes, but what I have comitted should at least prevent bogus dwarf2
> location list generation.

Ok, that looks like the right fix for me.  Thanks!