public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: Richard Henderson <rth@redhat.com>,
	gcc-patches@gcc.gnu.org,        "H.J. Lu" <hjl.tools@gmail.com>,
	Steve Ellcey <sje@cup.hp.com>
Subject: Re: [PATCH] Fix up typed DWARF stack support for POINTERS_EXTEND_UNSIGNED targets (PR debug/48853)
Date: Thu, 05 May 2011 15:24:00 -0000	[thread overview]
Message-ID: <20110505145605.GO17079@tyan-ft48-01.lab.bos.redhat.com> (raw)
In-Reply-To: <4DC2B371.2070802@redhat.com>

On Thu, May 05, 2011 at 10:25:53AM -0400, Jason Merrill wrote:
> >+	      && (mode != Pmode
> >+		  || GET_MODE_SIZE (ptr_mode) != DWARF2_ADDR_SIZE
> 
> This test seems overly cautious; it seems implausible to have
> DWARF2_ADDR_SIZE smaller than GET_MODE_SIZE (ptr_mode), and having
> it be larger doesn't seem like a problem.

Ok, I guess I can leave those ptr_mode GET_MODE_SIZE tests out.

> >+		  || mem_mode == VOIDmode)
> 
> We can't handle Pmode void* like other pointers?

mem_mode == VOIDmode doesn't mean a void* pointer, mem_mode != VOIDmode
means mem_loc_descriptor is called on some MEM's address and gives the
mode of the MEM, while VOIDmode mem_mode means it isn't a memory address,
but just a random rtl that we wish to translate into DWARF location
expression.

If it is not a MEM address (i.e. mem_mode is VOIDmode) and
Pmode is wider than DWARF2_ADDR_SIZE, then how do you otherwise find out
if it is a pointer and you leave it up to the debug info consumer to do
some zero/sign/something else extension from DWARF2_ADDR_SIZE to
Pmode size, or if it is any other DImode quantity, which needs to be
represented using DW_OP_GNU_*_type?
Say for i?86 -m32
unsigned long long x = (uintptr_t) &y + 0x123456789abcULL;
(plus:DI (zero_extend:DI (symbol_ref:SI "y")) (const_double 0x123456789abc))
using untyped ops would be incorrect.

We could have some flag/global var whether mem_loc_descriptor is called
from unwind info code or not, and just assume untyped (ptr_mode) arithmetics
is always fine in that case, and just use always DW_OP_GNU_*_type
on POINTERS_EXTEND_UNSIGNED targets for Pmode elsewhere, the problem with
that is that the generated debug info for -gdwarf-strict would be very bad
and debug info would be unnecessarily large.
And we'd still need to represent Pmode SYMBOL_REF/CONST/LABEL_REF somehow
with the zero/sign extension being explicit (like
DW_OP_addr <foo + 6> DW_OP_GNU_convert <unsigned int> DW_OP_GNU_convert <long long>
for zero-extension, s/unsigned int/int/ for sign extension).  Unfortunately
POINTERS_EXTEND_UNSIGNED can be also -1 which means target has special
instruction to do the extension, but nothing says what that insn actually
performs.  So I think it is better to use untyped ops for memory addresses
and typed ops outside of memory addresses when the mode is larger than
DWARF2_ADDR_SIZE.

	Jakub

  reply	other threads:[~2011-05-05 14:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-05  9:22 Jakub Jelinek
2011-05-05 14:53 ` Jason Merrill
2011-05-05 15:24   ` Jakub Jelinek [this message]
2011-05-05 15:29     ` Jason Merrill
2011-05-07  5:21 ` H.J. Lu
2011-05-09 19:24   ` Jason Merrill
2011-05-11 22:14 ` H.J. Lu
2011-05-12 16:40   ` Jakub Jelinek
2011-05-12 17:38     ` H.J. Lu
2011-05-12 19:55       ` Tom Tromey

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=20110505145605.GO17079@tyan-ft48-01.lab.bos.redhat.com \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hjl.tools@gmail.com \
    --cc=jason@redhat.com \
    --cc=rth@redhat.com \
    --cc=sje@cup.hp.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).