This is the mail archive of the
mailing list for the elfutils project.
Re: [PATCH] libebl: Add ebl_unwind_ret_mask.
- From: Kurt Roeckx <kurt at roeckx dot be>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Sun, 15 Jun 2014 21:27:32 +0200
- Subject: Re: [PATCH] libebl: Add ebl_unwind_ret_mask.
On Sun, Jun 15, 2014 at 08:56:17PM +0200, Mark Wielaard wrote:
> On Sun, 2014-06-15 at 20:47 +0200, Kurt Roeckx wrote:
> > On Sun, Jun 15, 2014 at 08:38:20PM +0200, Mark Wielaard wrote:
> > >
> > > Since the sparc backend doesn't have unwinder support it sounds unlikely
> > > one of these patches triggered the bus error. Do you have more
> > > specifics? Which test triggers it, do you have a backtrace? Are there
> > > logs before/after, etc.
> > Log before:
> > https://buildd.debian.org/status/fetch.php?pkg=elfutils&arch=sparc&ver=0.159-1&stamp=1401337598
> > Log after:
> > https://buildd.debian.org/status/fetch.php?pkg=elfutils&arch=sparc&ver=0.159-2&stamp=1402854485
> Strange indeed. But I am afraid you'll have to run one of the failing
> tests under GDB to help debug it. At least so we know where it is
> crashing and if it is crashing in elfutils code or somewhere else (using
> completely different gcc and glibc versions before/after is slightly
> suspicious, even though it might still be a bug in our code of course).
Program terminated with signal SIGBUS, Bus error.
b#0 core_set_initial_registers (thread=0xffef2018, thread_arg_voidp=<optimized out>) at linux-core-attach.c:299
299 uint64_t val64 = *(const uint64_t *) reg_desc;
#0 core_set_initial_registers (thread=0xffef2018, thread_arg_voidp=<optimized out>) at linux-core-attach.c:299
#1 0xf79f43cc in dwfl_thread_getframes (thread=thread(a)entry=0xffef2018, callback=callback(a)entry=0x12520 <frame_callback>, arg=arg(a)entry=0xffef2088) at dwfl_frame.c:402
#2 0x00012ba8 in thread_callback (thread=0xffef2018, thread_arg=0xffef2088) at stack.c:458
#3 0xf79f41e0 in dwfl_getthreads (dwfl=0x28358, callback=callback(a)entry=0x12b80 <thread_callback>, arg=arg(a)entry=0xffef2088) at dwfl_frame.c:270
#4 0x0001150c in main (argc=8, argv=0xffef2354) at stack.c:731
Dropping the patches doesn't have any effect on the result.
Note that this is a 32 bit userland sparc, but the kernel is 64 bit.
I'm not sure what that code is doing there. But it seems to be
looking at a 64 bit core file (x86_64, arm64, s390x) and then
create a 64 bit pointer is trying to dereference that.