This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: ia64 portion of libunwind patch
- From: "J. Johnston" <jjohnstn at redhat dot com>
- To: davidm at hpl dot hp dot com
- Cc: Andrew Cagney <ac131313 at redhat dot com>,Kevin Buettner <kevinb at redhat dot com>, gdb-patches at sources dot redhat dot com,davidm at napali dot hpl dot hp dot com
- Date: Wed, 10 Dec 2003 15:58:37 -0500
- Subject: Re: RFA: ia64 portion of libunwind patch
- Organization: Red Hat Inc.
- References: <3FA2B71A.3080905@redhat.com> <3FA2CA1B.7000502@redhat.com> <16290.59502.799536.383397@napali.hpl.hp.com> <3FAC12D3.2070207@redhat.com> <16300.8192.489647.740612@napali.hpl.hp.com> <3FAC2454.2030009@redhat.com> <16300.9949.513264.716812@napali.hpl.hp.com> <3FAC2D03.8070607@redhat.com> <16300.12503.585501.180768@napali.hpl.hp.com> <3FAC33B3.2030403@redhat.com> <1031108001337.ZM18506@localhost.localdomain> <3FAC388A.10207@redhat.com> <16300.39298.323956.667764@napali.hpl.hp.com> <3FAD7F01.2050407@gnu.org> <16304.3297.662733.250523@napali.hpl.hp.com> <3FB0149C.1060908@redhat.com> <16323.61371.6654.950171@napali.hpl.hp.com> <16334.39106.297492.636397@napali.hpl.hp.com> <3FCFC9FD.4040106@redhat.com> <16335.54210.785826.438051@napali.hpl.hp.com>
David Mosberger wrote:
On Thu, 04 Dec 2003 18:57:49 -0500, "J. Johnston" <jjohnstn@redhat.com> said:
Jeff> A questions regarding the .so name issue you mentioned. We
Jeff> are already grabbing the function names from UNW_OBJ macro
Jeff> from the generic libunwind.h header. I think we could
Jeff> generate the libunwind.so name similarly using the UNW_TARGET.
Jeff> Any problems with this strategy? (any scenarios where this
Jeff> value doesn't match the extension used by the libunwind
Jeff> library?)
No, that sounds fine to me. The part that I don't understand is that
at the moment it seems that only one libunwind-$TARGET.so can be
loaded. With a multi-target-capable gdb, that would obviously not be
sufficient, as you'd want to load, say, libunwind-ia64.so.1 for ia64
and libunwind-x86.so.1 for x86. But it's mostly a theoretical issue
at this point.
Thanks,
--david
I have created the patch to use UNW_TARGET.
Yes, the current implementation doesn't support multiple gdb targets, but it is
set up to make such a task relatively straightforward in the future (i.e. simply
put the function handles off of the target vector and pass in the target name).
Kevin, ok to commit?
-- Jeff J.
2003-12-10 Jeff Johnston <jjohnstn@redhat.com>
* libunwind-frame.c: If LIBUNWIND_SO not defined, define it to be
libunwind_target_lib.
(libunwind_target_lib): New static char string.
Index: libunwind-frame.c
===================================================================
RCS file: /cvs/src/src/gdb/libunwind-frame.c,v
retrieving revision 1.1
diff -u -r1.1 libunwind-frame.c
--- libunwind-frame.c 14 Nov 2003 21:17:51 -0000 1.1
+++ libunwind-frame.c 10 Dec 2003 20:52:10 -0000
@@ -46,7 +46,7 @@
static struct gdbarch_data *libunwind_descr_handle;
#ifndef LIBUNWIND_SO
-#define LIBUNWIND_SO "libunwind.so"
+#define LIBUNWIND_SO libunwind_target_lib
#endif
/* Required function pointers from libunwind. */
@@ -83,6 +83,8 @@
static char *create_addr_space_name = STRINGIFY(UNW_OBJ(create_addr_space));
static char *search_unwind_table_name = STRINGIFY(UNW_OBJ(search_unwind_table));
static char *find_dyn_list_name = STRINGIFY(UNW_OBJ(find_dyn_list));
+
+static char *libunwind_target_lib = "libunwind-" STRINGIFY(UNW_TARGET) ".so";
static struct libunwind_descr *
libunwind_descr (struct gdbarch *gdbarch)