From: Ian Lance Taylor <iant@google.com>
To: Andrew Pinski <pinskia@gmail.com>
Cc: Jakub Jelinek <jakub@redhat.com>,
Ulrich Weigand <uweigand@de.ibm.com>,
"H.J. Lu" <hjl.tools@gmail.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: PATCH: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)
Date: Tue, 22 Mar 2011 18:58:00 -0000 [thread overview]
Message-ID: <mcrei5zrniw.fsf@google.com> (raw)
In-Reply-To: <AANLkTi=TDMWza9tUzPE3qXDELEv4Kv3A2LwCexVhHtyr@mail.gmail.com> (Andrew Pinski's message of "Tue, 22 Mar 2011 09:52:15 -0700")
Andrew Pinski <pinskia@gmail.com> writes:
> On Tue, Mar 22, 2011 at 9:42 AM, Ian Lance Taylor <iant@google.com> wrote:
>>
>> Any target on which _Unwind_Word is larger than void * is broken today,
>> so I don't think we need to care about that case.
>
> So a MIPS N32 is broken? Lots of people use that target already and
> nothing like this has showed up yet.
That is a fair question. It does seem to me that it must be broken in
some cases. _Unwind_GetGRPtr will return &context->reg[index], which is
a void** cast to void*. We will then pass that to _Unwind_SetGRPtr. If
we later call _Unwind_SetGR on that register, it will write a value of
size _Unwind_Word through that pointer. Similarly if we call
_Unwind_GetGR, it will read a value of size _Unwind_Word. In both
cases, we will be accessing a 4-byte field as an 8-byte value.
If MIPS N32 works today, then something must be ensuring that that
sequence can never occur, or that for some reason it never matters.
Does anybody disagree with this analysis?
Ian
next prev parent reply other threads:[~2011-03-22 18:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-06 17:18 H.J. Lu
2011-03-06 21:15 ` Andrew Pinski
2011-03-06 21:28 ` H.J. Lu
2011-03-06 23:23 ` Richard Guenther
2011-03-06 23:40 ` H.J. Lu
2011-03-07 0:15 ` H.J. Lu
2011-03-14 17:49 ` H.J. Lu
2011-03-21 21:56 ` Ian Lance Taylor
2011-03-22 4:19 ` H.J. Lu
2011-03-22 6:32 ` Ian Lance Taylor
2011-03-22 15:19 ` Ulrich Weigand
2011-03-22 15:41 ` Jakub Jelinek
2011-03-22 16:42 ` Ian Lance Taylor
2011-03-22 16:52 ` Andrew Pinski
2011-03-22 18:58 ` Ian Lance Taylor [this message]
2011-03-22 19:30 ` Ulrich Weigand
2011-03-22 22:18 ` Ian Lance Taylor
2011-03-23 3:25 ` H.J. Lu
2011-03-23 4:53 ` Ian Lance Taylor
2011-03-23 5:01 ` H.J. Lu
2011-03-23 13:58 ` Ian Lance Taylor
2011-03-23 17:50 ` Richard Henderson
2011-03-23 18:04 ` Jakub Jelinek
2011-03-23 18:20 ` Richard Henderson
2011-03-23 18:24 ` H.J. Lu
2011-03-23 18:27 ` Richard Henderson
2011-03-23 18:37 ` Jakub Jelinek
2011-03-23 19:01 ` Richard Henderson
2011-03-23 19:17 ` Jakub Jelinek
2011-03-23 19:22 ` Ulrich Weigand
2011-03-24 7:15 ` H.J. Lu
2011-04-10 1:52 ` H.J. Lu
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=mcrei5zrniw.fsf@google.com \
--to=iant@google.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hjl.tools@gmail.com \
--cc=jakub@redhat.com \
--cc=pinskia@gmail.com \
--cc=uweigand@de.ibm.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).