From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27374 invoked by alias); 24 Oct 2003 15:04:29 -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 27362 invoked from network); 24 Oct 2003 15:04:25 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 24 Oct 2003 15:04:25 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id h9OF4G8q000286; Fri, 24 Oct 2003 17:04:16 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id h9OF4G5s001666; Fri, 24 Oct 2003 17:04:16 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id h9OF4G6Q001663; Fri, 24 Oct 2003 17:04:16 +0200 (CEST) Date: Fri, 24 Oct 2003 15:04:00 -0000 Message-Id: <200310241504.h9OF4G6Q001663@elgar.kettenis.dyndns.org> From: Mark Kettenis To: ac131313@redhat.com, gdb-patches@sources.redhat.com In-reply-to: <3F888D0E.4010001@redhat.com> (message from Andrew Cagney on Sat, 11 Oct 2003 19:06:54 -0400) Subject: [PATCH/RFA] Re: [RFC] Core files and the architecture vector References: <200310112207.h9BM7WW0010332@elgar.kettenis.dyndns.org> <3F888D0E.4010001@redhat.com> X-SW-Source: 2003-10/txt/msg00732.txt.bz2 Date: Sat, 11 Oct 2003 19:06:54 -0400 From: Andrew Cagney > The problem I'm having, is that we have no clean seperation between > initalizing and activating an architecture vector; it's all done from > gdbarch.c:gdbarch_update_p(). Looking at the function, it seems as if > it's not quite so easy to seperate the two because of the > per-architecture swapped data. I've hacked around this by > unconditionally setting the architecture from CORE_BFD, fetching the > core architecture vector from CURRENT_GDBARCH, and reset the > architecture from EXEC_BFD if we have one; refer to the attached code > to see what I mean. > > Is this kosher? Do folks agree with this approach? Is this kosher? No. Is there a better way? No. GDBARCH methods that give the appearance of returning an architecture (without affecting global state) vis: struct gdbarch *gdbarch_from_file (); are going to be needed (however, right now they would only allow us to fool ourselves into thinking we're safe :-). A method like: struct gdbarch *deprecated_select_gdbarch_hack (struct gdbarch *); method might also be useful? Certainly. I actually need such a method, since the way I solved things in my proposed patch doesn't really work for all architectures. I named the methods a little bit differently. Oh and the deperecated...hack is still static, since I'm not quite sure where it will be needed. Okay to check this in? Mark Index: ChangeLog from Mark Kettenis * arch-utils.c (deprecated_select_gdbarch_hack): New function. (gdbarch_from_bfd): New function. (set_gdbarch_from_file): Re-implement using gdbarch_from_bfd and deprecated_select_gdbarch_hack. Index: arch-utils.c =================================================================== RCS file: /cvs/src/src/gdb/arch-utils.c,v retrieving revision 1.98 diff -u -p -r1.98 arch-utils.c --- arch-utils.c 22 Oct 2003 23:54:10 -0000 1.98 +++ arch-utils.c 24 Oct 2003 14:57:13 -0000 @@ -496,17 +496,68 @@ set_architecture (char *ignore_args, int show_architecture (NULL, from_tty); } -/* Set the dynamic target-system-dependent parameters (architecture, - byte-order) using information found in the BFD */ +/* FIXME: kettenis/20031124: Of the functions that follow, only + gdbarch_from_bfd is supposed to survive. The others will + dissappear since in the future GDB will (hopefully) be truly + multi-arch. However, for now we're still stuck with the concept of + a single active architecture. */ -void -set_gdbarch_from_file (bfd *abfd) +/* Make GDBARCH the currently selected architecture. */ + +static void +deprecated_select_gdbarch_hack (struct gdbarch *gdbarch) { struct gdbarch_info info; + + /* FIXME: kettenis/20031024: The only way to select a specific + architecture is to clone its `struct gdbarch_info', and update + according to that copy. This is gross, but significant work will + need to be done before we can take a more sane approach. */ + gdbarch_info_init (&info); + info.bfd_arch_info = gdbarch_bfd_arch_info (gdbarch); + info.byte_order = gdbarch_byte_order (gdbarch); + info.osabi = gdbarch_osabi (gdbarch); + gdbarch_update_p (info); + gdb_assert (gdbarch == current_gdbarch); +} + +/* Return the architecture for ABFD. If no suitable architecture + could be find, return NULL. */ + +struct gdbarch * +gdbarch_from_bfd (bfd *abfd) +{ + struct gdbarch *old_gdbarch = current_gdbarch; + struct gdbarch *new_gdbarch; + struct gdbarch_info info; + + /* FIXME: kettenis/20031024: The only way to find the architecture + for a certain BFD is by doing an architecture update. This + activates the architecture, so we need to reactivate the old + architecture. This is gross, but significant work will need to + be done before we can take a more sane approach. */ gdbarch_info_init (&info); info.abfd = abfd; if (! gdbarch_update_p (info)) + return NULL; + + new_gdbarch = current_gdbarch; + deprecated_select_gdbarch_hack (old_gdbarch); + return new_gdbarch; +} + +/* Set the dynamic target-system-dependent parameters (architecture, + byte-order) using information found in the BFD */ + +void +set_gdbarch_from_file (bfd *abfd) +{ + struct gdbarch *gdbarch; + + gdbarch = gdbarch_from_bfd (abfd); + if (gdbarch == NULL) error ("Architecture of file not recognized.\n"); + deprecated_select_gdbarch_hack (gdbarch); } /* Initialize the current architecture. Update the ``set Index: arch-utils.h =================================================================== RCS file: /cvs/src/src/gdb/arch-utils.h,v retrieving revision 1.58 diff -u -p -r1.58 arch-utils.h --- arch-utils.h 22 Oct 2003 23:54:10 -0000 1.58 +++ arch-utils.h 24 Oct 2003 14:57:13 -0000 @@ -151,4 +151,9 @@ extern int legacy_register_sim_regno (in default values are not zero. */ extern void gdbarch_info_init (struct gdbarch_info *info); +/* Return the architecture for ABFD. If no suitable architecture + could be find, return NULL. */ + +extern struct gdbarch *gdbarch_from_bfd (bfd *abfd); + #endif