@rachelplusplus @hailey I remember the big drawback of x32 ABI being that to realize full gain, you'd need to recompile all applications, including the proprietary ones. Otherwise, you end up needing to keep the system libraries for x86 and x86-64 in memory while running processes that use those ABIs. Fine for embedded, not so fine for the more heterogeneous application mix on desktop. Was this solved?

#x86_64 #x32 #linux

@f4grx meanwhile, I also have something for you and other gdb with qemu users ;)

Installation

Either check out the directory with AnonCVS…

… or download the individual files (all but .cvsignore) from CVSweb https://mbsd.evolvis.org/cvs.cgi/contrib/hosted/tg/gdb/ (user=pass public due to LLM scrapers) and put them into a new directory ~/.etc/gdb/.

If you don’t use qemu 5.2 (Debian bullseye) or one with compatible XML files, you’ll have to do extra work. See below the <hr /> at the end of the post for this and a compatibility table.

Then, symlink ~/.etc/gdb/.gdbinit to ~/.gdbinit or merge things into yours if you already have one.

Usage

Start qemu either as qemu-system-i386 -S -s … (to run a 32-bit VM, then you use the qemu32 command inside gdb) or qemu-system-x86_64 -S -s … (to run a 64-bit VM, then you use the qemu64 command inside gdb). The -S makes it wait for a gdb c command before even booting. This gives you ample time to attach both vncviewer (as qemu lost its builtin SDL GUI 🤬🤬🤬) and gdb.

Start gdb and issue the user-defined qemu32 or qemu64 command.

BIOS

For a classical BIOS system, you’ll be in 16-bit real mode at F000:FFF0 at the beginning, so if you want to debug there a bit, run the c16 command to switch over, do a b *0x7c00 to set a breakpoint on the MBR, c to run until there, i to inspect the registers, u or uu COUNT to disassemble some, t to step into and tt to step over (uses a temp breakpoint at the next address, so make sure the mode is correct). Once it enters protected mode, issue the c32 command, once it enters long mode (if any), issue the c64 command. I’ve tested this with a MirBSD/i386 ISO and a Grml/amd64 ISO.

EFI

For your EFI scenario, set a breakpoint on your multiboot entry point (I used b *0x00100074 having gotten the address from nm on your ELF file, if you have symbols you can do that) and run c. Once it breaks, run the c32 command. Same as above, you can then use i, u, uu COUNT, t, tt, … (there’s also an i32 command if you prefer gdb’s standard format, it’s cleaned up a little, the i16 one is inspired by DOS DEBUG.COM; for 64-bit mode, only i64 is available in gdb’s format but the other still work and show the truncated values, perhaps somewhat usefully, especially for #x32 / #amd64ilp32 or when running a 32-bit userspace program). You can use c32 and c64 to switch between the modes and even use c16 if your bootloader exits 32-bit mode (e.g. to run BIOS calls before entering long mode), though that will be exceedingly rare in an EFI setup. I’ve tested that with the ISO you gave me.

others

The d and r2p commands are less useful to you, as they work with 16:16 segmented far pointers. The other commands (printqs5static, printqs5dynamic and the offsetof macro) are perhaps more useful when debugging host applications.

I’ve tried to make this not break when gdb is used for nōn-x86 targets, though the usability is limited there, of course.

HTH & HAND!

tdesc files

Compatibility matrix

As far as I can tell, the earliest version in which the tdesc XML files work is qemu 4.0.0 so you can exclude this for anything older.

There is, at the time of this writing, only one more commit (75ac231c67cdb13f0609943fab5499963858b587) on these files, which begun to be included with qemu 7.2.0 so anything between 4.0.0 and 7.1.x uses the same format, the one of the files contained in the repo.

Though, from the commit message, it looks like the diff…

… might be needed anyway, and it affects qemu-system-i386 only, too. Do this too if you get the Remote 'g' packet reply message and it differs by four bytes only.

Updating the tdesc files

If you find that your qemu’s files have sufficiently changed from the version I committed, you need to do the following:

• replace the downloaded/checked-out files i386-32bit.xml and i386-64bit.xml with these from the gdb-xml/ directory of the source tarball of your qemu version
• it is a good tone to add a matching <!-- obtained from qemu VERSION --> comment into line 2 like I did, so future you will be less surprised if he has to work with this more
• run the i386-64bit32.sh script to regenerate the i386-64bit32.xml file from the new i386-64bit.xml file (do some diffing to verify the changes are still good in your version)

Then you’re all set and can test things.

#x86 #i8086 #i386 #amd64 #gdb #qemu #debugging #asm #assembly