Troubleshooting statically built application using backtrace.

[ANDY KENNEDY]

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).

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