From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1788 invoked by alias); 13 Jan 2014 20:46:19 -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 1774 invoked by uid 89); 13 Jan 2014 20:46:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 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, 13 Jan 2014 20:46:18 +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.14.4/8.14.4) with ESMTP id s0DKkHPj006354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 13 Jan 2014 15:46:17 -0500 Received: from barimba (ovpn-113-85.phx2.redhat.com [10.3.113.85]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s0DKkFBL012214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 13 Jan 2014 15:46:16 -0500 From: Tom Tromey To: Pedro Alves 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> Date: Mon, 13 Jan 2014 20:46:00 -0000 In-Reply-To: <52CD5129.7090003@redhat.com> (Pedro Alves's message of "Wed, 08 Jan 2014 13:22:49 +0000") Message-ID: <8738kr1ug8.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-01/txt/msg00379.txt.bz2 >>>>> "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. [...] 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. Tom