From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30863 invoked by alias); 24 Oct 2003 04:30:26 -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 30848 invoked from network); 24 Oct 2003 04:30:25 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 24 Oct 2003 04:30:25 -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 h9O4UPM19270 for ; Fri, 24 Oct 2003 00:30:25 -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 h9O4UOr17401; Fri, 24 Oct 2003 00:30:24 -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 h9O4UMcY005012; Fri, 24 Oct 2003 00:30:22 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h9O4UGJ04584; Thu, 23 Oct 2003 21:30:16 -0700 Date: Fri, 24 Oct 2003 04:30:00 -0000 From: Kevin Buettner Message-Id: <1031024043016.ZM4583@localhost.localdomain> In-Reply-To: Marcel Moolenaar "Re: RFA: ia64 tdep patch" (Oct 23, 4:22pm) References: <3F9049EF.8060209@redhat.com> <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> 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/msg00720.txt.bz2 On Oct 23, 4:22pm, Marcel Moolenaar wrote: > On Thu, Oct 23, 2003 at 02:00:49PM -0700, Kevin Buettner wrote: > > On Oct 22, 3:02pm, Marcel Moolenaar wrote: > > > > > > They are needed because r32 to r127 are not accessible via the PTRACE > > > > interface. They are accessed via the bsp. Without flagging them as > > > > pseudo-registers, the regcache code returns 0 for all these registers. > > > > > > It depends. For FreeBSD I added ptrace(2) functions to get and set > > > stacked registers that are on the kernel stack. The problem more > > > generally is that registers above bspstore (but below bsp) are > > > not accessable in memory. I think it's better for gdb to keep the > > > distinction between stacked registers on the backing store and > > > "dirty" stacked registers. The distinction avoids that gdb makes > > > assumptions that are only valid on Linux or even only for the native > > > code. > > > > Unfortunately, the assumptions that you mention are already in place. > > (And have been in place for quite some time). > > Yes, and it is one of the pickles I'm working on. Do I change FreeBSD > to match the assumption in gdb or do I change gdb to remove the > assumption? > > One technical reason for removing the assumption in gdb is that it > is not always possible to flush the dirty registers onto the user > backing store. It could fail when BSPSTORE is close to or at the > boundary of the register stack. This is a border case, but it would > be impossible to debug a process when it actually operates under > these conditions. Also, when flushing the dirty registers onto the > user backing store, we change the state of the process, which may > hide the problem and interfere with debugging. It's mostly academic, > but still a fundamental "flaw" in debugging on ia64. > > A technical reason for changing FreeBSD is that it avoids changing > gdb and keeps access to the stacked registers uniform. However, even > though debugging is not performance critical, moving the complexity > into the debugger may avoid unnecessary and unconditional copying > from the kernel stack to the user stack and gives gdb (or any other > program that needs this) control over it... > > 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. >From what you said earlier, it sounds as though you'd already implemented something like this for FreeBSD... > > > BTW: I have partial support for FreeBSD/ia64. I'll send patches as > > > soon as I feel that the backtrace is reliable enough. > > > > Patches will most certainly be welcome. Do you have an FSF copyright > > assignment for GDB yet? If not, you might want to start working on > > the paperwork now... > > I do not have such assignment, but it's in the pipeline. Cool. Kevin