Summary: | The vdso is not available when running on ppc64* | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Tulio Magno Quites Machado Filho <tuliom> |
Component: | general | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | cel, mark, pedromfc, will_schmidt |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Tulio Magno Quites Machado Filho
2021-03-23 19:42:38 UTC
The issue does not appear to be just on the PPC platform. I tried the same test on my Intel laptop running a REL release more /etc/redhat-release Red Hat Enterprise Linux release 8.3 (Ootpa) and see the same issue LD_SHOW_AUXV=1 valgrind /bin/true AT_SYSINFO_EHDR: 0x7ffc587c4000 AT_HWCAP: bfebfbff AT_PAGESZ: 4096 AT_CLKTCK: 100 AT_PHDR: 0x559a635f1040 AT_PHENT: 56 AT_PHNUM: 11 AT_BASE: 0x7f5ced33d000 AT_FLAGS: 0x0 AT_ENTRY: 0x559a635f2580 AT_UID: 1000 AT_EUID: 1000 AT_GID: 1000 AT_EGID: 1000 AT_SECURE: 0 AT_RANDOM: 0x7ffc5864ab99 AT_HWCAP2: 0x0 AT_EXECFN: /usr/bin/valgrind AT_PLATFORM: x86_64 ==39447== Memcheck, a memory error detector ==39447== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==39447== Using Valgrind-3.16.0 and LibVEX; rerun with -h for copyright info ==39447== Command: /bin/true ==39447== AT_HWCAP: bfebfbff AT_PAGESZ: 4096 AT_CLKTCK: 100 AT_PHDR: 0x108040 AT_PHENT: 56 AT_PHNUM: 10 AT_BASE: 0x4000000 AT_FLAGS: 0x0 AT_ENTRY: 0x109740 AT_UID: 1000 AT_EUID: 1000 AT_GID: 1000 AT_EGID: 1000 AT_SECURE: 0 AT_RANDOM: 0x1fff000fdc AT_EXECFN: /bin/true AT_PLATFORM: x86_64 ==39447== ==39447== HEAP SUMMARY: ==39447== in use at exit: 0 bytes in 0 blocks ==39447== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==39447== ==39447== All heap blocks were freed -- no leaks are possible ==39447== ==39447== For lists of detected and suppressed errors, rerun with: -s ==39447== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) This is done deliberately, see coregrind/m_initimg/initimg-linux.c (setup_client_stack): case AT_SYSINFO_EHDR: { /* Trash this, because we don't reproduce it */ const NSegment* ehdrseg = VG_(am_find_nsegment)((Addr)auxv->u.a_ptr); vg_assert(ehdrseg); VG_(am_munmap_valgrind)(ehdrseg->start, ehdrseg->end - ehdrseg->start); auxv->a_type = AT_IGNORE; break; } So the application should use actual syscalls instead of using that magic vdso page when running under valgrind. Is there a reason you need AT_SYSINFO_EHDR? (In reply to Mark Wielaard from comment #2) > This is done deliberately, see coregrind/m_initimg/initimg-linux.c > (setup_client_stack): > > case AT_SYSINFO_EHDR: { > /* Trash this, because we don't reproduce it */ > const NSegment* ehdrseg = > VG_(am_find_nsegment)((Addr)auxv->u.a_ptr); > vg_assert(ehdrseg); > VG_(am_munmap_valgrind)(ehdrseg->start, ehdrseg->end - > ehdrseg->start); > auxv->a_type = AT_IGNORE; > break; > } > It seems that this case statement is #ifdefed out for ppc, and some other arches, correct? So shouldn't AT_SYSINFO_EHDR, and the vDSO, be available for these arches? > Is there a reason you need AT_SYSINFO_EHDR? It's used in glibc for ppc for the backtrace function that prints out return addresses for all frames in a stack. The symbol from the vDSO for the signal trampoline is used to handle the backtrace when there's a signal, which doesn't work when it's run under Valgrind, due to the missing vDSO. This was rediscovered in bug #446123 which has a bit more technical background. We might simply have to keep track of the vdso too (we currently don't, that is why we remove AT_SYSINFO_EHDR) Although in the case of glibc backtrace () we might also request a bug fix/workaround in glibc. *** This bug has been marked as a duplicate of bug 446123 *** (In reply to Mark Wielaard from comment #4) > Although in the case of glibc backtrace () we might also request a bug > fix/workaround in glibc. glibc's backtrace implementation has been removed in version 2.35 Source: https://sourceware.org/git/?p=glibc.git;a=commit;h=82fd7314c7df8c5555dce027df6f2c98ca5a927f So, I believe the fix you're expecting has already been implemented. |