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
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
