Re: x32 psABI draft version 0.2
On 2/16/2011 3:04 PM, H. Peter Anvin wrote: > On 02/16/2011 11:22 AM, H.J. Lu wrote: >> Hi, >> >> I updated x32 psABI draft to version 0.2 to change x32 library path >> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian, >> Ubuntu and other derivative distributions. The new x32 psABI is >> available from: >> >> https://sites.google.com/site/x32abi/home > I'm wondering if we should define a section header flag (sh_flags) > and/or an ELF header flag (e_flags) for x32 for the people unhappy about > keying it to the ELF class... For what it's worth, the Tilera 64-bit architecture (forthcoming) includes support for a 32-bit compatibility layer that is similar to x32. It uses 64-bit registers throughout (e.g. for double and long long), but 32-bit addresses. The addresses between 2GB and 4GB are not directly usable as 64-bit addresses since we sign-extend all 32-bit values to make the ISA more straightforward. We use the "compat" layer to provide our syscall table, since we don't have a traditional compatibility layer in this mode (unlike x86_64 and i386). We differentiate the 64-bit and 32-bit binaries just by the Elf class, a proposed by H.J. above. This seems plausible given that it does capture the differences correctly; everything else is the same, just the Elf class. (And we use /lib vs /lib32 on the 64-bit platform to support the 32-bit shared libraries, etc.) -- Chris Metcalf, Tilera Corp. http://www.tilera.com
Re: x32 psABI draft version 0.2
On 2/16/2011 3:46 PM, H.J. Lu wrote: > On Wed, Feb 16, 2011 at 12:39 PM, Andrew Pinski wrote: >> On Wed, Feb 16, 2011 at 12:35 PM, Chris Metcalf wrote: >>> For what it's worth, the Tilera 64-bit architecture (forthcoming) includes >>> support for a 32-bit compatibility layer that is similar to x32. It uses >>> 64-bit registers throughout (e.g. for double and long long), but 32-bit >>> addresses. The addresses between 2GB and 4GB are not directly usable as >>> 64-bit addresses since we sign-extend all 32-bit values to make the ISA >>> more straightforward. We use the "compat" layer to provide our syscall >>> table, since we don't have a traditional compatibility layer in this mode >>> (unlike x86_64 and i386). >> This sounds more like MIPS' n32 than x32 really. >> > Yes, x32 can access the full 4GB address space. There are some > additional optimizations which can be done in x32, but not in x86-64 > small model. Just to be clear, the "-m32" mode in our 64-bit architecture can access the full 4GB address space, but since "-m32" pointers are sign-extended in the high 32 bits, the kernel/userspace boundary has to convert between a sign-extended userspace pointer and a regular zero-extended pointer that the kernel wants to see. -- Chris Metcalf, Tilera Corp. http://www.tilera.com
Re: gcc vs. glibc bootstrapping of libgcc_eh.a
On 11/9/2011 12:28 PM, Linas Vepstas wrote: I've run into a bootstrapping issue which I'd like to solve "the right way", instead of continuing to hack around it. Briefly: I can't build glibc without libgcc_eh.a, which is provided by gcc. However, libgcc_eh.a is not built, unless I configure gcc with --enable-shared. But doing so causes gcc to attempt to build libgcc_s.so, which fails because it wants to link to libc.so, which hasn't been built yet. And so it goes The "obvious" fix, to me, is to change the libgcc/Makefile.in to always build libgcc_eh.a (and install it) Would such a patch be acceptable? BTW, this is for the "hexagon" architecture, being cross-built. Perhaps there's some other work-around that I missed... (our current work-around is to build uClibc first, install that, and then finish building gcc, then build glibc. Seems pretty yucky to me.) Take a look at the "gcc and glibc from scratch" section of http://www.tilera.com/scm/source.html . I don't know if this will handle your problem, but we do end up with libgcc_eh.a when the dust settles, and it avoids having to build uClibc :-) -- Chris Metcalf, Tilera Corp. http://www.tilera.com
Re: [PATCH v2 9/10] Tilera (and Linux asm-generic) support for glibc
On 11/11/2011 1:09 PM, Roland McGrath wrote:
2011-11-09 Chris Metcalf
* bits/byteswap.h (__bswap*): Use __builtin_bswap for gcc 4.3 and
above. Improves code generation for gcc 4.3 and 4.4 compilers
without bswap pattern detection.
This seems reasonable if some GCC folks can confirm that 4.3 and later
produce optimal code for __builtin_bswap{32,64} on all machines.
I'm cc'ing the gcc mailing list with this reply, so if someone there
can provide an authoritative statement, that would be great. It looks
like right now the i386/x86_64, ia64, and s390 architecture don't use
this header anyway, so it's less important for them. But powerpc and
sparc do use the header (in the core glibc), and most of the
architectures in the "ports" part of glibc do as well.
Roland, Joseph, if we don't hear something definitive from the gcc
folks, I'm inclined to revert this piece back to what I had in the v1
patch, where I provide a tile-specific byteswap.h using
__builtin_bswapNN(), so our gcc 4.4 will generate good code.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
Re: [PATCH v2 9/10] Tilera (and Linux asm-generic) support for glibc
On 11/11/2011 3:17 PM, Andrew Pinski wrote: On Fri, Nov 11, 2011 at 12:13 PM, Chris Metcalf wrote: I'm cc'ing the gcc mailing list with this reply, so if someone there can provide an authoritative statement, that would be great. It looks like right now the i386/x86_64, ia64, and s390 architecture don't use this header anyway, so it's less important for them. But powerpc and sparc do use the header (in the core glibc), and most of the architectures in the "ports" part of glibc do as well. Roland, Joseph, if we don't hear something definitive from the gcc folks, I'm inclined to revert this piece back to what I had in the v1 patch, where I provide a tile-specific byteswap.h using __builtin_bswapNN(), so our gcc 4.4 will generate good code. Right now it does not emit good code for MIPS 32/64 R2. Though I have patches to emit better code for that target. In retrospect, I guess the right question is not whether it produces bad code per se, but whether it produces worse code than for the standard generic byteswap.h: #define __bswap_16(x) \ x)>> 8)& 0xff) | (((x)& 0xff)<< 8)) #define __bswap_32(x) \ x)& 0xff00)>> 24) | (((x)& 0x00ff)>> 8) | \ (((x)& 0xff00)<< 8) | (((x)& 0x00ff)<< 24)) #define __bswap_64(x) \ x)& 0xff00ull)>> 56) \ | (((x)& 0x00ffull)>> 40) \ | (((x)& 0xff00ull)>> 24) \ | (((x)& 0x00ffull)>> 8) \ | (((x)& 0xff00ull)<< 8) \ | (((x)& 0x00ffull)<< 24) \ | (((x)& 0xff00ull)<< 40) \ | (((x)& 0x00ffull)<< 56)) (The 16-bit swap would be done via __builtin_bswap32(x)>> 16.) If it's no worse for any platform, and better for some, that's probably sufficient reason to make the change in glibc to use it. -- Chris Metcalf, Tilera Corp. http://www.tilera.com
