AMD64 version of GNAT Ada compiler broken due to libthr
Locked
 
|
|
On Fri, Dec 31, 2010 at 12:46:33PM +0100, John Marino wrote:
> For several months I have been getting the GNAT Ada compiler to work > properly on the four major BSDs. The i386 FreeBSD, the i386 Dragonfly > BSD, and the x86_64 Dragonfly BSD ports are currently perfect. The i386 > and x86_64 ports of NetBSD are nearly perfect, and only lack a > functional DWARF2 unwind mechanism, and the OpenBSD ports are in pretty > good shape too. The progress for this work can be seen at > http://www.dragonlace.net > > However the AMD64 FreeBSD version is unusable and it's due to libthr. > I'm not sure why the i386 version works with libthr and AMD64 version > doesn't. For all four BSDs, there is no configuration difference for > threading between architectures. > > The problem seems to be with the pthread_cond_wait functionality. > > I've logged a test case segfault via gdb7.1 below. I would greatly > appreciate some help in determining where the problem lies. If this > problem can be solved, it will likely result in a perfect port of the > GNAT Ada compiler for FreeBSD AMD64, something that has not existed before. > Second, I suspect that the backtrace you have shown is not from the thread that generated SIGSEGV. Switch to other threads and see their backtraces, I am almost sure that there will be something more interesting. Just to be sure, in gdb, disassemble _umtx_op_err() and see which instruction is executed when SIGSEGV generated. I think that the thread with the backtrace below is sleeping in syscall. > Regards, > John > > > > Starting program: /usr/home/marino/test_gnat/test_c9a009c/c9a009c > [New LWP 100051] > [New Thread 800a041c0 (LWP 100051)] > [New Thread 800a0ae40 (LWP 100073)] > [New Thread 800a64c80 (LWP 100080)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 800a64c80 (LWP 100080)] > 0x00007fffffbfeb19 in ?? () > * 4 Thread 800a64c80 (LWP 100080) 0x00007fffffbfeb19 in ?? () > 3 Thread 800a0ae40 (LWP 100073) 0x00000008006923cc in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 2 Thread 800a041c0 (LWP 100051) 0x00000008006923cc in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > [Switching to thread 3 (Thread 800a0ae40 (LWP 100073))]#0 > 0x00000008006923cc in _umtx_op_err () at > /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 37 RSYSCALL_ERR(_umtx_op) > #0 0x00000008006923cc in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > #1 0x00000008006904c5 in cond_wait_common (cond=<value optimized out>, > mutex=0x800a0c850, abstime=0x0, cancel=1) > at /usr/src/lib/libthr/thread/thr_cond.c:204 > #2 0x000000000040ca0f in system.tasking.stages.activate_tasks ( > chain_access=0x7fffffbfebb0) at s-tassta.adb:382 > #3 0x0000000000405950 in c9a009c.t1 (<_task>=<value optimized out>) > at c9a009c.adb:52 > #4 0x000000000040d655 in system.tasking.stages.task_wrapper ( > self_id=0x800a0c700) at s-tassta.adb:1207 > #5 0x0000000800688621 in thread_start (curthread=0x800a0ae40) > at /usr/src/lib/libthr/thread/thr_create.c:288 > #6 0x0000000000000000 in ?? () > > _______________________________________________ > [hidden email] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "[hidden email]" |
attachment0 (203 bytes) |
|
|
|
On Fri, Dec 31, 2010 at 01:35:14PM +0100, John Marino wrote:
> Hi Kostik, > You're right, that was an oversight. I'm using release 8.1, but I tried > troubleshooting this months ago on 8.0 and the result was identical. > > I'm well above my head here. I don't know what I should be looking for. > Here's the dissembled _umtx_op_err function, along with the > backtraces of the other two threads. They didn't look that interesting > to me the first time. The instruction counter is right before syscall, so I do think that the thread was executing the syscall. Backtrace for LWP 100073 indeed looks interesting, because the address 0x00007fffffbfeb19 belongs to the area used for stack(s), including the thread stacks. FreeBSD amd64 currently provides non-executable stacks for non-main threads, but executable stack for main thread. i386 has no support for nx bit on non-PAE kernels. As a useful experiment, go to src/lib/libthr/thread/thr_stack.c, find the following fragment if ((stackaddr = mmap(stackaddr, stacksize+guardsize, PROT_READ | PROT_WRITE, MAP_STACK, -1, 0)) != MAP_FAILED && and change the flags from PROT_READ | PROT_WRITE to PROT_READ | PROT_WRITE | PROT_EXEC. Then recompile and reinstall libthr, and report back what happens with your test. > > -- john > > > > Starting program: /usr/home/marino/test_gnat/test_c9a009c/c9a009c > [New LWP 100086] > [New Thread 800a041c0 (LWP 100086)] > [New Thread 800a0ae40 (LWP 100051)] > [New Thread 800a64c80 (LWP 100073)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 800a64c80 (LWP 100073)] > 0x00007fffffbfeb19 in ?? () > Cannot set lwp 100073 registers: Invalid argument > > An error occurred while in a function called from GDB. > Evaluation of the expression containing the function > (_umtx_op_err) will be abandoned. > When the function is done executing, GDB will silently stop. > Dump of assembler code for function _umtx_op_err: > 0x00000008006923c0 <+0>: mov $0x1c6,%rax > 0x00000008006923c7 <+7>: mov %rcx,%r10 > 0x00000008006923ca <+10>: syscall > 0x00000008006923cc <+12>: retq > 0x00000008006923cd <+13>: nop > 0x00000008006923ce <+14>: nop > 0x00000008006923cf <+15>: nop > 0x00000008006923d0 <+16>: mov 0x102d09(%rip),%rax # > 0x8007950e0 > 0x00000008006923d7 <+23>: push %rbx > 0x00000008006923d8 <+24>: cmp $0xffffffffffffffff,%rax > 0x00000008006923dc <+28>: je 0x8006923f5 <_umtx_op_err+53> > 0x00000008006923de <+30>: lea 0x102cfb(%rip),%rbx # > 0x8007950e0 > 0x00000008006923e5 <+37>: callq *%rax > 0x00000008006923e7 <+39>: mov -0x8(%rbx),%rax > 0x00000008006923eb <+43>: sub $0x8,%rbx > 0x00000008006923ef <+47>: cmp $0xffffffffffffffff,%rax > 0x00000008006923f3 <+51>: jne 0x8006923e5 <_umtx_op_err+37> > 0x00000008006923f5 <+53>: pop %rbx > 0x00000008006923f6 <+54>: retq > 0x00000008006923f7 <+55>: nop > End of assembler dump. > [Switching to thread 2 (Thread 800a041c0 (LWP 100086))]#0 > 0x00000008006923cc in _umtx_op_err () at > /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 37 RSYSCALL_ERR(_umtx_op) > #0 0x00000008006923cc in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > #1 0x00000008006904c5 in cond_wait_common (cond=<value optimized out>, > mutex=0x800a0bb50, abstime=0x0, cancel=1) > at /usr/src/lib/libthr/thread/thr_cond.c:204 > #2 0x000000000040bfeb in > system.tasking.stages.vulnerable_complete_master () > at s-tassta.adb:1696 > #3 0x000000000040620a in c9a009c () at c9a009c.adb:44 > [Switching to thread 4 (Thread 800a64c80 (LWP 100073))]#0 > 0x00007fffffbfeb19 in ?? () > #0 0x00007fffffbfeb19 in ?? () > #1 0x000000000040d655 in system.tasking.stages.task_wrapper ( > self_id=0x800a52500) at s-tassta.adb:1207 > #2 0x0000000800688621 in thread_start (curthread=0x800a64c80) > at /usr/src/lib/libthr/thread/thr_create.c:288 > #3 0x0000000000000000 in ?? () > > > > > Kostik Belousov wrote: > >On Fri, Dec 31, 2010 at 12:46:33PM +0100, John Marino wrote: > >>For several months I have been getting the GNAT Ada compiler to work > >>properly on the four major BSDs. The i386 FreeBSD, the i386 Dragonfly > >>BSD, and the x86_64 Dragonfly BSD ports are currently perfect. The i386 > >>and x86_64 ports of NetBSD are nearly perfect, and only lack a > >>functional DWARF2 unwind mechanism, and the OpenBSD ports are in pretty > >>good shape too. The progress for this work can be seen at > >>http://www.dragonlace.net > >> > >>However the AMD64 FreeBSD version is unusable and it's due to libthr. > >>I'm not sure why the i386 version works with libthr and AMD64 version > >>doesn't. For all four BSDs, there is no configuration difference for > >>threading between architectures. > >> > >>The problem seems to be with the pthread_cond_wait functionality. > >> > >>I've logged a test case segfault via gdb7.1 below. I would greatly > >>appreciate some help in determining where the problem lies. If this > >>problem can be solved, it will likely result in a perfect port of the > >>GNAT Ada compiler for FreeBSD AMD64, something that has not existed > >>before. > >> > >First, you did not specified which version of the base system you use. > > > >Second, I suspect that the backtrace you have shown is not from the > >thread that generated SIGSEGV. Switch to other threads and see their > >backtraces, I am almost sure that there will be something more interesting. > > > >Just to be sure, in gdb, disassemble _umtx_op_err() and see which > >instruction is executed when SIGSEGV generated. I think that the thread > >with the backtrace below is sleeping in syscall. > > > >>Regards, > >>John > >> |
|
|
|
|
On Fri, Dec 31, 2010 at 02:08:31PM +0100, John Marino wrote:
> Hi Kostik, > The result is the test passes. A small gdb log follows to prove it. > So what does this mean? This means that the Ada complier or tasking library uses on-stack trampolines for something. Since FreeBSD threads on amd64 get non-executable stacks, the tasking fails. The proper solution is to provide a support for conditional non-executable stacks, as described in http://lists.freebsd.org/pipermail/freebsd-arch/2010-November/010826.html The latest WIP patch is http://people.freebsd.org/~kib/misc/nxstacks.3.patch I hope to get something in the tree not too long. > > -- John > > > Starting program: /usr/home/marino/test_gnat/test_c9a009c/c9a009c > [New LWP 100064] > [New Thread 800a041c0 (LWP 100064)] > [New Thread 800a0ae40 (LWP 100051)] > [New Thread 800a64c80 (LWP 100073)] > [New Thread 800aa1ac0 (LWP 100090)] > [Thread 800aa1ac0 (LWP 100090) exited] > Invalid selected thread. > [Switching to thread 2 (Thread 800a041c0 (LWP 100064))]#0 > 0x00000008006923cc in _umtx_op_err () at > /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 37 RSYSCALL_ERR(_umtx_op) > Continuing. > [Thread 800a64c80 (LWP 100073) exited] > Invalid selected thread. > [Switching to thread 2 (Thread 800a041c0 (LWP 100064))]#0 > 0x00000008006923cc in _umtx_op_err () at > /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 37 RSYSCALL_ERR(_umtx_op) > Continuing. > [Thread 800a0ae40 (LWP 100051) exited] > Invalid selected thread. > [Switching to thread 2 (Thread 800a041c0 (LWP 100064))]#0 > 0x00000008006923cc in _umtx_op_err () at > /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 37 RSYSCALL_ERR(_umtx_op) > Continuing. > > Program exited normally. > > > > > Kostik Belousov wrote: > >On Fri, Dec 31, 2010 at 01:35:14PM +0100, John Marino wrote: > >>Hi Kostik, > >>You're right, that was an oversight. I'm using release 8.1, but I tried > >>troubleshooting this months ago on 8.0 and the result was identical. > >> > >>I'm well above my head here. I don't know what I should be looking for. > >> Here's the dissembled _umtx_op_err function, along with the > >>backtraces of the other two threads. They didn't look that interesting > >>to me the first time. > >The instruction counter is right before syscall, so I do think that the > >thread was executing the syscall. > > > >Backtrace for LWP 100073 indeed looks interesting, because the address > >0x00007fffffbfeb19 belongs to the area used for stack(s), including > >the thread stacks. > > > >FreeBSD amd64 currently provides non-executable stacks for non-main > >threads, but executable stack for main thread. i386 has no support for > >nx bit on non-PAE kernels. > > > >As a useful experiment, go to src/lib/libthr/thread/thr_stack.c, find > >the following fragment > > > > if ((stackaddr = mmap(stackaddr, stacksize+guardsize, > > PROT_READ | PROT_WRITE, MAP_STACK, > > -1, 0)) != MAP_FAILED && > > > >and change the flags from PROT_READ | PROT_WRITE to > >PROT_READ | PROT_WRITE | PROT_EXEC. Then recompile and reinstall libthr, > >and report back what happens with your test. > > |
|
|
|
|
On Fri, Dec 31, 2010 at 02:37:29PM +0100, John Marino wrote:
> Yeah, that's kind of what I was getting at. Would this patch get into > FreeBSD 8.2, and would that mean that GNAT would start working properly > starting with FreeBSD 8.2 if that happened? Definitely not in 8.2. Might be in 8.3, if successfully landed in HEAD. Besides the patch for the base system, compiler must be configured to properly mark the objects that need executable thunks on the stack. See the references in the arch@ message I pointed to. > > I guess that also means the other BSD's have been allowing executable > stacks all along. Or, there is a compiler configuration that prevents using the thunks on the stack. |
|
|
|
|
On Fri, Dec 31, 2010 at 08:37:14PM +0100, John Marino wrote:
> Hi Kostik, > > Thanks for pointing me in the right direction. After some research, I > discovered that only DragonFly BSD allows execution on the stack by > default. NetBSD and OpenBSD (and Solaris and Darwin) all were specially > configured within gcc to execute mprotect first to enable this > functionality. FreeBSD never had this gcc configuration code and > frankly it looks like it should have already been there. > > I created my own __enable_execute_stack macro function based on these > previous works and now GNAT has passed all tests! Since i386 always > worked, I only applied to macro to the AMD64 configuration header. > > You've been a great help! Once I understood what the issue was, > everything fell into place. Will you upstream the changes to gcc ? > > -- John > > > Kostik Belousov wrote: > >On Fri, Dec 31, 2010 at 02:37:29PM +0100, John Marino wrote: > >>Yeah, that's kind of what I was getting at. Would this patch get into > >>FreeBSD 8.2, and would that mean that GNAT would start working properly > >>starting with FreeBSD 8.2 if that happened? > >Definitely not in 8.2. > >Might be in 8.3, if successfully landed in HEAD. > > > >Besides the patch for the base system, compiler must be configured > >to properly mark the objects that need executable thunks on the stack. > >See the references in the arch@ message I pointed to. > > > >>I guess that also means the other BSD's have been allowing executable > >>stacks all along. > >Or, there is a compiler configuration that prevents using the thunks > >on the stack. |
|
|
|
|
|
Loading...
| Powered by Nabble | Edit this page |