[Bug tdep/30109] New: [gdb/tdep] Support status of x32 abi

[Bug tdep/30109] New: [gdb/tdep] Support status of x32 abi

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30109

            Bug ID: 30109
           Summary: [gdb/tdep] Support status of x32 abi
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tdep
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

On x86_64, there's the x32 abi, see here ( abi
https://en.wikipedia.org/wiki/X32_ABI ).

Gdb supports the x32 abi, through the "i386:x64-32" architecture.

The most recent related commits I could find are:

commit 0653f01479ecbcbf3c4dfa6083187a5b2c2258c2
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Thu Feb 24 07:34:01 2022 -0800

    gdb: Consolidate 32bit-pkeys.xml and 64bit-pkeys.xml

and:

commit a92d031d7ef6e192fb404a86d53fa834e1e3eb8c
Author: Tom de Vries <tdevries@suse.de>
Date:   Mon Nov 22 12:21:46 2021 +0100

    [gdb/build] Fix x86_64 x32 build

which are both signs of somebody building and testing it.

But I suppose this is not regularly build and tested, at least not by gdb
maintainers (maybe I'm wrong there).

Also, AFAICT the sourceware buildbots don't test it.

Looking at my own main development platform, it's x86_64-linux, with m32
biarch, so I've got the possibility to run tests for target board unix/-m32.

I can't use target board unix/-mx32, because I've got no stdlibs for this
flavour.

So let's try a nostdlib program:
....
$ cat start.c
void
_start (void)
{
}
...

x86_64:
...
$ gcc start.c -nostdlib 
$ gdb -q -batch a.out -ex "b _start" -ex run
Breakpoint 1 at 0x400148

Breakpoint 1, 0x0000000000400148 in _start ()
...

x86_64/-m32:
...
$ gcc start.c -nostdlib -m32
$ gdb -q -batch a.out -ex "b _start" -ex run
Breakpoint 1 at 0x80480db

Breakpoint 1, 0x080480db in _start ()
...

x86_64/-mx32:
...
$ gcc start.c -nostdlib -mx32
$ gdb -q -batch a.out -ex "b _start" -ex run
Breakpoint 1 at 0x4000db
/bin/bash: /home/vries/a.out: cannot execute binary file: Exec format error
/bin/bash: /home/vries/a.out: Success
During startup program exited with code 126.
...

That's not a gdb-specific problem:
...
$ ./a.out 
bash: ./a.out: cannot execute binary file: Exec format error
...

Looking at the wikipedia page, a multilib option is listed for gentoo, so I
have the impression this could work.

Maybe there's another reason?  Ok, my linux kernel configuration doesn't
support it, that's probably it:
...
$ grep X86_X32 /boot/config-5.14.21-150400.24.41-default 
# CONFIG_X86_X32 is not set
...

So, it seems the best possibility to add some regular testing of this is to
generate a nostdlib .s test-case (to handle cases where the compiler doesn't or
no longer does support -mx32) which we load into gdb, check that the proper
architecture is selected, set a breakpoint on start, and then, maybe even run
it to breakpoint if the kernel supports it (but, I can't test this on my
current platform).

-- 
You are receiving this mail because:
You are on the CC list for the bug.