RE: vdso handling

"Metzger, Markus T" <[email protected]>
Newsgroups gmane.comp.gdb.devel,gmane.comp.gnu.binutils
Message-ID <A78C989F6D9628469189715575E55B230AA9F2B0@IRSMSX103.ger.corp.intel.com>
> -----Original Message-----
> From: Metzger, Markus T
> Sent: Thursday, March 13, 2014 9:24 AM


> > 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.

This turned out to be rather simple.  Is this the right direction to go?
Should I maybe restrict this to PT_LOAD segments?


diff --git a/bfd/elfcode.h b/bfd/elfcode.h
index 20101be..22aae2a 100644
--- a/bfd/elfcode.h
+++ b/bfd/elfcode.h
@@ -1771,7 +1771,6 @@ NAME(_bfd_elf,bfd_from_remote_memory)
 	    return NULL;
 	  }
       }
-  free (x_phdrs);
 
   /* If the segments visible in memory didn't include the section headers,
      then clear them from the file header.  */
@@ -1791,6 +1790,7 @@ NAME(_bfd_elf,bfd_from_remote_memory)
   bim = (struct bfd_in_memory *) bfd_malloc (sizeof (struct bfd_in_memory));
   if (bim == NULL)
     {
+      free (x_phdrs);
       free (contents);
       bfd_set_error (bfd_error_no_memory);
       return NULL;
@@ -1799,6 +1799,7 @@ NAME(_bfd_elf,bfd_from_remote_memory)
   if (nbfd == NULL)
     {
       free (bim);
+      free (x_phdrs);
       free (contents);
       bfd_set_error (bfd_error_no_memory);
       return NULL;
@@ -1815,6 +1816,12 @@ NAME(_bfd_elf,bfd_from_remote_memory)
   nbfd->mtime = time (NULL);
   nbfd->mtime_set = TRUE;
 
+  /* Add fake sections for program headers.  We ignore errors.  */
+  for (i = 0; i < i_ehdr.e_phnum; ++i)
+    (void) bfd_section_from_phdr (nbfd, &i_phdrs[i], i);
+
+  free (x_phdrs);
+
   if (loadbasep)
     *loadbasep = loadbase;
   return nbfd;


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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.