From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27936 invoked by alias); 24 Oct 2003 18:56:37 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 27897 invoked from network); 24 Oct 2003 18:56:35 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 24 Oct 2003 18:56:35 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h9OIuZM22636 for ; Fri, 24 Oct 2003 14:56:35 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h9OIuXr30069; Fri, 24 Oct 2003 14:56:33 -0400 Received: from localhost.localdomain (vpn50-2.rdu.redhat.com [172.16.50.2]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h9OIuVdg025991; Fri, 24 Oct 2003 14:56:31 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h9OIuPJ09828; Fri, 24 Oct 2003 11:56:25 -0700 Date: Fri, 24 Oct 2003 18:56:00 -0000 From: Kevin Buettner Message-Id: <1031024185625.ZM9827@localhost.localdomain> In-Reply-To: "J. Johnston" "Re: RFA: ia64 portion of libunwind patch" (Oct 24, 2:20pm) References: <3F986E31.8050201@redhat.com> <1031024175718.ZM3475@localhost.localdomain> <3F996D88.9060505@redhat.com> To: "J. Johnston" , Kevin Buettner Subject: Re: RFA: ia64 portion of libunwind patch Cc: Marcel Moolenaar , ac131313@redhat.com, gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00748.txt.bz2 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 I would prefer to see 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