This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH/RFA] Re: [RFC] Core files and the architecture vector


   Date: Sat, 11 Oct 2003 19:06:54 -0400
   From: Andrew Cagney <ac131313@redhat.com>

   > 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  <kettenis@gnu.org>

	* 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]