From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7186 invoked by alias); 11 Feb 2010 16:37:32 -0000 Received: (qmail 7178 invoked by uid 22791); 11 Feb 2010 16:37:31 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 11 Feb 2010 16:37:24 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o1BGbLjp032660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 11 Feb 2010 11:37:21 -0500 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o1BGbIk0004914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Feb 2010 11:37:20 -0500 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.3) with ESMTP id o1BGbHdB021164 for ; Thu, 11 Feb 2010 17:37:17 +0100 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.3/Submit) id o1BGbH5h021163 for gdb-patches@sourceware.org; Thu, 11 Feb 2010 17:37:17 +0100 Date: Thu, 11 Feb 2010 16:37:00 -0000 From: Jan Kratochvil To: gdb-patches@sourceware.org Subject: [ping] [patch] Sanity check PIE displacement (like the PIC one) Message-ID: <20100211163716.GA20704@host0.dyn.jankratochvil.net> References: <20100201012004.GA6015@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100201012004.GA6015@host0.dyn.jankratochvil.net> User-Agent: Mutt/1.5.20 (2009-08-17) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-02/txt/msg00291.txt.bz2 Hi, ping(gdb-7.1?). There are some options if it should / should not print some of the messages. Still at least some form of the svr4_exec_displacement() part should IMO go in as otherwise there is a regression risk for gdb-7.1. Thanks, Jan ------------------------------------------------------------------------------ On Mon, 01 Feb 2010 02:20:04 +0100, Jan Kratochvil wrote: Hi, there is a regression-like problem from the PIE patchset: [RFC/ia64] memory error when reading wrong core file http://sourceware.org/ml/gdb-patches/2010-01/msg00645.html which reminded me the PIE displacement should be considered as valid only under some circumstances similar to the PIC ones. The PIC displacement is already being sanity checked since its beginning: cope with varying prelink base addresses http://sourceware.org/ml/gdb-patches/2006-02/msg00164.html http://sourceware.org/ml/gdb-cvs/2006-02/msg00133.html http://sourceware.org/ml/gdb-cvs/2006-02/msg00134.html 9d3251335df19906ffbf861c40199c7e28af3e7a -> ((l_addr & align) == 0 && ((dynaddr - l_dynaddr) & align) == 0) while the specific condition there was later relaxed by: [rfa] Fix detection of prelinked libraries on PPC http://sourceware.org/ml/gdb-patches/2007-07/msg00109.html http://sourceware.org/ml/gdb-cvs/2007-07/msg00055.html fc5294c8de7ee77ec3ed9e0ca2dff670d0e7789f -> ((l_addr & align) == ((l_dynaddr - dynaddr) & align)) No regressions on {x86_64,x86_64-m32,i686}-fedora12-linux-gnu. It has some mi* regressions in PIE mode (check//unix/-fPIE/-pie) due to the new message printed for PIE. If the message gets approved I will update the testcases. The current PIC message being printed "all the time" is: warning: .dynamic section for "/lib64/librt-2.11.1.so" is not at the expected address warning: difference appears to be caused by prelink, adjusting expectations The PIE message should be IMO printed iff te PIC message is printed (although the PIC message is printed only if the prelink state changes vs. PIE message is printed on each load of a PIE executable). I do not find the current PIC message too useful (moreover without any offset printed). Therefore I am open to removing both the PIC (and new PIE) messages when the offset is successfuly considered as valid. The patch also extends LM_ADDR_CHECK. This can be considered a separate patch part with possible independency of approval. The topic is the same so I have posted it together. Thanks, Jan 2010-02-01 Jan Kratochvil * solib-svr4.c (LM_ADDR_CHECK): Move variable align to a more inner block. New variable minpagesize, set it for ELF ABFDs. New comment on PPC-aware condition. Extend the condition using MINPAGESIZE. (svr4_exec_displacement): New variable retval. Sanity check it. --- a/gdb/solib-svr4.c +++ b/gdb/solib-svr4.c @@ -176,7 +176,7 @@ LM_ADDR_CHECK (struct so_list *so, bfd *abfd) if (so->lm_info->l_addr == (CORE_ADDR)-1) { struct bfd_section *dyninfo_sect; - CORE_ADDR l_addr, l_dynaddr, dynaddr, align = 0x1000; + CORE_ADDR l_addr, l_dynaddr, dynaddr; l_addr = LM_ADDR_FROM_LINK_MAP (so); @@ -193,6 +193,9 @@ LM_ADDR_CHECK (struct so_list *so, bfd *abfd) if (dynaddr + l_addr != l_dynaddr) { + CORE_ADDR align = 0x1000; + CORE_ADDR minpagesize = align; + if (bfd_get_flavour (abfd) == bfd_target_elf_flavour) { Elf_Internal_Ehdr *ehdr = elf_tdata (abfd)->elf_header; @@ -204,6 +207,8 @@ LM_ADDR_CHECK (struct so_list *so, bfd *abfd) for (i = 0; i < ehdr->e_phnum; i++) if (phdr[i].p_type == PT_LOAD && phdr[i].p_align > align) align = phdr[i].p_align; + + minpagesize = get_elf_backend_data (abfd)->minpagesize; } /* Turn it into a mask. */ @@ -217,8 +222,20 @@ LM_ADDR_CHECK (struct so_list *so, bfd *abfd) location, or anything, really. To avoid regressions, don't adjust the base offset in the latter case, although odds are that, if things really changed, debugging won't - quite work. */ - if ((l_addr & align) == ((l_dynaddr - dynaddr) & align)) + quite work. + + One could rather expect the condition + ((l_addr & align) == 0 && ((l_dynaddr - dynaddr) & align) == 0) + but the one below is relaxed for PPC. The PPC kernel supports + either 4k or 64k page sizes. To be prepared for 64k pages, + PPC ELF files are built using an alignment requirement of 64k. + However, when running on a kernel supporting 4k pages, the memory + mapping of the library may not actually happen on a 64k boundary! + + Check at least the MINPAGESIZE alignment still valid on PPC. */ + + if ((l_addr & (minpagesize - 1)) == 0 + && (l_addr & align) == ((l_dynaddr - dynaddr) & align)) { l_addr = l_dynaddr - dynaddr; @@ -1629,7 +1646,42 @@ svr4_exec_displacement (void) return 0; if (target_auxv_search (¤t_target, AT_ENTRY, &entry_point) == 1) - return entry_point - bfd_get_start_address (exec_bfd); + { + CORE_ADDR retval = entry_point - bfd_get_start_address (exec_bfd); + + /* If current executable is not PIE (Position Independent Executable) + suppress any messages. */ + if (retval == 0) + return 0; + + if (bfd_get_flavour (exec_bfd) == bfd_target_elf_flavour) + { + const struct elf_backend_data *elf = get_elf_backend_data (exec_bfd); + + /* Check of the alignment against max (p_align) of PT_LOAD segments + cannot be used here as in LM_ADDR_CHECK for PIC libraries as at + least amd64 PIE executables have 2MB p_align while Linux kernel + loads them with arbitrary 4KB displacement. As in this case there + is no LM_ADDR_FROM_LINK_MAP to verify the possible offset GDB has + to depend just on MINPAGESIZE. */ + + if ((retval & (elf->minpagesize - 1)) != 0) + { + warning (_("PIE (Position Independent Executable) displacement " + "%s is not aligned to the minimal page size %s " + "for \"%s\" (wrong executable or version mismatch?)"), + paddress (target_gdbarch, retval), + paddress (target_gdbarch, elf->minpagesize), + bfd_get_filename (exec_bfd)); + return 0; + } + } + + warning (_("Using PIE (Position Independent Executable) displacement %s " + "for \"%s\""), + paddress (target_gdbarch, retval), bfd_get_filename (exec_bfd)); + return retval; + } return svr4_static_exec_displacement (); }