RFC: Add 32bit x86-64 support to binutils

classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add 32bit x86-64 support to binutils

H.J. Lu-30
On Fri, Dec 31, 2010 at 8:50 AM, H.J. Lu <[hidden email]> wrote:

> On Fri, Dec 31, 2010 at 2:03 AM, Jakub Jelinek <[hidden email]> wrote:
>> On Thu, Dec 30, 2010 at 01:42:05PM -0800, H. Peter Anvin wrote:
>>> On 12/30/2010 11:57 AM, Jakub Jelinek wrote:
>>> >>
>>> >> Would be nice if LFS would be mandatory on the new ABI, thus
>>> >> off_t being 64bits.
>>> >
>>> > And avoid ambiguous cases that x86-64 ABI has, e.g. whether
>>> > caller or callee is responsible for sign/zero extension of arguments, to
>>> > avoid the need to sign/zero extend twice, etc.
>>> >
>>>
>>> Ehwhat?  x86-64 is completely unambiguous on that point; the i386 one is
>>> not.
>>
>> It is not, sadly, see http://gcc.gnu.org/PR46942
>> From what I can see the psABI doesn't talk about it, GCC usually sign/zero
>> extends on both sides (exception is 32-bit arguments into 64-bit isn't
>> apparently sign/zero extended on the caller side when doing tail calls),
>> from what I gathered LLVM expects the caller to sign/zero extend (which is
>> incompatible with GCC tail calls then), not sure about ICC, and kernel
>> probably expects for security reasons that the callee sign/zero extends.
>>
>>        Jakub
>>
>
> I added
>
> ---
> When a value of type signed/unsigned char or short is returned or passed
> in a register or on the stack, it should be sign/zero extended to
> signed/unsigned
> int.
> ---
>
> to hjl/extension branch at
>
> http://git.kernel.org/?p=devel/binutils/hjl/x86-64-psabi.git;a=summary
>

According to

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324

all compilers clears bits 1-31 when passing _Bool to a function.  Also
GCC doesn't
sign/zero extend on char/short return.  I updated x86-64 psABI to

----
When a value of type _Bool is returned in a register, bit 0 contains the truth
value and bits 1 to 7 shall be zero. When an argument of type _Bool is passed
in a register or on the stack, bit 0 contains the truth value and bits
1 to 31 shall be
zero.

When a value of type signed/unsigned char or short is returned in a register,
bits 0 to 7 for char and bits 0 to 15 for short contain the value and other
bits are left unspecified. When an argument of signed/unsigned type char or
short is passed in a register or on the stack, it shall be sign/zero extended to
signed/unsigned int.
---

on hjl/extension branch at

http://git.kernel.org/?p=devel/binutils/hjl/x86-64-psabi.git;a=summary


--
H.J.
hpa
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add 32bit x86-64 support to binutils

hpa
In reply to this post by Jakub Jelinek
On 12/31/2010 02:03 AM, Jakub Jelinek wrote:

> On Thu, Dec 30, 2010 at 01:42:05PM -0800, H. Peter Anvin wrote:
>> On 12/30/2010 11:57 AM, Jakub Jelinek wrote:
>>>>
>>>> Would be nice if LFS would be mandatory on the new ABI, thus
>>>> off_t being 64bits.
>>>
>>> And avoid ambiguous cases that x86-64 ABI has, e.g. whether
>>> caller or callee is responsible for sign/zero extension of arguments, to
>>> avoid the need to sign/zero extend twice, etc.
>>>
>>
>> Ehwhat?  x86-64 is completely unambiguous on that point; the i386 one is
>> not.
>
> It is not, sadly, see http://gcc.gnu.org/PR46942
> From what I can see the psABI doesn't talk about it, GCC usually sign/zero
> extends on both sides (exception is 32-bit arguments into 64-bit isn't
> apparently sign/zero extended on the caller side when doing tail calls),
> from what I gathered LLVM expects the caller to sign/zero extend (which is
> incompatible with GCC tail calls then), not sure about ICC, and kernel
> probably expects for security reasons that the callee sign/zero extends.
>

This is weird... we had long discussions about this when the psABI was
originally written, and the decision was that any bits outside the
fundamental type was undefined -- callee extends (caller in the case of
a return value.)  Yet somehow that (and several other discussions) seem
to either never have made it into the document or otherwise have
disappeared somewhere in the process.

There seems to have been problems with closing the loop on a number of
things, and in some cases the compiler writers have gone off and
implemented something completely different from the written document,
yet failed to get the documentation updated to match reality (it took
many years until the definition of _Bool matched what the compilers
actually implemented.)

        -hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add 32bit x86-64 support to binutils

Jan Beulich
In reply to this post by H.J. Lu-30
>>> On 30.12.10 at 21:02, "H.J. Lu" <[hidden email]> wrote:
>
> Here is the ILP32 psABI:
>
> http://www.kernel.org/pub/linux/devel/binutils/ilp32/ 
>

I think it is a gross misconception to tie the ABI to the ELF class of
an object. Specifying the ABI should imo be done via e_flags or
one of the unused bytes of e_ident, and in all reality the ELF class
should *only* affect the file layout (and 64-bit should never have
forbidden to use 32-bit ELF containers; similarly 64-bit ELF objects
may have uses for 32-bit architectures/ABIs, e.g. when debug
information exceeds the 4G boundary).

Jan

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add 32bit x86-64 support to binutils

H.J. Lu-30
On Mon, Jan 3, 2011 at 2:40 AM, Jan Beulich <[hidden email]> wrote:

>>>> On 30.12.10 at 21:02, "H.J. Lu" <[hidden email]> wrote:
>>
>> Here is the ILP32 psABI:
>>
>> http://www.kernel.org/pub/linux/devel/binutils/ilp32/
>>
>
> I think it is a gross misconception to tie the ABI to the ELF class of
> an object. Specifying the ABI should imo be done via e_flags or
> one of the unused bytes of e_ident, and in all reality the ELF class
> should *only* affect the file layout (and 64-bit should never have
> forbidden to use 32-bit ELF containers; similarly 64-bit ELF objects
> may have uses for 32-bit architectures/ABIs, e.g. when debug
> information exceeds the 4G boundary).
>

I agree with you in principle. But I think it should be done via
a new attribute section, similar to ARM.


--
H.J.
hpa
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add 32bit x86-64 support to binutils

hpa
On 01/04/2011 09:56 AM, H.J. Lu wrote:

>>
>> I think it is a gross misconception to tie the ABI to the ELF class of
>> an object. Specifying the ABI should imo be done via e_flags or
>> one of the unused bytes of e_ident, and in all reality the ELF class
>> should *only* affect the file layout (and 64-bit should never have
>> forbidden to use 32-bit ELF containers; similarly 64-bit ELF objects
>> may have uses for 32-bit architectures/ABIs, e.g. when debug
>> information exceeds the 4G boundary).
>
> I agree with you in principle. But I think it should be done via
> a new attribute section, similar to ARM.
>

Oh god, please, no.

I have to say I'm highly questioning to Jan's statement in the first
place.  Crossing 32- and 64-bit ELF like that sounds like a kernel
security hole waiting to happen.

        -hpa

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add 32bit x86-64 support to binutils

Jakub Jelinek
On Tue, Jan 04, 2011 at 10:35:42AM -0800, H. Peter Anvin wrote:

> On 01/04/2011 09:56 AM, H.J. Lu wrote:
> >>
> >> I think it is a gross misconception to tie the ABI to the ELF class of
> >> an object. Specifying the ABI should imo be done via e_flags or
> >> one of the unused bytes of e_ident, and in all reality the ELF class
> >> should *only* affect the file layout (and 64-bit should never have
> >> forbidden to use 32-bit ELF containers; similarly 64-bit ELF objects
> >> may have uses for 32-bit architectures/ABIs, e.g. when debug
> >> information exceeds the 4G boundary).
> >
> > I agree with you in principle. But I think it should be done via
> > a new attribute section, similar to ARM.
> >
>
> Oh god, please, no.
>
> I have to say I'm highly questioning to Jan's statement in the first
> place.  Crossing 32- and 64-bit ELF like that sounds like a kernel
> security hole waiting to happen.

Yeah, and there are other targets where the elf class determines ABI
too (e.g. EM_S390 is used for both 31-bit and 64-bit binaries and
the ELF class determines which).

        Jakub
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add 32bit x86-64 support to binutils

Jan Beulich
>>> On 04.01.11 at 21:02, Jakub Jelinek <[hidden email]> wrote:
> On Tue, Jan 04, 2011 at 10:35:42AM -0800, H. Peter Anvin wrote:
>> On 01/04/2011 09:56 AM, H.J. Lu wrote:
>> >>
>> >> I think it is a gross misconception to tie the ABI to the ELF class of
>> >> an object. Specifying the ABI should imo be done via e_flags or
>> >> one of the unused bytes of e_ident, and in all reality the ELF class
>> >> should *only* affect the file layout (and 64-bit should never have
>> >> forbidden to use 32-bit ELF containers; similarly 64-bit ELF objects
>> >> may have uses for 32-bit architectures/ABIs, e.g. when debug
>> >> information exceeds the 4G boundary).
>> >
>> > I agree with you in principle. But I think it should be done via
>> > a new attribute section, similar to ARM.
>> >
>>
>> Oh god, please, no.
>>
>> I have to say I'm highly questioning to Jan's statement in the first
>> place.  Crossing 32- and 64-bit ELF like that sounds like a kernel
>> security hole waiting to happen.

A particular OS/kernel has the freedom to not implement support for
other than the default format. But having the ABI disallow it
altogether certainly isn't the right choice. And yes, we had been
allowing cross-bitness ELF in an experimental (long canceled) OS
of ours.

> Yeah, and there are other targets where the elf class determines ABI
> too (e.g. EM_S390 is used for both 31-bit and 64-bit binaries and
> the ELF class determines which).

So the usual thing is going to happen - someone made a mistake (I'm
convinced the ELF class was never meant to affect anything but the
file format), and this gets taken as an excuse to let the mistake
spread.

Jan

hpa
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add 32bit x86-64 support to binutils

hpa
On 01/04/2011 11:46 PM, Jan Beulich wrote:

>>>
>>> Oh god, please, no.
>>>
>>> I have to say I'm highly questioning to Jan's statement in the first
>>> place.  Crossing 32- and 64-bit ELF like that sounds like a kernel
>>> security hole waiting to happen.
>
> A particular OS/kernel has the freedom to not implement support for
> other than the default format. But having the ABI disallow it
> altogether certainly isn't the right choice. And yes, we had been
> allowing cross-bitness ELF in an experimental (long canceled) OS
> of ours.
>
>> Yeah, and there are other targets where the elf class determines ABI
>> too (e.g. EM_S390 is used for both 31-bit and 64-bit binaries and
>> the ELF class determines which).
>
> So the usual thing is going to happen - someone made a mistake (I'm
> convinced the ELF class was never meant to affect anything but the
> file format), and this gets taken as an excuse to let the mistake
> spread.
>

I don't think it's all that unreasonable to say the ELF class affects
the ABI.  After all, there are lots of things about the ABI that is
related to the ELF class -- the format of the GOT and PLT, for one thing.

        -hpa
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add 32bit x86-64 support to binutils

Jan Beulich
>>> On 05.01.11 at 09:01, "H. Peter Anvin" <[hidden email]> wrote:
> On 01/04/2011 11:46 PM, Jan Beulich wrote:
>>>>
>>>> Oh god, please, no.
>>>>
>>>> I have to say I'm highly questioning to Jan's statement in the first
>>>> place.  Crossing 32- and 64-bit ELF like that sounds like a kernel
>>>> security hole waiting to happen.
>>
>> A particular OS/kernel has the freedom to not implement support for
>> other than the default format. But having the ABI disallow it
>> altogether certainly isn't the right choice. And yes, we had been
>> allowing cross-bitness ELF in an experimental (long canceled) OS
>> of ours.
>>
>>> Yeah, and there are other targets where the elf class determines ABI
>>> too (e.g. EM_S390 is used for both 31-bit and 64-bit binaries and
>>> the ELF class determines which).
>>
>> So the usual thing is going to happen - someone made a mistake (I'm
>> convinced the ELF class was never meant to affect anything but the
>> file format), and this gets taken as an excuse to let the mistake
>> spread.
>>
>
> I don't think it's all that unreasonable to say the ELF class affects
> the ABI.  After all, there are lots of things about the ABI that is
> related to the ELF class -- the format of the GOT and PLT, for one thing.

That's in executables and dynamic objects only. I'm not aware of
anything in relocatable objects, and I'd question it for core files.
The ABI, however, has to cover all of them.

Jan

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add 32bit x86-64 support to binutils

Jonathan Wakely-4
In reply to this post by H.J. Lu
On 30 December 2010 18:23, H.J. Lu wrote:
>
> This patch adds 32bit x86-64 support to binutils. Support in compiler,
> library and OS is required to use it.  It can be used to implement the
> new 32bit OS for x86-64.  Any comments?

I have a small comment on the changes to the c-i386.texi docs:

diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 1c6175b..c3956a8 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -56,11 +56,14 @@ dependent options:
 @table @gcctabopt
 @cindex @samp{--32} option, i386
 @cindex @samp{--32} option, x86-64
+@cindex @samp{--n32} option, i386
+@cindex @samp{--n32} option, x86-64
 @cindex @samp{--64} option, i386
 @cindex @samp{--64} option, x86-64
-@item --32 | --64
+@item --32 | --n32 | --64
 Select the word size, either 32 bits or 64 bits. Selecting 32-bit
 implies Intel i386 architecture, while 64-bit implies AMD x86-64
+architecture.  @samp{--n32} selects 32bit word size with AMD x86-64
 architecture.

Simply adding the new sentence at the end is not very clear, because
the last sentence contradicts the second sentence:  --n32 selects
32-bit word size, but does not imply Intel i386 architecture.

Also, "32bit" and "32-bit" should be used consistently.

How about:

 Select the word size, either 32 bits or 64 bits. @samp{--32}
 implies Intel i386 architecture, while @samp{--n32} and @samp{--64}
 imply AMD x86-64 architecture with 32-bit or 64-bit word-size
 respectively.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add 32bit x86-64 support to binutils

H.J. Lu-30
On Wed, Jan 5, 2011 at 11:52 AM, Jonathan Wakely <[hidden email]> wrote:

> On 30 December 2010 18:23, H.J. Lu wrote:
>>
>> This patch adds 32bit x86-64 support to binutils. Support in compiler,
>> library and OS is required to use it.  It can be used to implement the
>> new 32bit OS for x86-64.  Any comments?
>
> I have a small comment on the changes to the c-i386.texi docs:
>
> diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
> index 1c6175b..c3956a8 100644
> --- a/gas/doc/c-i386.texi
> +++ b/gas/doc/c-i386.texi
> @@ -56,11 +56,14 @@ dependent options:
>  @table @gcctabopt
>  @cindex @samp{--32} option, i386
>  @cindex @samp{--32} option, x86-64
> +@cindex @samp{--n32} option, i386
> +@cindex @samp{--n32} option, x86-64
>  @cindex @samp{--64} option, i386
>  @cindex @samp{--64} option, x86-64
> -@item --32 | --64
> +@item --32 | --n32 | --64
>  Select the word size, either 32 bits or 64 bits. Selecting 32-bit
>  implies Intel i386 architecture, while 64-bit implies AMD x86-64
> +architecture.  @samp{--n32} selects 32bit word size with AMD x86-64
>  architecture.
>
> Simply adding the new sentence at the end is not very clear, because
> the last sentence contradicts the second sentence:  --n32 selects
> 32-bit word size, but does not imply Intel i386 architecture.
>
> Also, "32bit" and "32-bit" should be used consistently.
>
> How about:
>
>  Select the word size, either 32 bits or 64 bits. @samp{--32}
>  implies Intel i386 architecture, while @samp{--n32} and @samp{--64}
>  imply AMD x86-64 architecture with 32-bit or 64-bit word-size
>  respectively.
>

Thanks. I checked it in.


--
H.J.
---
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gas/ChangeLog,v
retrieving revision 1.4376
diff -u -p -r1.4376 ChangeLog
--- ChangeLog 5 Jan 2011 00:16:49 -0000 1.4376
+++ ChangeLog 5 Jan 2011 21:34:34 -0000
@@ -1,3 +1,7 @@
+2011-01-05  Jonathan Wakely  <[hidden email]>
+
+ * doc/c-i386.texi: Clarify --n32.
+
 2011-01-04  H.J. Lu  <[hidden email]>

  * config/tc-i386.c (build_modrm_byte): Allow encoding 32/64bit
Index: doc/c-i386.texi
===================================================================
RCS file: /cvs/src/src/gas/doc/c-i386.texi,v
retrieving revision 1.53
diff -u -p -r1.53 c-i386.texi
--- doc/c-i386.texi 31 Dec 2010 00:33:34 -0000 1.53
+++ doc/c-i386.texi 5 Jan 2011 21:34:34 -0000
@@ -61,10 +61,10 @@ dependent options:
 @cindex @samp{--64} option, i386
 @cindex @samp{--64} option, x86-64
 @item --32 | --n32 | --64
-Select the word size, either 32 bits or 64 bits. Selecting 32-bit
-implies Intel i386 architecture, while 64-bit implies AMD x86-64
-architecture.  @samp{--n32} selects 32bit word size with AMD x86-64
-architecture.
+Select the word size, either 32 bits or 64 bits.  @samp{--32}
+implies Intel i386 architecture, while @samp{--n32} and @samp{--64}
+imply AMD x86-64 architecture with 32-bit or 64-bit word-size
+respectively.

 These options are only available with the ELF object file format, and
 require that the necessary BFD support has been included (on a 32-bit
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add 32bit x86-64 support to binutils

H.J. Lu-30
In reply to this post by H.J. Lu-30
On Fri, Dec 31, 2010 at 6:50 AM, H.J. Lu <[hidden email]> wrote:

> On Thu, Dec 30, 2010 at 4:48 PM, H.J. Lu <[hidden email]> wrote:
>> On Thu, Dec 30, 2010 at 4:42 PM, H. Peter Anvin <[hidden email]> wrote:
>>> On 12/30/2010 01:08 PM, Robert Millan wrote:
>>>> Hi folks,
>>>>
>>>> I had this unsubmitted patch in my local filesystem.  It makes Linux
>>>> detect ELF32 AMD64 binaries and sets a flag to restrict them to
>>>> 32-bit address space.
>>>>
>>>> It's not rocket science but can save you some work in case you
>>>> haven't implemented this already.
>>>>
>>>
>>> I have pushed my old kernel patches to a git tree at:
>>>
>>> git://git.kernel.org//pub/scm/linux/kernel/git/hpa/linux-2.6-ilp32.git
>>>
>>> They are currently based on 2.6.31 since that was the released version
>>> when I first did this work; they are not intended to be mergeble but
>>> rather as a prototype.
>>>
>>> Note that we have no intention of supporting this ABI for the kernel
>>> itself.  The kernel will be a normal x86-64 kernel.
>>>
>>
>> Here is the updated ILP32 patch for 2.6.35.
>>
>>
>
> I put my ILP32 gdb on hjl/ilp32 branch at
>
> http://git.kernel.org/?p=devel/gdb/hjl/x86.git;a=summary
>
> and my gcc 4.4 ILP32 on hjl/ilp32/gcc-4_4-branch branch at
>
> http://git.kernel.org/?p=devel/gcc/hjl/x86.git;a=summary
>

I checked a bunch ILP32 bug fixes into binutils, gdb and gcc.
I also renamed the option from n32 to x32.

Binutils and gdb should work correctly now. I tested them on
a simple C library with static and dynamic binaries.  Gcc only
works with -O0.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add 32bit x86-64 support to binutils

H.J. Lu-30
On Fri, Jan 14, 2011 at 3:46 PM, H.J. Lu <[hidden email]> wrote:

> On Fri, Dec 31, 2010 at 6:50 AM, H.J. Lu <[hidden email]> wrote:
>> On Thu, Dec 30, 2010 at 4:48 PM, H.J. Lu <[hidden email]> wrote:
>>> On Thu, Dec 30, 2010 at 4:42 PM, H. Peter Anvin <[hidden email]> wrote:
>>>> On 12/30/2010 01:08 PM, Robert Millan wrote:
>>>>> Hi folks,
>>>>>
>>>>> I had this unsubmitted patch in my local filesystem.  It makes Linux
>>>>> detect ELF32 AMD64 binaries and sets a flag to restrict them to
>>>>> 32-bit address space.
>>>>>
>>>>> It's not rocket science but can save you some work in case you
>>>>> haven't implemented this already.
>>>>>
>>>>
>>>> I have pushed my old kernel patches to a git tree at:
>>>>
>>>> git://git.kernel.org//pub/scm/linux/kernel/git/hpa/linux-2.6-ilp32.git
>>>>
>>>> They are currently based on 2.6.31 since that was the released version
>>>> when I first did this work; they are not intended to be mergeble but
>>>> rather as a prototype.
>>>>
>>>> Note that we have no intention of supporting this ABI for the kernel
>>>> itself.  The kernel will be a normal x86-64 kernel.
>>>>
>>>
>>> Here is the updated ILP32 patch for 2.6.35.
>>>
>>>
>>
>> I put my ILP32 gdb on hjl/ilp32 branch at
>>
>> http://git.kernel.org/?p=devel/gdb/hjl/x86.git;a=summary
>>
>> and my gcc 4.4 ILP32 on hjl/ilp32/gcc-4_4-branch branch at
>>
>> http://git.kernel.org/?p=devel/gcc/hjl/x86.git;a=summary
>>
>
> I checked a bunch ILP32 bug fixes into binutils, gdb and gcc.
> I also renamed the option from n32 to x32.
>
> Binutils and gdb should work correctly now. I tested them on
> a simple C library with static and dynamic binaries.  Gcc only
> works with -O0.

I put a small C library for x32 at

http://git.kernel.org/?p=devel/binutils/hjl/x32.git;a=summary


--
H.J.
123