From: Jeff Law <law@redhat.com>
To: Nick Clifton <nickc@redhat.com>, gcc-patches@gcc.gnu.org
Cc: gdb-patches@sourceware.org
Subject: Re: RFA: Generate normal DWARF DW_LOC descriptors for non integer mode pointers
Date: Mon, 16 May 2016 20:08:00 -0000 [thread overview]
Message-ID: <1c7da1c8-c088-6c35-dbc8-bacebd4ad4d0@redhat.com> (raw)
In-Reply-To: <87h9dyt7m3.fsf@redhat.com>
On 05/16/2016 08:12 AM, Nick Clifton wrote:
> Hi Guys,
>
> 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.
>
> For example the GDB testfile gdb/testsuite/gdb.base/advance.c contains
> this code fragment:
>
> int
> main ()
> {
> int result;
> int b, c;
> c = 5;
> b = 3; /* advance this location */
>
> func (c); /* stop here after leaving current frame */
>
> which compiles to these instructions:
>
> suba #6, r1
> mov #5, 4(r1)
> mov #3, 2(r1)
> mov 4(r1), r12
> calla #0 ;<func>
>
> (Note that only r1 - the stack pointer - is used. r4 - the frame
> pointer - is not).
>
> The debug information produced for the "c" local variable looks like
> this:
>
> Abbrev Number: 3 (DW_TAG_variable)
> DW_AT_name : c
> DW_AT_decl_file : 1
> DW_AT_decl_line : 40
> DW_AT_type : <0x37>
> DW_AT_location : 5 byte block: f5 4 21 32 1c (DW_OP_GNU_regval_type: 4 (r4) <0x21>; DW_OP_lit2; DW_OP_minus)
>
> ie it says that "c" is stored in memory location "r4 - 2", which is
> wrong since register r4 is not even used in this function.
>
> The patch below addresses this problem by allowing the normal,
> register based descriptor to be produced when the mode is Pmode.
>
> With this patch applied the unexpected failure count in the GDB
> testsuite for the MSP430's -mlarge multilib changes from 2253 to 367.
> There are no regressions, for MSP430 or x86_64, and no changes to
> the GCC testsuite results for either target.
>
> OK to apply ?
>
> Cheers
> Nick
>
> gcc/ChangeLog
> 2016-05-16 Nick Clifton <nickc@redhat.com>
>
> * dwarf2out.c (mem_loc_descriptor): Convert REG based addresses
> whose mode is Pmode into basereg descriptors even if Pmode is
> not an integer mode.
I'm not real familiar with dwarf, so if one of other maintainers steps
in and says this is OK, then ignore my comments/questions.
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? Where does that happen? Is it possible we've got the wrong
DECL_RTL or somesuch?
Jeff
next prev parent reply other threads:[~2016-05-16 20:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-16 14:12 Nick Clifton
2016-05-16 20:08 ` Jeff Law [this message]
2016-05-17 12:37 ` Nick Clifton
[not found] ` <9f8e1f36-5186-67bc-898e-6910e0d041a6@redhat.com>
2016-05-26 16:16 ` Nick Clifton
2016-06-21 22:09 ` Jeff Law
2016-06-22 15:13 ` Nick Clifton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1c7da1c8-c088-6c35-dbc8-bacebd4ad4d0@redhat.com \
--to=law@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=nickc@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox