Re: [PATCH] RISC-V: Fix elfutils testsuite unwind failures.

[Jim Wilson <jimw at sifive dot com>]

On Thu, Jan 17, 2019 at 9:05 AM Mark Wielaard <mark@klomp.org> wrote:
> For what it is worth on my setup with glibc-2.28.9000-24.fc30.riscv64
> your testcase goes into an infinite loop with -DUSE_PTHREADS=1, but
> ends quickly without. So it does seem useful.

Experimenting a bit, I've figured out that if I use the system
libpthread.so, then the testcase behaves as I expect.  It fails
without the libc.so patch, it works with my libc.so patch.  If I use
the libpthread.so I just built as part of the glibc build, then the
testcase always passes.

> You might be able to see how it exactly unwinds by simply adding
> something like printf ("%p\n", (void *) _Unwind_GetIP (ctx));
> in the callback () function.

Trying this, I see that with the system libpthread.so, the backtrace
reaches __thread_start, and then loops infinitely without my patch or
exits with a 0 with my patch.  With the just built libpthread.so, the
backtrace only gets to start_thread, and then exits.  start_thread has
unwind info and a valid return address pointing back to
__thread_start, so it isn't obvious why the unwind stops there.
libpthread does have its own personality routine, maybe something
changed there.  Or maybe one of the missing binutils/gcc/glibc/linux
kernel/etc features we have implemented since the system libpthread.so
was built is causing things to work slightly differently now.  Or
maybe my glibc is configured slightly differently than the system
glibc and that is effecting the result.

I do think the __thead_start change and the new testcase are correct.
Other ports have similar changes to __thread_start, and verifying that
unwind to top of stack in a thread works if a good test to do.

> Why not use cfi_startproc/cfi_endproc instead of the cfi_label?

I used the exact same solution that is already used in the RISC-V
_start function.  I don't care what solution is used here, but I do
think that _start and __thread_start should use the exact same
solution.

Jim