Description of problem: on recent x86_64 kernels the kernel VDSO has grown from 4KB to 8KB and GDB (<gdb-6.6-29.fc8) started to print: warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff00f68000 According to Roland McGrath it should be rather kept backward compatible in the kernel itself. Version-Release number of selected component (if applicable): kernel-2.6.23-0.204.rc8.fc8.x86_64 How reproducible: Always. Steps to Reproduce: 1. cat /proc/self/maps | grep vdso Actual results: 7ffff43fd000-7ffff43ff000 r-xp 7ffff43fd000 00:00 0 [vdso] (8KB) Expected results: on upstream kernels (such as linux-2.6.22-rc4-git7.x86_64) it is: ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vdso] (4KB) Additional info: binutils mail thread with Roland McGrath: http://sourceware.org/ml/binutils/2007-09/msg00339.html Fortunately it has no real functionality defect as AFAIK the VDSO decoding is not needed on x86_64.
Created attachment 211151 [details] Simple testcase (but check rather /proc/self/maps).
It's true that there is no good reason for today's vDSO to be as big as 4kb, and I have sent patches upstream that make it smaller. We could use those in rawhide, and it may be wise since before build-id it so happened that the vDSO image usually crept in just under 4kb and now is just over it in F8 kernels when probably noone has before seen a multiple page x86_64 vDSO. But, note that there is nothing unkosher about the current vDSO image and it certainly is likely that even the optimal vDSO layout will grow to more than 4kb in the future. Also, powerpc vDSOs are already more than one page and userland should be coping with all vDSOs with robust generic code.
so the real answer here is "fix gdb to cope with a larger vdso" ?
gdb should be fixed for the general case, certainly. However, it's undesireable to have more than one page unless really necessary. I have patches to change the layout that make it get smaller again, which are likely to be taken upstream before 2.6.24. Using such a patch in Fedora now would be very easy on the kernel side, and take the pressure off fixing gdb if that is in a crunch (I don't know that it is).
(In reply to comment #3) > so the real answer here is "fix gdb to cope with a larger vdso" ? FYI it is currently not a direct problem for Fedora as it is workarounded in GDB (GDB now reads from the SHDRs in the second page; the other patch floating around would parse PHDRs) in gdb-6.6-29.fc8: * Mon Sep 24 2007 Jan Kratochvil <jan.kratochvil> - 6.6-29 - Fixed the kernel VDSO loading (`warning: no loadable sections found in ...').
Ok, so this is a non-issue for F8 by the sounds of things. (Unless something other than gdb cares about the larger vdso). With less than a week before the final freeze for F8, I'm hesitant to include stuff in the kernel which isn't absolutely critical. By the sounds of things, it'll shrink again in F9 anyway, making this all moot.
commit c65916fe3586521932fbd1b734f39744657f2f0d Author: Roland McGrath <roland> Date: Wed Oct 17 18:04:41 2007 +0200 x86: vdso linker script cleanup seems to have fixed this upstream in rawhide. Closing bug as resolved.
On kernel-2.6.25-1.fc9.x86_64: The VDSO data are already fully self-contained in the first 4KB.. But still the mapped range is 8KB: 7fff4ddfd000-7fff4ddff000 r-xp 7fff4ddfd000 00:00 0 [vdso] The second page contains some garbage. arch/x86/kernel/vmlinux_64.lds.S: /* vdso blob that is mapped into user space */ vdso_start = . ; .vdso : AT(ADDR(.vdso) - LOAD_OFFSET) { *(.vdso) } . = ALIGN(PAGE_SIZE); vdso_end = .; arch/x86/vdso/vma.c: static int __init init_vdso_vars(void) { int npages = (vdso_end - vdso_start + PAGE_SIZE - 1) / PAGE_SIZE; (I do not understand from the code why there are 8KB, it should be 4KB.)
More lingering stupidity upstream, I sent another patch to clean out the cruft. The posting has not hit the archive yet, but you can see it RSN at the top of http://marc.info/?a=102883379600003&r=1&w=4 It should apply trivially to F-9 and/or rawhide 2.6.25 kernels if we care.
http://marc.info/?l=linux-kernel&m=120934719817657&q=raw