RE: vdso handling

> -----Original Message-----
> From: Alan Modra [mailto:[email protected]]
> Sent: Thursday, March 13, 2014 2:02 AM
> To: Cary Coutant
> Cc: Doug Evans; Metzger, Markus T; [email protected];
> [email protected]
> Subject: Re: vdso handling
> 
> On Wed, Mar 12, 2014 at 01:22:58PM -0700, Cary Coutant wrote:
> > > 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." :-)
> >
> > Add a PT_DEBUG program header entry? The PT_DEBUG segment would
> need
> > to have a small header that allows the debugger to find .debug_abbrev,
> > .debug_info, etc. (i.e., a mini section table). Or, just add
> > individual program header entries for each of the standard debug
> > sections: PT_DEBUG_ABBREV, PT_DEBUG_INFO, etc.
> 
> Debug sections are not normally loaded.  For that reason I don't think
> it makes any sense to specify program headers for them.  It wouldn't
> help in the vdso case anyway, since the problem there is that you only
> have the loaded part of the original ELF file.

The vdso contains a section table, as well.  When I hack
bfd_from_remote_memory to create BFD sections from them similar
to what elf_object_p does, I get the target sections that I wanted in GDB.
The patch is rather big, though, and duplicating a lot of elf_object_p's code.

I have not tried generating fake sections from segments, yet.

Regards,
Markus.
Intel GmbH
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