Re: RFA: Generate normal DWARF DW_LOC descriptors for non integer mode pointers

[Jeff Law <law at redhat dot com>]

On 05/17/2016 06:37 AM, Nick Clifton wrote:
> Hi Jeff,
>
> > >   Currently dwarf2out.c:mem_loc_descriptor() has some special case
> > >   code to handle the situation where an address is held in a register
> > >   whose mode is not of type MODE_INT.  It generates a
> > >   DW_OP_GNU_regval_type expression which may later on be converted into
> > >   a frame pointer based expression.  This is a problem for targets which
> > >   use a partial integer mode for their pointers (eg the msp430).  In
> > >   such cases the conversion to a frame pointer based expression could
> > >   be wrong if the frame pointer is not being used.
>
> > I may be missing something, but isn't it the transition to an FP
> > relative address rather than a SP relative address that's the problem
> > here?
>
> Yes, I believe so.
>
> > Where does that happen?
>
> I did not track it down.  But whilst I was searching for the cause I came
> across the code that is modified by the patch.  Reading the code it seemed
> obvious to me that the special case for handling non INT_MODE register modes
> was not intended for pointers, and when I tried out a small patch it worked.
Maybe rather than tweaking behaviour based on whether or not it's a 
pointer type, we should look at whether or not the object has an integer 
mode (ie, test for MODE_INT or MODE_PARTIAL_INT).

> > Is it possible we've got the wrong DECL_RTL or somesuch?
>
> I don't think so.  I am not familiar with this code myself, but the dump from
> the dwarf2 pass shows:
>
>   (insn 5 2 6 (set (mem/c:HI (plus:PSI (reg/f:PSI 1 R1)
>                 (const_int 4 [0x4])) [1 c+0 S2 A16])
>         (const_int 5 [0x5])) /work/sources/binutils/current/gdb/testsuite/gdb.base/advance.c:41 12 {movhi}
>      (nil))
>
> which to me pretty clearly shows that "c" is being stored at R1+4.
Right, but I believe a fair amount of the dwarf stuff goes back to 
trees, which have things like DECL_RTL/DECL_INCOMING_RTL and friends 
embedded inside them.

I wouldn't be terribly surprised to find that it's looking at some stale 
hunk of RTL that wasn't updated for register eliminations or something 
of that nature.

I think we should dig further into why the base register (and offset) is 
wrong and fix that.  We may independently want to tweak the code in 
mem_loc_descriptor to better handle partial integers.

jeff