This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: ia64 portion of libunwind patch


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]