This is the mail archive of the
mailing list for the binutils project.
Re: vdso handling
- From: Alan Modra <amodra at gmail dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: "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: Thu, 20 Mar 2014 12:03:05 +1030
- Subject: Re: vdso handling
- Authentication-results: sourceware.org; auth=none
- References: <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> <5329879C dot 6070805 at redhat dot com>
On Wed, Mar 19, 2014 at 12:03:40PM +0000, Pedro Alves wrote:
> 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.
Well, no, the section headers are part of the linking view. The ELF
file header points at their *file offset*. Thinking it odd that they
are not loaded is exactly the same as thinking it odd that .comment is
> Sounds like we should just make that a requirement?
You indeed could make that a requirement, but it'd mean that object
files loaded by glibc ld.so would not satisfy the requirement.
Taking Markus' vdso as an example, the PT_LOAD header covers file
offsets from 0 to 0xffd and page size is 0x1000. If ld.so were
loading a similar image, it would just load in 0 to 0xfff (assuming
ld.so's dl_pagesize is also 0x1000). The section headers are at file
offset 0x10e0 so would miss being loaded. Nor should they be loaded,
since they are completely extraneous to executing the image it would
be foolish to waste another page to load them.
> "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."
Heh, OK, so don't let my comments about more general uses of
bfd_from_remote_memory get in your way of fixing this problem.
Hmm, if you only want to read vdsos then bfd_from_remote_memory is way
overengineered. In fact, I think it could disappear entirely.
If you can find the extent of the vdso in gdb, then all of the ELF
version of bfd_from_remote_memory prior to allocating the bim is
unnecessary, because all that code really does is find the extent.
So the tail of bfd_from_remote_memory moves to bfd/opncls.c as
bfd_openr_bim (bfd *templ, void *contents, size_t contents_size)
struct bfd_in_memory *bim;
bim = (struct bfd_in_memory *) bfd_malloc (sizeof (struct bfd_in_memory));
if (bim == NULL)
nbfd = _bfd_new_bfd ();
if (nbfd == NULL)
nbfd->filename = "<in-memory>";
if (templ != NULL)
nbfd->xvec = templ->xvec;
bim->size = contents_size;
bim->buffer = (bfd_byte *) contents;
nbfd->iostream = bim;
nbfd->flags = BFD_IN_MEMORY;
nbfd->iovec = &_bfd_memory_iovec;
nbfd->origin = 0;
nbfd->direction = read_direction;
nbfd->mtime = time (NULL);
nbfd->mtime_set = TRUE;
gdb is then responsible for filling in "contents" and determining
"contents_size", which presumably can be done in the same way as
you did in https://sourceware.org/ml/binutils/2014-03/msg00130.html
The loadbase calculation also moves to gdb, which shouldn't be too
hard. Note that "templ" above is optional, which allows you to get
/* FIXME: cagney/2004-05-06: Should not require an existing
BFD when trying to create a run-time BFD of the VSYSCALL
Australia Development Lab, IBM