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.
John From: Daniel Jacobowitz [mailto:d...@false.org] Sent: Thursday, February 09, 2017 5:25 PM To: Dave Watson; John Knight Cc: libunwind-devel@nongnu.org; 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 <davejwat...@fb.com<mailto:davejwat...@fb.com>> 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. Thanks! __________________________________________________________________ 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: http://www.belkin.com/email-notice/French.html Für die deutsche Übersetzung: http://www.belkin.com/email-notice/German.html __________________________________________________________________
_______________________________________________ Libunwind-devel mailing list Libunwind-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/libunwind-devel
