* RFC: Add 32bit x86-64 support to binutils @ 2010-12-30 18:42 H.J. Lu 2010-12-30 18:59 ` Joseph S. Myers ` (2 more replies) 0 siblings, 3 replies; 53+ messages in thread From: H.J. Lu @ 2010-12-30 18:42 UTC (permalink / raw) To: binutils; +Cc: gcc [-- 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 --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 18:42 RFC: Add 32bit x86-64 support to binutils H.J. Lu @ 2010-12-30 18:59 ` Joseph S. Myers 2010-12-30 19:04 ` H.J. Lu 2010-12-31 1:16 ` Hans-Peter Nilsson 2011-01-05 19:52 ` Jonathan Wakely 2 siblings, 1 reply; 53+ messages in thread From: Joseph S. Myers @ 2010-12-30 18:59 UTC (permalink / raw) To: H.J. Lu; +Cc: binutils, gcc 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 18:59 ` Joseph S. Myers @ 2010-12-30 19:04 ` H.J. Lu 2010-12-30 19:31 ` H. Peter Anvin ` (2 more replies) 0 siblings, 3 replies; 53+ messages in thread From: H.J. Lu @ 2010-12-30 19:04 UTC (permalink / raw) To: Joseph S. Myers; +Cc: binutils, gcc, H. Peter Anvin 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 19:04 ` H.J. Lu @ 2010-12-30 19:31 ` H. Peter Anvin 2010-12-30 19:34 ` Joseph S. Myers 2010-12-30 19:40 ` David Daney 2 siblings, 0 replies; 53+ messages in thread From: H. Peter Anvin @ 2010-12-30 19:31 UTC (permalink / raw) To: H.J. Lu; +Cc: Joseph S. Myers, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 19:04 ` H.J. Lu 2010-12-30 19:31 ` H. Peter Anvin @ 2010-12-30 19:34 ` Joseph S. Myers 2010-12-30 19:53 ` H.J. Lu ` (2 more replies) 2010-12-30 19:40 ` David Daney 2 siblings, 3 replies; 53+ messages in thread From: Joseph S. Myers @ 2010-12-30 19:34 UTC (permalink / raw) To: H.J. Lu; +Cc: binutils, gcc, H. Peter Anvin [-- 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 19:34 ` Joseph S. Myers @ 2010-12-30 19:53 ` H.J. Lu 2010-12-30 20:12 ` H.J. Lu 2010-12-30 19:58 ` Richard Guenther 2010-12-30 21:17 ` Robert Millan 2 siblings, 1 reply; 53+ messages in thread From: H.J. Lu @ 2010-12-30 19:53 UTC (permalink / raw) To: Joseph S. Myers; +Cc: binutils, gcc, H. Peter Anvin 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 19:53 ` H.J. Lu @ 2010-12-30 20:12 ` H.J. Lu 2010-12-30 20:27 ` H.J. Lu 2011-01-03 10:41 ` Jan Beulich 0 siblings, 2 replies; 53+ messages in thread From: H.J. Lu @ 2010-12-30 20:12 UTC (permalink / raw) To: Joseph S. Myers; +Cc: binutils, gcc, H. Peter Anvin 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 20:12 ` H.J. Lu @ 2010-12-30 20:27 ` H.J. Lu 2011-01-03 10:41 ` Jan Beulich 1 sibling, 0 replies; 53+ messages in thread From: H.J. Lu @ 2010-12-30 20:27 UTC (permalink / raw) To: Joseph S. Myers; +Cc: binutils, gcc, H. Peter Anvin 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 20:12 ` H.J. Lu 2010-12-30 20:27 ` H.J. Lu @ 2011-01-03 10:41 ` Jan Beulich 2011-01-04 17:57 ` H.J. Lu 1 sibling, 1 reply; 53+ messages in thread From: Jan Beulich @ 2011-01-03 10:41 UTC (permalink / raw) To: H.J. Lu; +Cc: Joseph S. Myers, gcc, binutils, H. Peter Anvin >>> 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2011-01-03 10:41 ` Jan Beulich @ 2011-01-04 17:57 ` H.J. Lu 2011-01-04 18:35 ` H. Peter Anvin 0 siblings, 1 reply; 53+ messages in thread From: H.J. Lu @ 2011-01-04 17:57 UTC (permalink / raw) To: Jan Beulich; +Cc: Joseph S. Myers, gcc, binutils, H. Peter Anvin 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2011-01-04 17:57 ` H.J. Lu @ 2011-01-04 18:35 ` H. Peter Anvin 2011-01-04 20:03 ` Jakub Jelinek 0 siblings, 1 reply; 53+ messages in thread From: H. Peter Anvin @ 2011-01-04 18:35 UTC (permalink / raw) To: H.J. Lu; +Cc: Jan Beulich, Joseph S. Myers, gcc, binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2011-01-04 18:35 ` H. Peter Anvin @ 2011-01-04 20:03 ` Jakub Jelinek 2011-01-05 7:46 ` Jan Beulich 0 siblings, 1 reply; 53+ messages in thread From: Jakub Jelinek @ 2011-01-04 20:03 UTC (permalink / raw) To: H. Peter Anvin; +Cc: H.J. Lu, Jan Beulich, Joseph S. Myers, gcc, binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2011-01-04 20:03 ` Jakub Jelinek @ 2011-01-05 7:46 ` Jan Beulich 2011-01-05 8:01 ` H. Peter Anvin 0 siblings, 1 reply; 53+ messages in thread From: Jan Beulich @ 2011-01-05 7:46 UTC (permalink / raw) To: Jakub Jelinek, H. Peter Anvin; +Cc: Joseph S. Myers, gcc, H.J. Lu, binutils >>> 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2011-01-05 7:46 ` Jan Beulich @ 2011-01-05 8:01 ` H. Peter Anvin 2011-01-05 8:20 ` Jan Beulich 0 siblings, 1 reply; 53+ messages in thread From: H. Peter Anvin @ 2011-01-05 8:01 UTC (permalink / raw) To: Jan Beulich; +Cc: Jakub Jelinek, Joseph S. Myers, gcc, H.J. Lu, binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2011-01-05 8:01 ` H. Peter Anvin @ 2011-01-05 8:20 ` Jan Beulich 0 siblings, 0 replies; 53+ messages in thread From: Jan Beulich @ 2011-01-05 8:20 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Joseph S. Myers, gcc, H.J. Lu, Jakub Jelinek, binutils >>> 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 19:34 ` Joseph S. Myers 2010-12-30 19:53 ` H.J. Lu @ 2010-12-30 19:58 ` Richard Guenther 2010-12-30 20:02 ` Jakub Jelinek ` (3 more replies) 2010-12-30 21:17 ` Robert Millan 2 siblings, 4 replies; 53+ messages in thread From: Richard Guenther @ 2010-12-30 19:58 UTC (permalink / raw) To: Joseph S. Myers; +Cc: H.J. Lu, binutils, gcc, H. Peter Anvin 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 19:58 ` Richard Guenther @ 2010-12-30 20:02 ` Jakub Jelinek 2010-12-30 22:19 ` H. Peter Anvin 2010-12-30 20:13 ` H. Peter Anvin ` (2 subsequent siblings) 3 siblings, 1 reply; 53+ messages in thread From: Jakub Jelinek @ 2010-12-30 20:02 UTC (permalink / raw) To: Richard Guenther; +Cc: Joseph S. Myers, H.J. Lu, binutils, gcc, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 20:02 ` Jakub Jelinek @ 2010-12-30 22:19 ` H. Peter Anvin 2010-12-31 11:01 ` Jakub Jelinek 0 siblings, 1 reply; 53+ messages in thread From: H. Peter Anvin @ 2010-12-30 22:19 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Richard Guenther, Joseph S. Myers, H.J. Lu, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 22:19 ` H. Peter Anvin @ 2010-12-31 11:01 ` Jakub Jelinek 2010-12-31 14:51 ` H.J. Lu ` (2 more replies) 0 siblings, 3 replies; 53+ messages in thread From: Jakub Jelinek @ 2010-12-31 11:01 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Richard Guenther, Joseph S. Myers, H.J. Lu, binutils, gcc 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-31 11:01 ` Jakub Jelinek @ 2010-12-31 14:51 ` H.J. Lu 2010-12-31 17:03 ` H.J. Lu 2010-12-31 22:31 ` H. Peter Anvin 2 siblings, 0 replies; 53+ messages in thread From: H.J. Lu @ 2010-12-31 14:51 UTC (permalink / raw) To: Jakub Jelinek Cc: H. Peter Anvin, Richard Guenther, Joseph S. Myers, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-31 11:01 ` Jakub Jelinek 2010-12-31 14:51 ` H.J. Lu @ 2010-12-31 17:03 ` H.J. Lu 2010-12-31 18:43 ` H.J. Lu 2010-12-31 22:31 ` H. Peter Anvin 2 siblings, 1 reply; 53+ messages in thread From: H.J. Lu @ 2010-12-31 17:03 UTC (permalink / raw) To: Jakub Jelinek Cc: H. Peter Anvin, Richard Guenther, Joseph S. Myers, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-31 17:03 ` H.J. Lu @ 2010-12-31 18:43 ` H.J. Lu 0 siblings, 0 replies; 53+ messages in thread From: H.J. Lu @ 2010-12-31 18:43 UTC (permalink / raw) To: Jakub Jelinek, discuss Cc: H. Peter Anvin, Richard Guenther, Joseph S. Myers, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-31 11:01 ` Jakub Jelinek 2010-12-31 14:51 ` H.J. Lu 2010-12-31 17:03 ` H.J. Lu @ 2010-12-31 22:31 ` H. Peter Anvin 2 siblings, 0 replies; 53+ messages in thread From: H. Peter Anvin @ 2010-12-31 22:31 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Richard Guenther, Joseph S. Myers, H.J. Lu, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 19:58 ` Richard Guenther 2010-12-30 20:02 ` Jakub Jelinek @ 2010-12-30 20:13 ` H. Peter Anvin 2010-12-30 20:39 ` Joseph S. Myers 2010-12-30 22:23 ` Robert Millan 3 siblings, 0 replies; 53+ messages in thread From: H. Peter Anvin @ 2010-12-30 20:13 UTC (permalink / raw) To: Richard Guenther; +Cc: Joseph S. Myers, H.J. Lu, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 19:58 ` Richard Guenther 2010-12-30 20:02 ` Jakub Jelinek 2010-12-30 20:13 ` H. Peter Anvin @ 2010-12-30 20:39 ` Joseph S. Myers 2010-12-30 22:23 ` Robert Millan 3 siblings, 0 replies; 53+ messages in thread From: Joseph S. Myers @ 2010-12-30 20:39 UTC (permalink / raw) To: Richard Guenther; +Cc: H.J. Lu, binutils, gcc, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 19:58 ` Richard Guenther ` (2 preceding siblings ...) 2010-12-30 20:39 ` Joseph S. Myers @ 2010-12-30 22:23 ` Robert Millan 2010-12-30 23:00 ` H. Peter Anvin 3 siblings, 1 reply; 53+ messages in thread From: Robert Millan @ 2010-12-30 22:23 UTC (permalink / raw) To: Richard Guenther; +Cc: Joseph S. Myers, H.J. Lu, binutils, gcc, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 22:23 ` Robert Millan @ 2010-12-30 23:00 ` H. Peter Anvin 2010-12-31 0:26 ` Joseph S. Myers 0 siblings, 1 reply; 53+ messages in thread From: H. Peter Anvin @ 2010-12-30 23:00 UTC (permalink / raw) To: Robert Millan; +Cc: Richard Guenther, Joseph S. Myers, H.J. Lu, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 23:00 ` H. Peter Anvin @ 2010-12-31 0:26 ` Joseph S. Myers 2010-12-31 0:37 ` H.J. Lu 0 siblings, 1 reply; 53+ messages in thread From: Joseph S. Myers @ 2010-12-31 0:26 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Robert Millan, Richard Guenther, H.J. Lu, binutils, gcc 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-31 0:26 ` Joseph S. Myers @ 2010-12-31 0:37 ` H.J. Lu 2010-12-31 0:42 ` H.J. Lu 0 siblings, 1 reply; 53+ messages in thread From: H.J. Lu @ 2010-12-31 0:37 UTC (permalink / raw) To: Joseph S. Myers Cc: H. Peter Anvin, Robert Millan, Richard Guenther, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-31 0:37 ` H.J. Lu @ 2010-12-31 0:42 ` H.J. Lu 0 siblings, 0 replies; 53+ messages in thread From: H.J. Lu @ 2010-12-31 0:42 UTC (permalink / raw) To: Joseph S. Myers Cc: H. Peter Anvin, Robert Millan, Richard Guenther, binutils, gcc 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 19:34 ` Joseph S. Myers 2010-12-30 19:53 ` H.J. Lu 2010-12-30 19:58 ` Richard Guenther @ 2010-12-30 21:17 ` Robert Millan 2010-12-30 21:33 ` H. Peter Anvin 2010-12-31 0:48 ` H. Peter Anvin 2 siblings, 2 replies; 53+ messages in thread From: Robert Millan @ 2010-12-30 21:17 UTC (permalink / raw) To: Joseph S. Myers; +Cc: H.J. Lu, binutils, gcc, H. Peter Anvin [-- 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) ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 21:17 ` Robert Millan @ 2010-12-30 21:33 ` H. Peter Anvin 2010-12-30 21:41 ` H.J. Lu 2010-12-31 0:48 ` H. Peter Anvin 1 sibling, 1 reply; 53+ messages in thread From: H. Peter Anvin @ 2010-12-30 21:33 UTC (permalink / raw) To: Robert Millan, Joseph S. Myers; +Cc: H.J. Lu, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 21:33 ` H. Peter Anvin @ 2010-12-30 21:41 ` H.J. Lu 2010-12-30 22:21 ` Robert Millan 0 siblings, 1 reply; 53+ messages in thread From: H.J. Lu @ 2010-12-30 21:41 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Robert Millan, Joseph S. Myers, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 21:41 ` H.J. Lu @ 2010-12-30 22:21 ` Robert Millan 2010-12-30 22:26 ` H.J. Lu 2010-12-30 22:27 ` H. Peter Anvin 0 siblings, 2 replies; 53+ messages in thread From: Robert Millan @ 2010-12-30 22:21 UTC (permalink / raw) To: H.J. Lu; +Cc: H. Peter Anvin, Joseph S. Myers, binutils, gcc 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 22:21 ` Robert Millan @ 2010-12-30 22:26 ` H.J. Lu 2010-12-30 22:27 ` H. Peter Anvin 1 sibling, 0 replies; 53+ messages in thread From: H.J. Lu @ 2010-12-30 22:26 UTC (permalink / raw) To: Robert Millan; +Cc: H. Peter Anvin, Joseph S. Myers, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 22:21 ` Robert Millan 2010-12-30 22:26 ` H.J. Lu @ 2010-12-30 22:27 ` H. Peter Anvin 1 sibling, 0 replies; 53+ messages in thread From: H. Peter Anvin @ 2010-12-30 22:27 UTC (permalink / raw) To: Robert Millan; +Cc: H.J. Lu, Joseph S. Myers, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 21:17 ` Robert Millan 2010-12-30 21:33 ` H. Peter Anvin @ 2010-12-31 0:48 ` H. Peter Anvin 2010-12-31 1:11 ` H.J. Lu 1 sibling, 1 reply; 53+ messages in thread From: H. Peter Anvin @ 2010-12-31 0:48 UTC (permalink / raw) To: Robert Millan; +Cc: Joseph S. Myers, H.J. Lu, binutils, gcc 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-31 0:48 ` H. Peter Anvin @ 2010-12-31 1:11 ` H.J. Lu 2010-12-31 15:00 ` H.J. Lu 0 siblings, 1 reply; 53+ messages in thread From: H.J. Lu @ 2010-12-31 1:11 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Robert Millan, Joseph S. Myers, binutils, gcc [-- 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(¤t->sighand->siglock); + current->blocked = set; + recalc_sigpending(); + spin_unlock_irq(¤t->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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-31 1:11 ` H.J. Lu @ 2010-12-31 15:00 ` H.J. Lu 2011-01-14 23:47 ` H.J. Lu 0 siblings, 1 reply; 53+ messages in thread From: H.J. Lu @ 2010-12-31 15:00 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Robert Millan, Joseph S. Myers, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-31 15:00 ` H.J. Lu @ 2011-01-14 23:47 ` H.J. Lu 2011-01-15 21:01 ` H.J. Lu 0 siblings, 1 reply; 53+ messages in thread From: H.J. Lu @ 2011-01-14 23:47 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Robert Millan, Joseph S. Myers, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2011-01-14 23:47 ` H.J. Lu @ 2011-01-15 21:01 ` H.J. Lu 0 siblings, 0 replies; 53+ messages in thread From: H.J. Lu @ 2011-01-15 21:01 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Robert Millan, Joseph S. Myers, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 19:04 ` H.J. Lu 2010-12-30 19:31 ` H. Peter Anvin 2010-12-30 19:34 ` Joseph S. Myers @ 2010-12-30 19:40 ` David Daney 2010-12-30 20:27 ` H. Peter Anvin 2 siblings, 1 reply; 53+ messages in thread From: David Daney @ 2010-12-30 19:40 UTC (permalink / raw) To: H.J. Lu; +Cc: Joseph S. Myers, binutils, gcc, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 19:40 ` David Daney @ 2010-12-30 20:27 ` H. Peter Anvin 2010-12-30 20:29 ` David Daney 0 siblings, 1 reply; 53+ messages in thread From: H. Peter Anvin @ 2010-12-30 20:27 UTC (permalink / raw) To: David Daney; +Cc: H.J. Lu, Joseph S. Myers, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 20:27 ` H. Peter Anvin @ 2010-12-30 20:29 ` David Daney 2010-12-30 20:31 ` H.J. Lu 2010-12-30 21:32 ` H. Peter Anvin 0 siblings, 2 replies; 53+ messages in thread From: David Daney @ 2010-12-30 20:29 UTC (permalink / raw) To: H. Peter Anvin; +Cc: H.J. Lu, Joseph S. Myers, binutils, gcc 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 20:29 ` David Daney @ 2010-12-30 20:31 ` H.J. Lu 2010-12-30 21:08 ` David Daney 2010-12-30 21:32 ` H. Peter Anvin 1 sibling, 1 reply; 53+ messages in thread From: H.J. Lu @ 2010-12-30 20:31 UTC (permalink / raw) To: David Daney; +Cc: H. Peter Anvin, Joseph S. Myers, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 20:31 ` H.J. Lu @ 2010-12-30 21:08 ` David Daney 2010-12-30 21:42 ` H. Peter Anvin 0 siblings, 1 reply; 53+ messages in thread From: David Daney @ 2010-12-30 21:08 UTC (permalink / raw) To: H.J. Lu; +Cc: H. Peter Anvin, Joseph S. Myers, binutils, gcc 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 21:08 ` David Daney @ 2010-12-30 21:42 ` H. Peter Anvin 0 siblings, 0 replies; 53+ messages in thread From: H. Peter Anvin @ 2010-12-30 21:42 UTC (permalink / raw) To: David Daney; +Cc: H.J. Lu, Joseph S. Myers, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 20:29 ` David Daney 2010-12-30 20:31 ` H.J. Lu @ 2010-12-30 21:32 ` H. Peter Anvin 1 sibling, 0 replies; 53+ messages in thread From: H. Peter Anvin @ 2010-12-30 21:32 UTC (permalink / raw) To: David Daney; +Cc: H.J. Lu, Joseph S. Myers, binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 18:42 RFC: Add 32bit x86-64 support to binutils H.J. Lu 2010-12-30 18:59 ` Joseph S. Myers @ 2010-12-31 1:16 ` Hans-Peter Nilsson 2010-12-31 2:44 ` Hans-Peter Nilsson 2011-01-05 19:52 ` Jonathan Wakely 2 siblings, 1 reply; 53+ messages in thread From: Hans-Peter Nilsson @ 2010-12-31 1:16 UTC (permalink / raw) To: hjl.tools; +Cc: binutils > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-31 1:16 ` Hans-Peter Nilsson @ 2010-12-31 2:44 ` Hans-Peter Nilsson 2010-12-31 10:04 ` H.J. Lu 0 siblings, 1 reply; 53+ messages in thread From: Hans-Peter Nilsson @ 2010-12-31 2:44 UTC (permalink / raw) To: hjl.tools; +Cc: binutils > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-31 2:44 ` Hans-Peter Nilsson @ 2010-12-31 10:04 ` H.J. Lu 0 siblings, 0 replies; 53+ messages in thread From: H.J. Lu @ 2010-12-31 10:04 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: binutils 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); -} ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2010-12-30 18:42 RFC: Add 32bit x86-64 support to binutils H.J. Lu 2010-12-30 18:59 ` Joseph S. Myers 2010-12-31 1:16 ` Hans-Peter Nilsson @ 2011-01-05 19:52 ` Jonathan Wakely 2011-01-05 21:36 ` H.J. Lu 2 siblings, 1 reply; 53+ messages in thread From: Jonathan Wakely @ 2011-01-05 19:52 UTC (permalink / raw) To: H.J. Lu; +Cc: binutils, gcc 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Add 32bit x86-64 support to binutils 2011-01-05 19:52 ` Jonathan Wakely @ 2011-01-05 21:36 ` H.J. Lu 0 siblings, 0 replies; 53+ messages in thread From: H.J. Lu @ 2011-01-05 21:36 UTC (permalink / raw) To: Jonathan Wakely; +Cc: binutils, gcc 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
end of thread, other threads:[~2011-01-15 21:01 UTC | newest] Thread overview: 53+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-12-30 18:42 RFC: Add 32bit x86-64 support to binutils H.J. Lu 2010-12-30 18:59 ` Joseph S. Myers 2010-12-30 19:04 ` H.J. Lu 2010-12-30 19:31 ` H. Peter Anvin 2010-12-30 19:34 ` Joseph S. Myers 2010-12-30 19:53 ` H.J. Lu 2010-12-30 20:12 ` H.J. Lu 2010-12-30 20:27 ` H.J. Lu 2011-01-03 10:41 ` Jan Beulich 2011-01-04 17:57 ` H.J. Lu 2011-01-04 18:35 ` H. Peter Anvin 2011-01-04 20:03 ` Jakub Jelinek 2011-01-05 7:46 ` Jan Beulich 2011-01-05 8:01 ` H. Peter Anvin 2011-01-05 8:20 ` Jan Beulich 2010-12-30 19:58 ` Richard Guenther 2010-12-30 20:02 ` Jakub Jelinek 2010-12-30 22:19 ` H. Peter Anvin 2010-12-31 11:01 ` Jakub Jelinek 2010-12-31 14:51 ` H.J. Lu 2010-12-31 17:03 ` H.J. Lu 2010-12-31 18:43 ` H.J. Lu 2010-12-31 22:31 ` H. Peter Anvin 2010-12-30 20:13 ` H. Peter Anvin 2010-12-30 20:39 ` Joseph S. Myers 2010-12-30 22:23 ` Robert Millan 2010-12-30 23:00 ` H. Peter Anvin 2010-12-31 0:26 ` Joseph S. Myers 2010-12-31 0:37 ` H.J. Lu 2010-12-31 0:42 ` H.J. Lu 2010-12-30 21:17 ` Robert Millan 2010-12-30 21:33 ` H. Peter Anvin 2010-12-30 21:41 ` H.J. Lu 2010-12-30 22:21 ` Robert Millan 2010-12-30 22:26 ` H.J. Lu 2010-12-30 22:27 ` H. Peter Anvin 2010-12-31 0:48 ` H. Peter Anvin 2010-12-31 1:11 ` H.J. Lu 2010-12-31 15:00 ` H.J. Lu 2011-01-14 23:47 ` H.J. Lu 2011-01-15 21:01 ` H.J. Lu 2010-12-30 19:40 ` David Daney 2010-12-30 20:27 ` H. Peter Anvin 2010-12-30 20:29 ` David Daney 2010-12-30 20:31 ` H.J. Lu 2010-12-30 21:08 ` David Daney 2010-12-30 21:42 ` H. Peter Anvin 2010-12-30 21:32 ` H. Peter Anvin 2010-12-31 1:16 ` Hans-Peter Nilsson 2010-12-31 2:44 ` Hans-Peter Nilsson 2010-12-31 10:04 ` H.J. Lu 2011-01-05 19:52 ` Jonathan Wakely 2011-01-05 21:36 ` H.J. Lu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).