From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19051 invoked by alias); 15 Oct 2003 22:36:36 -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 19012 invoked from network); 15 Oct 2003 22:36:35 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 15 Oct 2003 22:36:35 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h9FMaYM26617 for ; Wed, 15 Oct 2003 18:36:34 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h9FMaRL28415; Wed, 15 Oct 2003 18:36:27 -0400 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h9FMaMJ09024; Wed, 15 Oct 2003 15:36:22 -0700 Message-ID: <3F8DCBE6.2030304@redhat.com> Date: Wed, 15 Oct 2003 22:36:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Elizabeth Chastain CC: ac131313@redhat.com, drow@mvista.com, ezannoni@redhat.com, gdb-patches@sources.redhat.com Subject: Re: RFA: Breakpoint infrastructure cleanups [0/8] References: <200310152213.h9FMDoCE028172@duracef.shout.net> In-Reply-To: <200310152213.h9FMDoCE028172@duracef.shout.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00517.txt.bz2 Michael Elizabeth Chastain wrote: > Michael Snyder writes: > >>Disassemble doesn't share the same syntax/semantics (decode_line_1); >>it has its own (I think?) -- but you're right, it's another command >>that takes a source location and "translates" it into a target >>location. > > > Yeah, we are in agreement here. My point is that there are > "source" locations (or whatever we want to call them) > and "target" locations (or whatever we want to call them). > We have to go back to the manual and the design stage and separate > all these out as separate concepts. OK, yes, agreed. > mec> (gdb) break *0x12345678 > ms> Now I don't follow you. "*0x12345678" isn't a source address. > ms> Is it? > > Ah, I am just saying that this is a user command that is oriented > towards "target" locations. So we can't just hide the concept > of "target" location from people, because that concept is already > present in the input language. Oh yes, of course. I don't mean to make the concept go away, just not to reveal it (if avoidable) when the user didn't ask. Just as the user can get the value of a variable without being told the variable's location -- but can still obtain the location if desired.