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: Andrew Cagney <ac131313 at redhat dot com>
- Cc: "J. Johnston" <jjohnstn at redhat dot com>, davidm at hpl dot hp dot com,gdb-patches at sources dot redhat dot com, Kevin Buettner <kevinb at redhat dot com>
- Date: Fri, 31 Oct 2003 14:55:42 -0800
- Subject: Re: RFA: ia64 portion of libunwind patch
- References: <3FA2B71A.3080905@redhat.com><3FA2CA1B.7000502@redhat.com>
- Reply-to: davidm at hpl dot hp dot com
>>>>> On Fri, 31 Oct 2003 15:46:19 -0500, Andrew Cagney <ac131313@redhat.com> said:
>> The way the libunwind interface works nowadays, the only
>> buffering that is strictly needed is for the unwind info of the
>> procedure being looked up (which usually has a size of the order
>> of tens of bytes). But this would require doing a binary search
>> on the unwind-table in the target space, which might be rather
>> slow (there is one 24-byte entry in this table per procedure).
>> Thus, it might be easier (and certainly faster) to buffer the
>> unwind table inside gdb.
Andrew> Given a PC, how is the table located? I see the change does
Andrew> roughly: pc -> section -> objfile -> BFD -> unwind segment
Andrew> -> paddr/size?
That's about right.
Andrew> (GDB appears to have a log2 (128k of unwind section / 24) =
Andrew> ~14) I'm guessing that the binary search involves about 14
Andrew> fetches and provided they are serviced from a cache they
Andrew> will be very efficient.
Yup.
--david