From: "Jan Beulich" <jbeulich@novell.com>
To: "Luca" <luca.b633@gmail.com>, "Andrew Pinski" <pinskia@gmail.com>
Cc: <gcc@gcc.gnu.org>, <binutils@sourceware.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [RFC] [PATCH] 32-bit pointers in x86-64
Date: Wed, 05 Dec 2007 09:31:20 +0000 [thread overview]
Message-ID: <47567DF8.76E4.0078.0@novell.com> (raw)
In-Reply-To: <de8d50360711251045l4566f894m92fbb32d00fa362@mail.gmail.com>
>>> "Andrew Pinski" <pinskia@gmail.com> 25.11.07 19:45 >>>
>On 11/25/07, Luca <luca.b633@gmail.com> wrote:
>> 7.1. Add __attribute__((pointer_size(XXX))) and #pragma pointer_size
>> to allow 64-bit pointers in 32-bit mode and viceversa
>
>This is already there, try using __attribute__((mode(DI) )).
Hmm, unless this is a new feature in 4.3, I can't seem to get this to work on
either i386 (using mode DI) or x86-64 (using mode SI). Could you clarify? If
this worked consistently on at least all 64-bit architectures, I would have a
use for it in the kernel (cutting down the kernel size by perhaps several
pages). Btw., I continue to think that the error message 'initializer element
is not computable at load time' on 64-bit code like this
extern char array[];
unsigned int p = (unsigned long)array;
or 32-bit code like this
extern char array[];
unsigned long long p = (unsigned long)array;
is incorrect - the compiler generally has no knowledge what 'array' is (it may
know whether the architecture is generally capable of expressing the
necessary relocation, but if 'array' is really a placeholder for an assembly
level constant, possibly even defined through __asm__() in the same
translation unit, this diagnostic should at best be a warning). I'm pretty
sure I have an open bug for this, but the sad thing is that bugs like this
never appear to really get looked at.
Thanks, Jan
next prev parent reply other threads:[~2007-12-05 9:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-25 16:29 [RFC] [PATCH] 32-bit pointers in x86-64 Luca
2007-11-25 18:45 ` Andrew Pinski
2007-12-05 9:31 ` Jan Beulich [this message]
2007-12-05 10:48 ` Andrew Pinski
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=47567DF8.76E4.0078.0@novell.com \
--to=jbeulich@novell.com \
--cc=binutils@sourceware.org \
--cc=gcc@gcc.gnu.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.b633@gmail.com \
--cc=pinskia@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.