Hi Luke, Objdump did not show .ARM.exidx or .ARM.extab. There is only one section specific to arm: .ARM.attributes.
I donât know what this all means, but I am hoping it makes sense to you. đ John From: Luke Diamand <l...@diamand.org> Sent: Wednesday, May 23, 2018 12:05 AM To: John Knight <john.kni...@belkin.com> Cc: libunwind-devel@nongnu.org Subject: Re: [Libunwind-devel] Minimum Linux Version requirements for libunwind? On 22 May 2018 at 23:23, John Knight <john.kni...@belkin.com<mailto:john.kni...@belkin.com>> wrote: > I just checked the make logs for recent build. I donât see any of the > compiler options you mentioned below to change the stack backtracing > methods. If you use "objdump --section-headers" on the ELF file(s) you should see some sections called .ARM.exidx and .ARM.extab with a reasonable size (a few percent of the image size). > > > > I am curious, when a signal handler is called because of a fault, is this > done via a long jump? I presume the libunwind has the intelligence to > handle longjumps and recognize the call stack prior to the longjump? libunwind has code to detect when it's being called from a signal handler. So that ought to work, though if you're using uclibc it might be different (I don't know). > > > > John > > > > From: John Knight > Sent: Tuesday, May 22, 2018 3:13 PM > To: 'Luke Diamand' <l...@diamand.org<mailto:l...@diamand.org>> > Cc: libunwind-devel@nongnu.org<mailto:libunwind-devel@nongnu.org> > Subject: RE: [Libunwind-devel] Minimum Linux Version requirements for > libunwind? > > > > Hi Luke, > > > > If I do a nm on libc.so.1 I see that it also has references to uclibc⌠we > have both libc and uclibc on our system. I donât know if that means that > the libc library is really uclibc or if the libc is just augmenting its > functionality by linking to the uclibc. It looks like its using uclibc to > pull capabilities such as bcopy and other low-level functions from it. > > > > I have no idea on how to determine what type of stack backtracing is being > used. All this stuff is a bit beyond my knowledge and understanding. I > will see if I can figure it out. > > > > Thanks for your help. > > > > John > > > > From: Luke Diamand <l...@diamand.org<mailto:l...@diamand.org>> > Sent: Tuesday, May 22, 2018 3:03 PM > To: John Knight <john.kni...@belkin.com<mailto:john.kni...@belkin.com>> > Cc: libunwind-devel@nongnu.org<mailto:libunwind-devel@nongnu.org> > Subject: Re: [Libunwind-devel] Minimum Linux Version requirements for > libunwind? > > > > On 22 May 2018 at 20:14, John Knight > <john.kni...@belkin.com<mailto:john.kni...@belkin.com>> wrote: >> Thanks Luke for your response. This is good information. >> >> According to the man page for backtrace, it indicates that "backtrace(), >> backtrace_symbols(), and backtrace_symbols_fd() are provided in glibc since >> version 2.1". Sorry for any confusion on this. >> Unfortunately, my glibc is apparently older than 2.1. I am not sure >> exactly how to tell how old... the usual method to try to run the libc.so.1 >> to get the version number results in a segmentation fault. Ldd --version is >> not understood by ldd as well. I also tried to use the >> gnu_get_libc_version() function that is supposed to always work, but it does >> not exist on my system. I think my glibc is very old... libc-so.1 vs >> libc-so.6 I am seeing commonly referenced. Sigh. > > Or maybe not glibc at all? uclibc or musl? > > The release history glibc suggests that if you have glibc2.1, then > it's over fifteen years old! > >> So to summarize, my linux kernel is 3.14.77, glibc is old (version ????), >> and gcc is 4.8.3. >> >> Anyhow, I am being unsuccessful at getting libunwind working too. It >> prints one stack backtrace step for __clone + 80 and then exits. I know >> there is one function call from the signal handler to get to the backtrace() >> function, so this looks bogus. I just need a backtrace capability that >> works. This is an embedded linux environment and I am restricted as to >> software updates I can do, so I think I am between a rock and a hard place. > > Do you know what stack backtracing method you are using? > > - might be frame pointer enabled (so -fno-omit-frame-pointer turned > on), but people tend not to use that as it's a bit slower and larger > - might be using c++ unwind tables, but then you either need to be > compiling c++ code with exceptions enabled, or, if using c, add > -fexceptions or -funwind-tables/-fasynchronous-unwind-tables along > with some linker flags > - using the DWARF debug information, but then you need to give > libunwind access to the debug image, and you need to build libunwind > with support for it > > You're probably not using the last of those. > > > >> >> John >> >> >> -----Original Message----- >> From: Luke Diamand <l...@diamand.org<mailto:l...@diamand.org>> >> Sent: Tuesday, May 22, 2018 1:50 AM >> To: John Knight <john.kni...@belkin.com<mailto:john.kni...@belkin.com>> >> Cc: libunwind-devel@nongnu.org<mailto:libunwind-devel@nongnu.org> >> Subject: Re: [Libunwind-devel] Minimum Linux Version requirements for >> libunwind? >> >> On 22 May 2018 at 00:55, John Knight >> <john.kni...@belkin.com<mailto:john.kni...@belkin.com>> wrote: >>> Hi, >>> >>> >>> >>> I am trying to get libunwind to work on an ARM processor running an >>> older version of linx (version 3.14.77). I am wondering if there are >>> any particular requirements of the Linux kernel or supporting >>> libraries that would prohibit me from running on this older kernel? >>> If so, what is the minimum kernel version required for libunwind? >> >> I don't think it has any special kernel dependencies unless you're going >> to a really old kernel version (?). I'm using libunwind with 3.10. >> >>> >>> This kernel does NOT have support of backtrace()⌠my understanding is >>> that support came with glibc in version 3.2 which had kernel support >>> for it. The lack of a backtrace has led me to try and use libunwind >>> as an alternative to give me a stack backtrace when my program SEG >>> faults. >> >> I didn't think backtrace was a kernel feature - doesn't it live in glibc? >> And uses unwind tables generated by gcc/g++ together with the unwinding code >> in libstdc++ (as per the ABI). >> >> If you're using glibc's backtrace() with unwind tables rather than frame >> pointer unwinding then you'll need a gcc that's new enough to generate it >> (and enable generation). That's been mostly there for a decade or more, but >> I think a bug was fixed recently (gcc 4.9.4/5.2 >> timeframe) for some obscure corner-cases. >> >> But back to your question, I think the oldest kernel version I've used >> libunwind with is 3.0 with glibc=2.18 and gcc=4.9. >> >> Luke >> >> __________________________________________________________________ >> 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<http://www.belkin.com/email-notice/French.html> >> FĂźr die deutsche Ăbersetzung: >> http://www.belkin.com/email-notice/German.html<http://www.belkin.com/email-notice/German.html> >> __________________________________________________________________ > > __________________________________________________________________ > 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<http://www.belkin.com/email-notice/French.html> > FĂźr die deutsche Ăbersetzung: > http://www.belkin.com/email-notice/German.html<http://www.belkin.com/email-notice/German.html> > __________________________________________________________________ __________________________________________________________________ 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
