From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27460 invoked by alias); 15 Jan 2014 11:42:34 -0000 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 Received: (qmail 27443 invoked by uid 89); 15 Jan 2014 11:42:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 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; Wed, 15 Jan 2014 11:42:32 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s0FBgUm5005269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 15 Jan 2014 06:42:30 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s0FBgTIe007971; Wed, 15 Jan 2014 06:42:30 -0500 Message-ID: <52D67425.9050904@redhat.com> Date: Wed, 15 Jan 2014 11:42:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tom Tromey CC: gdb-patches@sourceware.org Subject: Re: [PATCH 2/3] relocate the entry point addess when used References: <1389040247-2620-1-git-send-email-tromey@redhat.com> <1389040247-2620-3-git-send-email-tromey@redhat.com> <52CD5129.7090003@redhat.com> <8738kr1ug8.fsf@fleche.redhat.com> In-Reply-To: <8738kr1ug8.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-01/txt/msg00495.txt.bz2 On 01/13/2014 08:46 PM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > > Tom> I think the existing code here is wrong. It computes the entry point > Tom> address directly from the BFD, not applying any runtime offsets. > Tom> However, then objfile_relocate1 passes this address to find_pc_section > Tom> -- which does use the offsets . So, it seems to me that the current > Tom> code can only find the correct address by luck. > > Pedro> It's twisted, but I don't think it's luck. You can convince yourself > Pedro> it works by debugging a PIE, and trying a backtrace past main > Pedro> ("set backtrace past-main" will then trigger the code to stop the > Pedro> backtrace at the entry point), or doing "info files" (shows the entry). > > Well, what I don't understand is that most addresses in dwarf2read.c are > offset: > > baseaddr = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile)); > > ... however this is not done for the entry point, which comes directly > from the BFD: > > objfile->per_bfd->ei.entry_point = bfd_get_start_address (objfile->obfd); > > I suppose there is some other invariant ensuring that the entry point is > only computed when all the objfile offsets are zero. This part is not > obvious to me. I think it's just that the entry point is only really used for the main executable, and if that is loaded at some relocation offset, we'll always go through objfile_relocate (either PIE handling, or RSP qOffsets handling for embedded systems) after reading in symbols, while shared libraries are read in with the offsets already handy upfront. Even though init_entry_point_info seemingly computes the entry point for shared libraries, that's really still for the main executable: https://sourceware.org/ml/gdb-patches/2008-05/msg00112.html and is probably indeed wrong for real shared libraries not the main executable. I do think your patch makes things much clearer and sturdier. > > [...] > Pedro> This is assuming osect ends up NULL after iterating over all. > Pedro> It's violating the abstraction of the macro. And, actually, > Pedro> it's wrong, showing exactly why such assumptions are a bad idea: > > Sorry about that, I'll fix it up locally. Thanks. -- Pedro Alves