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: David Mosberger <davidm at napali dot hpl dot hp dot com>
- To: "J. Johnston" <jjohnstn at redhat dot com>
- Cc: davidm at hpl dot hp dot com, 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: Thu, 4 Dec 2003 16:39:30 -0800
- Subject: Re: RFA: ia64 portion of libunwind patch
- 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>
- Reply-to: davidm at hpl dot hp dot com
>>>>> 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