From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23102 invoked by alias); 25 Jul 2009 09:56:57 -0000 Received: (qmail 23093 invoked by uid 22791); 25 Jul 2009 09:56:56 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 25 Jul 2009 09:56:49 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id n6P9uIPH020845; Sat, 25 Jul 2009 11:56:18 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id n6P9uHM2020162; Sat, 25 Jul 2009 11:56:17 +0200 (CEST) Date: Sat, 25 Jul 2009 09:56:00 -0000 Message-Id: <200907250956.n6P9uHM2020162@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: thiago.bauermann@gmail.com CC: ppluzhnikov@google.com, gdb@sourceware.org, brobecker@adacore.com In-reply-to: <200907242312.42358.thiago.bauermann@gmail.com> (message from Thiago Jung Bauermann on Fri, 24 Jul 2009 23:12:41 -0300) Subject: Re: [7.0] PR/9723: gdb breakpoints silently fail on PIE binaries References: <200907192257.08197.thiago.bauermann@gmail.com> <8ac60eac0907192113s54f996a7m2fac203e07687272@mail.gmail.com> <200907242312.42358.thiago.bauermann@gmail.com> 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 X-SW-Source: 2009-07/txt/msg00200.txt.bz2 > From: Thiago Jung Bauermann > Date: Fri, 24 Jul 2009 23:12:41 -0300 > > Em Segunda-feira 20 Julho 2009 01:13:00 Paul Pluzhnikov escreveu: > > On Sun, Jul 19, 2009 at 6:57 PM, Thiago Jung > > > > Bauermann wrote: > > > All this to say: can somebody save me some research time and tell in high > > > level how can I recognize from looking at an ELF file that I'm dealing > > > with a PIE binary (NOT a PIC library, of course)? Something like "see if > > > the frob bit in the bozo section is set") is enough, I can go from there. > > > > Elf*_Ehdr.e_type == ET_DYN for the main executable? > > > > Elf*_Phdr.p_vaddr == 0 for the first PT_LOAD segment? > > [This one is only true for non-prelinked -pie executable.] > > Great, thanks for the tip. Since nobody jumped into discussion, I assume any > of those ways will work and have no known side-effect or false > positive/negative. We'll see. :-) Well, I'm not sure the second method is something you can rely on. I think Elf*_Phdr.p_vaddr can be 0 for non-PIC executables as well on some architectures. > Now I have this issue, I'd like to ask people's opinion about it: by > design (or defect?) the BFD library is a PITA to access the program > header. I feel very tempted to use elf32.h and elf64.h directly in > order to check that field. My only worry is that a cross-debugging > session with a win32 gdb and a linux remote target would not be > possible, unless windows includes such sysv elf headers too (perhaps > it does?). > > Do you have an opinion? Which elf32.h and elf64.h. I don't think those are standardized headers in any way. Defenitely no files with those names under /usr/include on OpenBSD. Heck, even my Linux workstation at work doesn't have any files named like that. There is "elf/common.h" in the src tree though. Anyway, if the BFD library doesn't provide some functionality you need, I think the best thing to do would be to add it there. There seems to be an Elf_Internal_Phdr pointer in struct elf_obj_tdata, so perhaps the only thing you need to add is a macro like elf_elfheader() to access it.