From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5678 invoked by alias); 18 Mar 2014 15:14:04 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 5577 invoked by uid 89); 18 Mar 2014 15:14:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mga09.intel.com Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Mar 2014 15:14:01 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 18 Mar 2014 08:06:34 -0700 X-ExtLoop1: 1 Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga001.jf.intel.com with ESMTP; 18 Mar 2014 08:11:05 -0700 Received: from irsmsx104.ger.corp.intel.com (163.33.3.159) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 18 Mar 2014 15:09:59 +0000 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.27]) by IRSMSX104.ger.corp.intel.com ([169.254.5.224]) with mapi id 14.03.0123.003; Tue, 18 Mar 2014 15:09:59 +0000 From: "Metzger, Markus T" To: Alan Modra , Pedro Alves CC: Mark Wielaard , Cary Coutant , "Doug Evans" , "gdb@sourceware.org" , "binutils@sourceware.org" Subject: RE: vdso handling Date: Tue, 18 Mar 2014 15:14:00 -0000 Message-ID: References: <20140312071701.GW26922@bubble.grove.modra.org> <20140313010147.GZ26922@bubble.grove.modra.org> <1394704336.11818.115.camel@bordewijk.wildebeest.org> <20140313130322.GA3384@bubble.grove.modra.org> <5321C7C8.6000707@redhat.com> <5321C8FA.40708@gmail.com> <5321CE1A.20509@redhat.com> <20140313235347.GD3384@bubble.grove.modra.org> In-Reply-To: <20140313235347.GD3384@bubble.grove.modra.org> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00049.txt.bz2 > -----Original Message----- > From: Alan Modra [mailto:amodra@gmail.com] > Sent: Friday, March 14, 2014 12:54 AM > OK, so I think Markus should be looking at why bfd_from_remote_memory > decides to exclude the section headers. ie. why the following code > is being executed >=20 > /* If the segments visible in memory didn't include the section headers, > then clear them from the file header. */ > if ((bfd_vma) contents_size < (i_ehdr.e_shoff > + i_ehdr.e_shnum * i_ehdr.e_shentsize)) > { > memset (&x_ehdr.e_shoff, 0, sizeof x_ehdr.e_shoff); > memset (&x_ehdr.e_shnum, 0, sizeof x_ehdr.e_shnum); > memset (&x_ehdr.e_shstrndx, 0, sizeof x_ehdr.e_shstrndx); > } >=20 > It may be that we can tweak the heuristic. One thing I noticed is > that the following >=20 > /* Trim the last segment so we don't bother with zeros in the last page > that are off the end of the file. However, if the extra bit in that > page includes the section headers, keep them. */ >=20 > will trim off .symtab which might otherwise be available. GNU ld places > .symtab after the section headers. Something like this? diff --git a/bfd/elfcode.h b/bfd/elfcode.h index 20101be..601d7ea 100644 --- a/bfd/elfcode.h +++ b/bfd/elfcode.h @@ -1616,7 +1616,7 @@ NAME(_bfd_elf,bfd_from_remote_memory) bfd_byte *contents; int err; unsigned int i; - bfd_vma loadbase; + bfd_vma loadbase, shdr_begin, shdr_end; bfd_boolean loadbase_set; =20 /* Read in the ELF header in external format. */ @@ -1728,20 +1728,16 @@ NAME(_bfd_elf,bfd_from_remote_memory) } =20 /* Trim the last segment so we don't bother with zeros in the last page - that are off the end of the file. However, if the extra bit in that - page includes the section headers, keep them. */ - if ((bfd_vma) contents_size > last_phdr->p_offset + last_phdr->p_filesz - && (bfd_vma) contents_size >=3D (i_ehdr.e_shoff - + i_ehdr.e_shnum * i_ehdr.e_shentsize)) - { - contents_size =3D last_phdr->p_offset + last_phdr->p_filesz; - if ((bfd_vma) contents_size < (i_ehdr.e_shoff - + i_ehdr.e_shnum * i_ehdr.e_shentsize)) - contents_size =3D i_ehdr.e_shoff + i_ehdr.e_shnum * i_ehdr.e_shentsize; - } - else + that are off the end of the file. */ + if ((bfd_vma) contents_size > last_phdr->p_offset + last_phdr->p_filesz) contents_size =3D last_phdr->p_offset + last_phdr->p_filesz; =20 + /* Keep the section headers. */ + shdr_begin =3D i_ehdr.e_shoff; + shdr_end =3D shdr_begin + i_ehdr.e_shnum * i_ehdr.e_shentsize; + if (shdr_end > (bfd_vma) contents_size) + contents_size =3D shdr_end; + /* Now we know the size of the whole image we want read in. */ contents =3D (bfd_byte *) bfd_zmalloc (contents_size); if (contents =3D=3D NULL) @@ -1773,18 +1769,19 @@ NAME(_bfd_elf,bfd_from_remote_memory) } free (x_phdrs); =20 - /* If the segments visible in memory didn't include the section headers, - then clear them from the file header. */ - if ((bfd_vma) contents_size < (i_ehdr.e_shoff - + i_ehdr.e_shnum * i_ehdr.e_shentsize)) - { - memset (&x_ehdr.e_shoff, 0, sizeof x_ehdr.e_shoff); - memset (&x_ehdr.e_shnum, 0, sizeof x_ehdr.e_shnum); - memset (&x_ehdr.e_shstrndx, 0, sizeof x_ehdr.e_shstrndx); - } + /* Copy the section headers. */ + err =3D target_read_memory (ehdr_vma + shdr_begin, + contents + shdr_begin, shdr_end - shdr_begin); + if (err) + { + free (contents); + bfd_set_error (bfd_error_system_call); + errno =3D err; + return NULL; + } =20 /* This will normally have been in the first PT_LOAD segment. But it - conceivably could be missing, and we might have just changed it. */ + conceivably could be missing. */ memcpy (contents, &x_ehdr, sizeof x_ehdr); =20 /* Now we have a memory image of the ELF file contents. Make a BFD. */ Would it be OK to send this patch as part of a GDB patch series with binutils-patches and you CC'ed? Or do you want a separate patch only to binutils-patches? This patch alone runs without new fails in the gdb and binutils suite on x86-64 Fedora 19. For the latter I ran "make check" from $build/binutils, where $build is my build directory from I which I called configure. In combination with my other GDB changes, it shows regressions in gdb.base/break-interp.exp. I'll send the patch once I fixed them. thanks, 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