RE: Troubleshooting statically built application using backtrace.
> > What did I do wrong? > You have to add "-fexceptions" compiler option in command line, this > enable the gcc to > add frame unwind information for all functions. > I used the same test and working fine without any problems on my SH target: > > root@arcidiaf:/home/filippo/bkt# gcc -static -o test-static-0.9.33 > -rdynamic -fexceptions test.c -lubacktrace -ldl > root@arcidiaf:/home/filippo/bkt# ./test-static-0.9.33 3 > backtrace() returned 7 addresses > [0x4003ea] > [0x400504] > [0x400548] > [0x40053e] > [0x40053e] > [0x4005be] > [0x40d3a6] Yup that was it. We can now execute the hello_world app from the man page and our app. Thanks guys! Andy ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Troubleshooting statically built application using backtrace.
On 5/14/2013 9:05 PM, ANDY KENNEDY wrote: 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 Let's say I do that. I don't think that resolves the issue of it not doing a backtrace, will it? 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. As I reported this seg faults. This is a FULL description of what I did: # Extract the code from `man 3 backtrace` in to hello_world.c /opt/toolchains/powerpc-unknown-linux-uclibcgnuspe/bin/powerpc-linux-gcc \ -static -rdynamic -o hello_world hello_world.c -lubacktrace -ldl # Next, I copy over to my target (essentially this is a P1010RDB): SYSROOT=$(/opt/toolchains/powerpc-unknown-linux-uclibcgnuspe/bin/powerpc-linux-gcc -print-sysroot) LIBDIR=$SYSROOT/lib for i in ld-uClibc.so.0 libc.so.0 libgcc_s.so.1 ; do \ cp $LIBDIR/$i /tftpboot ; \ done cp hello_world /tftpboot ssh tftp LD_LIBRARY_PATH=./ hello_world 5 That should produce five function calls and a backtrace through each (as it does on my x86_64 host). I only get the backtrace function in the list. What did I do wrong? You have to add "-fexceptions" compiler option in command line, this enable the gcc to add frame unwind information for all functions. I used the same test and working fine without any problems on my SH target: root@arcidiaf:/home/filippo/bkt# gcc -static -o test-static-0.9.33 -rdynamic -fexceptions test.c -lubacktrace -ldl root@arcidiaf:/home/filippo/bkt# ./test-static-0.9.33 3 backtrace() returned 7 addresses [0x4003ea] [0x400504] [0x400548] [0x40053e] [0x40053e] [0x4005be] [0x40d3a6] Thanks, Andy ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: Troubleshooting statically built application using backtrace.
Il giorno 14/mag/2013 20:08, "ANDY KENNEDY" ha scritto: > > > > 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 > > Let's say I do that. I don't think that resolves the issue of it not > doing a backtrace, will it? > > > > > > > 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. > > > > > As I reported this seg faults. > > This is a FULL description of what I did: > > # Extract the code from `man 3 backtrace` in to hello_world.c > /opt/toolchains/powerpc-unknown-linux-uclibcgnuspe/bin/powerpc-linux-gcc \ > -static -rdynamic -o hello_world hello_world.c -lubacktrace -ldl You are bot passing the unwind table flag -fasynchronous-unwind-tables > # Next, I copy over to my target (essentially this is a P1010RDB): > SYSROOT=$(/opt/toolchains/powerpc-unknown-linux-uclibcgnuspe/bin/powerpc-linux-gcc -print-sysroot) > LIBDIR=$SYSROOT/lib > for i in ld-uClibc.so.0 libc.so.0 libgcc_s.so.1 ; do \ > cp $LIBDIR/$i /tftpboot ; \ > done > cp hello_world /tftpboot > ssh > tftp > LD_LIBRARY_PATH=./ hello_world 5 > > > That should produce five function calls and a backtrace through each > (as it does on my x86_64 host). I only get the backtrace function > in the list. > > What did I do wrong? > > Thanks, > Andy ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: Troubleshooting statically built application using backtrace.
> > 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 Let's say I do that. I don't think that resolves the issue of it not doing a backtrace, will it? > > > > 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. > > As I reported this seg faults. This is a FULL description of what I did: # Extract the code from `man 3 backtrace` in to hello_world.c /opt/toolchains/powerpc-unknown-linux-uclibcgnuspe/bin/powerpc-linux-gcc \ -static -rdynamic -o hello_world hello_world.c -lubacktrace -ldl # Next, I copy over to my target (essentially this is a P1010RDB): SYSROOT=$(/opt/toolchains/powerpc-unknown-linux-uclibcgnuspe/bin/powerpc-linux-gcc -print-sysroot) LIBDIR=$SYSROOT/lib for i in ld-uClibc.so.0 libc.so.0 libgcc_s.so.1 ; do \ cp $LIBDIR/$i /tftpboot ; \ done cp hello_world /tftpboot ssh tftp LD_LIBRARY_PATH=./ hello_world 5 That should produce five function calls and a backtrace through each (as it does on my x86_64 host). I only get the backtrace function in the list. What did I do wrong? Thanks, Andy ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Troubleshooting statically built application using backtrace.
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 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 uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: Troubleshooting statically built application using backtrace.
> 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. > Seg fault. I cannot describe to you where we seg fault, but I do know that it is within dlopen() somewhere. I can do more testing if you'd like. Just let me know. Thanks, Andy ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: Troubleshooting statically built application using backtrace.
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 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Troubleshooting statically built application using backtrace.
On 5/9/2013 6:32 AM, Carmelo Amoroso wrote: Il giorno 08/mag/2013 22:33, "ANDY KENNEDY" ha scritto: -Original Message- From: Carmelo Amoroso [mailto:carmel...@gmail.com] Sent: Wednesday, May 08, 2013 2:36 PM To: ANDY KENNEDY Cc: uclibc@uclibc.org Subject: Re: Troubleshooting statically built application using backtrace. Andy I'll commit fixes forma backtrace with static applications tomorrow. Thanks forma tour patience Carmelo Carmelo, Okay cool! Can you tell me what you've found so far? My next step was to disable the "New" way of doing the dl_hash. I've just built a new config with that disabled and am completing the toolchain now. We have actually fixed it. Static dlopen was broken 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. Will that do what I'm expecting or am I off base (that is to say, you are doing something that does NOT involve the whole libgcc_s.so.1 library)? Still want to use libgcc Thanks man. I'm being patient. I didn't know you were working on it. I have been working on it since e-mail a week ago or so. I wasn't expecting anything out of the developers of uClibc, but was attempting to fix something and actually (for a change) contribute in place of just use ;). Andy Cheers Carmelo Cheers Filippo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: Troubleshooting statically built application using backtrace.
Il giorno 08/mag/2013 22:33, "ANDY KENNEDY" ha scritto: > > > -Original Message- > > From: Carmelo Amoroso [mailto:carmel...@gmail.com] > > Sent: Wednesday, May 08, 2013 2:36 PM > > To: ANDY KENNEDY > > Cc: uclibc@uclibc.org > > Subject: Re: Troubleshooting statically built application using backtrace. > > > > Andy > > I'll commit fixes forma backtrace with static applications tomorrow. > > > > Thanks forma tour patience > > Carmelo > > Carmelo, > > Okay cool! Can you tell me what you've found so far? > > My next step was to disable the "New" way of doing the dl_hash. I've just > built a new config with that disabled and am completing the toolchain now. > We have actually fixed it. Static dlopen was broken > Will that do what I'm expecting or am I off base (that is to say, you are > doing something that does NOT involve the whole libgcc_s.so.1 library)? > Still want to use libgcc > Thanks man. I'm being patient. I didn't know you were working on it. I > have been working on it since e-mail a week ago or so. I wasn't expecting > anything out of the developers of uClibc, but was attempting to fix > something and actually (for a change) contribute in place of just use ;). > > Andy Cheers Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: Troubleshooting statically built application using backtrace.
> -Original Message- > From: Carmelo Amoroso [mailto:carmel...@gmail.com] > Sent: Wednesday, May 08, 2013 2:36 PM > To: ANDY KENNEDY > Cc: uclibc@uclibc.org > Subject: Re: Troubleshooting statically built application using backtrace. > > Andy > I'll commit fixes forma backtrace with static applications tomorrow. > > Thanks forma tour patience > Carmelo Carmelo, Okay cool! Can you tell me what you've found so far? My next step was to disable the "New" way of doing the dl_hash. I've just built a new config with that disabled and am completing the toolchain now. Will that do what I'm expecting or am I off base (that is to say, you are doing something that does NOT involve the whole libgcc_s.so.1 library)? Thanks man. I'm being patient. I didn't know you were working on it. I have been working on it since e-mail a week ago or so. I wasn't expecting anything out of the developers of uClibc, but was attempting to fix something and actually (for a change) contribute in place of just use ;). Andy ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Troubleshooting statically built application using backtrace.
Andy I'll commit fixes forma backtrace with static applications tomorrow. Thanks forma tour patience Carmelo Il giorno 08/mag/2013 21:24, "ANDY KENNEDY" ha scritto: > Attempting to backtrace in a simple helloworld app. For the simple app, > we are just using the source of the example from man backtrace. We SEEM > to be running into an infinite loop around line 296 of file > dlso/dlso/dl-hash.c in which there is a loop that (again) SEEMS to walk > off into oblivion. BTW, this is the 0.9.33.2 packaged version, if it is > fixed later, I don't know it. > > What we are attempting to do is source level debug (from gdbserver > running on a p1014 target) uClibc. I'm using CrossTool-NG to build the > toolchain. I've hacked up CTNG to REMOVE the sed scripts that remove > the debug information settings in my .config file. Setting the > following flags: > > DODEBUG=y > # DOASSERTS is not set > SUPPORT_LD_DEBUG=y > > ends in a build failure in which it appears that one of the .a libs is > attempting to link against libgcc_s.so.1 (which contains > _Unwind_Backtrace and (I think) _Unwind_Resume. This won't work so good > since these are not available static. Here is the error I get: > > /usr/bin/make -C extra/locale locale_headers > make[3]: Nothing to be done for `locale_headers'. > true -x -R .note -R .comment libc/libc_so.a > rm -f lib/libc.so lib/libc.so.0 lib/libuClibc-0.9.33.2.so > powerpc-unknown-linux-uclibcgnuspe-gcc -Wl,-EB -shared -Wl,--warn-common > -Wl,--warn-once -Wl,-z,combreloc -Wl,-z,relro -Wl,-z,now -Wl,-z,defs > -Wl,-init,__uClibc_init -Wl,-soname=libc.so.0 -nostdlib -o lib/libuClib > c-0.9.33.2.so -Wl,--whole-archive libc/libc_so.a -Wl,--no-whole-archive > ./lib/interp.os ./lib/ld-uClibc.so.0 ./lib/uclibc_nonshared.a /crap/cro > sstool-ng-1.18.0/.build/powerpc-unknown-linux-uclibcgnuspe/buildtools/li > b/gcc/powerpc-unknown-linux-uclibcgnuspe/4.7.2/libgcc.a > libc/libc_so.a(lockf.os): In function `__GI_lockf': > /crap/crosstool-ng-1.18.0/.build/powerpc-unknown-linux-uclibcgnuspe/buil > d/build-libc/libc/misc/file/lockf.c:73: undefined reference to `_Unwind_ > Resume' > libc/libc_so.a(lockf.os):(.sdata.DW.ref.__gcc_personality_v0[DW.ref.__gc > c_personality_v0]+0x0): undefined reference to `__gcc_personality_v0' > collect2: error: ld returned 1 exit status > make[1]: *** [lib/libc.so] Error 1 > > Is there an easy way to enable source level debugging so that we can > work out the issues that dl_* are having with opening up the > libgcc_s.so.1 file at run-time? > > Thanks in advance for any assistance you can give. > > Andy > ___ > uClibc mailing list > uClibc@uclibc.org > http://lists.busybox.net/mailman/listinfo/uclibc > ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Troubleshooting statically built application using backtrace.
Attempting to backtrace in a simple helloworld app. For the simple app, we are just using the source of the example from man backtrace. We SEEM to be running into an infinite loop around line 296 of file dlso/dlso/dl-hash.c in which there is a loop that (again) SEEMS to walk off into oblivion. BTW, this is the 0.9.33.2 packaged version, if it is fixed later, I don't know it. What we are attempting to do is source level debug (from gdbserver running on a p1014 target) uClibc. I'm using CrossTool-NG to build the toolchain. I've hacked up CTNG to REMOVE the sed scripts that remove the debug information settings in my .config file. Setting the following flags: DODEBUG=y # DOASSERTS is not set SUPPORT_LD_DEBUG=y ends in a build failure in which it appears that one of the .a libs is attempting to link against libgcc_s.so.1 (which contains _Unwind_Backtrace and (I think) _Unwind_Resume. This won't work so good since these are not available static. Here is the error I get: /usr/bin/make -C extra/locale locale_headers make[3]: Nothing to be done for `locale_headers'. true -x -R .note -R .comment libc/libc_so.a rm -f lib/libc.so lib/libc.so.0 lib/libuClibc-0.9.33.2.so powerpc-unknown-linux-uclibcgnuspe-gcc -Wl,-EB -shared -Wl,--warn-common -Wl,--warn-once -Wl,-z,combreloc -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,-init,__uClibc_init -Wl,-soname=libc.so.0 -nostdlib -o lib/libuClib c-0.9.33.2.so -Wl,--whole-archive libc/libc_so.a -Wl,--no-whole-archive ./lib/interp.os ./lib/ld-uClibc.so.0 ./lib/uclibc_nonshared.a /crap/cro sstool-ng-1.18.0/.build/powerpc-unknown-linux-uclibcgnuspe/buildtools/li b/gcc/powerpc-unknown-linux-uclibcgnuspe/4.7.2/libgcc.a libc/libc_so.a(lockf.os): In function `__GI_lockf': /crap/crosstool-ng-1.18.0/.build/powerpc-unknown-linux-uclibcgnuspe/buil d/build-libc/libc/misc/file/lockf.c:73: undefined reference to `_Unwind_ Resume' libc/libc_so.a(lockf.os):(.sdata.DW.ref.__gcc_personality_v0[DW.ref.__gc c_personality_v0]+0x0): undefined reference to `__gcc_personality_v0' collect2: error: ld returned 1 exit status make[1]: *** [lib/libc.so] Error 1 Is there an easy way to enable source level debugging so that we can work out the issues that dl_* are having with opening up the libgcc_s.so.1 file at run-time? Thanks in advance for any assistance you can give. Andy ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
