Date: Tue, 22 Jan 2019 09:50:20 -0800 From: John Baldwin <jhb@FreeBSD.org> To: Mark Millard <marklmi@yahoo.com> Cc: "freebsd-ppc@freebsd.org" <freebsd-ppc@FreeBSD.org> Subject: Re: GDB TLS testing Message-ID: <eff896f3-e385-9a12-5132-3884e69689ca@FreeBSD.org> In-Reply-To: <AB56B3D1-1762-4115-B7B4-91D4B997F1C4@yahoo.com> References: <b0f5b62f-54fb-309f-a578-7b4d9e340a55@FreeBSD.org> <19343397-859C-4629-A4A5-B0DCDE25957B@yahoo.com> <AB56B3D1-1762-4115-B7B4-91D4B997F1C4@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/21/19 7:02 PM, Mark Millard wrote:
>
>
> On 2019-Jan-21, at 18:24, Mark Millard <marklmi at yahoo.com> wrote:
>
>
>
>> On 2019-Jan-21, at 12:58, John Baldwin <jh at freebsd.org> wrote:
>>
>>> . . .
>>>
>>> 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);
>>> }
>>
>> Note: This is from my odd devel/pwoerpc64-xtoolchain-gcc based buildworld
>> based environment with cc being system clang:
>>
>> # uname -apKU
>> FreeBSD FBSDG5L 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r341836M: Tue Dec 11 20:11:21 PST 2018 markmi@FBSDFSSD:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1300005 1300005
>>
>>
>> Absent makeinfo the make failed to complete. (I've no clue if there are
>> more dependencies required.)
>>
>> # ./configure
>> checking build system type... powerpc64-unknown-freebsd13.0
>> checking host system type... powerpc64-unknown-freebsd13.0
>> checking target system type... powerpc64-unknown-freebsd13.0
>> checking for a BSD-compatible install... /usr/bin/install -c
>> . . .
>> checking for makeinfo... no
>> /root/c_tests/ppc64_tls_git/missing: makeinfo: not found
>> checking for expect... no
>> . . .
>> # make
>> Configuring in ./libiberty
>> configure: creating cache ./config.cache
>> checking whether to enable maintainer-specific portions of Makefiles... no
>> checking for makeinfo... /root/c_tests/ppc64_tls_git/missing makeinfo --split-size=5000000
>> configure: WARNING:
>> *** Makeinfo is missing. Info documentation will not be built.
>> checking for perl... perl
>> . . .
>> creating bfdver.texi
>> restore=: && backupdir=".am$$" && rm -rf $backupdir && mkdir $backupdir && if (/root/c_tests/ppc64_tls_git/missing makeinfo --split-size=5000000 --split-size=5000000 --version) >/dev/null 2>&1; then for f in bfd.info bfd.info-[0-9] bfd.info-[0-9][0-9] bfd.i[0-9] bfd.i[0-9][0-9]; do if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; done; else :; fi && if /root/c_tests/ppc64_tls_git/missing makeinfo --split-size=5000000 --split-size=5000000 -I . -o bfd.info `test -f 'bfd.texi' || echo './'`bfd.texi; then rc=0; else rc=$?; $restore $backupdir/* `echo "./bfd.info" | sed 's|[^/]*$||'`; fi; rm -rf $backupdir; exit $rc
>> /root/c_tests/ppc64_tls_git/missing: makeinfo: not found
>> WARNING: 'makeinfo' is missing on your system.
>> You should only need it if you modified a '.texi' file, or
>> any other file indirectly affecting the aspect of the manual.
>> You might want to install the Texinfo package:
>> <http://www.gnu.org/software/texinfo/>;
>> The spurious makeinfo call might also be the consequence of
>> using a buggy 'make' (AIX, DU, IRIX), in which case you might
>> want to install GNU make:
>> <http://www.gnu.org/software/make/>;
>> *** Error code 127
>>
>> Stop.
>> make[3]: stopped in /root/c_tests/ppc64_tls_git/bfd/doc
>> *** Error code 1
>>
>> Stop.
>> make[2]: stopped in /root/c_tests/ppc64_tls_git/bfd
>> *** Error code 1
>>
>> Stop.
>> make[1]: stopped in /root/c_tests/ppc64_tls_git
>> *** Error code 1
>>
>> Stop.
>> make: stopped in /root/c_tests/ppc64_tls_git
>
>
> After installing print/texinfo to get makeinfo , the
> next problem for me is libintl.h not being found
> despite its existence in /usr/local/include/ :
>
> # make
> . . .
> libtool: compile: cc -DHAVE_CONFIG_H -I. -DBINDIR=\"/usr/local/bin\" -I. -I. -I./../include -DHAVE_powerpc_elf64_fbsd_vec -DHAVE_powerpc_elf64_vec -DHAVE_powerpc_elf32_vec -DHAVE_powerpc_elf32_fbsd_vec -DHAVE_powerpc_elf32_le_vec -DHAVE_rs6000_xcoff_vec -DHAVE_rs6000_xcoff64_vec -DHAVE_rs6000_xcoff64_aix_vec -DHAVE_elf64_le_vec -DHAVE_elf64_be_vec -DHAVE_elf32_le_vec -DHAVE_elf32_be_vec -DHAVE_plugin_vec -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -I./../zlib -g -O2 -MT archive.lo -MD -MP -MF .deps/archive.Tpo -c archive.c -o archive.o
> In file included from archive.c:134:
> ./sysdep.h:185:11: fatal error: 'libintl.h' file not found
> # include <libintl.h>
> ^~~~~~~~~~~
> 1 error generated.
> *** Error code 1
>
> Stop.
> make[4]: stopped in /root/c_tests/ppc64_tls_git/bfd
> *** Error code 1
>
> Stop.
> make[3]: stopped in /root/c_tests/ppc64_tls_git/bfd
> *** Error code 1
>
> Stop.
> make[2]: stopped in /root/c_tests/ppc64_tls_git/bfd
> *** Error code 1
>
> Stop.
> make[1]: stopped in /root/c_tests/ppc64_tls_git
> *** Error code 1
>
> Stop.
> make: stopped in /root/c_tests/ppc64_tls_git
>
>
>
> # find /usr/local/include/ -name libintl.h -print
> /usr/local/include/libintl.h
This is an issue with GDB's configure that I haven't not been able to fix.
I usually use a wrapper script, but it should be sufficient to set CFLAGS
to "-I/usr/local/include" in the environment when invoking ./configure.
Nevertheless, I was able to use a FAT filesystem image as a side car (as
suggested by Justin) to examine the core dumps in a cross-debugger which was
enough to test my current TLS patch:
% ~/work/git/gdb/obj/gdb/gdb tls_single
GNU gdb (GDB) 8.2.50.20190115-git
...
Reading symbols from tls_single...
Reading symbols from /usr/home/john/work/johnsvn/test/tls_single/ppc64/tls_single.debug...
(gdb) set sysroot /qemu/ppc64/rootfs/
(gdb) core-file tls_single.core
[New LWP 100058]
Core was generated by `./tls_single'.
Program terminated with signal SIGSEGV, Segmentation fault.
Python Exception <type 'exceptions.AttributeError'> 'module' object has no attribute 'objfiles':
#0 0x00000000100006bc in main (ac=
<optimized out>, av=<optimized out>) at tls_single.
c:16
16 *(char *)NULL = 1;
(gdb) p id
$1 = 688
(gdb) info proc
process 688
cmdline = './tls_single'
cwd = '/root'
exe = '/root/tls_single'
Hopefully this will land in GDB 8.3 when it is released. (Still need to get
C++ exceptions working to have a functional native GDB for powerpc64 though.)
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?eff896f3-e385-9a12-5132-3884e69689ca>