From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26998 invoked by alias); 11 Oct 2003 02:17:45 -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 26991 invoked from network); 11 Oct 2003 02:17:44 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 11 Oct 2003 02:17:44 -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 h9B2HiM13358 for ; Fri, 10 Oct 2003 22:17:44 -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 h9B2Hhc08578; Fri, 10 Oct 2003 22:17:43 -0400 Received: from localhost.localdomain (vpn50-39.rdu.redhat.com [172.16.50.39]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h9B2Hg95002150; Fri, 10 Oct 2003 22:17:42 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h9B2Hae01458; Fri, 10 Oct 2003 19:17:36 -0700 Date: Sat, 11 Oct 2003 02:17:00 -0000 From: Kevin Buettner Message-Id: <1031011021736.ZM1457@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: [RFC] TARGET_ADJUST_BREAKPOINT_ADDRESS - patch 1 of 4" (Oct 8, 2:26pm) References: <1031004002813.ZM24546@localhost.localdomain> <200310061249.h96CnP6f000466@elgar.kettenis.dyndns.org> <1031006153657.ZM11197@localhost.localdomain> <200310062109.h96L9Waq000481@elgar.kettenis.dyndns.org> <3F8456E8.6090005@redhat.com> To: Andrew Cagney , Mark Kettenis , kevinb@redhat.com Subject: Re: [RFC] TARGET_ADJUST_BREAKPOINT_ADDRESS - patch 1 of 4 Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00392.txt.bz2 On Oct 8, 2:26pm, Andrew Cagney wrote: > I also wonder if PPC64 GDB could use this to do the descriptor -> > function address transformation that I described in: > http://sources.redhat.com/ml/gdb-patches/2003-09/msg00415.html I suppose it could, although that's definitely not the (well, my) intended purpose of ADJUST_BREAKPOINT_ADDRESS. If we do wind up using it for this purpose, we'll want to disable the warning messages. It makes no sense to have a breakpoint on the descriptor, so when used in this way, it'd definitely be the case that gdb is just doing the "right thing". It'd be easy enough to add an argument to the method which passes indicating the kind of adjustment. Off hand, I think a tri-state value makes sense: 1) the adjustment can potentially alter expected behavior making user warnings manditory. E.g, FR-V architecture constraints. 2) benign, the breakpoint's location has been moved slightly, but there should be no change in expected behavior. Perhaps an informational message could be displayed for this state. E.g. - maybe - that old v850 problem that Gary Thomas once told us about in which he had to sometimes place breakpoints that were larger than the smallest instruction. 3) the adjustment was necessary because to place a breakpoint on the original address is wrong. E.g, function descriptors - it makes no sense to place a breakpoint on the function descriptor, but it does make sense to place a breakpoint on the code address that the descriptor points to. Kevin