Wed Mar 19 12:03:00 GMT 2014
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:
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. */
# 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 $@ \
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:
"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."
More information about the Binutils