From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10087 invoked by alias); 24 Oct 2003 07:08:32 -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 10078 invoked from network); 24 Oct 2003 07:08:31 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 24 Oct 2003 07:08:31 -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 h9O78VM13991 for ; Fri, 24 Oct 2003 03:08:31 -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 h9O78Ur17983; Fri, 24 Oct 2003 03:08:30 -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 h9O78ScY016453; Fri, 24 Oct 2003 03:08:28 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h9O78NZ05955; Fri, 24 Oct 2003 00:08:23 -0700 Date: Fri, 24 Oct 2003 07:08:00 -0000 From: Kevin Buettner Message-Id: <1031024070822.ZM5954@localhost.localdomain> In-Reply-To: Marcel Moolenaar "Re: RFA: ia64 tdep patch" (Oct 23, 10:40pm) References: <1031020201315.ZM20659@localhost.localdomain> <3F9459B6.5000909@redhat.com> <1031021222239.ZM26261@localhost.localdomain> <3F95BB43.1040703@redhat.com> <1031022193747.ZM31624@localhost.localdomain> <3F96EF3E.6070402@redhat.com> <20031022220258.GA10464@dhcp01.pn.xcllnt.net> <1031023210049.ZM1243@localhost.localdomain> <20031023232251.GA14660@dhcp01.pn.xcllnt.net> <1031024043016.ZM4583@localhost.localdomain> <20031024054033.GA73267@dhcp01.pn.xcllnt.net> To: Marcel Moolenaar , Kevin Buettner Subject: Re: RFA: ia64 tdep patch Cc: "J. Johnston" , gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00722.txt.bz2 On Oct 23, 10:40pm, Marcel Moolenaar wrote: > > >From what you said earlier, it sounds as though you'd already > > implemented something like this for FreeBSD... > > It still requires a special ptrace(2) call, making the distinction > between flushed and dirty stacked registers explicit to gdb. It also > doesn't address how to handle coredumps. Having the dirty registers > in some note section to avoid modifying the state of the process > represented by the core file is appealing to me. This too makes it > explicit that dirty registers are special WRT flushed registers. > > Again: by hiding the details, we obfuscate the true state of a > process. I can't stop thinking how that can make some class of > failures undebuggable (e.g. bugs related to NaT collections, near > stack overflow conditions, context switching bugs or maybe even > setjmp/longjmp bugs). > > Thoughts? I believe that the Linux/ia64 ptrace() code handles the problems with NaT collections. I'm not sure how it behaves with regard to the other conditions that you mention. (Though for things like context switching bugs, that's really not a user space problem.) IMO, this stuff is really arcane and there's going to be some hair somewhere. When I was doing the Linux/ia64 port for GDB, I was happy that a lot of the hair was in ptrace() so that GDB could be presented with a somewhat simplified interface. I also did the now defunct IA-64 GDB port for AIX and was pleased to find that the kernel authors seemed to handle these issues in much the same way as Linux. That said, I've been expecting some kind of debug interface for IA-64 to emerge which wants to use a model which is closer to the metal than what GDB currently expects. If that's the way you decide to go, I'm willing to review the necessary IA-64 related patches to make it happen. Kevin