RFC: Add 32bit x86-64 support to binutils

RFC: Add 32bit x86-64 support to binutils

[H.J. Lu]

[-- Attachment #1: Type: text/plain, Size: 9865 bytes --]

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  <hongjiu.lu@intel.com>

	* 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  <hongjiu.lu@intel.com>

	* 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  <hongjiu.lu@intel.com>

	* 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  <hongjiu.lu@intel.com>

	* 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  <hongjiu.lu@intel.com>

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


[-- Attachment #2: binutils-ilp32-1.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 76410 bytes --]

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

[Joseph S. 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
joseph@codesourcery.com

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

[H.J. Lu]

On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
<joseph@codesourcery.com> 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.

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

[H. Peter Anvin]

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.

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

[Joseph S. Myers]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3704 bytes --]

On Thu, 30 Dec 2010, H.J. Lu wrote:

> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
> <joseph@codesourcery.com> 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
joseph@codesourcery.com

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

[David Daney]

On 12/30/2010 10:59 AM, H.J. Lu wrote:
> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
> <joseph@codesourcery.com>  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

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

[H.J. Lu]

On Thu, Dec 30, 2010 at 11:30 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Thu, 30 Dec 2010, H.J. Lu wrote:
>
>> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
>> <joseph@codesourcery.com> 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.

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

[Richard Guenther]

On Thu, Dec 30, 2010 at 8:30 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Thu, 30 Dec 2010, H.J. Lu wrote:
>
>> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
>> <joseph@codesourcery.com> 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.

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

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

[H.J. Lu]

On Thu, Dec 30, 2010 at 11:40 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Dec 30, 2010 at 11:30 AM, Joseph S. Myers
> <joseph@codesourcery.com> wrote:
>> On Thu, 30 Dec 2010, H.J. Lu wrote:
>>
>>> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
>>> <joseph@codesourcery.com> 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.

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

[H. Peter Anvin]

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.

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

[H.J. Lu]

On Thu, Dec 30, 2010 at 12:02 PM, H.J. Lu <hjl.tools@gmail.com> 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.

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

[H. Peter Anvin]

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.

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

[David Daney]

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

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

[H.J. Lu]

On Thu, Dec 30, 2010 at 12:27 PM, David Daney <ddaney@caviumnetworks.com> 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.

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

[Joseph S. Myers]

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
joseph@codesourcery.com

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

[David Daney]

On 12/30/2010 12:28 PM, H.J. Lu wrote:
> On Thu, Dec 30, 2010 at 12:27 PM, David Daney<ddaney@caviumnetworks.com>  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

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

[Robert Millan]

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

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

[-- Attachment #2: amd32.diff --]
[-- Type: text/plain, Size: 8088 bytes --]

diff -Nur linux-2.6-2.6.26-libre2.old/arch/x86/kernel/sys_x86_64.c linux-2.6-2.6.26-libre2/arch/x86/kernel/sys_x86_64.c
--- linux-2.6-2.6.26-libre2.old/arch/x86/kernel/sys_x86_64.c	2008-07-13 23:51:29.000000000 +0200
+++ linux-2.6-2.6.26-libre2/arch/x86/kernel/sys_x86_64.c	2009-05-29 22:57:41.000000000 +0200
@@ -48,7 +48,7 @@
 static void find_start_end(unsigned long flags, unsigned long *begin,
 			   unsigned long *end)
 {
-	if (!test_thread_flag(TIF_IA32) && (flags & MAP_32BIT)) {
+	if ((!test_thread_flag(TIF_IA32) && (flags & MAP_32BIT)) || test_thread_flag(TIF_AMD32)) {
 		unsigned long new_begin;
 		/* This is usually used needed to map code in small
 		   model, so it needs to be in the first 31bit. Limit
@@ -94,7 +94,7 @@
 		    (!vma || addr + len <= vma->vm_start))
 			return addr;
 	}
-	if (((flags & MAP_32BIT) || test_thread_flag(TIF_IA32))
+	if (((flags & MAP_32BIT) || test_thread_flag(TIF_IA32) || test_thread_flag(TIF_AMD32))
 	    && len <= mm->cached_hole_size) {
 	        mm->cached_hole_size = 0;
 		mm->free_area_cache = begin;
@@ -150,8 +150,8 @@
 	if (flags & MAP_FIXED)
 		return addr;
 
-	/* for MAP_32BIT mappings we force the legact mmap base */
-	if (!test_thread_flag(TIF_IA32) && (flags & MAP_32BIT))
+	/* for MAP_32BIT mappings we force the legacy mmap base */
+	if ((!test_thread_flag(TIF_IA32) && (flags & MAP_32BIT)) || test_thread_flag(TIF_AMD32))
 		goto bottomup;
 
 	/* requesting a specific address */
@@ -232,5 +232,7 @@
 	up_read(&uts_sem);
 	if (personality(current->personality) == PER_LINUX32) 
 		err |= copy_to_user(&name->machine, "i686", 5); 		
+	else if (test_thread_flag(TIF_AMD32))
+		err |= copy_to_user(&name->machine, "amd32", 6);
 	return err ? -EFAULT : 0;
 }
diff -Nur linux-2.6-2.6.26-libre2.old/arch/x86/mm/mmap.c linux-2.6-2.6.26-libre2/arch/x86/mm/mmap.c
--- linux-2.6-2.6.26-libre2.old/arch/x86/mm/mmap.c	2008-07-13 23:51:29.000000000 +0200
+++ linux-2.6-2.6.26-libre2/arch/x86/mm/mmap.c	2009-05-26 14:30:53.000000000 +0200
@@ -53,6 +53,15 @@
 	return 0;
 }
 
+static int mmap_is_32bit(void)
+{
+	if (mmap_is_ia32 ())
+		return 1;
+	if (test_thread_flag(TIF_AMD32))
+		return 1;
+	return 0;
+}
+
 static int mmap_is_legacy(void)
 {
 	if (current->personality & ADDR_COMPAT_LAYOUT)
@@ -73,7 +82,7 @@
 	* 28 bits of randomness in 64bit mmaps, 40 address space bits
 	*/
 	if (current->flags & PF_RANDOMIZE) {
-		if (mmap_is_ia32())
+		if (mmap_is_32bit())
 			rnd = (long)get_random_int() % (1<<8);
 		else
 			rnd = (long)(get_random_int() % (1<<28));
diff -Nur linux-2.6-2.6.26-libre2.old/fs/binfmt_elf_amd32.c linux-2.6-2.6.26-libre2/fs/binfmt_elf_amd32.c
--- linux-2.6-2.6.26-libre2.old/fs/binfmt_elf_amd32.c	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6-2.6.26-libre2/fs/binfmt_elf_amd32.c	2009-05-26 14:26:24.000000000 +0200
@@ -0,0 +1,46 @@
+/*
+ *  Support for loading AMD32 binaries
+ *  Copyright (C) 2009  Robert Millan
+ *
+ *  This program is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/elfcore-compat.h>
+
+#undef	ELF_CLASS
+#define	ELF_CLASS	ELFCLASS32
+
+#undef	elfhdr
+#define elfhdr		elf32_hdr
+#undef	elf_phdr
+#define elf_phdr	elf32_phdr
+#undef	elf_note
+#define elf_note	elf32_note
+#undef	elf_addr_t
+#define elf_addr_t	Elf32_Addr
+
+#undef	ELF_PLATFORM
+#define	ELF_PLATFORM	("amd32")
+
+#undef	elf_check_arch
+#define	elf_check_arch(x)	((x)->e_machine == EM_X86_64 && (x)->e_ident[EI_CLASS] == ELFCLASS32)
+
+#undef	SET_PERSONALITY
+#define SET_PERSONALITY(ex, ibcs2)	do { set_personality_64bit(); set_thread_flag(TIF_AMD32); current->personality |= force_personality32; } while (0)
+
+/* Use the generic 32-bit definition from asm/elf.h */
+#undef	ELF_ET_DYN_BASE
+#define	ELF_ET_DYN_BASE		COMPAT_ELF_ET_DYN_BASE
+
+#include "binfmt_elf.c"
diff -Nur linux-2.6-2.6.26-libre2.old/fs/Kconfig.binfmt linux-2.6-2.6.26-libre2/fs/Kconfig.binfmt
--- linux-2.6-2.6.26-libre2.old/fs/Kconfig.binfmt	2008-07-13 23:51:29.000000000 +0200
+++ linux-2.6-2.6.26-libre2/fs/Kconfig.binfmt	2009-05-25 00:26:10.000000000 +0200
@@ -23,6 +23,13 @@
 	  ld.so (check the file <file:Documentation/Changes> for location and
 	  latest version).
 
+config BINFMT_ELF_AMD32
+	bool "Kernel support for AMD32 binaries"
+	depends on X86_64
+	default y
+	help
+	  Support for ELF32 binaries on AMD x86-64.
+
 config COMPAT_BINFMT_ELF
 	bool
 	depends on COMPAT && MMU
diff -Nur linux-2.6-2.6.26-libre2.old/fs/Makefile linux-2.6-2.6.26-libre2/fs/Makefile
--- linux-2.6-2.6.26-libre2.old/fs/Makefile	2008-07-13 23:51:29.000000000 +0200
+++ linux-2.6-2.6.26-libre2/fs/Makefile	2009-05-25 00:24:37.000000000 +0200
@@ -39,6 +39,7 @@
 obj-y				+= binfmt_script.o
 
 obj-$(CONFIG_BINFMT_ELF)	+= binfmt_elf.o
+obj-$(CONFIG_BINFMT_ELF_AMD32)	+= binfmt_elf_amd32.o
 obj-$(CONFIG_COMPAT_BINFMT_ELF)	+= compat_binfmt_elf.o
 obj-$(CONFIG_BINFMT_ELF_FDPIC)	+= binfmt_elf_fdpic.o
 obj-$(CONFIG_BINFMT_SOM)	+= binfmt_som.o
diff -Nur linux-2.6-2.6.26-libre2.old/include/asm-x86/elf.h linux-2.6-2.6.26-libre2/include/asm-x86/elf.h
--- linux-2.6-2.6.26-libre2.old/include/asm-x86/elf.h	2008-07-13 23:51:29.000000000 +0200
+++ linux-2.6-2.6.26-libre2/include/asm-x86/elf.h	2009-05-26 14:03:51.000000000 +0200
@@ -298,7 +298,7 @@
 #define VDSO_HIGH_BASE		0xffffe000U /* CONFIG_COMPAT_VDSO address */
 
 /* 1GB for 64bit, 8MB for 32bit */
-#define STACK_RND_MASK (test_thread_flag(TIF_IA32) ? 0x7ff : 0x3fffff)
+#define STACK_RND_MASK ((test_thread_flag(TIF_IA32) || test_thread_flag(TIF_AMD32)) ? 0x7ff : 0x3fffff)
 
 #define ARCH_DLINFO							\
 do {									\
diff -Nur linux-2.6-2.6.26-libre2.old/include/asm-x86/processor.h linux-2.6-2.6.26-libre2/include/asm-x86/processor.h
--- linux-2.6-2.6.26-libre2.old/include/asm-x86/processor.h	2008-07-13 23:51:29.000000000 +0200
+++ linux-2.6-2.6.26-libre2/include/asm-x86/processor.h	2009-05-26 14:06:49.000000000 +0200
@@ -881,9 +881,9 @@
 #define IA32_PAGE_OFFSET	((current->personality & ADDR_LIMIT_3GB) ? \
 					0xc0000000 : 0xFFFFe000)
 
-#define TASK_SIZE		(test_thread_flag(TIF_IA32) ? \
+#define TASK_SIZE		((test_thread_flag(TIF_IA32) || test_thread_flag(TIF_AMD32)) ? \
 					IA32_PAGE_OFFSET : TASK_SIZE64)
-#define TASK_SIZE_OF(child)	((test_tsk_thread_flag(child, TIF_IA32)) ? \
+#define TASK_SIZE_OF(child)	((test_tsk_thread_flag(child, TIF_IA32) || test_tsk_thread_flag(child, TIF_AMD32)) ? \
 					IA32_PAGE_OFFSET : TASK_SIZE64)
 
 #define STACK_TOP		TASK_SIZE
diff -Nur linux-2.6-2.6.26-libre2.old/include/asm-x86/thread_info_64.h linux-2.6-2.6.26-libre2/include/asm-x86/thread_info_64.h
--- linux-2.6-2.6.26-libre2.old/include/asm-x86/thread_info_64.h	2008-07-13 23:51:29.000000000 +0200
+++ linux-2.6-2.6.26-libre2/include/asm-x86/thread_info_64.h	2009-05-26 14:28:33.000000000 +0200
@@ -111,8 +111,8 @@
 #define TIF_SECCOMP		8	/* secure computing */
 #define TIF_MCE_NOTIFY		10	/* notify userspace of an MCE */
 #define TIF_HRTICK_RESCHED	11	/* reprogram hrtick timer */
-/* 16 free */
-#define TIF_IA32		17	/* 32bit process */
+#define TIF_AMD32		16	/* 32bit AMD process */
+#define TIF_IA32		17	/* 32bit Intel process */
 #define TIF_FORK		18	/* ret_from_fork */
 #define TIF_ABI_PENDING		19
 #define TIF_MEMDIE		20
@@ -134,6 +134,7 @@
 #define _TIF_SECCOMP		(1 << TIF_SECCOMP)
 #define _TIF_MCE_NOTIFY		(1 << TIF_MCE_NOTIFY)
 #define _TIF_HRTICK_RESCHED	(1 << TIF_HRTICK_RESCHED)
+#define _TIF_AMD32		(1 << TIF_AMD32)
 #define _TIF_IA32		(1 << TIF_IA32)
 #define _TIF_FORK		(1 << TIF_FORK)
 #define _TIF_ABI_PENDING	(1 << TIF_ABI_PENDING)

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

[H. Peter Anvin]

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" <ddaney@caviumnetworks.com> 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.

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

[H. Peter Anvin]

We do have a slightly more extensive patch already implemented.

"Robert Millan" <rmh@gnu.org> 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.

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

[H.J. Lu]

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 <hpa@zytor.com> wrote:
> We do have a slightly more extensive patch already implemented.
>
> "Robert Millan" <rmh@gnu.org> 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.

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

[H. Peter Anvin]

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.

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

[H. Peter Anvin]

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.

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

[Robert Millan]

2010/12/30 H.J. Lu <hjl.tools@gmail.com>:
> 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 <hpa@zytor.com> 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

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

[Robert Millan]

2010/12/30 Richard Guenther <richard.guenther@gmail.com>:
> 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

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

[H.J. Lu]

On Thu, Dec 30, 2010 at 2:18 PM, Robert Millan <rmh@gnu.org> wrote:
> 2010/12/30 H.J. Lu <hjl.tools@gmail.com>:
>> 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 <hpa@zytor.com> 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.

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

[H. Peter Anvin]

On 12/30/2010 02:18 PM, Robert Millan wrote:
> 2010/12/30 H.J. Lu <hjl.tools@gmail.com>:
>> 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 <hpa@zytor.com> 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.

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

[H. Peter Anvin]

On 12/30/2010 02:21 PM, Robert Millan wrote:
> 2010/12/30 Richard Guenther <richard.guenther@gmail.com>:
>> 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.

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

[Joseph S. 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 <richard.guenther@gmail.com>:
> >> 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
joseph@codesourcery.com

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

[H.J. Lu]

On Thu, Dec 30, 2010 at 3:00 PM, Joseph S. Myers
<joseph@codesourcery.com> 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 <richard.guenther@gmail.com>:
>> >> 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.

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

[H.J. Lu]

On Thu, Dec 30, 2010 at 4:25 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Dec 30, 2010 at 3:00 PM, Joseph S. Myers
> <joseph@codesourcery.com> 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 <richard.guenther@gmail.com>:
>>> >> 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  <hongjiu.lu@intel.com>

	* 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

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

[H. Peter Anvin]

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

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

[H.J. Lu]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

On Thu, Dec 30, 2010 at 4:42 PM, H. Peter Anvin <hpa@zytor.com> 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.

[-- Attachment #2: linux-2.6.35-ilp32-1.patch --]
[-- Type: text/plain, Size: 14224 bytes --]

diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
index 588a7aa..ae915c8 100644
--- a/arch/x86/ia32/ia32_signal.c
+++ b/arch/x86/ia32/ia32_signal.c
@@ -42,6 +42,14 @@
 
 void signal_fault(struct pt_regs *regs, void __user *frame, char *where);
 
+/* We use the standard 64-bit versions of these for the ILP32 variants */
+int
+restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc,
+		   unsigned long *pax);
+int
+setup_sigcontext(struct sigcontext __user *sc, void __user *fpstate,
+		 struct pt_regs *regs, unsigned long mask);
+
 int copy_siginfo_to_user32(compat_siginfo_t __user *to, siginfo_t *from)
 {
 	int err = 0;
@@ -565,3 +573,118 @@ int ia32_setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
 
 	return 0;
 }
+
+int ia32_setup_ilp32_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
+			   compat_sigset_t *set, struct pt_regs *regs)
+{
+	struct rt_sigframe_ilp32 __user *frame;
+	void __user *restorer;
+	int err = 0;
+	void __user *fpstate = NULL;
+
+	/* __copy_to_user optimizes that into a single 8 byte store */
+	static const struct {
+		u8 movl;
+		u32 val;
+		u16 int80;
+		u8  pad;
+	} __attribute__((packed)) code = {
+		0xb8,
+		__NR_ia32_ilp32_sigreturn,
+		0x80cd,
+		0,
+	};
+
+	frame = get_sigframe(ka, regs, sizeof(*frame), &fpstate);
+
+	if (!access_ok(VERIFY_WRITE, frame, sizeof(*frame)))
+		return -EFAULT;
+
+	put_user_try {
+		put_user_ex(sig, &frame->sig);
+		put_user_ex(ptr_to_compat(&frame->info), &frame->pinfo);
+		put_user_ex(ptr_to_compat(&frame->uc), &frame->puc);
+		err |= copy_siginfo_to_user32(&frame->info, info);
+
+		/* Create the ucontext.  */
+		if (cpu_has_xsave)
+			put_user_ex(UC_FP_XSTATE, &frame->uc.uc_flags);
+		else
+			put_user_ex(0, &frame->uc.uc_flags);
+		put_user_ex(0, &frame->uc.uc_link);
+		put_user_ex(current->sas_ss_sp, &frame->uc.uc_stack.ss_sp);
+		put_user_ex(sas_ss_flags(regs->sp),
+			    &frame->uc.uc_stack.ss_flags);
+		put_user_ex(current->sas_ss_size, &frame->uc.uc_stack.ss_size);
+		err |= setup_sigcontext(&frame->uc.uc_mcontext, fpstate,
+					regs, set->sig[0]);
+		err |= __copy_to_user(&frame->uc.uc_sigmask, set, sizeof(*set));
+
+		if (ka->sa.sa_flags & SA_RESTORER)
+			restorer = ka->sa.sa_restorer;
+		else
+			restorer = VDSO32_SYMBOL(current->mm->context.vdso,
+						 rt_sigreturn);
+		put_user_ex(ptr_to_compat(restorer), &frame->pretcode);
+
+		/*
+		 * Not actually used anymore, but left because some gdb
+		 * versions need it.
+		 */
+		put_user_ex(*((u64 *)&code), (u64 *)frame->retcode);
+	} put_user_catch(err);
+
+	if (err)
+		return -EFAULT;
+
+	/* Set up registers for signal handler */
+	regs->sp = (unsigned long) frame;
+	regs->ip = (unsigned long) ka->sa.sa_handler;
+
+	/* We use the 64-bit ILP32 calling convention here... */
+	regs->di = sig;
+	regs->si = (unsigned long) &frame->info;
+	regs->dx = (unsigned long) &frame->uc;
+
+	loadsegment(ds, __USER_DS);
+	loadsegment(es, __USER_DS);
+
+	regs->cs = __USER_CS;
+	regs->ss = __USER_DS;
+
+	return 0;
+}
+
+asmlinkage long sys32_ilp32_sigreturn(struct pt_regs *regs)
+{
+	struct rt_sigframe_ilp32 __user *frame;
+	sigset_t set;
+	unsigned long ax;
+	struct pt_regs tregs;
+
+	frame = (struct rt_sigframe_ilp32 __user *)(regs->sp - 4);
+
+	if (!access_ok(VERIFY_READ, frame, sizeof(*frame)))
+		goto badframe;
+	if (__copy_from_user(&set, &frame->uc.uc_sigmask, sizeof(set)))
+		goto badframe;
+
+	sigdelsetmask(&set, ~_BLOCKABLE);
+	spin_lock_irq(&current->sighand->siglock);
+	current->blocked = set;
+	recalc_sigpending();
+	spin_unlock_irq(&current->sighand->siglock);
+
+	if (restore_sigcontext(regs, &frame->uc.uc_mcontext, &ax))
+		goto badframe;
+
+	tregs = *regs;
+	if (sys32_sigaltstack(&frame->uc.uc_stack, NULL, &tregs) == -EFAULT)
+		goto badframe;
+
+	return ax;
+
+badframe:
+	signal_fault(regs, frame, "64bit ilp32 sigreturn");
+	return 0;
+}
diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index 4f5f71e..51f9951 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -475,6 +475,7 @@ quiet_ni_syscall:
 
 	CFI_STARTPROC32
 
+	PTREGSCALL stub32_ilp32_sigreturn, sys32_ilp32_sigreturn, %rdi
 	PTREGSCALL stub32_rt_sigreturn, sys32_rt_sigreturn, %rdi
 	PTREGSCALL stub32_sigreturn, sys32_sigreturn, %rdi
 	PTREGSCALL stub32_sigaltstack, sys32_sigaltstack, %rdx
@@ -761,7 +762,7 @@ ia32_sys_call_table:
 	.quad compat_sys_io_submit
 	.quad sys_io_cancel
 	.quad sys32_fadvise64		/* 250 */
-	.quad quiet_ni_syscall 	/* free_huge_pages */
+	.quad stub32_ilp32_sigreturn
 	.quad sys_exit_group
 	.quad sys32_lookup_dcookie
 	.quad sys_epoll_create
diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index f2ad216..7393347 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -5,6 +5,8 @@
  * ELF register definitions..
  */
 
+#include <linux/thread_info.h>
+
 #include <asm/ptrace.h>
 #include <asm/user.h>
 #include <asm/auxvec.h>
@@ -155,7 +157,12 @@ do {						\
 #define elf_check_arch(x)			\
 	((x)->e_machine == EM_X86_64)
 
-#define compat_elf_check_arch(x)	elf_check_arch_ia32(x)
+#define compat_elf_check_arch(x)		\
+	(elf_check_arch_ia32(x) || (x)->e_machine == EM_X86_64)
+
+#if __USER32_DS != __USER_DS
+# error "The following code assumes __USER32_DS == __USER_DS"
+#endif
 
 static inline void elf_common_init(struct thread_struct *t,
 				   struct pt_regs *regs, const u16 ds)
@@ -178,8 +185,9 @@ static inline void elf_common_init(struct thread_struct *t,
 void start_thread_ia32(struct pt_regs *regs, u32 new_ip, u32 new_sp);
 #define compat_start_thread start_thread_ia32
 
-void set_personality_ia32(void);
-#define COMPAT_SET_PERSONALITY(ex) set_personality_ia32()
+void set_personality_ia32(bool);
+#define COMPAT_SET_PERSONALITY(ex)			\
+	set_personality_ia32((ex).e_machine == EM_X86_64)
 
 #define COMPAT_ELF_PLATFORM			("i686")
 
@@ -277,7 +285,9 @@ do {									\
 
 #define VDSO_HIGH_BASE		(__fix_to_virt(FIX_VDSO))
 
-#define ARCH_DLINFO		ARCH_DLINFO_IA32(vdso_enabled)
+#define ARCH_DLINFO							\
+if (!test_thread_flag(TIF_64BIT_ILP32))					\
+	ARCH_DLINFO_IA32(vdso_enabled)
 
 /* update AT_VECTOR_SIZE_ARCH if the number of NEW_AUX_ENT entries changes */
 
diff --git a/arch/x86/include/asm/ia32.h b/arch/x86/include/asm/ia32.h
index 1f7e625..e19de80 100644
--- a/arch/x86/include/asm/ia32.h
+++ b/arch/x86/include/asm/ia32.h
@@ -43,6 +43,14 @@ struct ucontext_ia32 {
 	compat_sigset_t	  uc_sigmask;	/* mask last for extensibility */
 };
 
+struct ucontext_ilp32 {
+	unsigned int	  uc_flags;
+	unsigned int 	  uc_link;
+	stack_ia32_t	  uc_stack;
+	struct sigcontext uc_mcontext;  /* the 64-bit sigcontext type */
+	compat_sigset_t	  uc_sigmask;	/* mask last for extensibility */
+};
+
 /* This matches struct stat64 in glibc2.2, hence the absolutely
  * insane amounts of padding around dev_t's.
  */
diff --git a/arch/x86/include/asm/ia32_unistd.h b/arch/x86/include/asm/ia32_unistd.h
index 976f6ec..cc11c64 100644
--- a/arch/x86/include/asm/ia32_unistd.h
+++ b/arch/x86/include/asm/ia32_unistd.h
@@ -8,11 +8,12 @@
  * the number. This should be otherwise in sync with asm-x86/unistd_32.h. -AK
  */
 
-#define __NR_ia32_restart_syscall 0
-#define __NR_ia32_exit		  1
-#define __NR_ia32_read		  3
-#define __NR_ia32_write		  4
-#define __NR_ia32_sigreturn	119
-#define __NR_ia32_rt_sigreturn	173
+#define __NR_ia32_restart_syscall	  0
+#define __NR_ia32_exit			  1
+#define __NR_ia32_read			  3
+#define __NR_ia32_write			  4
+#define __NR_ia32_sigreturn		119
+#define __NR_ia32_rt_sigreturn		173
+#define __NR_ia32_ilp32_sigreturn	251
 
 #endif /* _ASM_X86_IA32_UNISTD_H */
diff --git a/arch/x86/include/asm/sigframe.h b/arch/x86/include/asm/sigframe.h
index 4e0fe26..1e31107 100644
--- a/arch/x86/include/asm/sigframe.h
+++ b/arch/x86/include/asm/sigframe.h
@@ -59,6 +59,21 @@ struct rt_sigframe_ia32 {
 #endif /* defined(CONFIG_X86_32) || defined(CONFIG_IA32_EMULATION) */
 
 #ifdef CONFIG_X86_64
+
+#ifdef CONFIG_IA32_EMULATION
+struct rt_sigframe_ilp32 {
+	u32 pretcode;
+	int sig;
+	u32 pinfo;
+	u32 puc;
+	compat_siginfo_t info;
+	struct ucontext_ilp32 uc;
+	char retcode[8];
+	/* fp state follows here */
+};
+
+#endif /* CONFIG_IA32_EMULATION */
+
 struct rt_sigframe {
 	char __user *pretcode;
 	struct ucontext uc;
diff --git a/arch/x86/include/asm/signal.h b/arch/x86/include/asm/signal.h
index 598457c..4922358 100644
--- a/arch/x86/include/asm/signal.h
+++ b/arch/x86/include/asm/signal.h
@@ -94,6 +94,10 @@ typedef unsigned long sigset_t;
  *
  * SA_ONESHOT and SA_NOMASK are the historical Linux names for the Single
  * Unix names RESETHAND and NODEFER respectively.
+ *
+ * SA_GPR64 dumps the entire 64-bit GPR register set.  This flag is only
+ * applicable to the 32-bit system calls when running on a 64-bit kernel,
+ * and only when SA_SIGINFO is specified.
  */
 #define SA_NOCLDSTOP	0x00000001u
 #define SA_NOCLDWAIT	0x00000002u
@@ -107,6 +111,7 @@ typedef unsigned long sigset_t;
 #define SA_ONESHOT	SA_RESETHAND
 
 #define SA_RESTORER	0x04000000
+#define SA_GPR64	0x02000000
 
 /*
  * sigaltstack controls
diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
index f0b6e5d..7cf9feb 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -95,6 +95,7 @@ struct thread_info {
 #define TIF_BLOCKSTEP		25	/* set when we want DEBUGCTLMSR_BTF */
 #define TIF_LAZY_MMU_UPDATES	27	/* task is updating the mmu lazily */
 #define TIF_SYSCALL_TRACEPOINT	28	/* syscall tracepoint instrumentation */
+#define TIF_64BIT_ILP32		29	/* 32-bit native x86-64 binary */
 
 #define _TIF_SYSCALL_TRACE	(1 << TIF_SYSCALL_TRACE)
 #define _TIF_NOTIFY_RESUME	(1 << TIF_NOTIFY_RESUME)
@@ -117,6 +118,7 @@ struct thread_info {
 #define _TIF_BLOCKSTEP		(1 << TIF_BLOCKSTEP)
 #define _TIF_LAZY_MMU_UPDATES	(1 << TIF_LAZY_MMU_UPDATES)
 #define _TIF_SYSCALL_TRACEPOINT	(1 << TIF_SYSCALL_TRACEPOINT)
+#define _TIF_64BIT_ILP32	(1 << TIF_64BIT_ILP32)
 
 /* work to do in syscall_trace_enter() */
 #define _TIF_WORK_SYSCALL_ENTRY	\
diff --git a/arch/x86/include/asm/unistd_32.h b/arch/x86/include/asm/unistd_32.h
index beb9b5f..ac96d72 100644
--- a/arch/x86/include/asm/unistd_32.h
+++ b/arch/x86/include/asm/unistd_32.h
@@ -256,7 +256,7 @@
 #define __NR_io_submit		248
 #define __NR_io_cancel		249
 #define __NR_fadvise64		250
-/* 251 is available for reuse (was briefly sys_set_zone_reclaim) */
+#define __NR_ilp32_sigreturn	251
 #define __NR_exit_group		252
 #define __NR_lookup_dcookie	253
 #define __NR_epoll_create	254
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 3c2422a..239ce5a 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -355,7 +355,9 @@ start_thread(struct pt_regs *regs, unsigned long new_ip, unsigned long new_sp)
 void start_thread_ia32(struct pt_regs *regs, u32 new_ip, u32 new_sp)
 {
 	start_thread_common(regs, new_ip, new_sp,
-			    __USER32_CS, __USER32_DS, __USER32_DS);
+			    test_thread_flag(TIF_64BIT_ILP32)
+			    ? __USER_CS : __USER32_CS,
+			    __USER_DS, __USER_DS);
 }
 #endif
 
@@ -507,12 +509,16 @@ void set_personality_64bit(void)
 	current->personality &= ~READ_IMPLIES_EXEC;
 }
 
-void set_personality_ia32(void)
+void set_personality_ia32(bool ilp32)
 {
 	/* inherit personality from parent */
 
 	/* Make sure to be in 32bit mode */
 	set_thread_flag(TIF_IA32);
+	if (ilp32)
+		set_thread_flag(TIF_64BIT_ILP32);
+	else
+		clear_thread_flag(TIF_64BIT_ILP32);
 	current->personality |= force_personality32;
 
 	/* Prepare the first "return" to user space */
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 70c4872..c20f6d1 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1294,7 +1294,8 @@ void update_regset_xstate_info(unsigned int size, u64 xstate_mask)
 const struct user_regset_view *task_user_regset_view(struct task_struct *task)
 {
 #ifdef CONFIG_IA32_EMULATION
-	if (test_tsk_thread_flag(task, TIF_IA32))
+	if (test_tsk_thread_flag(task, TIF_IA32) &&
+	    !test_tsk_thread_flag(task, TIF_64BIT_ILP32))
 #endif
 #if defined CONFIG_X86_32 || defined CONFIG_IA32_EMULATION
 		return &user_x86_32_view;
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index 4fd173c..6512444 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -68,7 +68,7 @@
 	regs->seg = GET_SEG(seg) | 3;			\
 } while (0)
 
-static int
+int
 restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc,
 		   unsigned long *pax)
 {
@@ -125,7 +125,7 @@ restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc,
 	return err;
 }
 
-static int
+int
 setup_sigcontext(struct sigcontext __user *sc, void __user *fpstate,
 		 struct pt_regs *regs, unsigned long mask)
 {
@@ -647,10 +647,12 @@ static int signr_convert(int sig)
 #define is_ia32	0
 #endif /* CONFIG_IA32_EMULATION */
 
+int ia32_setup_ilp32_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
+			   sigset_t *set, struct pt_regs *regs);
 int ia32_setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
-		sigset_t *set, struct pt_regs *regs);
+			sigset_t *set, struct pt_regs *regs);
 int ia32_setup_frame(int sig, struct k_sigaction *ka,
-		sigset_t *set, struct pt_regs *regs);
+		     sigset_t *set, struct pt_regs *regs);
 
 #endif /* CONFIG_X86_32 */
 
@@ -664,7 +666,14 @@ setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
 	/* Set up the stack frame */
 	if (is_ia32) {
 		if (ka->sa.sa_flags & SA_SIGINFO)
-			ret = ia32_setup_rt_frame(usig, ka, info, set, regs);
+#ifdef CONFIG_X86_64
+			if (ka->sa.sa_flags & SA_GPR64)
+				ret = ia32_setup_ilp32_frame(usig, ka, info,
+							     set, regs);
+			else
+#endif
+				ret = ia32_setup_rt_frame(usig, ka, info,
+							  set, regs);
 		else
 			ret = ia32_setup_frame(usig, ka, set, regs);
 	} else
diff --git a/scripts/checksyscalls.sh b/scripts/checksyscalls.sh
index 66ad375..9a96111 100755
--- a/scripts/checksyscalls.sh
+++ b/scripts/checksyscalls.sh
@@ -145,6 +145,7 @@ cat << EOF
 #define __IGNORE_sysfs
 #define __IGNORE_uselib
 #define __IGNORE__sysctl
+#define __IGNORE_ilp32_sigreturn
 
 /* ... including the "new" 32-bit uid syscalls */
 #define __IGNORE_lchown32

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

[Hans-Peter Nilsson]

> Date: Thu, 30 Dec 2010 10:23:08 -0800
> From: "H.J. Lu" <hongjiu.lu@intel.com>

> 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

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 <hp@axis.com>

> 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

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

[H.J. Lu]

On Thu, Dec 30, 2010 at 5:16 PM, Hans-Peter Nilsson
<hans-peter.nilsson@axis.com> wrote:
>> Date: Fri, 31 Dec 2010 02:11:15 +0100
>> From: Hans-Peter Nilsson <hp@axis.com>
>
>> 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  <hongjiu.lu@intel.com>

+	* 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  <hongjiu.lu@intel.com>
+
 	* 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);
-}

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

[Jakub Jelinek]

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

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

[H.J. Lu]

On Fri, Dec 31, 2010 at 2:03 AM, Jakub Jelinek <jakub@redhat.com> 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.

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

[H.J. Lu]

On Thu, Dec 30, 2010 at 4:48 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Dec 30, 2010 at 4:42 PM, H. Peter Anvin <hpa@zytor.com> 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.

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

[H.J. Lu]

On Fri, Dec 31, 2010 at 2:03 AM, Jakub Jelinek <jakub@redhat.com> 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.

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

[H.J. Lu]

On Fri, Dec 31, 2010 at 8:50 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Dec 31, 2010 at 2:03 AM, Jakub Jelinek <jakub@redhat.com> 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.

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

[H. Peter Anvin]

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.

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

[Jan Beulich]

>>> On 30.12.10 at 21:02, "H.J. Lu" <hjl.tools@gmail.com> 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

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

[H.J. Lu]

On Mon, Jan 3, 2011 at 2:40 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>> On 30.12.10 at 21:02, "H.J. Lu" <hjl.tools@gmail.com> 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.

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

[H. Peter Anvin]

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

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

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

[Jan Beulich]

>>> On 04.01.11 at 21:02, Jakub Jelinek <jakub@redhat.com> 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

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

[H. Peter Anvin]

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

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

[Jan Beulich]

>>> On 05.01.11 at 09:01, "H. Peter Anvin" <hpa@zytor.com> 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

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

[Jonathan Wakely]

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.

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

[H.J. Lu]

On Wed, Jan 5, 2011 at 11:52 AM, Jonathan Wakely <jwakely.gcc@gmail.com> 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  <jwakely.gcc@gmail.com>
+
+	* doc/c-i386.texi: Clarify --n32.
+
 2011-01-04  H.J. Lu  <hongjiu.lu@intel.com>

 	* 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

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

[H.J. Lu]

On Fri, Dec 31, 2010 at 6:50 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Dec 30, 2010 at 4:48 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Thu, Dec 30, 2010 at 4:42 PM, H. Peter Anvin <hpa@zytor.com> 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.

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

[H.J. Lu]

On Fri, Jan 14, 2011 at 3:46 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Dec 31, 2010 at 6:50 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Thu, Dec 30, 2010 at 4:48 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Thu, Dec 30, 2010 at 4:42 PM, H. Peter Anvin <hpa@zytor.com> 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.