From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18757 invoked by alias); 11 Oct 2003 16:17:07 -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 18746 invoked from network); 11 Oct 2003 16:17:06 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 11 Oct 2003 16:17:06 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 561042B89; Sat, 11 Oct 2003 12:17:00 -0400 (EDT) Message-ID: <3F882CFC.1020300@redhat.com> Date: Sat, 11 Oct 2003 16:17:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: [RFC] TARGET_ADJUST_BREAKPOINT_ADDRESS - patch 1 of 4 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> <1031011021736.ZM1457@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00404.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: right. > 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. or: if (the architecture can adjust things) adjust if (the architecture thinks the adjustment is weird) warning A follow-on change can refine it. Andrew