From: Mark Kettenis <kettenis@chello.nl>
To: ac131313@redhat.com, gdb-patches@sources.redhat.com
Subject: [PATCH/RFA] Re: [RFC] Core files and the architecture vector
Date: Fri, 24 Oct 2003 15:04:00 -0000 [thread overview]
Message-ID: <200310241504.h9OF4G6Q001663@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: <3F888D0E.4010001@redhat.com> (message from Andrew Cagney on Sat, 11 Oct 2003 19:06:54 -0400)
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
next parent reply other threads:[~2003-10-24 15:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200310112207.h9BM7WW0010332@elgar.kettenis.dyndns.org>
[not found] ` <3F888D0E.4010001@redhat.com>
2003-10-24 15:04 ` Mark Kettenis [this message]
2003-10-27 15:49 ` Andrew Cagney
2003-10-27 20:53 ` Mark Kettenis
2003-10-28 15:55 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200310241504.h9OF4G6Q001663@elgar.kettenis.dyndns.org \
--to=kettenis@chello.nl \
--cc=ac131313@redhat.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox