Re: [Libunwind-devel] Minimum Linux Version requirements for libunwind?

[Luke Diamand]

On 22 May 2018 at 23:23, John Knight <address@hidden> 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' <address@hidden>
> Cc: address@hidden
> 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 <address@hidden>
> Sent: Tuesday, May 22, 2018 3:03 PM
> To: John Knight <address@hidden>
> Cc: address@hidden
> Subject: Re: [Libunwind-devel] Minimum Linux Version requirements for
> libunwind?
>
>
>
> On 22 May 2018 at 20:14, John Knight <address@hidden> 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 <address@hidden>
>> Sent: Tuesday, May 22, 2018 1:50 AM
>> To: John Knight <address@hidden>
>> Cc: address@hidden
>> Subject: Re: [Libunwind-devel] Minimum Linux Version requirements for
>> libunwind?
>>
>> On 22 May 2018 at 00:55, John Knight <address@hidden> 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 Für die deutsche Übersetzung:
>> 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
> __________________________________________________________________