[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] mips implementation libunwind SEGV Faulting

From: John Knight
Subject: Re: [Libunwind-devel] mips implementation libunwind SEGV Faulting
Date: Fri, 10 Feb 2017 02:31:11 +0000

A bit more input. I just added printfs to the console to determine where it seg faults; I instrumented my function called log_stack_trace() which makes a series of libunwind calls to do the backtrace. I see it calling unw_getcontext(&uc), then unw_init_local((&cursor,&uc), and then it calls unw_step(&cursor).  It does NOT return from unw_step(); Whatever is happening in unw_step() is causing the signal_handler to kick in which reports signal 11 (SEGV fault) received.  I guess next step is to instrument unw_step() to see where it fails in its processing.  Unfortunately, I don’t know the libunwind code at all… if anyone has some pointers on what to look for, I would appreciate it. 




From: Daniel Jacobowitz [mailto:address@hidden
Sent: Thursday, February 09, 2017 5:25 PM
To: Dave Watson; John Knight
Cc: address@hidden; Tommi Rantala; Faraz Shahbazker
Subject: Re: [Libunwind-devel] mips implementation libunwind SEGV Faulting


Sorry, it's been far too long; I definitely did have everything working on MIPS at the time (6-7 years ago).


On Thu, Feb 9, 2017, 8:21 PM Dave Watson <address@hidden> wrote:

On 02/10/17 01:05 AM, John Knight wrote:
> Hi Dave,
> I finally got a few cycles to work on your suggestions for trying to use libunwind version 1.1 and 1.0.  I have confirmed that libunwind version 1.1 also SEGVs when compiled for Mips.  Same as 1.2.
> As for version 1.0, the source does NOT compile... it fails to compile tests/Gperf-simple.c with multiple undefined references to _Umips_getcontext.  I have attached an excerpt from make log file for your review.
> I also have one complaint that covers versions 1.1 and 1.2:
> The file tests/test-coredump-unwind.c fails to compile on our linux system (linux 2.6.36)... the issue is that the test relies on the presence of execinfo.h, and functions backtrace() and backtrace_symbols_fd().  The issue here is that older linux versions do not have execinfo.h, nor do they have backtrace() or backtrace_symbols_fd().  If our version of linux had these, than I would not be looking to implement backtrace() capability with libunwind.  I am not sure I understand why this test uses these, unless to compare the output of libunwind to the output of glibc's backtrace() capability.  At any rate, we can't use this test and we end up patching the libunwind test source, effectively removing the inclusion of execinfo.h and the calls to backtrace() and backtrace_symbols() from the source code just to get it to compile.  It would be VERY NICE if there was a flag that could be set in the Makefile to skip compiling all of the tests.  In our embedded environment, the tests are not useful anyhow.

Git master now has a --disable-tests, but alas it just missed inclusion in 1.2.  Next release though.

> At this point, I have pretty much determined that libunwind's mips implementation is perhaps just a work in progress and not debugged and working. This might explain why mips was not listed as a supported architecture in the online documentation; I was kinda afraid of this.  As for me, I really don't know enough of the mips architecture to provide useful help in debugging this, nor do I have much time available for the activity.   I can tell you it does not work in your current source base (1.2) and also broken in 1.1.  The fact it doesn't compile in 1.0 is also pretty telling for that release as well.  Perhaps the contributor of the mips code to the libunwind project can help get it to work?  If the issues with it cannot be resolved any time soon, I am afraid I may have to find an alternative way to implement backtrace on mips... not something I look forward to.

I've cc'd a few of the mips committers if they have any suggestions for help.

> Thanks for your suggestions and help with this... I will see if I can gleen any more info from the SEGV fault, but alas, I don't have a lot of hope for this.  I'll see if I can at least determine what function is actually causing the SEGV... beyond this, not sure how much more I can do.

If you do get any more info let us know, I'm out of ideas for now though.


__________________________________________________________________ Confidential This e-mail and any files transmitted with it are the property of Belkin International, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this e-mail in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. Pour la version française: Für die deutsche Übersetzung: __________________________________________________________________

reply via email to

[Prev in Thread] Current Thread [Next in Thread]