In Linux 3.16-rc1, the vdso is more heavily stripped than it is in prior versions. It has no section table*. Nonetheless, gdb should still be able to find its build-id, because its PT_NOTE phdr is in perfect order. eu-readelf -n works, but readelf -n does not. (Actually, there's a complication: due to a workaround for a bug in Go, the 64-bit vdso currently has a fake section header that does not contain a note section. This causes even elfutils to be unable to find the ELF notes. If necessary, I can change that.)
I think the bug is in bfd_elf_bfd_from_remote_memory, which isn't even trying to load phdrs when section headers are unavailable. The binutils phdr parser knows how to read PT_NOTE.
Hi Andy, Could you upload a copy of the stipped binary for us to play with ? 32-bit and 64-bit versions if possible. Cheers Nick
Which GDB version? Note bfd_elf_bfd_from_remote_memory was changed recently to better handle the vDSO. E.g., 5979d6b69b20a8355ea94b75fad97415fce4788c.
Created attachment 7642 [details] Stripped vDSO image This is the 64-bit image mapped into memory for whatever config I'm running on revision e0bf7b86dace87eccdabdd66d2769ccad19cb81c of the tip/x86/vdso tree. It should be more or less identical to Linus' tree, assuming he's fully caught up.
Created attachment 7643 [details] 32-bit stripped vDSO image 32-bit variant. This one has no sections at all, because the Go workaround isn't needed for 32-bit code (I think).
GDB version?
I tested GDB version 7.7.1-13.fc20. GDB/binutils revision 5979d6b69b20a8355ea94b75fad97415fce4788c is unlikely to help. It's actually related to why I changed the vdso in the first place. The issue is that there's now user/kernel shared data right after the vdso PT_LOAD segment. That breaks if the section headers spill past the end of the last page in the vdso PT_LOAD segment. It's also nice to keep the vdso mapping as small as possible. My solution was to just strip off the section headers entirely. If necessary, I'm willing to compromise in the kernel (I already had to for Go), but it looked like this should be easy to fix in binutils.
"unlikely to help" != "I tested current mainline and it doesn't help". ;-) > It's actually related to why I changed the vdso in the first place. How so? > My solution was to just strip off the section headers entirely. This will break btrace disassembly again: https://sourceware.org/ml/gdb-patches/2014-04/msg00055.html GDB could be fixed to not rely on section headers, but, that wouldn't look like 7.8 material, which has just branched...
(In reply to Pedro Alves from comment #8) > "unlikely to help" != "I tested current mainline and it doesn't help". ;-) True. But I'm on an amazingly slow connection, so I probably won't be able to build and test gdb today. > > > It's actually related to why I changed the vdso in the first place. > > How so? The section headers dangling off the last loadable page were a problem for the vdso implementation as well as for gdb, so I wanted to get rid of them. > > > My solution was to just strip off the section headers entirely. > > This will break btrace disassembly again: > > https://sourceware.org/ml/gdb-patches/2014-04/msg00055.html > > GDB could be fixed to not rely on section headers, but, that wouldn't look > like 7.8 material, which has just branched... Yuck. How accurate do the section headers need to be? Will having section headers that don't match between the in-memory vdso and the symbol file be a problem? IOW, if I give a section for the entire loadable segment, a dummy shstrndx section (maybe actually aliased to another section to save space), a note section, and a SHT_SYNDYM section (for Go), will gdb work? Will it lose functionality like CFI data when it loads the symbol file if the in-memory sections don't match quite right?
Apparently even stripping the names off of the sections breaks gdb. This stuff seems really fragile.
Created attachment 7644 [details] process note segments when no note sections are found
Hi Andy, Fixing "readelf -n" is fairly easy - the uploaded patch takes care of this. Cheers Nick
It looks like gdb has a lot of trouble using debug symbols for DSOs that are heavily stripped: it tries to line up addresses by section name. I don't know whether symbols for section-table-less DSOs are expected to work at all. I sent these kernel patches: http://lkml.kernel.org/g/cover.1403129369.git.luto@amacapital.net The re-add a lot of bloat, making the vdso be two pages again, but they seem to restore gdb's ability to debug it. If gdb gains the ability to debug fully-stripped DSOs at some point, then maybe I can revert those patches.