GDB TLS testing

John Baldwin <[email protected]>
Newsgroups gmane.os.freebsd.devel.ppc
Message-ID <[email protected]>
First, I tried to boot FreeBSD under QEMU (but not using an ISO image to
boot, building a disk image via makefs so I could modify it, etc.) following
these instructions:

- make buildworld TARGET_ARCH=powerpc64 CROSS_TOOLCHAIN=powerpc64-gcc
- make buildkernel TARGET_ARCH=powerpc64 CROSS_TOOLCHAIN=powerpc64-gcc KERNCONF=GENERIC64
- make installkernel TARGET_ARCH=powerpc64 CROSS_TOOLCHAIN=powerpc64-gcc KERNCONF=GENERIC64 DESTDIR=/qemu/ppc64/rootfs/
- make installworld TARGET_ARCH=powerpc64 CROSS_TOOLCHAIN=powerpc64-gcc DESTDIR=/qemu/ppc64/rootfs/
- make distribution TARGET_ARCH=powerpc64 CROSS_TOOLCHAIN=powerpc64-gcc DESTDIR=/qemu/ppc64/rootfs/
- etcupdate extract -B -D /qemu/ppc64/rootfs -s /home/john/work/freebsd/head -M "TARGET_ARCH=powerpc64 CROSS_TOOLCHAIN=powerpc64-gcc"
- makefs -M 32g -f 200000 -o version=2 -B big /qemu/ppc64/fs.img /qemu/ppc64/rootfs
- mkimg -s mbr -p prepboot:=/qemu/ppc64/rootfs/boot/boot1.elf -p freebsd:=/qemu/ppc64/fs.img -a 1 -o /qemu/ppc64/disk.img
- qemu-system-ppc64 -drive file=/qemu/ppc64/disk.img,format=raw -nographic -vga none -nic tap,ifname=tap2

This did let me boot into QEMU, but I had some weird issues with keyboard
input not always working correctly.  The network interface (llan0) also did
not work at all.  When it tried to DHCP, I saw no traffic on the tap2
interface on the host.  I also tried using '-nic user' and that wasn't able
to DHCP either.  It seems like it if_llan(4) isn't actually transmitting
packets.

Anyway, the thing I am trying to test is support for thread-local-storage
(TLS) variables under GDB.  Since networking wasn't working, I tried to
just copy my test programs (cross-built) and a GDB binary (also cross-built)
into the disk image and booting that.  However, my test program that used
threads core dumped just trying to create a 3rd thread (so second call to
pthread_create()), and when I tried to use GDB either live or against a
core, it would just spin in userland forever (probably because C++ exceptions
aren't working).  Fixing C++ probably means moving to LLVM's libunwind instead
of the ancient libgcc from gcc4.2 (though I know Mark Millard has a patch for
the ancient libgcc that helped in his testing).

Would someone with a working ppc system be willing to help test the GDB bits
for me?  You can grab the 'fbsd_tls' branch from github/bsdjhb/gdb.git to
build a GDB.  For testing purposes, just generating a core from the test
programs I'm using and looking at that core on a non-ppc host would also
work fine.  For example, in my case where I have the ppc system installed to
/qemu/ppc64/rootfs, I would do 'set sysroot /qemu/ppc64/rootfs' at the GDB
prompt to point GDB at the ppc64 libraries, etc.  Note that modern GDB is
written in C++11, so you can't build it with gcc4.2.

The first test program I am using is below and should generate a core when
run.  To test the TLS functionality you would want to make sure 'p id'
reports the proper value (PID from the program's output), and also that
'p &id' also reports an address matching the program's output:

#include <stdio.h>
#include <unistd.h>

static __thread int id;

int
main(int ac, char **av)
{

	printf("main: PID %d\n", getpid());
	id = getpid();
	printf("id = %d (%p)\n", id, &id);
	(void)getchar();
#if 1
#if defined(__powerpc__)
	*(char *)NULL = 1;
#else
	__builtin_trap();
#endif
#endif
	return (0);
}


-- 
John Baldwin

                                                                            
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.