From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3072 invoked by alias); 13 Jun 2003 22:48:12 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 3037 invoked from network); 13 Jun 2003 22:48:11 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 13 Jun 2003 22:48:11 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h5DMmBH21201 for ; Fri, 13 Jun 2003 18:48:11 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5DMmBI25156 for ; Fri, 13 Jun 2003 18:48:11 -0400 Received: from localhost.localdomain (vpn50-55.rdu.redhat.com [172.16.50.55]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5DMmAe18501; Fri, 13 Jun 2003 18:48:11 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h5DMm5C07629; Fri, 13 Jun 2003 15:48:05 -0700 Date: Fri, 13 Jun 2003 22:48:00 -0000 From: Kevin Buettner Message-Id: <1030613224805.ZM7628@localhost.localdomain> In-Reply-To: Jim Blandy "Re: [ppc64-linux] gdbarch hook to find true execution entry point" (Jun 13, 5:32pm) References: <1030611231105.ZM27287@localhost.localdomain> To: Jim Blandy , Kevin Buettner Subject: Re: [ppc64-linux] gdbarch hook to find true execution entry point Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00483.txt.bz2 On Jun 13, 5:32pm, Jim Blandy wrote: > > What cases do you know of where calling bfd_get_start_address() is > > insufficient for finding the start address? I'm wondering if we > > need a gdbarch hook at all... > > The comment on the gdbarch.sh entry is supposed to explain why it's > necessary. I've expanded it a bit; is it clearer? Is there someplace > else I should put it? I probably missed the comment in your original patch. But what you wrote below looks good to me. > + # The actual instruction address at which ABFD would begin execution. > + # If ABFD is position-independent code, this address is not relocated; > + # it's the address at which execution would begin if the file were > + # loaded at its sections' vmas. > + # > + # On most architectures, this is simply bfd_get_start_address. But on > + # some (like 64-bit PPC), that points to a function descriptor, not an > + # instruction. The descriptor contains the actual entry point, and > + # other pointers needed to call the function. > + m:1::CORE_ADDR:bfd_entry_point:bfd *abfd:abfd:::generic_bfd_entry_point::0 > > Revised patch: > > 2003-06-11 Jim Blandy > > * gdbarch.sh (gdbarch_bfd_entry_point): New gdbarch method. > * arch-utils.c (generic_bfd_entry_point): New function. > * arch-utils.h (generic_bfd_entry_point): New declaration. > * gdbarch.c, gdbarch.h: Regenerated. > * solib-svr4.c (enable_break): Call it, instead of accessing > tmp_bfd->start_address directly. The solib-svr4.c change is okay with me. If you can get Andrew on board for the gdbarch changes, you're good to go. If you wind up implementing it in bfd, consider the solib change to be pre-approved. Kevin