Description of problem: eu-addr2line(1) does not resolve functions from VDSO Version-Release number of selected component (if applicable): kernel-xen-2.6.19-1.2898.2.3.fc7.i686 elfutils-0.126-1.i386 How reproducible: Always. Steps to Reproduce: 1. sleep 1h & pid=$! 2. grep -w vdso /proc/$pid/maps 3. eu-addr2line -f -p $pid $(ai "Address off VDSO + 0x420 where __kernel_sigreturn() is located") Actual results: ?? ??:0 Expected results: __kernel_sigreturn ??:0 Additional info: This is definitely a kernel Bug and this one should be reassigned to kernel. But elfutils has code to read VDSO by pread64(2) and I believe it should have been working somewhere when you released elfutils this way. I failed to find a single i686 kernel version/variant (incl. upstream versions) supporting reading from `/proc/%d/mem' by read(2). Therefore I cannot call it a kernel Regression.
Created attachment 149185 [details] Kernel testcase for read(2)/mmap(2)/trace(2) `/proc/%d/mem' readers. Testcase using read(2) or mmap(2) or ptrace(2) to read VDSO contents. On local kernel-xen-2.6.19-1.2898.2.3.fc7.i686 only ptrace(2) works. Probably to be submitted to RHTS later.
Created attachment 149186 [details] elfutils-0.126 workaround using PTRACE_PEEKTEXT instead of `/proc/%d/mem'. Here is a workaround for elfutils-0.126 that uses PTRACE_PEEKTEXT instead of the original `/proc/%d/mem' pread64(2)ing code. It somehow handles ptrace(2) recursivity for processes already being ptrace(2)d from the current caller's process.
Created attachment 149248 [details] test case Run the attached test case with no args to duplicate -p PID behavior as seen from eu-addr2line et al, and with argument "ptrace" to demonstrate how it works when called from the thread that is ptrace'ing the target PID.
Try also e.g. "sh -c 'exec eu-addr2line -f -p $$ 0x40000420'". It is intended behavior in the upstream kernel and this is unchanged in Fedora kernels, that /proc/PID/mem reads are allowed only by that thread itself or by the thread that is ptrace'ing it. It was not always this way, but some "security" decision was made to disallow reads even by a thread that would be allowed to attach ptrace, if it is not actually doing ptrace at the time (so gdb can read). The libdwfl code that the -p option gets to, especially the vdso-grokking stuff, was not really intended necessarily to work standalone as it is entirely. It's more of an example of how things all plug together in the library support and what code you'd reuse in a more complex caller integrated with actual debugging stuff. In the fullness of time, there will be clean things to plug into instead of ptrace and /proc grovelling, and then -p PID support can use those and the vdso support will fall into place.
Created attachment 149350 [details] Patch on-demand PTRACE_ATTACHING the inferior for /proc/PID/mem read(2). As there is needed some workaround of the current state proposing it for elfutils. Otherwise the same code should be present in all the applications using it. Your testcase from Comment 3 would be fine to also include for elfutils together with this patch (it would run without the "ptrace" argument and it should work).
According to Roland this case never occurs as the only tool exhibiting it is `eu-addr2line -p ...'. Included a note in libunwind (Bug 229424): /* FIXME: Here we would fail for a process not being ourselves and not being PTRACE_ATTACHed for unwinding of VDSO symbols (such as sigreturn function from a signal handler on the 32-bit x86 platform). Fails read_proc_memory() with ESRCH on pread64() there. As this case probably never occurs with libunwind we do not workaround it. */