[RFC] [PATCH] 32-bit pointers in x86-64
This proof of concept patch modifies GCC to have 32-bit pointers and
longs on x86-64.
This allows to create an "x86-32" architecture that takes advantage of
the higher number of registers and support for 64-bit computation in
x86-64 long mode while avoiding the disadvantage of increased memory
usage due to 64-bit pointers and longs in structures.
Thus, such a GCC version could be used to produce a GNU/Linux
distribution with the performance of x86-64 and the reduced memory
usage of i386. Furthermore, programs requiring "large data" could use
special "64-bit pointer" attributes to only use 64-bit pointers to
reference the relevant large arrays/structures, using 32-bit pointers
for everything else.
The current patch is just an hack and should obviously be made
configurable and reimplemented properly.
Just setting POINTER_SIZE to 32 mostly works but more hacks are
necessary to get PIC compilation working (note that the hacks are
probably at least partially wrong, since I'm not an experienced GCC
hacker).
A patch to binutils is also required to stop it from complaining about
32-bit relocations in shared objects.
Currently a simple "Hello world!" program will work using a standard
x86-64 dynamic loader and libc.
This is because the function call ABI is unchanged and thus anything
that doesn't use structures containing pointers or longs should be
binary compatible.
I do not really intend to work on this personally: I did this initial
work for fun and I'm posting these patches to possibly stimulate
broader interest on this concept.
A possible roadmap for this would be:
1. Make it configurable
2. Fix the LEA hacks and allow proper PIC compilation
3. Fix everything else that may not work properly (e.g. PIC,
relocations, exception handling, TLS, debug info)
4. Add a "32-bit object" flag to x86-64 objects
5. Modify libc so that allocations are made in the lower 4GB space for
x86-32 shared objects and modify x86-64 assembly code to work with
32-bit pointers
6. Compile a native x86-32 libc and compile and test a full Debian or
Ubuntu distribution
7. Add support for loading x86-32 and x86-64 objects in the same
address space, using a single modified 64-bit libc (that for
compatibility actually generate pointers in the low 4GB)
7.1. Add __attribute__((pointer_size(XXX))) and #pragma pointer_size
to allow 64-bit pointers in 32-bit mode and viceversa
7.2. Surround glibc headers with #pragma pointer_size 64
7.3. Modify the dynamic loader to support different namespaces and
directories for x86-32 and x86-64. Symbols starting with "__64_" or
"__32_" or similar could be mapped to the other namespace. Also
support "multiarchitecture" objects that would be added to both.
7.4. Split malloc/mmap in __32_malloc, __32_mmap and similar in glibc.
glibc itself would use 32-bit allocations and be loaded in the low
4GB.
7.5. Compile the result and use a modified libc/dynamic loader
compiled in x86-64 mode flagged as multiarchitecture to load both
x86-32 and x86-64 objects
8. Modify popular programs to explicitly use 64-bit allocations and
pointers for potentially huge allocations (e.g. database caches,
compression program data structures, P2P software file mappings)
Patches are against GCC 4.2.2 and Binutils HEAD.
Index: bfd/elf64-x86-64.c
===
RCS file: /cvs/src/src/bfd/elf64-x86-64.c,v
retrieving revision 1.144
diff -u -r1.144 elf64-x86-64.c
--- bfd/elf64-x86-64.c 18 Oct 2007 09:13:51 - 1.144
+++ bfd/elf64-x86-64.c 25 Nov 2007 14:19:17 -
@@ -1038,6 +1038,8 @@
case R_X86_64_TPOFF32:
if (info->shared)
{
+ if(0)
+ {
(*_bfd_error_handler)
(_("%B: relocation %s against `%s' can not be used when making a shared object; recompile with -fPIC"),
abfd,
@@ -1045,6 +1047,7 @@
(h) ? h->root.root.string : "a local symbol");
bfd_set_error (bfd_error_bad_value);
return FALSE;
+ }
}
break;
@@ -1198,6 +1201,8 @@
&& (sec->flags & SEC_ALLOC) != 0
&& (sec->flags & SEC_READONLY) != 0)
{
+ if(0)
+ {
(*_bfd_error_handler)
(_("%B: relocation %s against `%s' can not be used when making a shared object; recompile with -fPIC"),
abfd,
@@ -1205,6 +1210,7 @@
(h) ? h->root.root.string : "a local symbol");
bfd_set_error (bfd_error_bad_value);
return FALSE;
+ }
}
/* Fall through. */
@@ -2599,6 +2605,8 @@
|| !is_32bit_relative_branch (contents,
rel->r_offset)))
{
+ if(0)
+ {
if (h->def_regular
&& r_type == R_X86_64_PC32
&& h->type == STT_FUNC
@@ -2613,6 +2621,7 @@
h->root.root.string);
bfd_set_error (bfd_error_bad_value);
return FALSE;
+ }
}
/* Fall through. */
diff -ur g_orig/gcc-4.2.2/gcc/config/i386/i386.c gcc-4.2.2/gcc/config/i386/i386.c
--- g_orig/gcc-4.2.2/gcc/config/i386/i386.c 2007-09-01 17:28:30.0 +0200
+++ gcc-4.2.2/gcc/config/i386/i386.c
GCC 4.0.0: (mostly) successful build and installation on GNU/Linux PowerPC
This is the information requested in INSTALL/finalinstall.html: Output of config.guess: powerpc-unknown-linux-gnu Output of gcc-4.0.0 -v: Using built-in specs. Target: powerpc-unknown-linux-gnu Configured with: ../gcc-4.0.0/configure --enable-threads=posix --with-cpu=750 --enable-languages=c,c++,java --disable-checking --disable-maintainer-mode --disable-altivec --with-tune=750 --enable-java-awt=gtk --program-suffix=-4.0.0 Thread model: posix gcc version 4.0.0 Languages enabled: C, C++, Java Built on GNU/Linux Distribution: hand-crafted by me Kernel version: 2.6.3 glibc version: 2.3.3 (unpatched FSF version) binutils version: 2.15.90.0.1 20040303 Other information: Compiled using "-O9 -funroll-loops -finline-functions -mcpu=750" for CFLAGS, CXXFLAGS, BOOT_CFLAGS, LIBCFLAGS, LIBGCJ_CXXFLAGS, GCJFLAGS, JCFLAGS and LIBCXXFLAGS. I had a problem at installation time; make tried to run a target ' ' from powerpc-unknown-linux-gnu/boehm-gc/. I managed to fix it with some kludges, and now after installation everything works. I apologize for not being able to further investigate the problem, but compiling the Java runtime takes a *long* time on my machine (PowerPC 750, 600MHz). Thanks for your great work. -- Luca Saiu, maintainer of GNU epsilon http://www.gnu.org/software/epsilon http://www.cli.di.unipi.it/~saiu/brevetti.html
Option to set the debug map (DW_AT_comp_dir) value "from scratch"
Hi everyone, Recently I used the following debugger option: -fdebug-prefix-map=old=new in order to set the DW_AT_comp_dir, in the target executable, according to my needs. In order to do this, first of all, I needed to know the DW_AT_comp_dir value set in the executable after an initial build. So, I was forced to use the "objdump" command in order to fetch it (e.g.: /path/to/replace). With this value I was able to populate the option values accordingly: -fdebug-prefix-map=/path/to/replace=/new/path/to/set I'm curious if there is a property like the following e.g.: -fdebug-map=/new/path/to/set to set the DW_AT_comp_dir path, directly, from scratch, without the need to look for the value to replace before. Thanks, Luca
March=native with a main 64bit system and 32bit chroot
Hi all,
I've a main Gentoo 64bit system with CHOST="x86_64-pc-linux-gnu" and
CFLAGS="-march=native -mtune=native -O2 -pipe -fomit-frame-pointer".
My cpu is a Pentium 4 Prescott and i'm using gcc-4.3.2.
With this little script:
"echo 'float x(float x){return x < 0 ? -x : x;}' > x.c && gcc
-fverbose-asm -mtune=native -march=native -S x.c && grep
'\(-march\|-mtune\)' x.s && rm -fr x.c && rm -fr x.s "
i've found that gcc uses march=nocona and mtune=nocona, and this is ok.
In this main system i've some 32bit chroots with
CHOST="i686-pc-linux-gnu" and CFLAGS="-march=native -mtune=native -O2
-pipe -fomit-frame-pointer".
But this time gcc is using march=nocona and mtune=nocona again, that
is wrong i think.
Should i use march=native or march=prescott (that is what i was using
with old gcc versions) for my chroots?
If march=prescott is the right choice i think that the gcc "native"
detection should consider also $CHOST.
GCC talks at the GNU Hackers Meeting?
Hello people. We're organizing the next GNU Hackers Meeting which will take place next August in Paris, France; see http://www.gnu.org/ghm/2013/paris . We still have free slots, so I'm starting to contact people a little more pro-actively. Personally speaking, what I *really* would like is a tutorial talk about writing a GCC frontend -- which is to say, how to interface with the middle end. But there are a lot of possible topics as well; out of this list, I think people don't hear enough about what's happening in the community. Would you like to give a talk? If you simply want to attend without speaking, you can register as well. We're trying to do a little outreach so the talks will be open to everybody, but of course we particularly welcome GNU contributors. Regards, -- Luca Saiu Home page: http://ageinghacker.net GNU epsilon: http://www.gnu.org/software/epsilon Marionnet: http://marionnet.org
Re: GCC talks at the GNU Hackers Meeting?
Hello Philip. On 2013-06-23 at 16:52, Philip Herron wrote: > I would like to do a talk on writing a front-end from my experience > with my python front-end That sounds very interesting. > but not sure if i can schedule it in time > since i am moving house at the moment but i might is there a deadline > for a talk submission? We're keeping the organization very informal, so don't worry too much about submission deadlines. If you think you'll be definitely able to attend, I can add you to the official page right now; otherwise I can mark your talk as "to be confirmed". Just tell me. It's not a problem if you finish preparing the talk at the last minute; we'd like to publish presentation slides and such as well as videos, but we can add them later. Please subscribe to ghm-discuss (Cc'd; the subscription web interface is at https://lists.gnu.org/mailman/listinfo/ghm-discuss ), so that we can discuss about your talk without bothering the other gcc people. Thanks! -- Luca Saiu Home page: http://ageinghacker.net GNU epsilon: http://www.gnu.org/software/epsilon Marionnet: http://marionnet.org
Re: GCC talks at the GNU Hackers Meeting?
Hello Iain. I'm adding ghm-discuss in Cc. I think we shouldn't follow up on gcc@ any more at this point. Let's not bother the hardworking compiler masters :-). On 2013-06-24 at 01:15, Iain Buclaw wrote: > I did a similar such talk at DConf 2013 with my GCC front-end for the > D programming language (GDC). Not sure if would be relevant a GCC > conference, but I could think about some of the challenges I've faced. > :o) I for one would be very interested. Well, the conference is about GNU in general, so many people will not be particularly familiar with GCC internals. I, for example, have some knowledge about the general architecture but don't actually know the API, and have never attempted any non-trivial modification to the GCC source base. Some people will be more familiar than me, others even less; but I don't think that it's a serious problem if a few talks are less accessible than others. I like Einstein's phrase "as simple as possible, but not simpler". If needed we can make a GCC session or an "advanced" session, and schedule all such talks close together for the public's sake. Your talk could follow Philip's, I suppose, since if I understood correctly Philips wanted to talk about frontends in general, and you more specifically about the frontend of D. What do you think, Philip? We can certainly have both talks, but I think it would be better if we tried not to say the same things twice. > In any case, I would be interested in attending this - just to get a > better feel of the community, as a definite future goal would be to > get the D front-end merged into GCC proper as an officially supported > language. Of course, welcome. I've registered you and added your talk to the web page. Please register to ghm-discuss at https://lists.gnu.org/mailman/listinfo/ghm-discuss . Philip, I'm waiting for your confirmation before adding you to the official page as well; we can write "to be confirmed" if you want. Thanks, -- Luca Saiu Home page: http://ageinghacker.net GNU epsilon: http://www.gnu.org/software/epsilon Marionnet: http://marionnet.org
Re: GCC talks at the GNU Hackers Meeting?
On 2013-06-24 at 19:14, Iain Buclaw wrote: > My talk at Dconf2013 can be bulleted into the following: > > - What is GDC? > - A brief history of porting the D language to GCC. > - D language and library support, including current challenges being faced. > - Introduction to GCC, in particular an overview of the compilation > process from GENERIC down to RTL and how things tie in with the D > front end. > - Taking advantage of the GCC backend. What features of GCC are > leveraged by the D front end (eg: builtin functions, extended > assembler) > - Future goals and architecture support. Cool for me. If we have Philip's talk as well then part of your fourth point might become redundant, but it's quite small fraction of the talk. Of course you can reuse slides. We all do :-). > Have registered myself. I'll have to confirm my availability. Oh, sorry. I'm marking your name as "to be confirmed" then. Thanks, -- Luca Saiu Home page: http://ageinghacker.net GNU epsilon: http://www.gnu.org/software/epsilon Marionnet: http://marionnet.org
What does 'experimental support for C++11' exactly mean for production work?
Hello, I would like to propose the adoption of C++11 to my colleagues for our production code. We use to rebuild everything with the same compiler version each time (GCC 4.7.3 for now), so ABI incompatibilities between different GCC versions are not an issue for us. However, with C++11 in mind everything would have to be rebuilt with the "-std=c++11" compiler flag turned on, as we could not accept any possible binary incompatibilities between C++11 and C++98. I have been personally using almost all the supported C++11 compiler features for long time without any particular problems. I am also aware of the fact that some big companies already decided to switch from C++98 to C++11 entirely. However, some of my colleagues might not be familiar with C++11 at all and might wonder what the claim "experimental support for C++11" from the official GCC >4.7.3 status pages means in terms of "risks" for our code. Apart from some (minor) C++11 features not being implemented in the standard library or in the compiler yet, I'd like to know what else intrinsic to C++11 with GCC we should consider before switching. Thank you in advance.
Checking for built-in functions from build systems
Hello dear GCC developers, I am working on an issue in Meson wrt GCC built-in functions, see https://github.com/mesonbuild/meson/issues/10641. As you already know, some built-ins are always inlined, while others are inlined only at times (e.g. depending on the target architecture) and resolve to a regular function call otherwise. The issue is about the latter's, i.e. those that may emit regular function calls. In fact, even though __has_builtin(func) evaluates to 1, func may not be present in libraries (libgcc, libc, libm), causing linking errors if not inlined. Because some of the GCC built-in functions are not part of the C standard (e.g. sincos), it's not worthwhile to require having implementations in libc. In addition, should generic implementations be added to libgcc, those would likely have sub-par performance or accuracy issues (being generic). As such, I think that a build system should check if an implementation of a conditionally-inlined built-in function is provided in the target libc. I have a few questions: 1. Is inlining of built-ins dependant only on the target architecture and command-line arguments? 2. If the answer to 1 is yes, could a __is_builtin_inlined (func) macro be added to GCC? It should tell whether func is going to be substituted inline for the given compiler invocation 3. Is it true that conditionally-inlined built-ins are exactly those that come in the two variants of '__builtin_func' and 'func'? Thanks, Luca Bacci
Re: Checking for built-in functions from build systems
Thank you very much, Jonathan. That's very helpful!
This test program:
int main()
{
void *a = alloca(10);
return 0;
}
Compiles fine with:
gcc -o test test.c
But then fails with:
gcc -o test test.c -fno-builtin
That's on an Arch Linux system (based on glibc)
The issue is that what happens when built-ins are not inlined is not well
defined. The libc may not implement the routine, or it's not clear which
dependency should provide it.
Thanks,
Luca Bacci
Il giorno mer 10 ago 2022 alle ore 23:27 Jonathan Wakely <
jwakely@gmail.com> ha scritto:
>
>
> On Wed, 10 Aug 2022, 23:12 Luca Bacci via Gcc, wrote:
>
>>
>> 1. Is inlining of built-ins dependant only on the target architecture and
>> command-line arguments?
>>
>
> No, I think it can depend on the arguments to the built-in as well.
>
>
> 2. If the answer to 1 is yes, could a __is_builtin_inlined (func) macro be
>> added to GCC? It should tell whether func is going to be substituted
>> inline
>> for the given compiler invocation
>
>
> I don't think that can work for some built-ins, e.g. in a single
> translation unit memcmp can be inlined for constant arguments of small
> size, and not inlined for other calls.
>
>
>
>
