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
|

RFC: Add 32bit x86-64 support to binutils

H.J. Lu
Hi,

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?

Thanks.

H.J.
----
bfd/

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

        * archures.c (bfd_mach_x64_32): New.
        (bfd_mach_x64_32_intel_syntax): Likewise.
        * bfd-in2.h: Regenerated.

        * config.bfd (targ64_selvecs): Add bfd_elf32_x86_64_vec for
        i[3-7]86-*-linux-*.
        (targ_selvecs): Add bfd_elf32_x86_64_vec for x86_64-*-linux-*.

        * configure.in: Support bfd_elf32_x86_64_vec.
        * configure: Regenerated.

        * cpu-i386.c (bfd_x64_32_arch_intel_syntax): New.
        (bfd_x64_32_arch): Likewise.

        * elf-bfd.h (elf_append_rela): New prototype.
        (elf_append_rel): Likewise.
        (elf64_r_info): Likewise.
        (elf32_r_info): Likewise.
        (elf64_r_sym): Likewise.
        (elf32_r_sym): Likewise.

        * elf64-x86-64.c (ABI_64_P): New.
        (elf_x86_64_info_to_howto): Replace ELF64_R_TYPE with
        ELF32_R_TYPE.  Replace ELF64_ST_TYPE with ELF_ST_TYPE.
        (elf_x86_64_check_tls_transition):Likewise.
        (elf_x86_64_check_relocs): Likewise.
        (elf_x86_64_gc_mark_hook):Likewise.
        (elf_x86_64_gc_sweep_hook): Likewise.
        (elf_x86_64_relocate_section): Likewise.
        (elf_x86_64_reloc_type_class): Likewise.
        (ELF_DYNAMIC_INTERPRETER): Renamed to ...
        (ELF64_DYNAMIC_INTERPRETER): This.
        (ELF32_DYNAMIC_INTERPRETER): New.
        (elf_x86_64_link_hash_table): Add r_info, r_sym, swap_reloca_out,
        dynamic_interpreter and dynamic_interpreter_size.
        (elf_x86_64_get_local_sym_hash): Replace ELF64_R_SYM with
        htab->r_sym.  Replace ELF64_R_INFO with htab->r_info.
        (elf_x86_64_get_local_sym_hash): Likewise.
        (elf_x86_64_check_tls_transition):Likewise.
        (elf_x86_64_check_relocs): Likewise.
        (elf_x86_64_gc_mark_hook):Likewise.
        (elf_x86_64_gc_sweep_hook): Likewise.
        (elf_x86_64_relocate_section): Likewise.
        (elf_x86_64_finish_dynamic_symbol): Likewise.
        (elf_x86_64_finish_local_dynamic_symbol): Likewise.
        (elf_x86_64_link_hash_table_create): Initialize r_info, r_sym,
        swap_reloca_out, dynamic_interpreter and dynamic_interpreter_size.
        (elf_x86_64_check_relocs): Check ABI_64_P when requesting for
        PIC.
        (elf_x86_64_relocate_section): Likewise.
        (elf64_x86_64_adjust_dynamic_symbol): Replace sizeof
        (Elf64_External_Rela) with bed->s->sizeof_rela.
        (elf64_x86_64_allocate_dynrelocs): Likewise.
        (elf64_x86_64_size_dynamic_sections): Likewise.
        (elf64_x86_64_finish_dynamic_symbol): Likewise.
        (elf64_x86_64_append_rela): Removed.
        (elf32_x86_64_elf_object_p): New.
        Add bfd_elf32_x86_64_vec.

        * elf64-x86-64.c (elf64_x86_64_xxx): Renamed to ...
        (elf_x86_64_xxx): This.

        * elflink.c (bfd_elf_final_link): Check ELF file class on error.
        (elf_append_rela): New.
        (elf_append_rel): Likewise.
        (elf64_r_info): Likewise.
        (elf32_r_info): Likewise.
        (elf64_r_sym): Likewise.
        (elf32_r_sym): Likewise.

        * targets.c (bfd_elf32_x86_64_vec): New.
        (_bfd_target_vector): Add bfd_elf32_x86_64_vec.

gas/

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

        * config/tc-i386.c (x86_elf_abi): New.
        (i386_mach): Return bfd_mach_x64_32 for ILP32.
        (OPTION_N32): Likewise.
        (md_longopts): Add "n32" for ELF.
        (md_parse_option): Handle OPTION_N32.
        (md_show_usage): Add --n32.
        (i386_target_format): Update and check x86_elf_abi.

        * config/tc-i386.h (ELF_TARGET_FORMAT32): New.

        * doc/as.texinfo: Document --n32.
        * doc/c-i386.texi: Likewise.

gas/testsuite/

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

        * gas/i386/ilp32/lns/ilp32.exp: New.
        * gas/i386/ilp32/lns/lns-common-1.d: Likewise.
        * gas/i386/ilp32/lns/lns-duplicate.d: Likewise.

        * gas/i386/ilp32/cfi/cfi-common-1.d: New.
        * gas/i386/ilp32/cfi/cfi-common-2.d: Likewise.
        * gas/i386/ilp32/cfi/cfi-common-3.d: Likewise.
        * gas/i386/ilp32/cfi/cfi-common-4.d: Likewise.
        * gas/i386/ilp32/cfi/cfi-common-5.d: Likewise.
        * gas/i386/ilp32/cfi/cfi-common-6.d: Likewise.
        * gas/i386/ilp32/cfi/cfi-common-7.d: Likewise.
        * gas/i386/ilp32/cfi/cfi-x86_64.d: Likewise.
        * gas/i386/ilp32/cfi/ilp32.exp: Likewise.
        * gas/i386/ilp32/elf/ehopt0.d: Likewise.
        * gas/i386/ilp32/elf/equ-reloc.d: Likewise.
        * gas/i386/ilp32/elf/file.d: Likewise.
        * gas/i386/ilp32/elf/group0a.d: Likewise.
        * gas/i386/ilp32/elf/group0b.d: Likewise.
        * gas/i386/ilp32/elf/group1a.d: Likewise.
        * gas/i386/ilp32/elf/group1b.d: Likewise.
        * gas/i386/ilp32/elf/ifunc-1.d: Likewise.
        * gas/i386/ilp32/elf/ilp32.exp: Likewise.
        * gas/i386/ilp32/elf/redef.d: Likewise.
        * gas/i386/ilp32/elf/section0.d: Likewise.
        * gas/i386/ilp32/elf/section1.d: Likewise.
        * gas/i386/ilp32/elf/section3.d: Likewise.
        * gas/i386/ilp32/elf/section4.d: Likewise.
        * gas/i386/ilp32/elf/section6.d: Likewise.
        * gas/i386/ilp32/elf/section7.d: Likewise.
        * gas/i386/ilp32/elf/struct.d: Likewise.
        * gas/i386/ilp32/elf/symtab.d: Likewise.
        * gas/i386/ilp32/elf/symver.d: Likewise.

        * gas/i386/ilp32/ilp32.exp: New.
        * gas/i386/ilp32/immed64.d: Likewise.
        * gas/i386/ilp32/mixed-mode-reloc64.d: Likewise.
        * gas/i386/ilp32/reloc64.d: Likewise.
        * gas/i386/ilp32/rex.d: Likewise.
        * gas/i386/ilp32/rexw.d: Likewise.
        * gas/i386/ilp32/svme64.d: Likewise.
        * gas/i386/ilp32/x86-64-addr32.d: Likewise.
        * gas/i386/ilp32/x86-64-addr32-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-aes.d: Likewise.
        * gas/i386/ilp32/x86-64-aes-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-amdfam10.d: Likewise.
        * gas/i386/ilp32/x86-64-arch-1.d: Likewise.
        * gas/i386/ilp32/x86-64-arch-2.d: Likewise.
        * gas/i386/ilp32/x86-64-avx.d: Likewise.
        * gas/i386/ilp32/x86-64-avx-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-avx-swap.d: Likewise.
        * gas/i386/ilp32/x86-64-avx-swap-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-branch.d: Likewise.
        * gas/i386/ilp32/x86-64-cbw.d: Likewise.
        * gas/i386/ilp32/x86-64-cbw-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-clmul.d: Likewise.
        * gas/i386/ilp32/x86-64-clmul-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-crc32.d: Likewise.
        * gas/i386/ilp32/x86-64-crc32-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-crx.d: Likewise.
        * gas/i386/ilp32/x86-64-crx-suffix.d: Likewise.
        * gas/i386/ilp32/x86-64.d: Likewise.
        * gas/i386/ilp32/x86-64-disp.d: Likewise.
        * gas/i386/ilp32/x86-64-disp-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-drx.d: Likewise.
        * gas/i386/ilp32/x86-64-drx-suffix.d: Likewise.
        * gas/i386/ilp32/x86-64-ept.d: Likewise.
        * gas/i386/ilp32/x86-64-ept-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-fma4.d: Likewise.
        * gas/i386/ilp32/x86-64-fma.d: Likewise.
        * gas/i386/ilp32/x86-64-fma-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-gidt.d: Likewise.
        * gas/i386/ilp32/x86-64-ifunc.d: Likewise.
        * gas/i386/ilp32/x86-64-intel64.d: Likewise.
        * gas/i386/ilp32/x86-64-io.d: Likewise.
        * gas/i386/ilp32/x86-64-io-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-io-suffix.d: Likewise.
        * gas/i386/ilp32/x86-64-localpic.d: Likewise.
        * gas/i386/ilp32/x86-64-mem.d: Likewise.
        * gas/i386/ilp32/x86-64-mem-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-movbe.d: Likewise.
        * gas/i386/ilp32/x86-64-movbe-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-nops-1-core2.d: Likewise.
        * gas/i386/ilp32/x86-64-nops-1.d: Likewise.
        * gas/i386/ilp32/x86-64-nops-1-k8.d: Likewise.
        * gas/i386/ilp32/x86-64-nops-1-nocona.d: Likewise.
        * gas/i386/ilp32/x86-64-nops-1-pentium.d: Likewise.
        * gas/i386/ilp32/x86-64-nops-2.d: Likewise.
        * gas/i386/ilp32/x86-64-nops-3.d: Likewise.
        * gas/i386/ilp32/x86-64-nops-4-core2.d: Likewise.
        * gas/i386/ilp32/x86-64-nops-4.d: Likewise.
        * gas/i386/ilp32/x86-64-nops-4-k8.d: Likewise.
        * gas/i386/ilp32/x86-64-nops-5.d: Likewise.
        * gas/i386/ilp32/x86-64-nops-5-k8.d: Likewise.
        * gas/i386/ilp32/x86-64-nops.d: Likewise.
        * gas/i386/ilp32/x86-64-opcode.d: Likewise.
        * gas/i386/ilp32/x86-64-opcode-inval.d: Likewise.
        * gas/i386/ilp32/x86-64-opcode-inval-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-opts.d: Likewise.
        * gas/i386/ilp32/x86-64-opts-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-pcrel.d: Likewise.
        * gas/i386/ilp32/x86-64-reg.d: Likewise.
        * gas/i386/ilp32/x86-64-reg-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-rep.d: Likewise.
        * gas/i386/ilp32/x86-64-rep-suffix.d: Likewise.
        * gas/i386/ilp32/x86-64-rip.d: Likewise.
        * gas/i386/ilp32/x86-64-rip-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-sib.d: Likewise.
        * gas/i386/ilp32/x86-64-sib-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-simd.d: Likewise.
        * gas/i386/ilp32/x86-64-simd-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-simd-suffix.d: Likewise.
        * gas/i386/ilp32/x86-64-sse2avx.d: Likewise.
        * gas/i386/ilp32/x86-64-sse2avx-opts.d: Likewise.
        * gas/i386/ilp32/x86-64-sse2avx-opts-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-sse3.d: Likewise.
        * gas/i386/ilp32/x86-64-sse4_1.d: Likewise.
        * gas/i386/ilp32/x86-64-sse4_1-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-sse4_2.d: Likewise.
        * gas/i386/ilp32/x86-64-sse4_2-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-sse-check.d: Likewise.
        * gas/i386/ilp32/x86-64-sse-check-none.d: Likewise.
        * gas/i386/ilp32/x86-64-sse-check-warn.d: Likewise.
        * gas/i386/ilp32/x86-64-sse-noavx.d: Likewise.
        * gas/i386/ilp32/x86-64-ssse3.d: Likewise.
        * gas/i386/ilp32/x86-64-stack.d: Likewise.
        * gas/i386/ilp32/x86-64-stack-intel.d: Likewise.
        * gas/i386/ilp32/x86-64-stack-suffix.d: Likewise.
        * gas/i386/ilp32/x86-64-unwind.d: Likewise.
        * gas/i386/ilp32/x86-64-vmx.d: Likewise.
        * gas/i386/ilp32/x86-64-xsave.d: Likewise.
        * gas/i386/ilp32/x86-64-xsave-intel.d: Likewise.

ld/

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

        * emulparams/elf32_x86_64.sh: New.

        * configure.tgt (targ64_extra_emuls): Add elf32_x86_64 for
        i[3-7]86-*-linux-*.
        (targ_extra_libpath): Likewise.
        (targ_extra_emuls): Add elf32_x86_64 for x86_64-*-linux-*.
        (targ_extra_libpath): Likewise.

        * Makefile.am (ALL_64_EMULATION_SOURCES): Add eelf32_x86_64.c.
        (eelf32_x86_64.c): New.
        * Makefile.in: Regenerated.

opcodes/

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

        * i386-dis.c (print_insn): Support bfd_mach_x64_32 and
        bfd_mach_x64_32_intel_syntax.


binutils-ilp32-1.patch.bz2 (102K) Download Attachment
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.J. Lu wrote:

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

Do you have a public psABI document?  I think the psABI at the ELF level
needs to come before the binutils bits, at the function call level needs
to come before the GCC bits, etc.

You appear (judging by the support for Linux targets in the binutils
patch) to envisage Linux support for this ABI.  How do you plan to avoid
the problems that have plagued the MIPS n32 syscall ABI, which seems like
a similar case?

(If you could arrange for the syscall ABI always to be the same as the
existing 64-bit ABI, rather than needing to handle three different syscall
ABIs in the kernel, that might be one solution, but it could have its own
complexities in ensuring that none of the types whose layout forms part of
the kernel/userspace interface have layout differing between n32 and the
existing ABI; without any action, structures would tend to get layout
similar to that of the existing 32-bit ABI, though quite possibly not the
same depending on alignment peculiarities - I'm guessing that the new ABI
will use natural alignment - while long long arguments would tend to be
passed in a single register, resulting in the complicated hybrid syscall
ABI present on MIPS.  If you do have an all-new syscall ABI rather than
sharing the existing 64-bit one, I imagine it would need to follow the
cut-down set of syscalls for new ports, so involving the issue of how to
build glibc for that set of syscalls discussed three months ago in the
Tilera context.)

--
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 10:42 AM, Joseph S. Myers
<[hidden email]> wrote:

> On Thu, 30 Dec 2010, H.J. Lu wrote:
>
>> Hi,
>>
>> 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?
>
> Do you have a public psABI document?  I think the psABI at the ELF level
> needs to come before the binutils bits, at the function call level needs
> to come before the GCC bits, etc.

The psABI is the same as x86-64 psABI, except for 32bit ELF instead of
64bit.

> You appear (judging by the support for Linux targets in the binutils
> patch) to envisage Linux support for this ABI.  How do you plan to avoid

I enabled it for Linux so that I can run ILP32 binutils tests on Linux/x86-64.

> the problems that have plagued the MIPS n32 syscall ABI, which seems like
> a similar case?

Can you describe MIPS n32 problems?

> (If you could arrange for the syscall ABI always to be the same as the
> existing 64-bit ABI, rather than needing to handle three different syscall
> ABIs in the kernel, that might be one solution, but it could have its own
> complexities in ensuring that none of the types whose layout forms part of
> the kernel/userspace interface have layout differing between n32 and the
> existing ABI; without any action, structures would tend to get layout
> similar to that of the existing 32-bit ABI, though quite possibly not the
> same depending on alignment peculiarities - I'm guessing that the new ABI
> will use natural alignment - while long long arguments would tend to be
> passed in a single register, resulting in the complicated hybrid syscall
> ABI present on MIPS.  If you do have an all-new syscall ABI rather than
> sharing the existing 64-bit one, I imagine it would need to follow the
> cut-down set of syscalls for new ports, so involving the issue of how to
> build glibc for that set of syscalls discussed three months ago in the
> Tilera context.)
>

You are right.  Add ILP32 support to Linux kernel may be tricky.
We did some experiment to use IA32 syscall interface for ILP32:

[hjl@gnu-18 simple]$ make ilp32
make LDFLAGS="-m elf32_x86_64" CFLAGS="-g -O2 -D__i386__ -mn32"
make[1]: Entering directory `/export/gnu/import/svn/psABI/x86-64/ilp32/simple'
/export/build/gnu/gcc-ilp32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-ilp32/build-x86_64-linux/gcc/ -g -O2
-D__i386__ -mn32 -c -D__ASSEMBLY__ start.S
/export/build/gnu/gcc-ilp32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-ilp32/build-x86_64-linux/gcc/ -g -O2
-D__i386__ -mn32   -c -o simple.o simple.c
/export/build/gnu/gcc-ilp32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-ilp32/build-x86_64-linux/gcc/ -g -O2
-D__i386__ -mn32 -c -D__ASSEMBLY__ syscall.S
ld -m elf32_x86_64 -o simple start.o simple.o syscall.o
./simple This is a test.
This is a test.
Hello world
make[1]: Leaving directory `/export/gnu/import/svn/psABI/x86-64/ilp32/simple'
[hjl@gnu-18 simple]$ file simple
simple: ELF 32-bit LSB executable, x86-64, version 1 (SYSV),
statically linked, not stripped
[hjl@gnu-18 simple]$

I also have a patch for GDB:

[hjl@gnu-18 simple]$ ./gdb simple
GNU gdb (GDB) 7.2.50.20101229-cvs
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/export/gnu/import/svn/psABI/x86-64/ilp32/simple/simple...done.
(gdb) b main
Breakpoint 1 at 0x4000f0: file simple.c, line 25.
(gdb) r
Starting program: /export/gnu/import/svn/psABI/x86-64/ilp32/simple/simple

Breakpoint 1, main (argc=1, argv=0xffffd4f4) at simple.c:25
25 {
(gdb) info reg
rax            0x0 0
rbx            0x0 0
rcx            0x0 0
rdx            0x0 0
rsi            0xffffd4f4 4294956276
rdi            0x1 1
rbp            0x0 0x0
rsp            0xffffd4e8 0xffffd4e8
r8             0x0 0
r9             0x0 0
r10            0x0 0
r11            0x200 512
r12            0x0 0
r13            0x0 0
r14            0x0 0
r15            0x0 0
rip            0x4000f0 0x4000f0 <main>
eflags         0x286 [ PF SF IF ]
cs             0x33 51
ss             0x2b 43
ds             0x2b 43
es             0x2b 43
fs             0x0 0
---Type <return> to continue, or q <return> to quit---
gs             0x0 0
(gdb) p $rsp
$1 = (void *) 0xffffd4e8
(gdb) p $sp
$2 = (void *) 0xffffd4e8
(gdb) p $pc
$3 = (void (*)()) 0x4000f0 <main>
(gdb)

int syscall(int number, ...);

is implemented with

        pushq %rbp
        pushq %rbx
        mov %edi, %eax /* Syscall number -> rax.  */
        mov %esi, %ebx /* shift arg1 - arg6.  */
        xchg %edx, %ecx
        mov %r8d, %edi
        mov %r9d, %ebp
        int $0x80
        popq %rbx
        popq %rbp

That means we pass 64bit integers to kernel the same way as ia32.

Of course, there are some exceptions for ptrace and signals.

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

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

hpa
On 12/30/2010 10:59 AM, H.J. Lu wrote:

>
>> (If you could arrange for the syscall ABI always to be the same as the
>> existing 64-bit ABI, rather than needing to handle three different syscall
>> ABIs in the kernel, that might be one solution, but it could have its own
>> complexities in ensuring that none of the types whose layout forms part of
>> the kernel/userspace interface have layout differing between n32 and the
>> existing ABI; without any action, structures would tend to get layout
>> similar to that of the existing 32-bit ABI, though quite possibly not the
>> same depending on alignment peculiarities - I'm guessing that the new ABI
>> will use natural alignment - while long long arguments would tend to be
>> passed in a single register, resulting in the complicated hybrid syscall
>> ABI present on MIPS.  If you do have an all-new syscall ABI rather than
>> sharing the existing 64-bit one, I imagine it would need to follow the
>> cut-down set of syscalls for new ports, so involving the issue of how to
>> build glibc for that set of syscalls discussed three months ago in the
>> Tilera context.)
>>
>
> You are right.  Add ILP32 support to Linux kernel may be tricky.
> We did some experiment to use IA32 syscall interface for ILP32:
>

The current plan is to simply use the 32-bit kernel ABI more or less
unmodified, although probably with a different entry point using syscall
rather than int 0x80 for performance.  In order for the ABI to map 1:1,
there needs to be a few concessions:

a) 64-bit arguments will need to be split in user space.
b) The Linux kernel  exported __u64 type will need to be declared
   __attribute__((aligned(4))).  This will only affect a handful of
   structures in practice since implicit padding is frowned upon.

(a) could also be fixed by a different syscall dispatch table, it's not
the hard part of this.  We definitely want to avoid adding a different
memory ABI; that's the part that hurts.

        -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
In reply to this post by H.J. Lu-30
On Thu, 30 Dec 2010, H.J. Lu wrote:

> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
> <[hidden email]> wrote:
> > On Thu, 30 Dec 2010, H.J. Lu wrote:
> >
> >> Hi,
> >>
> >> 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?
> >
> > Do you have a public psABI document?  I think the psABI at the ELF level
> > needs to come before the binutils bits, at the function call level needs
> > to come before the GCC bits, etc.
>
> The psABI is the same as x86-64 psABI, except for 32bit ELF instead of
> 64bit.
I don't think that's an adequate description.  If the "ILP32" name is
accurate then it's certainly wrong at the C level since some type sizes
are different, with effects in turn on such things as the description of
initial stack layout storing argv.  At the ELF level are you saying that
each relocation applies to a relocatable field of the same width as for
64-bit (but with the width of the addend being restricted, of course)?  Do
any relocations applying to word64 fields need 32-bit variants applying to
word32 for the ILP32 ABI?

The right thing to do would be to go through the ABI sources and prepare a
patch adding a description of the ILP32 ABI at least place where any
change is needed.

> > the problems that have plagued the MIPS n32 syscall ABI, which seems like
> > a similar case?
>
> Can you describe MIPS n32 problems?

Syscalls sometimes need three different versions in the kernel; sometimes
the wrong version gets put in the n32 syscall table.  Special syscall
wrappers are often needed in glibc; although for most purposes the glibc
port is a 32-bit one, including having separate functions for 32-bit and
64-bit off_t, syscalls tend to need to be called in the 64-bit way (long
long values as single arguments, in particular).

> You are right.  Add ILP32 support to Linux kernel may be tricky.
> We did some experiment to use IA32 syscall interface for ILP32:

That seems likely to run into the structure layout issues I mentioned
(long long only being 4-byte aligned for IA32, but 8-byte aligned for
x86-64 and I presume for the new ABI).

> That means we pass 64bit integers to kernel the same way as ia32.

That has its own problems.  If the C prototype of a system call, at the
userspace level, has a 64-bit integer argument, it's desirable that the
argument is passed to the kernel in the same way as it is passed to the C
function implementing the syscall.  This allows glibc's automatically
generated syscall wrappers to work.  (Note how fanotify_mark is defined to
use i:iiiiis for 32-bit, i:iiiis for 64-bit - and i:iiiis for MIPS n32
because a 64-bit argument is passed in a single register for n32.  
Recently added syscalls have had care taken to position 64-bit arguments
so that this sort of thing does work for 32-bit architectures, rather than
leaving an unused register for alignment as can arise with bad positioning
of the 64-bit arguments.)  MIPS n32 still needs special wrappers in
various cases where generic Linux needs C wrappers (posix_fadvise,
fallocate, posix_fallocate, for example) but avoids them for syscalls.list
cases.

If the C ABI for 64-bit integers passes them in single registers (as is
the natural adaptation of the 64-bit ABI), then such integers should also
be passed to the kernel in single registers; otherwise you need custom
wrappers for each affected syscall.  But then you certainly can't use the
IA32 syscall ABI....

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

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

David Daney-4
In reply to this post by H.J. Lu-30
On 12/30/2010 10:59 AM, H.J. Lu wrote:

> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
> <[hidden email]>  wrote:
>> On Thu, 30 Dec 2010, H.J. Lu wrote:
>>
>>> Hi,
>>>
>>> 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?
>>
>> Do you have a public psABI document?  I think the psABI at the ELF level
>> needs to come before the binutils bits, at the function call level needs
>> to come before the GCC bits, etc.
>
> The psABI is the same as x86-64 psABI, except for 32bit ELF instead of
> 64bit.
>
>> You appear (judging by the support for Linux targets in the binutils
>> patch) to envisage Linux support for this ABI.  How do you plan to avoid
>
> I enabled it for Linux so that I can run ILP32 binutils tests on Linux/x86-64.
>
>> the problems that have plagued the MIPS n32 syscall ABI, which seems like
>> a similar case?
>
> Can you describe MIPS n32 problems?
>

I can.  As Joseph indicated, any syscall that passes data in memory
(ioctl, {set,get}sockopt, etc) potentially must have a translation done
between kernel and user ABIs.

Currently this is done in kernel/compat.c fs/compat_binfmt_elf.c and
fs/compat_ioctl.c as well as a bunch of architecture specific ad hoc
code.  Look at the change history for those files to see that there is
an unending flow of bugs being fixed due to this ABI mismatch.

Even today there are many obscure ioctls that don't work on MIPS n32.
Most of the code works most of the time, but then someone tries
something new, and BAM! ABI mismatch hits anew.

My suggestion:  Since people already spend a great deal of effort
maintaining the existing i386 compatible Linux syscall infrastructure,
make your new 32-bit x86-64 Linux syscall ABI identical to the existing
i386 syscall ABI.  This means that the psABI must use the same size and
alignment rules for in-memory structures as the i386 does.

David Daney
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 Joseph Myers
On Thu, Dec 30, 2010 at 11:30 AM, Joseph S. Myers
<[hidden email]> wrote:

> On Thu, 30 Dec 2010, H.J. Lu wrote:
>
>> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
>> <[hidden email]> wrote:
>> > On Thu, 30 Dec 2010, H.J. Lu wrote:
>> >
>> >> Hi,
>> >>
>> >> 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?
>> >
>> > Do you have a public psABI document?  I think the psABI at the ELF level
>> > needs to come before the binutils bits, at the function call level needs
>> > to come before the GCC bits, etc.
>>
>> The psABI is the same as x86-64 psABI, except for 32bit ELF instead of
>> 64bit.
>
> I don't think that's an adequate description.  If the "ILP32" name is
> accurate then it's certainly wrong at the C level since some type sizes
> are different, with effects in turn on such things as the description of
> initial stack layout storing argv.  At the ELF level are you saying that
> each relocation applies to a relocatable field of the same width as for
> 64-bit (but with the width of the addend being restricted, of course)?  Do
> any relocations applying to word64 fields need 32-bit variants applying to
> word32 for the ILP32 ABI?

ILP32 uses small model in x86-64 psABI.

> The right thing to do would be to go through the ABI sources and prepare a
> patch adding a description of the ILP32 ABI at least place where any
> change is needed.

That is on my TODO list. I am planning to publish an ILP32 psABI.

>> > the problems that have plagued the MIPS n32 syscall ABI, which seems like
>> > a similar case?
>>
>> Can you describe MIPS n32 problems?
>
> Syscalls sometimes need three different versions in the kernel; sometimes
> the wrong version gets put in the n32 syscall table.  Special syscall
> wrappers are often needed in glibc; although for most purposes the glibc
> port is a 32-bit one, including having separate functions for 32-bit and
> 64-bit off_t, syscalls tend to need to be called in the 64-bit way (long
> long values as single arguments, in particular).
>
>> You are right.  Add ILP32 support to Linux kernel may be tricky.
>> We did some experiment to use IA32 syscall interface for ILP32:
>
> That seems likely to run into the structure layout issues I mentioned
> (long long only being 4-byte aligned for IA32, but 8-byte aligned for
> x86-64 and I presume for the new ABI).
>
>> That means we pass 64bit integers to kernel the same way as ia32.
>
> That has its own problems.  If the C prototype of a system call, at the
> userspace level, has a 64-bit integer argument, it's desirable that the
> argument is passed to the kernel in the same way as it is passed to the C
> function implementing the syscall.  This allows glibc's automatically
> generated syscall wrappers to work.  (Note how fanotify_mark is defined to
> use i:iiiiis for 32-bit, i:iiiis for 64-bit - and i:iiiis for MIPS n32
> because a 64-bit argument is passed in a single register for n32.
> Recently added syscalls have had care taken to position 64-bit arguments
> so that this sort of thing does work for 32-bit architectures, rather than
> leaving an unused register for alignment as can arise with bad positioning
> of the 64-bit arguments.)  MIPS n32 still needs special wrappers in
> various cases where generic Linux needs C wrappers (posix_fadvise,
> fallocate, posix_fallocate, for example) but avoids them for syscalls.list
> cases.
>
> If the C ABI for 64-bit integers passes them in single registers (as is
> the natural adaptation of the 64-bit ABI), then such integers should also
> be passed to the kernel in single registers; otherwise you need custom
> wrappers for each affected syscall.  But then you certainly can't use the
> IA32 syscall ABI....
>

We will address those issues if we want to support ILP32 on Linux.

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

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

Richard Biener
In reply to this post by Joseph Myers
On Thu, Dec 30, 2010 at 8:30 PM, Joseph S. Myers
<[hidden email]> wrote:

> On Thu, 30 Dec 2010, H.J. Lu wrote:
>
>> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
>> <[hidden email]> wrote:
>> > On Thu, 30 Dec 2010, H.J. Lu wrote:
>> >
>> >> Hi,
>> >>
>> >> 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?
>> >
>> > Do you have a public psABI document?  I think the psABI at the ELF level
>> > needs to come before the binutils bits, at the function call level needs
>> > to come before the GCC bits, etc.
>>
>> The psABI is the same as x86-64 psABI, except for 32bit ELF instead of
>> 64bit.
>
> I don't think that's an adequate description.  If the "ILP32" name is
> accurate then it's certainly wrong at the C level since some type sizes
> are different, with effects in turn on such things as the description of
> initial stack layout storing argv.  At the ELF level are you saying that
> each relocation applies to a relocatable field of the same width as for
> 64-bit (but with the width of the addend being restricted, of course)?  Do
> any relocations applying to word64 fields need 32-bit variants applying to
> word32 for the ILP32 ABI?
>
> The right thing to do would be to go through the ABI sources and prepare a
> patch adding a description of the ILP32 ABI at least place where any
> change is needed.
>
>> > the problems that have plagued the MIPS n32 syscall ABI, which seems like
>> > a similar case?
>>
>> Can you describe MIPS n32 problems?
>
> Syscalls sometimes need three different versions in the kernel; sometimes
> the wrong version gets put in the n32 syscall table.  Special syscall
> wrappers are often needed in glibc; although for most purposes the glibc
> port is a 32-bit one, including having separate functions for 32-bit and
> 64-bit off_t, syscalls tend to need to be called in the 64-bit way (long
> long values as single arguments, in particular).

Would be nice if LFS would be mandatory on the new ABI, thus
off_t being 64bits.

Richard.
Reply | Threaded
Open this post in threaded view
|

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

Jakub Jelinek
On Thu, Dec 30, 2010 at 08:53:32PM +0100, Richard Guenther wrote:
> > Syscalls sometimes need three different versions in the kernel; sometimes
> > the wrong version gets put in the n32 syscall table.  Special syscall
> > wrappers are often needed in glibc; although for most purposes the glibc
> > port is a 32-bit one, including having separate functions for 32-bit and
> > 64-bit off_t, syscalls tend to need to be called in the 64-bit way (long
> > long values as single arguments, in particular).
>
> 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.

        Jakub
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 11:40 AM, H.J. Lu <[hidden email]> wrote:

> On Thu, Dec 30, 2010 at 11:30 AM, Joseph S. Myers
> <[hidden email]> wrote:
>> On Thu, 30 Dec 2010, H.J. Lu wrote:
>>
>>> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
>>> <[hidden email]> wrote:
>>> > On Thu, 30 Dec 2010, H.J. Lu wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> 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?
>>> >
>>> > Do you have a public psABI document?  I think the psABI at the ELF level
>>> > needs to come before the binutils bits, at the function call level needs
>>> > to come before the GCC bits, etc.
>>>
>>> The psABI is the same as x86-64 psABI, except for 32bit ELF instead of
>>> 64bit.
>>
>> I don't think that's an adequate description.  If the "ILP32" name is
>> accurate then it's certainly wrong at the C level since some type sizes
>> are different, with effects in turn on such things as the description of
>> initial stack layout storing argv.  At the ELF level are you saying that
>> each relocation applies to a relocatable field of the same width as for
>> 64-bit (but with the width of the addend being restricted, of course)?  Do
>> any relocations applying to word64 fields need 32-bit variants applying to
>> word32 for the ILP32 ABI?
>
> ILP32 uses small model in x86-64 psABI.
>

Here is the ILP32 psABI:

http://www.kernel.org/pub/linux/devel/binutils/ilp32/


--
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 Richard Biener
On 12/30/2010 11:53 AM, Richard Guenther wrote:
>
> Would be nice if LFS would be mandatory on the new ABI, thus
> off_t being 64bits.
>

Yes, although that's a higher-order thing.

        -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 David Daney-4
On 12/30/2010 11:34 AM, David Daney wrote:
>
> My suggestion:  Since people already spend a great deal of effort
> maintaining the existing i386 compatible Linux syscall infrastructure,
> make your new 32-bit x86-64 Linux syscall ABI identical to the existing
> i386 syscall ABI.  This means that the psABI must use the same size and
> alignment rules for in-memory structures as the i386 does.
>

No, it doesn't.  It just means it need to do so *for the types used by
the kernel*.  The kernel uses types like __u64, which would indeed have
to be declared aligned(4).

        -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

H.J. Lu-30
In reply to this post by H.J. Lu-30
On Thu, Dec 30, 2010 at 12:02 PM, H.J. Lu <[hidden email]> wrote:
>
> Here is the ILP32 psABI:
>
> http://www.kernel.org/pub/linux/devel/binutils/ilp32/
>

I put my x86-64 psABI changes at:

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

Please send me patches to improve the ILP32 psABI.

Thanks.


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

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

David Daney-4
In reply to this post by hpa
On 12/30/2010 12:12 PM, H. Peter Anvin wrote:

> On 12/30/2010 11:34 AM, David Daney wrote:
>>
>> My suggestion:  Since people already spend a great deal of effort
>> maintaining the existing i386 compatible Linux syscall infrastructure,
>> make your new 32-bit x86-64 Linux syscall ABI identical to the existing
>> i386 syscall ABI.  This means that the psABI must use the same size and
>> alignment rules for in-memory structures as the i386 does.
>>
>
> No, it doesn't.  It just means it need to do so *for the types used by
> the kernel*.  The kernel uses types like __u64, which would indeed have
> to be declared aligned(4).
>

Some legacy interfaces don't use fixed width types.  There almost
certainly are some ioctls that don't use your fancy __u64.

Then there are things like ppoll() that take a pointer to:

            struct timespec {
                long    tv_sec;         /* seconds */
                long    tv_nsec;        /* nanoseconds */
            };

There are no fields in there that are controlled by __u64 either.
Admittedly this case might not differ between the two 32-bit ABIs, but
it shows that __u64/__u32 are not universally used in the Linux syscall
ABIs.

If you are happy with potential memory layout differences between the
two 32-bit ABIs, then don't specify that they are the same.  But don't
claim that use of __u64/__u32 covers all cases.

David Daney
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 12:27 PM, David Daney <[hidden email]> wrote:

> On 12/30/2010 12:12 PM, H. Peter Anvin wrote:
>>
>> On 12/30/2010 11:34 AM, David Daney wrote:
>>>
>>> My suggestion:  Since people already spend a great deal of effort
>>> maintaining the existing i386 compatible Linux syscall infrastructure,
>>> make your new 32-bit x86-64 Linux syscall ABI identical to the existing
>>> i386 syscall ABI.  This means that the psABI must use the same size and
>>> alignment rules for in-memory structures as the i386 does.
>>>
>>
>> No, it doesn't.  It just means it need to do so *for the types used by
>> the kernel*.  The kernel uses types like __u64, which would indeed have
>> to be declared aligned(4).
>>
>
> Some legacy interfaces don't use fixed width types.  There almost certainly
> are some ioctls that don't use your fancy __u64.
>
> Then there are things like ppoll() that take a pointer to:
>
>           struct timespec {
>               long    tv_sec;         /* seconds */
>               long    tv_nsec;        /* nanoseconds */
>           };
>
> There are no fields in there that are controlled by __u64 either. Admittedly
> this case might not differ between the two 32-bit ABIs, but it shows that
> __u64/__u32 are not universally used in the Linux syscall ABIs.
>
> If you are happy with potential memory layout differences between the two
> 32-bit ABIs, then don't specify that they are the same.  But don't claim
> that use of __u64/__u32 covers all cases.

We can put a syscall wrapper to translate it.


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

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

Joseph Myers
In reply to this post by Richard Biener
On Thu, 30 Dec 2010, Richard Guenther wrote:

> Would be nice if LFS would be mandatory on the new ABI, thus
> off_t being 64bits.

That's certainly abstractly better (and something BSDs do better than
GNU/Linux).  I expect you'd run into a few complications actually making a
32-bit glibc port like that (lots of the generic 32-bit code will want to
build separate 32-bit and 64-bit versions as functions; maybe it will be
easy to build things with those just ending up as duplicates, but making
them aliases, as they generally are for 64-bit, could be harder).

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

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

David Daney-4
In reply to this post by H.J. Lu-30
On 12/30/2010 12:28 PM, H.J. Lu wrote:

> On Thu, Dec 30, 2010 at 12:27 PM, David Daney<[hidden email]>  wrote:
>> On 12/30/2010 12:12 PM, H. Peter Anvin wrote:
>>>
>>> On 12/30/2010 11:34 AM, David Daney wrote:
>>>>
>>>> My suggestion:  Since people already spend a great deal of effort
>>>> maintaining the existing i386 compatible Linux syscall infrastructure,
>>>> make your new 32-bit x86-64 Linux syscall ABI identical to the existing
>>>> i386 syscall ABI.  This means that the psABI must use the same size and
>>>> alignment rules for in-memory structures as the i386 does.
>>>>
>>>
>>> No, it doesn't.  It just means it need to do so *for the types used by
>>> the kernel*.  The kernel uses types like __u64, which would indeed have
>>> to be declared aligned(4).
>>>
>>
>> Some legacy interfaces don't use fixed width types.  There almost certainly
>> are some ioctls that don't use your fancy __u64.
>>
>> Then there are things like ppoll() that take a pointer to:
>>
>>            struct timespec {
>>                long    tv_sec;         /* seconds */
>>                long    tv_nsec;        /* nanoseconds */
>>            };
>>
>> There are no fields in there that are controlled by __u64 either. Admittedly
>> this case might not differ between the two 32-bit ABIs, but it shows that
>> __u64/__u32 are not universally used in the Linux syscall ABIs.
>>
>> If you are happy with potential memory layout differences between the two
>> 32-bit ABIs, then don't specify that they are the same.  But don't claim
>> that use of __u64/__u32 covers all cases.
>
> We can put a syscall wrapper to translate it.
>

Of course you can.

But you are starting with a blank slate, you should be asking yourself
why you would want to.

What is your objective here?  Is it:

1) Fastest time to a relatively bug free useful system?

or

2) Purity of ABI design?


What would the performance penalty be for identical structure layout
between the two 32-bit ABIs?

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.

David Daney
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 Joseph Myers
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

amd32.diff (10K) Download Attachment
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
I believe it covers all cases *relevant for this particular situation* (unlike, say, MIPS) and that any deviation is a bug which can and should be fixed.

"David Daney" <[hidden email]> wrote:

>On 12/30/2010 12:12 PM, H. Peter Anvin wrote:
>> On 12/30/2010 11:34 AM, David Daney wrote:
>>>
>>> My suggestion:  Since people already spend a great deal of effort
>>> maintaining the existing i386 compatible Linux syscall
>infrastructure,
>>> make your new 32-bit x86-64 Linux syscall ABI identical to the
>existing
>>> i386 syscall ABI.  This means that the psABI must use the same size
>and
>>> alignment rules for in-memory structures as the i386 does.
>>>
>>
>> No, it doesn't.  It just means it need to do so *for the types used
>by
>> the kernel*.  The kernel uses types like __u64, which would indeed
>have
>> to be declared aligned(4).
>>
>
>Some legacy interfaces don't use fixed width types.  There almost
>certainly are some ioctls that don't use your fancy __u64.
>
>Then there are things like ppoll() that take a pointer to:
>
>            struct timespec {
>                long    tv_sec;         /* seconds */
>                long    tv_nsec;        /* nanoseconds */
>            };
>
>There are no fields in there that are controlled by __u64 either.
>Admittedly this case might not differ between the two 32-bit ABIs, but
>it shows that __u64/__u32 are not universally used in the Linux syscall
>
>ABIs.
>
>If you are happy with potential memory layout differences between the
>two 32-bit ABIs, then don't specify that they are the same.  But don't
>claim that use of __u64/__u32 covers all cases.
>
>David Daney

--
Sent from my mobile phone.  Please pardon any lack of formatting.
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
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.
123