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