Re: vdso handling

[Pedro Alves <palves@redhat.com>]

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