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
next prev parent 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).