From patchwork Fri Mar 28 23:00:37 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Modra X-Patchwork-Id: 342 Return-Path: X-Original-To: siddhesh@wilcox.dreamhost.com Delivered-To: siddhesh@wilcox.dreamhost.com Received: from homiemail-mx20.g.dreamhost.com (caibbdcaaahc.dreamhost.com [208.113.200.72]) by wilcox.dreamhost.com (Postfix) with ESMTP id C1671360486 for ; Fri, 28 Mar 2014 16:00:50 -0700 (PDT) Received: by homiemail-mx20.g.dreamhost.com (Postfix, from userid 14314964) id 7AE6340CF3058; Fri, 28 Mar 2014 16:00:50 -0700 (PDT) X-Original-To: gdb@patchwork.siddhesh.in Delivered-To: x14314964@homiemail-mx20.g.dreamhost.com Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by homiemail-mx20.g.dreamhost.com (Postfix) with ESMTPS id 2A31A409B96A3 for ; Fri, 28 Mar 2014 16:00:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=x335 2BLbDeiQtcA8OyvmBd4grKoQvMMNXPx9Yc2jBxttoCzr9yruSA8fiGlg3bufrGaw zi1Oj4jEs8Lc2yAGdArwnbTMbiCKBphBvoMqRzkJSglwTlUjbnSP4R0STOKQIj0R rKLo+v4NhSKbX0kttYwrliT0Fr/8eNaNicZFue0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=TxkZ+o4E5O wjnSJ0mytPYop9nq0=; b=U+uYqJGVu++frNCrHE2UNGVDfJdyXnJUIZ9fAlXebC 2iUl39hdM5MMww51JSouKvcXPwPLwedKKoS3U6IElselW0uhApWODtQ2fFigjQFH 5WOcRE0v3FcNFOGSkljNDRTBoNuAZwOXDu0+7XHQx5JA76+kvCsR9dBllYlZQIoX 8= Received: (qmail 28798 invoked by alias); 28 Mar 2014 23:00:47 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 28778 invoked by uid 89); 28 Mar 2014 23:00:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-pb0-f43.google.com Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com) (209.85.160.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 28 Mar 2014 23:00:45 +0000 Received: by mail-pb0-f43.google.com with SMTP id um1so5614254pbc.2 for ; Fri, 28 Mar 2014 16:00:44 -0700 (PDT) X-Received: by 10.66.164.70 with SMTP id yo6mr11260048pab.85.1396047644107; Fri, 28 Mar 2014 16:00:44 -0700 (PDT) Received: from bubble.grove.modra.org ([101.166.26.37]) by mx.google.com with ESMTPSA id om6sm27358228pbc.43.2014.03.28.16.00.40 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Mar 2014 16:00:43 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id C4064EA00DD; Sat, 29 Mar 2014 09:30:37 +1030 (CST) Date: Sat, 29 Mar 2014 09:30:37 +1030 From: Alan Modra To: Pedro Alves Cc: "Metzger, Markus T" , Mark Wielaard , Cary Coutant , Doug Evans , gdb-patches@sourceware.org, binutils@sourceware.org Subject: Re: vdso handling Message-ID: <20140328230037.GW18201@bubble.grove.modra.org> Mail-Followup-To: Pedro Alves , "Metzger, Markus T" , Mark Wielaard , Cary Coutant , Doug Evans , gdb-patches@sourceware.org, binutils@sourceware.org References: <5321C8FA.40708@gmail.com> <5321CE1A.20509@redhat.com> <20140313235347.GD3384@bubble.grove.modra.org> <20140318230939.GA9145@bubble.grove.modra.org> <5329879C.6070805@redhat.com> <20140320013305.GA13347@bubble.grove.modra.org> <532C5F60.80700@redhat.com> <20140328061321.GU18201@bubble.grove.modra.org> <53357B30.6040006@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <53357B30.6040006@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-DH-Original-To: gdb@patchwork.siddhesh.in On Fri, Mar 28, 2014 at 01:37:52PM +0000, Pedro Alves wrote: > Hmm. Indeed. With current mainline, and with your patch as is, > the command still fails for me. In fact, it turns out > exactly related to p_align vs page size. > > $ cat /proc/30669/maps | grep ncurses > 324d000000-324d023000 r-xp 00000000 fd:01 315662 /usr/lib64/libncurses.so.5.9 > 324d023000-324d222000 ---p 00023000 fd:01 315662 /usr/lib64/libncurses.so.5.9 > 324d222000-324d223000 r--p 00022000 fd:01 315662 /usr/lib64/libncurses.so.5.9 > 324d223000-324d224000 rw-p 00023000 fd:01 315662 /usr/lib64/libncurses.so.5.9 > > So when trying to read the second PT_LOAD with p_vmaddr 324d222cf8 > and p_vmaddr+p_filesz 324d2236b4, (the 3rd and 4th region above), > we'd end up reading from 324d200000 to 324d2236b4: > > (top-gdb) p /x loadbase + vaddr > $5 = 0x324d200000 > (top-gdb) p /x end > $6 = 0x236b4 > (top-gdb) p /x loadbase + vaddr + end > $8 = 0x324d2236b4 > > which fails as it hits the (324d023000-324d222000) region, > which has no permissions. Ah ha! What's more, if the read did happen to succeed you'd overwrite contents written when processing the first PT_LOAD. I believe that will still happen with your fixup patch. Not that it's a problem, since ld.so reads the page holding the end of the first PT_LOAD and the beginning of the second PT_LOAD twice, but I think it would be better if BFD didn't rely on this ld.so behaviour (and an exact match between BFD and ld.so's page size). I believe the intent of rounding to a page was to pick up the file and program headers at the start of a file and section headers at the end, so let's do just that. On top of my last patch: diff --git a/bfd/elfcode.h b/bfd/elfcode.h index 31f67a8..a005948 100644 --- a/bfd/elfcode.h +++ b/bfd/elfcode.h @@ -1612,7 +1612,7 @@ NAME(_bfd_elf,bfd_from_remote_memory) Elf_External_Ehdr x_ehdr; /* Elf file header, external form */ Elf_Internal_Ehdr i_ehdr; /* Elf file header, internal form */ Elf_External_Phdr *x_phdrs; - Elf_Internal_Phdr *i_phdrs, *last_phdr; + Elf_Internal_Phdr *i_phdrs, *last_phdr, *first_phdr; bfd *nbfd; struct bfd_in_memory *bim; bfd_byte *contents; @@ -1621,7 +1621,6 @@ NAME(_bfd_elf,bfd_from_remote_memory) bfd_vma high_offset; bfd_vma shdr_end; bfd_vma loadbase; - bfd_boolean loadbase_set; /* Read in the ELF header in external format. */ err = target_read_memory (ehdr_vma, (bfd_byte *) &x_ehdr, sizeof x_ehdr); @@ -1694,9 +1693,9 @@ NAME(_bfd_elf,bfd_from_remote_memory) i_phdrs = (Elf_Internal_Phdr *) &x_phdrs[i_ehdr.e_phnum]; high_offset = 0; - last_phdr = NULL; loadbase = 0; - loadbase_set = FALSE; + first_phdr = NULL; + last_phdr = NULL; for (i = 0; i < i_ehdr.e_phnum; ++i) { elf_swap_phdr_in (templ, &x_phdrs[i], &i_phdrs[i]); @@ -1712,7 +1711,7 @@ NAME(_bfd_elf,bfd_from_remote_memory) /* If this program header covers offset zero, where the file header sits, then we can figure out the loadbase. */ - if (!loadbase_set) + if (first_phdr == NULL) { bfd_vma p_offset = i_phdrs[i].p_offset; bfd_vma p_vaddr = i_phdrs[i].p_vaddr; @@ -1725,7 +1724,7 @@ NAME(_bfd_elf,bfd_from_remote_memory) if (p_offset == 0) { loadbase = ehdr_vma - p_vaddr; - loadbase_set = TRUE; + first_phdr = &i_phdrs[i]; } } } @@ -1784,13 +1783,15 @@ NAME(_bfd_elf,bfd_from_remote_memory) bfd_vma end = start + i_phdrs[i].p_filesz; bfd_vma vaddr = i_phdrs[i].p_vaddr; - if (i_phdrs[i].p_align > 1) + /* Extend the beginning of the first pt_load to cover file + header and program headers. */ + if (first_phdr == &i_phdrs[i]) { - start &= -i_phdrs[i].p_align; - end = (end + i_phdrs[i].p_align - 1) & -i_phdrs[i].p_align; - vaddr &= -i_phdrs[i].p_align; + vaddr -= start; + start = 0; } - if (end > high_offset) + /* Extend the end of the last pt_load to cover section headers. */ + if (last_phdr == &i_phdrs[i]) end = high_offset; err = target_read_memory (loadbase + vaddr, contents + start, end - start);