Metzger, Markus T
Fri Mar 21 08:10:00 GMT 2014
> -----Original Message-----
> From: Alan Modra [mailto:firstname.lastname@example.org]
> Sent: Thursday, March 20, 2014 2:33 AM
> 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
> not loaded!
> > 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
> > underlying function symbol_file_add_from_memory. That function does
> > 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
> (totally untested):
> 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
> if (bim == NULL)
> return NULL;
> nbfd = _bfd_new_bfd ();
> if (nbfd == NULL)
> free (bim);
> return 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;
> return nbfd;
> 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
> rid of
> /* FIXME: cagney/2004-05-06: Should not require an existing
> BFD when trying to create a run-time BFD of the VSYSCALL
I was waiting for Pedro to reply but he didn't.
This would move the ELF processing itself into GDB. That sounds a bit
odd to me but it seems GDB already does a fair amount of ELF reading.
Pedro, are you OK with this? Will you accept a patch that goes into
the direction that Alan described above?
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
More information about the Binutils