Re: vdso handling
Doug Evans <[email protected]>
| Newsgroups | gmane.comp.gnu.binutils,gmane.comp.gdb.devel |
|---|---|
| Message-ID | <CADPb22SAmK5JB3muW_nCvuHN5L-aOcdyzYNR+OtnM3bA1x_OJg@mail.gmail.com> |
On Wed, Mar 12, 2014 at 12:17 AM, Alan Modra <[email protected]> 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. I think a case can be made that gdb should be able to use the "execution view" of the program here. As for how to achieve that ... "Discuss." :-)