Re: RFA: ia64 portion of libunwind patch

["J. Johnston" <jjohnstn@redhat.com>]

Kevin Buettner wrote:
> 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.
>

Sorry, I understand now.

> 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...)
> 

The kernel unwind table is kmalloc'd.  The syscall makes a copy of it.
> 
>>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...)
>

Andrew has suggested I look at to_read_partial.

-- Jeff J.