Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [PATCH/RFA] Re: [RFC] Core files and the architecture vector
       [not found] ` <3F888D0E.4010001@redhat.com>
@ 2003-10-24 15:04   ` Mark Kettenis
  2003-10-27 15:49     ` Andrew Cagney
  0 siblings, 1 reply; 4+ messages in thread
From: Mark Kettenis @ 2003-10-24 15:04 UTC (permalink / raw)
  To: ac131313, gdb-patches

   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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH/RFA] Re: [RFC] Core files and the architecture vector
  2003-10-24 15:04   ` [PATCH/RFA] Re: [RFC] Core files and the architecture vector Mark Kettenis
@ 2003-10-27 15:49     ` Andrew Cagney
  2003-10-27 20:53       ` Mark Kettenis
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2003-10-27 15:49 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: gdb-patches

> 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.
> 

Like it.  Yep.

BTW, while you're there can you tweak:

      error ("Architecture of file not recognized.\n");

to something like this:

   error ("Architecture %s of file not recognized",
          bfd_get_arch_info(bfd)->printable_name);

Andrew



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH/RFA] Re: [RFC] Core files and the architecture vector
  2003-10-27 15:49     ` Andrew Cagney
@ 2003-10-27 20:53       ` Mark Kettenis
  2003-10-28 15:55         ` Andrew Cagney
  0 siblings, 1 reply; 4+ messages in thread
From: Mark Kettenis @ 2003-10-27 20:53 UTC (permalink / raw)
  To: ac131313; +Cc: gdb-patches

   Date: Mon, 27 Oct 2003 10:49:19 -0500
   From: Andrew Cagney <ac131313@redhat.com>

   Like it.  Yep.

Thanks, I checked it in, with a ChangeLog that also mentions the
change to arch-utils.h:

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.
	* arch-utils.h (gdbarch_from_bfd): New prototype.

   BTW, while you're there can you tweak:

	 error ("Architecture of file not recognized.\n");

   to something like this:

      error ("Architecture %s of file not recognized",
	     bfd_get_arch_info(bfd)->printable_name);

Hmm, that would seem strange to me:

   Architecture sparc:v8plus of file not recognized

Quite contradictory isn't it.  By printing the name GDB implies that
it is somehow recognizing the architecture.  So I left this out for
now.  Perhaps we can change the string to something that doesn't let
GDB make a fool out of itself?

Mark


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH/RFA] Re: [RFC] Core files and the architecture vector
  2003-10-27 20:53       ` Mark Kettenis
@ 2003-10-28 15:55         ` Andrew Cagney
  0 siblings, 0 replies; 4+ messages in thread
From: Andrew Cagney @ 2003-10-28 15:55 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: gdb-patches

>      bfd_get_arch_info(bfd)->printable_name);
> 
> Hmm, that would seem strange to me:
> 
>    Architecture sparc:v8plus of file not recognized
> 
> Quite contradictory isn't it.  By printing the name GDB implies that
> it is somehow recognizing the architecture.  So I left this out for
> now.  Perhaps we can change the string to something that doesn't let
> GDB make a fool out of itself?

Hmm, true.  "Architecture ... not supported"?  'The file's architecture 
(%s) is not supported"?  However, which ever.

Andrew



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-10-28 15:55 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <200310112207.h9BM7WW0010332@elgar.kettenis.dyndns.org>
     [not found] ` <3F888D0E.4010001@redhat.com>
2003-10-24 15:04   ` [PATCH/RFA] Re: [RFC] Core files and the architecture vector Mark Kettenis
2003-10-27 15:49     ` Andrew Cagney
2003-10-27 20:53       ` Mark Kettenis
2003-10-28 15:55         ` Andrew Cagney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox