This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wed 12 Mar 2014 17:47:02 Alan Modra wrote: > On Mon, Mar 10, 2014 at 01:04:33PM +0000, Metzger, Markus T wrote: > > I noticed that the BFD created for the VDSO (system-provided in-memory > > DSO) does not contain any BFD sections. Is this intentional? Or has > > there just been no need for them? > > [snip] > > > The vdso is processed in symbol_file_add_from_memory at > > gdb/symfile-mem.c:84. It calls bfd_from_remote_memory to create a BFD > > for the vdso and then processes it. > > The underlying cause is that you're trying to debug an ELF binary that > only contains the execution view. The linking view (of which the > sections are a part) is not loaded, so bfd_from_remote_memory does not > have this information. See elfcode.h bfd_from_remote_memory. > > You can see similar breakage of gdb and binutils if you zap e_shoff, > e_shnum, and e_shstrndx of your favourite hello world program. > > I suppose one way to provide something that gdb and other tools expect > would be to treat the vdso like a core file, and create fake sections > corresponding to the program headers. I'm not really keen on the idea > though, since I know that will open up a can of worms. > > Can't you point gdb at a file image for the vdso? i don't think distros generally ship it ? the kernel doesn't install it by default (e.g. into /lib/modules/$(uname -r)/vdso/). -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |