This is the mail archive of the
mailing list for the binutils 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: Fri, 21 Mar 2014 15:48:48 +0000
- 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> <20140320013305 dot GA13347 at bubble dot grove dot modra dot org>
On 03/20/2014 01:33 AM, Alan Modra wrote:
> 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!
:-) Sorry, I get that, but I was somehow assuming the elf header
wasn't itself covered by a PT_LOAD. Rookie mistake...
>> 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.
Indeed. So this mechanism could be further extended in future
to be able to read DSOs out of memory, and be able to retrieve
the dynamic symbol table, etc., which would allow getting at
unwind info for already-deleted libraries. I guess that's what
the elfutils folks had been talking about, but I somehow managed
to not connect the dots. :-)
I just tried pointing add-symbol-file-from-memory at an already
mapped DSO's elf header, but it doesn't work as is unfortunately:
(gdb) info shared curses
0x000000324d006d20 0x000000324d01df58 Yes /lib64/libncurses.so.5
(gdb) x /4b 0x000000324d000000
0x324d000000: 127 69 76 70
(gdb) add-symbol-file-from-memory 0x000000324d000000
Failed to read a valid object file image from memory.
I single stepped a little through
bfd_elf_bfd_from_remote_memory - something goes wrong with the
reading of the load segment contents, probably something wrong
with the address computations.
> 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. Thinking further ahead, it would be good to make GDB be able
to read deleted DSOs off of memory like elfutils is now doing.
With that in mind, it does seem to make sense to have this
bfd_elf_bfd_from_remote_memory code in place as is, but extend it to
treat section-less elfs just like cores, creating pseudo bfd
sections from segments...