From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30118 invoked by alias); 18 Mar 2014 23:10:13 -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 30098 invoked by uid 89); 18 Mar 2014 23:10:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-pd0-f172.google.com Received: from mail-pd0-f172.google.com (HELO mail-pd0-f172.google.com) (209.85.192.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 18 Mar 2014 23:09:49 +0000 Received: by mail-pd0-f172.google.com with SMTP id p10so7776389pdj.17 for ; Tue, 18 Mar 2014 16:09:47 -0700 (PDT) X-Received: by 10.68.178.66 with SMTP id cw2mr36089771pbc.89.1395184187199; Tue, 18 Mar 2014 16:09:47 -0700 (PDT) Received: from bubble.grove.modra.org ([101.166.26.37]) by mx.google.com with ESMTPSA id ja8sm56163106pbd.3.2014.03.18.16.09.43 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 16:09:46 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id A49F6EA00D2; Wed, 19 Mar 2014 09:39:39 +1030 (CST) Date: Tue, 18 Mar 2014 23:10:00 -0000 From: Alan Modra To: "Metzger, Markus T" Cc: Pedro Alves , Mark Wielaard , Cary Coutant , Doug Evans , "gdb@sourceware.org" , "binutils@sourceware.org" Subject: Re: vdso handling Message-ID: <20140318230939.GA9145@bubble.grove.modra.org> Mail-Followup-To: "Metzger, Markus T" , Pedro Alves , Mark Wielaard , Cary Coutant , Doug Evans , "gdb@sourceware.org" , "binutils@sourceware.org" References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-03/txt/msg00050.txt.bz2 On Tue, Mar 18, 2014 at 03:09:58PM +0000, Metzger, Markus T wrote: > 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; > > /* Read in the ELF header in external format. */ > @@ -1728,20 +1728,16 @@ NAME(_bfd_elf,bfd_from_remote_memory) > } > > /* 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 >= (i_ehdr.e_shoff > - + i_ehdr.e_shnum * i_ehdr.e_shentsize)) > - { > - contents_size = 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 = 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 = last_phdr->p_offset + last_phdr->p_filesz; > > + /* Keep the section headers. */ > + shdr_begin = i_ehdr.e_shoff; > + shdr_end = shdr_begin + i_ehdr.e_shnum * i_ehdr.e_shentsize; > + if (shdr_end > (bfd_vma) contents_size) > + contents_size = shdr_end; > + I don't think this is a good idea. If/when bfd_from_remote_memory is used for something other than the linux kernel vdso, we can't assume the section headers are loaded. The original code made the assumption that the highest address loaded from a PT_LOAD header was rounded up to a page, and that the page size could be inferred from p_align. Here: segment_end = (i_phdrs[i].p_offset + i_phdrs[i].p_filesz + i_phdrs[i].p_align - 1) & -i_phdrs[i].p_align; if (segment_end > (bfd_vma) contents_size) contents_size = segment_end; Now, p_align is generally set from the page size if using GNU ld, but I'm wondering if your vdso somehow doesn't have that property. Can you show us your vdso readelf -e output? If p_align isn't set to a page, then the change in heuristic I envision is to make use of elf_backend_data maxpagesize to figure out which parts of the image might be loaded. If that isn't enough then perhaps we should add another parameter to bfd_from_remote_memory to allow its caller to specify the end of the image. > 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? I don't mind either way. This part of bfd belongs to gdb, so gdb maintainers really have the final say on patch approval. I'm just someone who happened to become interested in the problem.. -- Alan Modra Australia Development Lab, IBM