From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31683 invoked by alias); 31 Mar 2014 18:47:37 -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 31671 invoked by uid 89); 31 Mar 2014 18:47:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 31 Mar 2014 18:47:35 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2VIlVdA028850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Mar 2014 14:47:31 -0400 Received: from host2.jankratochvil.net (ovpn-116-76.ams2.redhat.com [10.36.116.76]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2VIlOku007054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 Mar 2014 14:47:29 -0400 Date: Mon, 31 Mar 2014 18:47:00 -0000 From: Jan Kratochvil To: Robert Jarzmik Cc: gdb@sourceware.org, robert.jarzmik@intel.com Subject: Re: Gdb, PIE and scan_dyntag(DT_DEBUG) Message-ID: <20140331184724.GA6038@host2.jankratochvil.net> References: <87bnwuuhzp.fsf@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87bnwuuhzp.fsf@free.fr> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00073.txt.bz2 On Tue, 25 Mar 2014 21:43:22 +0100, Robert Jarzmik wrote: > I have a problem with gdb not finding the shared library list when analyzing a > core dump of an ELF-X86-64 binary on Linux. The problem is it works for me. Tested on Fedora 20 x86_64 although I am not aware of any distro-specific stuff which could affect this functionality. It is also relevant to know prelink status but I have tested this functionality now even with unprelinked ld.so and libc.so: $ echo 'int main(void) { return *(volatile int *)0=0; }'|gcc -o segv -Wall -g -fPIE -pie -x c -;rm -f core.*;(ulimit -c unlimited;./segv);mv core.* segv.core;.../gdb -batch ./segv{,.core} -ex 'info sharedlibrary' [...] >From To Syms Read Shared Object Library 0x00007f7ceda53560 0x00007f7cedb94bb4 Yes /lib64/libc.so.6 0x00007f7ceddf3b10 0x00007f7cede0cc70 Yes /lib64/ld-linux-x86-64.so.2 > The trouble lies in the scan_dyntag(DT_DEBUG) called by elf_locate_base() for me > : > - it tries first target_ops=core_ops, and looks at non-displaced address of > .dynamic => failure => that's great > - it then tries target_ops=exec_ops, and looks at non-displaced address of > .dynamic => it succeeds, returning 0 => that's my problem It returns the proper displacement for me. exec_bfd gets relocated to its proper address during: #1 in objfile_relocate1 (objfile=0x602c00003680, new_offsets=0x7fffffffcec0) at objfiles.c:819 #2 in objfile_relocate (objfile=0x602c00003680, new_offsets=0x7fffffffcec0) at objfiles.c:843 #3 in svr4_relocate_main_executable () at solib-svr4.c:2882 #4 in svr4_solib_create_inferior_hook (from_tty=1) at solib-svr4.c:2926 #5 in solib_create_inferior_hook (from_tty=1) at solib.c:1200 #6 in post_create_inferior (target=0x3d9e9a0 , from_tty=1) at infcmd.c:442 #7 in core_open (filename=0x6006000138a0 "/home/jks", from_tty=1) at corelow.c:412 #8 in core_file_command (filename=0x7fffffffdd5d "./segv.core", from_tty=1) at corefile.c:81 You should check why svr4_exec_displacement() does not work in your case. > As the call succeeded, elf_locate_base() won't call scan_dyntag_auxv() > > I manually "forced" elf_locate_base() to call scan_dyntag_aux() and then all my > shared libraries appear. Yes but exec_bfd probably remains wrongly (=not) relocated. > why GDB is looking at the executable file .dynamic section before attempting > AUXV AT_BASE reading and memory read accordingly ? I do not know answer to this question now but it should work anyway. Jan