From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4825 invoked by alias); 24 Oct 2003 05:40:42 -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 4730 invoked from network); 24 Oct 2003 05:40:41 -0000 Received: from unknown (HELO ns1.xcllnt.net) (209.128.86.226) by sources.redhat.com with SMTP; 24 Oct 2003 05:40:41 -0000 Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h9O5eYbe061782; Thu, 23 Oct 2003 22:40:34 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10) with ESMTP id h9O5eXLd073422; Thu, 23 Oct 2003 22:40:33 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10/Submit) id h9O5eXm6073421; Thu, 23 Oct 2003 22:40:33 -0700 (PDT) (envelope-from marcel) Date: Fri, 24 Oct 2003 05:40:00 -0000 From: Marcel Moolenaar To: Kevin Buettner Cc: "J. Johnston" , gdb-patches@sources.redhat.com Subject: Re: RFA: ia64 tdep patch Message-ID: <20031024054033.GA73267@dhcp01.pn.xcllnt.net> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1031024043016.ZM4583@localhost.localdomain> User-Agent: Mutt/1.5.4i X-SW-Source: 2003-10/txt/msg00721.txt.bz2 On Thu, Oct 23, 2003 at 09:30:16PM -0700, Kevin Buettner wrote: > > > > I'm leaning towards changing gdb. I just need to underdstand better > > what I'm getting into. I have little experience with gdb... > > If you take a look at the Linux/ia64 implementation of ptrace(), > you'll see that some of this complexity has been moved into the > ptrace() implementation. ptrace() will get/set the user portion of > registers stored in the kernel's register backing store. Yes. The PEEK{DATA|TEXT} and POKE{DATA|TEXT} functions interpret addresses between [bspstore, bsp> differently. Besides hiding the fact that there are registers on the kernel stack that belong to the process it also has the drawback that it makes it impossible to actually read from the backing store between [bspstore, bsp>. Also, reading from and writing to user memory is common code in FreeBSD. I hate to make ia64 a special case only to hide some details that a ptrace(2) user can deal with without too much problems. > >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? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net