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
I also have a patch for gcc 4.4 which works on simple codes.


H.J.
On Thu, Dec 30, 2010 at 1:31 PM, H. Peter Anvin <[hidden email]> wrote:

> We do have a slightly more extensive patch already implemented.
>
> "Robert Millan" <[hidden email]> 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.
>>
>>Best regards
>>
>>--
>>Robert Millan
>
> --
> Sent from my mobile phone.  Please pardon any lack of formatting.
>



--
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 David Daney-4
On 12/30/2010 12:39 PM, David Daney wrote:
>
> Really I don't care one way or the other.  The necessity of syscall
> wrappers is actually probably beneficial to me.  It will create a
> greater future employment demand for people with the necessary skills to
> write them.
>

Or perhaps automatic generation will actually get implemented.  I wrote
an automatic syscall wrapper generator for klibc; one of the best design
decisions I made for that project.

        -hpa

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

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/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.

        -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

Robert Millan-6
In reply to this post by H.J. Lu-30
2010/12/30 H.J. Lu <[hidden email]>:
> I also have a patch for gcc 4.4 which works on simple codes.
>
> H.J.
> On Thu, Dec 30, 2010 at 1:31 PM, H. Peter Anvin <[hidden email]> wrote:
>> We do have a slightly more extensive patch already implemented.

Could you make those patches available somewhere?  It'd be
interesting to play with them.

Btw, I recommend against 8-byte longs.  In the tests I did in
2009, I recall glibc source was extremely unhappy due to
sizeof(long)==sizeof(void *) assumptions.

--
Robert Millan
Reply | Threaded
Open this post in threaded view
|

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

Robert Millan-6
In reply to this post by Richard Biener
2010/12/30 Richard Guenther <[hidden email]>:
> Would be nice if LFS would be mandatory on the new ABI, thus
> off_t being 64bits.

Please do also consider time_t.

--
Robert Millan
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 Robert Millan-6
On Thu, Dec 30, 2010 at 2:18 PM, Robert Millan <[hidden email]> wrote:

> 2010/12/30 H.J. Lu <[hidden email]>:
>> I also have a patch for gcc 4.4 which works on simple codes.
>>
>> H.J.
>> On Thu, Dec 30, 2010 at 1:31 PM, H. Peter Anvin <[hidden email]> wrote:
>>> We do have a slightly more extensive patch already implemented.
>
> Could you make those patches available somewhere?  It'd be
> interesting to play with them.
>
> Btw, I recommend against 8-byte longs.  In the tests I did in
> 2009, I recall glibc source was extremely unhappy due to
> sizeof(long)==sizeof(void *) assumptions.
>

ILP32 psABI specifies 4byte for long.

--
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 Robert Millan-6
On 12/30/2010 02:18 PM, Robert Millan wrote:

> 2010/12/30 H.J. Lu <[hidden email]>:
>> I also have a patch for gcc 4.4 which works on simple codes.
>>
>> H.J.
>> On Thu, Dec 30, 2010 at 1:31 PM, H. Peter Anvin <[hidden email]> wrote:
>>> We do have a slightly more extensive patch already implemented.
>
> Could you make those patches available somewhere?  It'd be
> interesting to play with them.
>
> Btw, I recommend against 8-byte longs.  In the tests I did in
> 2009, I recall glibc source was extremely unhappy due to
> sizeof(long)==sizeof(void *) assumptions.
>

Yes, it's ILP32.

        -hpa

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

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 Robert Millan-6
On 12/30/2010 02:21 PM, Robert Millan wrote:
> 2010/12/30 Richard Guenther <[hidden email]>:
>> Would be nice if LFS would be mandatory on the new ABI, thus
>> off_t being 64bits.
>
> Please do also consider time_t.
>

Changing the kernel-facing time_t might completely wreck the reuse of
the i386 kernel ABI; I'm not sure.

        -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

Joseph Myers
On Thu, 30 Dec 2010, H. Peter Anvin wrote:

> On 12/30/2010 02:21 PM, Robert Millan wrote:
> > 2010/12/30 Richard Guenther <[hidden email]>:
> >> Would be nice if LFS would be mandatory on the new ABI, thus
> >> off_t being 64bits.
> >
> > Please do also consider time_t.
> >
>
> Changing the kernel-facing time_t might completely wreck the reuse of
> the i386 kernel ABI; I'm not sure.

Before changing time_t for a new ILP32 ABI, you probably want to work out
what is required - on both the libc and kernel sides - to change it for
existing 32-bit ABIs (whether providing a new ABI variant like
_FILE_OFFSET_BITS does, or changing it unconditionally and using symbol
versioning for compatibility with old binaries built for 32-bit time_t).  
Having done that you then have whatever new syscalls may be needed to work
with 64-bit time_t on IA32, and can make the new ILP32 ABI not use the old
32-bit time_t syscalls if desired.

Of course making LFS (or 64-bit time_t) mandatory doesn't help with those
interfaces that hardcode types such as "int" or "long" - you'll still have
code that uses fseek rather than fseeko, for example.  If you follow the
GNU principles of avoiding arbitrary (or at least inappropriate) limits,
there are quite a lot of libc interfaces that can be problematic in
extreme cases (large files, strings over 2GB (e.g. regoff_t - glibc bug
5945 - which is probably one of the easier cases), etc.).  It would be
good to fix these things, both on the GNU principles and for general
robustness (there are probably various security holes related to these
issues - integer overflow issues are always tricky to avoid in C, but bad
choice of types in APIs certainly doesn't help), but it's quite tricky
(lots of core ISO C interfaces are involved) and really needs to be kept
separate from the introduction of new ABIs at the level of x86_64 ILP32.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

H.J. Lu-30
On Thu, Dec 30, 2010 at 3:00 PM, Joseph S. Myers
<[hidden email]> wrote:

> On Thu, 30 Dec 2010, H. Peter Anvin wrote:
>
>> On 12/30/2010 02:21 PM, Robert Millan wrote:
>> > 2010/12/30 Richard Guenther <[hidden email]>:
>> >> Would be nice if LFS would be mandatory on the new ABI, thus
>> >> off_t being 64bits.
>> >
>> > Please do also consider time_t.
>> >
>>
>> Changing the kernel-facing time_t might completely wreck the reuse of
>> the i386 kernel ABI; I'm not sure.
>
> Before changing time_t for a new ILP32 ABI, you probably want to work out
> what is required - on both the libc and kernel sides - to change it for
> existing 32-bit ABIs (whether providing a new ABI variant like
> _FILE_OFFSET_BITS does, or changing it unconditionally and using symbol
> versioning for compatibility with old binaries built for 32-bit time_t).
> Having done that you then have whatever new syscalls may be needed to work
> with 64-bit time_t on IA32, and can make the new ILP32 ABI not use the old
> 32-bit time_t syscalls if desired.
>
> Of course making LFS (or 64-bit time_t) mandatory doesn't help with those
> interfaces that hardcode types such as "int" or "long" - you'll still have
> code that uses fseek rather than fseeko, for example.  If you follow the
> GNU principles of avoiding arbitrary (or at least inappropriate) limits,
> there are quite a lot of libc interfaces that can be problematic in
> extreme cases (large files, strings over 2GB (e.g. regoff_t - glibc bug
> 5945 - which is probably one of the easier cases), etc.).  It would be
> good to fix these things, both on the GNU principles and for general
> robustness (there are probably various security holes related to these
> issues - integer overflow issues are always tricky to avoid in C, but bad
> choice of types in APIs certainly doesn't help), but it's quite tricky
> (lots of core ISO C interfaces are involved) and really needs to be kept
> separate from the introduction of new ABIs at the level of x86_64 ILP32.
>

I am checking in ILP32 binutils so that people can play with it.

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

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

H.J. Lu-30
On Thu, Dec 30, 2010 at 4:25 PM, H.J. Lu <[hidden email]> wrote:

> On Thu, Dec 30, 2010 at 3:00 PM, Joseph S. Myers
> <[hidden email]> wrote:
>> On Thu, 30 Dec 2010, H. Peter Anvin wrote:
>>
>>> On 12/30/2010 02:21 PM, Robert Millan wrote:
>>> > 2010/12/30 Richard Guenther <[hidden email]>:
>>> >> Would be nice if LFS would be mandatory on the new ABI, thus
>>> >> off_t being 64bits.
>>> >
>>> > Please do also consider time_t.
>>> >
>>>
>>> Changing the kernel-facing time_t might completely wreck the reuse of
>>> the i386 kernel ABI; I'm not sure.
>>
>> Before changing time_t for a new ILP32 ABI, you probably want to work out
>> what is required - on both the libc and kernel sides - to change it for
>> existing 32-bit ABIs (whether providing a new ABI variant like
>> _FILE_OFFSET_BITS does, or changing it unconditionally and using symbol
>> versioning for compatibility with old binaries built for 32-bit time_t).
>> Having done that you then have whatever new syscalls may be needed to work
>> with 64-bit time_t on IA32, and can make the new ILP32 ABI not use the old
>> 32-bit time_t syscalls if desired.
>>
>> Of course making LFS (or 64-bit time_t) mandatory doesn't help with those
>> interfaces that hardcode types such as "int" or "long" - you'll still have
>> code that uses fseek rather than fseeko, for example.  If you follow the
>> GNU principles of avoiding arbitrary (or at least inappropriate) limits,
>> there are quite a lot of libc interfaces that can be problematic in
>> extreme cases (large files, strings over 2GB (e.g. regoff_t - glibc bug
>> 5945 - which is probably one of the easier cases), etc.).  It would be
>> good to fix these things, both on the GNU principles and for general
>> robustness (there are probably various security holes related to these
>> issues - integer overflow issues are always tricky to avoid in C, but bad
>> choice of types in APIs certainly doesn't help), but it's quite tricky
>> (lots of core ISO C interfaces are involved) and really needs to be kept
>> separate from the introduction of new ABIs at the level of x86_64 ILP32.
>>
>
> I am checking in ILP32 binutils so that people can play with it.
>

I checked in this patch to avoid using ELF32 relocations on ELF64
inputs and vice verse.


--
H.J.
---
2010-12-30  H.J. Lu  <[hidden email]>

        * elf64-x86-64.c (elf_x86_64_relocs_compatible): New.
        (elf_backend_relocs_compatible): Defined to
        elf_x86_64_relocs_compatible.

diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
index a50dccc..3dd16ba 100644
--- a/bfd/elf64-x86-64.c
+++ b/bfd/elf64-x86-64.c
@@ -4496,6 +4496,17 @@ elf_x86_64_hash_symbol (struct elf_link_hash_entry *h)
   return _bfd_elf_hash_symbol (h);
 }

+/* Return TRUE iff relocations for INPUT are compatible with OUTPUT. */
+
+static bfd_boolean
+elf_x86_64_relocs_compatible (const bfd_target *input,
+      const bfd_target *output)
+{
+  return ((xvec_get_elf_backend_data (input)->s->elfclass
+   == xvec_get_elf_backend_data (output)->s->elfclass)
+  && _bfd_elf_relocs_compatible (input, output));
+}
+
 static const struct bfd_elf_special_section
   elf_x86_64_special_sections[]=
 {
@@ -4536,7 +4547,7 @@ static const struct bfd_elf_special_section
   elf_x86_64_reloc_name_lookup

 #define elf_backend_adjust_dynamic_symbol   elf_x86_64_adjust_dynamic_symbol
-#define elf_backend_relocs_compatible    _bfd_elf_relocs_compatible
+#define elf_backend_relocs_compatible    elf_x86_64_relocs_compatible
 #define elf_backend_check_relocs    elf_x86_64_check_relocs
 #define elf_backend_copy_indirect_symbol    elf_x86_64_copy_indirect_symbol
 #define elf_backend_create_dynamic_sections elf_x86_64_create_dynamic_sections
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 Robert Millan-6
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.

        -hpa

Reply | Threaded
Open this post in threaded view
|

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

H.J. Lu-30
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.


--
H.J.

linux-2.6.35-ilp32-1.patch (19K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Hans-Peter Nilsson
In reply to this post by H.J. Lu
> Date: Thu, 30 Dec 2010 10:23:08 -0800
> From: "H.J. Lu" <[hidden email]>

> 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?

Broke 32-bit bfd build.  Try building on a 32-bit host (or if
you have none handy, use 'CC=gcc -m32' as below with gcc-4.3.x)
for target --target=cris-axis-elf and cris-axis-linux-gnu but I
don't think the target is important.

...
libtool: compile:  gcc -O2 -m32 -DHAVE_CONFIG_H -I. -I/tmp/hpautotest-binutils/bsrc/src/bfd -I. -I/tmp/hpautotest-binutils/bsrc/src/bfd -I/tmp/hpautotest-binutils/bsrc/src/bfd/../include -DHAVE_cris_aout_vec -DHAVE_bfd_elf32_us_cris_vec -DHAVE_bfd_elf32_cris_vec -DHAVE_ieee_vec -DHAVE_bfd_elf32_little_generic_vec -DHAVE_bfd_elf32_big_generic_vec -DBINDIR=\"/usr/local/bin\" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT elflink.lo -MD -MP -MF .deps/elflink.Tpo -c /tmp/hpautotest-binutils/bsrc/src/bfd/elflink.c -o elflink.o
cc1: warnings being treated as errors
/tmp/hpautotest-binutils/bsrc/src/bfd/elflink.c: In function 'elf64_r_sym':
/tmp/hpautotest-binutils/bsrc/src/bfd/elflink.c:12776: warning: right shift count >= width of type
make[4]: Leaving directory `/tmp/hpautotest-binutils/cris-axis-elf/bfd'
make[3]: Leaving directory `/tmp/hpautotest-binutils/cris-axis-elf/bfd'
make[2]: Leaving directory `/tmp/hpautotest-binutils/cris-axis-elf/bfd'
make[1]: Leaving directory `/tmp/hpautotest-binutils/cris-axis-elf'
make[4]: *** [elflink.lo] Error 1

brgds, H-P
Reply | Threaded
Open this post in threaded view
|

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

Hans-Peter Nilsson
> Date: Fri, 31 Dec 2010 02:11:15 +0100
> From: Hans-Peter Nilsson <[hidden email]>

> use 'CC=gcc -m32' as below with gcc-4.3.x)

JFTR, I was wrong on the gcc version:
pchp2:hp:/tmp: rpm -q gcc
gcc-4.4.3-4.fc12.x86_64
and it was 'CC=gcc -O2 -m32'.

brgds, H-P
Reply | Threaded
Open this post in threaded view
|

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

H.J. Lu-30
On Thu, Dec 30, 2010 at 5:16 PM, Hans-Peter Nilsson
<[hidden email]> wrote:

>> Date: Fri, 31 Dec 2010 02:11:15 +0100
>> From: Hans-Peter Nilsson <[hidden email]>
>
>> use 'CC=gcc -m32' as below with gcc-4.3.x)
>
> JFTR, I was wrong on the gcc version:
> pchp2:hp:/tmp: rpm -q gcc
> gcc-4.4.3-4.fc12.x86_64
> and it was 'CC=gcc -O2 -m32'.
>

I checked in this patch to fix it.

Thanks.


--
H.J.
---
diff --git a/bfd/ChangeLog b/bfd/ChangeLog
index fc4e5a3..7899936 100644
--- a/bfd/ChangeLog
+++ b/bfd/ChangeLog
@@ -1,5 +1,15 @@
 2010-12-30  H.J. Lu  <[hidden email]>

+ * elfcode.h (NAME(elf,r_info)): New.
+ (NAME(elf,r_sym)): Likewise.
+
+ * elflink.c (elf64_r_info): Removed.
+ (elf32_r_info): Likewise.
+ (elf64_r_sym): Likewise.
+ (elf32_r_sym): Likewise.
+
+2010-12-30  H.J. Lu  <[hidden email]>
+
  * elf64-x86-64.c (elf_x86_64_relocs_compatible): New.
  (elf_backend_relocs_compatible): Defined to
  elf_x86_64_relocs_compatible.
diff --git a/bfd/elfcode.h b/bfd/elfcode.h
index 5ef4610..509d426 100644
--- a/bfd/elfcode.h
+++ b/bfd/elfcode.h
@@ -1855,6 +1855,22 @@ NAME(_bfd_elf,bfd_from_remote_memory)
     *loadbasep = loadbase;
   return nbfd;
 }
+
+/* Function for ELF_R_INFO.  */
+
+bfd_vma
+NAME(elf,r_info) (bfd_vma sym, bfd_vma type)
+{
+  return ELF_R_INFO (sym, type);
+}
+
+/* Function for ELF_R_SYM.  */
+
+bfd_vma
+NAME(elf,r_sym) (bfd_vma r_info)
+{
+  return ELF_R_SYM (r_info);
+}


 #include "elfcore.h"


diff --git a/bfd/elflink.c b/bfd/elflink.c
index c0dae0f..79256bf 100644
--- a/bfd/elflink.c
+++ b/bfd/elflink.c
@@ -12751,35 +12751,3 @@ elf_append_rel (bfd *abfd, asection *s,
Elf_Internal_Rela *rel)
   BFD_ASSERT (loc + bed->s->sizeof_rel <= s->contents + s->size);
   bed->s->swap_reloca_out (abfd, rel, loc);
 }
-
-/* Function for ELF64_R_INFO.  */
-
-bfd_vma
-elf64_r_info (bfd_vma sym, bfd_vma type)
-{
-  return ELF64_R_INFO (sym, type);
-}
-
-/* Function for ELF32_R_INFO.  */
-
-bfd_vma
-elf32_r_info (bfd_vma sym, bfd_vma type)
-{
-  return ELF32_R_INFO (sym, type);
-}
-
-/* Function for ELF64_R_SYM .  */
-
-bfd_vma
-elf64_r_sym (bfd_vma r_info)
-{
-  return ELF64_R_SYM (r_info);
-}
-
-/* Function for ELF32_R_SYM .  */
-
-bfd_vma
-elf32_r_sym (bfd_vma r_info)
-{
-  return ELF32_R_SYM (r_info);
-}
Reply | Threaded
Open this post in threaded view
|

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

Jakub Jelinek
In reply to this post by hpa
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
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 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.

I prefer caller to do sign/zero extension so that we don't update partial
register.

--
H.J.
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 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


--
H.J.
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 Jakub Jelinek
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


--
H.J.
123