Re: RFA: ia64 portion of libunwind patch

[Kevin Buettner <kevinb@redhat.com>]

On Oct 28,  8:28pm, Daniel Jacobowitz wrote:

> On Tue, Oct 28, 2003 at 06:53:36PM -0500, J. Johnston wrote:
> > I have addressed your comments below.  The bfd stuff (map_segment, 
> > map_info) has been replaced by a simple call to bfd_bread().  I have moved 
> > the getunwind syscall stuff into ia64-linux-tdep.c and I access it via the 
> > gdbarch_tdep structure.
> 
> Nothing which involves a syscall is acceptable in a tdep file.  That's
> what the t means - target support.
> 
> Move it to the -nat file.

Yes, I agree with Daniel.  Earlier, I had said:

    ... and the code for ia64_getunwind() will have to go in
    ia64-linux-nat.c.  Presumably, if a remote target wanted to use
    the unwind library, there'd need to be some remote protocol
    modifications.

I also asked the following questions:

    Hmm...  thinking about this some more, I'd like to know why a
    syscall is required.  Is there any way this functionality could be
    implemented in an OS independent fashion?

I'm guessing that there's kernel state that the unwinder needs to be
made aware of and that it won't be possible to implement ia64_getunwind()
in an OS independent manner.  (I'd like someone to verify this though...)

> I don't know how you should integrate it with the gdbarch tdep.

If my speculation above is correct, I don't think the gdbarch tdep
ought to be used for accessing ia64_getunwind().  This sort of smells
like something that belongs in the target vector.  (Since we need
different mechanisms for the remote and native cases.)  But, since
this functionality is highly ia64-centric, I'd really hate to pollute
the target vector with such a method.  The only approach that comes
to mind (at the moment) is something similar to the
native_find_global_pointer hook in ia64-tdep.c.  (AIX/rs6000 has
something similar.)  Note though that this kind of hook doesn't
help with the native / remote problem.

Again, it'd be really, *really*, REALLY nice if we could come up with
an OS independent way of determining the necessary information.  E.g.
Is there any way to do memory reads to obtain the necessary information?
(I'm guessing not, but it doesn't hurt to ask...)

Kevin