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.

The new ChangeLog is:

2003-10-28  Jeff Johnston  <jjohnstn@redhat.com>
             David Mosberger  <davidm@hpl.hp.com>

	* ia64-tdep.c: Include <fcntl.h>, elf.h, and <sys/mman.h>.
	[HAVE_LIBUNWIND_IA64_H]: Include libunwind-frame.h and libunwind-ia64.h.
	(gdbarch_tdep): Add getunwind_table function pointer to struct.
	(ia64_rse_slot_num, ia64_rse_skip_regs): Ditto.
	(ia64_gdb2uw_regnum, ia64_uw2gdb_regnum): Ditto.
	(ia64_is_fpreg, ia64_access_reg): Ditto.
	(ia64_access_fpreg, ia64_access_mem): Ditto.
	(get_kernel_table): Ditto.
	(ia64_find_unwind_table): Ditto.
	(ia64_find_proc_info_x, ia64_put_unwind_info): Ditto.
	(ia64_get_dyn_info_list, ia64_libunwind_frame_this_id): Ditto.
	(ia64_libunwind_frame_prev_register): Ditto.
	(ia64_libunwind_frame_sniffer,
	(ia64_gdbarch_init)[HAVE_LIBUNWIND_IA64_H]: Add libunwind frame
	sniffer.  Set up getunwind_table function.  Register libunwind functions 
needed by generic libunwind frame code using
	libunwind_frame_set_descr().

Ok?  More comments?

-- Jeff J.


Kevin Buettner wrote:
> On Oct 24,  2:20pm, J. Johnston wrote:
> 
> 
>>Kevin Buettner wrote:
>>
>>
>>>>+#ifdef HAVE_LIBUNWIND_IA64_H
>>>>+
>>>>+# ifndef __NR_getunwind
>>>>+#  define __NR_getunwind	1215
>>>>+# endif
>>>
>>>Is this part still needed?
>>
>>Not if we include <sys/syscall.h>
> 
> 
> I would prefer to see <sys/syscall.h> included -- but not in
> ia64-tdep.c.  This include 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.
> 
> Also, apparently, there'll be some FreeBSD patches for IA-64 coming
> down the pike.  FreeBSD, if it chooses to use the libunwind library,
> will need to implement its own version of ia64_getunwind().
> 
> Hmm... thinking about this some more, I'd like to know why a syscall
> is required.  Is there anyway this functionality could be implemented
> in an OS independent fashion?
> 
> 
>>>>+static void *
>>>>+map_segment (bfd *bfd, Elf_Internal_Phdr *p_text, struct map_info *mi)
> 
> [...]
> 
> 
>>>For the above, why isn't bfd being employed to read the segment?
>>
>>Are you referring to using bfd_bread() if the mmap fails or do you mean 
>>something higher level?
> 
> 
> I hadn't given it much thought.  It looked odd to see file reading
> code in this patch.  It might be okay to use bfd_bread if the mmap
> fails, but I'd prefer to push as much of this problem (reading of
> files) as possible over to the bfd side.
> 
> Kevin
>