This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: vdso handling
- From: Pedro Alves <palves at redhat dot com>
- To: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>, Mark Wielaard <mjw at redhat dot com>, Cary Coutant <ccoutant at google dot com>, Doug Evans <dje at google dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 19 Mar 2014 12:03:40 +0000
- Subject: Re: vdso handling
- Authentication-results: sourceware.org; auth=none
- References: <CADPb22SAmK5JB3muW_nCvuHN5L-aOcdyzYNR+OtnM3bA1x_OJg at mail dot gmail dot com> <CAHACq4o=HmdCo1FPFL-96raf2UN805jvM=VZM-9dbKrmzJFJTw at mail dot gmail dot com> <20140313010147 dot GZ26922 at bubble dot grove dot modra dot org> <1394704336 dot 11818 dot 115 dot camel at bordewijk dot wildebeest dot org> <20140313130322 dot GA3384 at bubble dot grove dot modra dot org> <5321C7C8 dot 6000707 at redhat dot com> <5321C8FA dot 40708 at gmail dot com> <5321CE1A dot 20509 at redhat dot com> <20140313235347 dot GD3384 at bubble dot grove dot modra dot org> <A78C989F6D9628469189715575E55B230AAB6B17 at IRSMSX103 dot ger dot corp dot intel dot com> <20140318230939 dot GA9145 at bubble dot grove dot modra dot org>
On 03/18/2014 11:09 PM, Alan Modra wrote:
> I don't think this is a good idea. If/when bfd_from_remote_memory is
> used for something other than the linux kernel vdso, we can't assume
> the section headers are loaded.
I wonder what use cases are these though. It'd be odd to me to
load the elf headers, but not all that the headers point at.
Sounds like we should just make that a requirement?
I looked at the history of this whole code, and here's what I found.
Roland originally added this bfd function for reading the Linux
vsyscall dso, in 8d6337fe:
https://sourceware.org/ml/binutils/2003-05/msg00542.html
As far as I can judge from http://lwn.net/Articles/30258/ , and
from looking at the early days of the vsyscall dso in the Linux
tree, it looks like the vsyscall dso was always included complete
in memory (e.g., at v2.6.12-rc2, the initial git import):
...
/* 32bit VDSOs mapped into user space. */
asm(".section \".init.data\",\"aw\"\n"
"syscall32_syscall:\n"
".incbin \"arch/x86_64/ia32/vsyscall-syscall.so\"\n"
"syscall32_syscall_end:\n"
"syscall32_sysenter:\n"
".incbin \"arch/x86_64/ia32/vsyscall-sysenter.so\"\n"
"syscall32_sysenter_end:\n"
".previous");
...
# The DSO images are built using a special linker script
quiet_cmd_syscall = SYSCALL $@
cmd_syscall = $(CC) -m32 -nostdlib -shared -s \
-Wl,-soname=linux-gate.so.1 -o $@ \
-Wl,-T,$(filter-out FORCE,$^)
...
I found no sign of strip or of any special elf munging.
GDB only uses bfd_elf_bfd_from_remote_memory for the vdso,
and for "add-symbol-file-from-memory".
Roland himself added the "add-symbol-file-from-memory"
command (5417f6dc) to GDB too, at:
https://www.sourceware.org/ml/gdb-patches/2003-10/msg00045.html
"This command may not really be worth having, but it serves to exercise the
underlying function symbol_file_add_from_memory. That function does the
work of reading symbols and unwind info from the Linux vsyscall DSO."
--
Pedro Alves