* [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