This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA: Generate normal DWARF DW_LOC descriptors for non integer mode pointers
- From: Nick Clifton <nickc at redhat dot com>
- To: Jeff Law <law at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 17 May 2016 13:37:52 +0100
- Subject: Re: RFA: Generate normal DWARF DW_LOC descriptors for non integer mode pointers
- Authentication-results: sourceware.org; auth=none
- References: <87h9dyt7m3 dot fsf at redhat dot com> <1c7da1c8-c088-6c35-dbc8-bacebd4ad4d0 at redhat dot com>
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