Troubleshooting statically built application using backtrace.

[Filippo ARCIDIACONO]

On 5/14/2013 12:51 AM, ANDY KENNEDY wrote:
> Filippo/Carmelo/all:
>
>> The patches fixes the infinite loop and extend the backtrace support in
>> statically linked app,
>> has been committed in master branch and cherry piched in 0.9.33 branch.
>> Moreover to properly build the libubacktrace you should manually apply
>> the patch posted in
>> http://lists.uclibc.org/pipermail/uclibc/2013-May/047772.html
>> It will be committed shortly if no objections are raised.
> Gathered all this together and did a build.  First off, using the tip of
> uClibc resulted in other strange error I didn't expect:  Apparently,
> down deep in our code, there is a reference to __close().  In the
> 0.9.33.2 code (currently being "shipped" with CrossTool-NG), this is a
> valid library call.  In the tip, however, I get an "undefined reference
> to `__close'".  A bit more digging into this one made me think that
> there was a fundamental issue with the build of libc.  Back-porting ONLY
> the changes since Thursday night (the following list):
>
> ldso/ldso/ldso.c
> ldso/libdl/libdl.c
> libc/misc/elf/dl-support.c
> libc/misc/internals/__uClibc_main.c
> libubacktrace/Makefile.in
> libubacktrace/arm/Makefile.arch
> libubacktrace/arm/backtrace.c
> libubacktrace/backtrace.c
>
> resulted in a toolchain that would execute both our proprietary app and
> the backtrace example from the man 3 backtrace page.  Neither of these
> two applications listed a backtrace.  Only one line is printed with an
> address (presumably of the backtrace function call).
Yes, it is the calling function address.
You can use addr2line command to convert the address in line number.
Before you have to compile the application with debug information (add 
-g compiler flag),
then use:
addr2line -e <exec_name> <address>
>
> It appears that, since the reference to dlopen was removed from
> libubacktrace/backtrace.c, that the libgcc_s.so.1 is removed from the
> equation entirely.  Believing this, I'm attempting to revert the
> changes made to that file so that we still attempt to dlopen the
> libgcc_s.so.1 library prior to performing the backtrace.
>
> I'll let the list know whether this works.
>
> I think we are almost there (I hope).
>
> Andy
>
>
>
>