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: gdb-patches at sources dot redhat dot com
- Cc: Andrew Cagney <ac131313 at redhat dot com>,Kevin Buettner <kevinb at redhat dot com>, davidm at hpl dot hp dot com
- Date: Fri, 31 Oct 2003 14:25:14 -0500
- Subject: Re: RFA: ia64 portion of libunwind patch
- Organization: Red Hat Inc.
David Mosberger has answered the questions below. I'd like to include him in
the discussion from now on.
-- Jeff J.
-------- Original Message --------
On Thu, 30 Oct 2003 14:18:20 -0500, "J. Johnston" <jjohnstn@redhat.com> said:
Andrew> Can you expand a little here on how this function interacts
Andrew> with libunwind?
It is used by libunwind to access the unwind info. This is read-only
data that part of the ELF image and (at least for ia64) is also mapped
into the target space.
Andrew> I can see that its reading in data, but is that data found
Andrew> in the target's space?
It could be found there.
Andrew> If it is then the info should be pulled direct from the
Andrew> target and the BFD/objfile should not be used. The relevant
Andrew> target stratum can then re-direct the request to a local
Andrew> file.
I agree, it sounds like this would be a much cleaner way of doing it.
Andrew> I'm also wondering if the unwind code (probably impossible I
Andrew> know) could use a callback to request the memory rather than
Andrew> require an entire buffer.
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.
--david