From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12493 invoked by alias); 1 Jun 2005 20:13:35 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12482 invoked by uid 22791); 1 Jun 2005 20:13:31 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 01 Jun 2005 20:13:31 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j51KDUqq009465 for ; Wed, 1 Jun 2005 16:13:30 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j51KDUO09412 for ; Wed, 1 Jun 2005 16:13:30 -0400 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id j51KDTMX004159 for ; Wed, 1 Jun 2005 16:13:29 -0400 Received: from [172.16.14.72] (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id B090E800104 for ; Wed, 1 Jun 2005 16:13:29 -0400 (EDT) Message-ID: <429E16E9.8010301@redhat.com> Date: Wed, 01 Jun 2005 20:13:00 -0000 From: Jeff Johnston User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: [RFA]: Upstream bfd patch for ia64 vDSO support Content-Type: multipart/mixed; boundary="------------080104090304040304030501" X-SW-Source: 2005-06/txt/msg00011.txt.bz2 This is a multi-part message in MIME format. --------------080104090304040304030501 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 759 The attached patch has been checked in to binutils by Jim Wilson. It fixes a problem with the ia64 vDSO so that gdb can backtrace from system calls. I need this to check in an ia64/libunwind patch that fixes backtracing through syscalls. I didn't know if one could just check in upstream bfd patches without approval so I will ask. May I commit this? Without the patch, the bfd_from_remote_memory call sets a bogus address for loadbase and symbol_file_add_from_memory fails. See http://sourceware.org/ml/binutils/2005-05/msg00725.html for the patch and references to the discussion 2005-05-31 James E Wilson * elfcode.h (NAME(bfd_elf,bfd_from_remote_memory)): Check for program header PF_R flag on PT_LOAD segments. --------------080104090304040304030501 Content-Type: text/plain; name="elfcode.h.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="elfcode.h.patch" Content-length: 1323 Index: elfcode.h =================================================================== RCS file: /cvs/src/src/bfd/elfcode.h,v retrieving revision 1.69 diff -u -p -r1.69 elfcode.h --- elfcode.h 26 May 2005 07:41:13 -0000 1.69 +++ elfcode.h 1 Jun 2005 19:58:09 -0000 @@ -1656,7 +1656,10 @@ NAME(_bfd_elf,bfd_from_remote_memory) for (i = 0; i < i_ehdr.e_phnum; ++i) { elf_swap_phdr_in (templ, &x_phdrs[i], &i_phdrs[i]); - if (i_phdrs[i].p_type == PT_LOAD) + /* IA-64 vDSO may have two mappings for one segment, where one mapping + is executable only, and one is read only. We must not use the + executable one. */ + if (i_phdrs[i].p_type == PT_LOAD && (i_phdrs[i].p_flags & PF_R)) { bfd_vma segment_end; segment_end = (i_phdrs[i].p_offset + i_phdrs[i].p_filesz @@ -1703,7 +1706,10 @@ NAME(_bfd_elf,bfd_from_remote_memory) } for (i = 0; i < i_ehdr.e_phnum; ++i) - if (i_phdrs[i].p_type == PT_LOAD) + /* IA-64 vDSO may have two mappings for one segment, where one mapping + is executable only, and one is read only. We must not use the + executable one. */ + if (i_phdrs[i].p_type == PT_LOAD && (i_phdrs[i].p_flags & PF_R)) { bfd_vma start = i_phdrs[i].p_offset & -i_phdrs[i].p_align; bfd_vma end = (i_phdrs[i].p_offset + i_phdrs[i].p_filesz --------------080104090304040304030501--