Kyle, On 9/13/06, Kyle Galloway <[EMAIL PROTECTED]> wrote:
libunwind is using /proc/PID/maps to get segment info for the functions of a particular process under linux. Normally this will work, even on x86 and x86_64, so you can trace a simple app without any problems. If you attach to the process when it is stuck in a system call, libunwind won't find a matching segment, and will deduce that dwarf_step has failed to find any info. I have attached output of a test run where I had libunwind print out the IP address and the list of ranges it searches through to try to find a match. The program I am tracing is stuck in a system call, so the ip value is not inside any of the segments found by searching /proc/PID/maps. The problem here, as I see it, is that libunwind fails to parse out the vdso info to get segment ranges to cover the case where the application being traced is making a system call.
On x86, I believe the problem reported here: http://sources.redhat.com/bugzilla/show_bug.cgi?id=595 is still an issue. The situation is probably better on x86-64 but I don't see why the vdso info shouldn't be parsed. Did you see why libunwind failed to pickup the info from the vdso? BTW: Could you try to use "tests/Gtest-bt -v" as your test case. The second case (Backtrace across signal handler) tests exactly what you want: unwinding across a system-call stub. This way, we all have the same test-case handy.
While I was searching this out, I found another strange issue. When libunwind goes to look in the /proc/PID/maps info, it always assumes that /proc/PID/maps exists, even for subsidiary threads of a single process. Though this data exists, likely for legacy compatibility with 2.4 kernels, it seems unwise to rely on it always being there.
That would be news to me. In the past, Linus always advocated "intelligent" threads and removing /proc/PID/maps from "threads" would be quite contrary to that mantra. Maybe this changed, but if so, I certainly haven't heard about it. In other words, I don't think this is something we need to change, but if somebody has info to the contrary, I'd certainly like to hear about it. Thanks, --david -- Mosberger Consulting LLC, http://www.mosberger-consulting.com/ _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
