From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22267 invoked by alias); 31 Oct 2003 21:02:21 -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 22259 invoked from network); 31 Oct 2003 21:02:20 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 31 Oct 2003 21:02:20 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 2C1C2800412; Fri, 31 Oct 2003 16:02:19 -0500 (EST) Message-ID: <3FA2CDDB.9020703@redhat.com> Date: Fri, 31 Oct 2003 21:02:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com, Andrew Cagney , kevinb@redhat.com, davidm@hpl.hp.com Subject: Re: getunwind syscall References: <3FA2B7CA.5070200@redhat.com> <20031031200126.GA6723@nevyn.them.org> In-Reply-To: <20031031200126.GA6723@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00887.txt.bz2 Daniel Jacobowitz wrote: > On Fri, Oct 31, 2003 at 02:28:10PM -0500, J. Johnston wrote: > >>More info from David. > > > So the getunwind syscall returns data from the gate DSO? I was under > the impression it was some register backing store, or similar. In that > case Roland's patches for the same issue on x86 should be persued > instead of using the syscall. > > I don't believe that level of complexity is required. The syscall is only used if we fail the find_pc_section() call. Admittedly, Andrew has comments regarding replacing the find_pc_section() and accompanying bfd calls but that is an orthogonal issue. The x86 problem is different in my mind in that gdb doesn't have other recourse. Per comments, I have already changed the syscall in ia64-tdep.c to be a call to to_read_partial() which for linux ends up being mapped to the syscall within the ia64-linux-nat.c code (I haven't reposted a change yet as I want to also get the bfd stuff cleared up too). Failing all of this, the regular prologue examination methods still come into play and they are good enough to match libunwind for the gdb testsuite. -- Jeff J. >> >>-------- Original Message -------- >> >> >>>>>>>On Thu, 30 Oct 2003 14:20:13 -0500, "J. Johnston" >>>>>>> said: >> >> >> Nothing which involves a syscall is acceptable in a tdep file. >> >> That's what the t means - target support. >> >> Andrew> Is this information available via /proc? In a core file? >> >>The unwind info for the Linux kernel does get included in the >>core-dump (see Roland McGrath's work on this), but it is not available >>via /proc. Note that in the future, it won't be necessary to do a >>syscall. Instead, the kernel's unwind info will be available (to the >>running process) via dl_iterate_phdr(). I'm not sure though how this >>is supposed to be made accessible to programs such as gdb. >> >> --david >> >> > >