> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Brian Niebuhr > Sent: Monday, December 09, 2013 12:51 PM > To: [email protected] > Subject: Any way to get symbols for backtrace in librt? > > All - > > I am currently trying to move from an arm uclibc toolchain based on > buildroot-2010.05 with uClibc-0.9.31 to a crosstool-ng based toolchain with > uClibc-0.9.33.2. In my application I have a number of threads that block on > mq_timedreceive, and while debugging with my buildroot toolchain I can see > the backtrace on those threads normally. However on the crosstool-ng > toolchain the backtraces for those threads appear to stop at the shared > library entry point. > > My assumption is that the librt library compiled by crosstool-ng is missing > some debug symbols that are in buildroot's librt, but digging around I can't > figure out what the difference is. As far as I can tell, buildroot doesn't > set > uclibc's DODEBUG configuration setting, and I don't see anything else that > would affect this behavior. > > Could anyone give me an idea about what I might be missing? Or if I'm > making a mistake, please let me know. What do I need to do to put enough > information in librt so I can successfully backtrace out of it?
I have a little more information on this issue, but I'm still stuck. To summarize, I'm using uClibc 0.9.33.2 with NPTL on ARM/Linux, gcc 4.8.1, and I'm trying to debug an application using gdb 7.6. I have some threads that block in system calls like mq_timedreceive(). When you examine those threads, gdb is unable to unwind the stack, so all you see in the stack for those threads is the system call followed by garbage. gdb can unwind some system calls, like select(), presumably because they don't use the PSEUDO interface. My first assumption was that the CFI information was being stripped, and that the included ARM unwind instructions were insufficient. I attempted to make some changes that mirrored this patch to glibc: https://patches.linaro.org/707/. I may have made some mistakes because I don't completely understand how stack unwinding works, but in any case that patch didn't fix the problem. So next I attempted to rebuild librt with debug symbols included to make sure that the CFI information was available. That also did not fix the problem - gdb still can't unwind the stack when blocked in a system call. I can tell you exactly where gdb gets lost. In libc/sysdeps/linux/common/bits/syscalls-common.h, inside the PSEUDO macro, inside the SINGLE_THREAD_P macro, as soon as r0 and lr are popped off of the stack, gdb can no longer unwind the stack. I don't know if it's a problem with the gdb unwind algorithm, or if there's something subtle I'm missing and an extra unwind or cfi directive would fix the issue. Is there anyone out there that understands ARM stack unwinding that can explain to me why gdb gets stuck here? Thanks, Brian This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, distribution, review, copy or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify us by reply e-mail, and destroy the original transmission and its attachments without reading them or saving them to disk. Thank you. _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
