Re: 32 bit applcaition debugging with 64bit gdb on 64bit machine

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Tue, 01 Dec 2009 10:15:47 +0100, paawan oza wrote:
> I have following questions, please try to clarify.
>
>  I compile gdb on 64 bit machine,
>
> 1) 32 bit application compiled on 32 bit system and directly using them on 64 bit machine, and then we debug the 32 bit application using 64 bit gdb on 64 bit machine.
>
> 2) 32 bit applications compiled on 64 bit machine using  -m32 flag, and then I try to compile 32 bit application using 64 bit gdb in 64 bit machine.
>
> 3) of course 64bit applications must be able to be debugged easily by 64 bit gdb on 64 bit machine.
>
> In 1 and 2,  is there any case where gdb may not work or may have some issue ?
> I suppose 3 must not have any issue.

build:

Differences between native 32bit build and -m32 build on 64bit should be none
as (a) the gcc target code is the same and (b) the 32bit libraries are exactly
the same binary on 64bit hosts (at least on FedorA).

debugging:

All the cases should work and they are +/- supported for debugging:
kernel debugger inferior
x86_64 x86_64   x86_64    = native 64bit
x86_64 x86_64   i386
x86_64 i386     i386
i386   i386     i386      = native 32bit

But there are occasional GDB bugs such as:
	[patch] Fix syscall restarts for amd64->i386 biarch
	http://sourceware.org/ml/gdb-patches/2009-11/msg00592.html

	[patch 03/15] PIE: breakpoint_address_match gdbarch_addr_bit workaround
	http://sourceware.org/ml/gdb-patches/2009-11/msg00170.html
		(while this case is required only for the still non-upstreamed
		 PIE patch I guess one could find similar bug in existing code)

	[checked-in]
	[patch] Fix i386 memory-by-register access on amd64
	http://sourceware.org/ml/gdb-patches/2009-04/msg00786.html

	[not upstreamed]
	[patch] Support gcore for i386 inferiors on amd64
	http://sourceware.org/ml/gdb-patches/2006-09/msg00159.html
	http://cvs.fedora.redhat.com/viewvc/rpms/gdb/F-12/gdb-6.5-gcore-i386-on-amd64.patch?content-type=text%2Fplain&view=co

Linux kernels had various problems running both the x86_64-x86_64-i386 and
x86_64-i386-i386 cases (the same for ppc*; for example s390x-s390-s390 is
officailly not supported).  Various such bugs were found/fixed, this is why
biarch-tests/ build (erestartsys-trap was failing only in biarch mode
recently) and -debugge{r,e} testcases exist there:
	http://sourceware.org/systemtap/wiki/utrace/tests

One should run the two biarch modes (-m32 build of gdb and check//unix/-m32
testsuite run with 64bit gdb) and check the gdb testsuite produces exactly the
same results as on native 32bit host/kernel.  I was doing these comparisons in
the past which were a source for some bugreports+fixes above and others.
I do not run these tests regularly, one should recheck it.


vDSO:

Linux kernel provides [vdso] 4KB page which intentionally uses some
instructions not present on 32bit native targets which may cause some
incompatibilities for 32-bit era debuggers not ready for them:

Vitaly Mayatskikh:
I can confirm, this is internal kernel issue in arch/x86_64/ia32/syscall32.c.
It reproducible on every AMD machine, because kernel uses `sysenter' for Intel
machines and `syscall' instead of `int80' otherwise.

Seems, AMD is able to execute `syscall' from compatibility mode and this is
faster than `int80'. Isn't it cheaper to fix gdb and not to loose cpu time for
every system call in ia32 emulation mode? IIRC, on Intel machines `syscall'
costs approx. 1200 tacts and `int80' approx 2500.  


Regards,
Jan