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

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.