From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17878 invoked by alias); 12 Jun 2003 22:25:10 -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 17799 invoked from network); 12 Jun 2003 22:25:09 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 12 Jun 2003 22:25:09 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C25652B63; Thu, 12 Jun 2003 18:25:01 -0400 (EDT) Message-ID: <3EE8FDBD.5000308@redhat.com> Date: Thu, 12 Jun 2003 22:25:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: [ppc64-linux] gdbarch hook to find true execution entry point References: <3EE72E0F.4010607@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00433.txt.bz2 > Andrew Cagney writes: > > >> > 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. >> > > >> I think this should be in BFD. Not just GDB but also the simulators >> are going to need this information. > > > Not sure I agree. The interesting information for process startup is > intrinsically ABI-specific; for PPC64 Linux it's the TOC and > environment pointers, but for another target it might be something > else. You need ABI-specific code on the consumer's side anyway, just > to know, for example, which registers everything goes in, so as long > as that's there anyway, why not let BFD stick to what it does best --- > interpreting object files? not forgettting architecture, disassembler, minimal symbols, ... > In general, the code in GDB supporting an ABI needs to be able to > provide its own code to interpret what comes out of BFD. This is just > one case that wasn't covered --- thus the gdbarch method. From my PS: > I think this should be in BFD. Not just GDB but also the simulators are going to need this information. > > PS: If BFD does this, ENTRY_POINT_ADDRESS can also, finally, be deleted. The above and CALL_DUMMY_ADDRESS are effecively doing the same thing - returning the entry-point address. If nothing else, some juggling will let them share a common architecture method and avoid this duplication. Anyway, I still think it's better to have it available in bfd (where the sim can use it). Andrew