From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11368 invoked by alias); 16 Aug 2004 18:59:35 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 11358 invoked from network); 16 Aug 2004 18:59:34 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 16 Aug 2004 18:59:34 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7GIxTe3022837 for ; Mon, 16 Aug 2004 14:59:34 -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 i7GIxTa11155; Mon, 16 Aug 2004 14:59:29 -0400 Received: from localhost.localdomain (vpn50-19.rdu.redhat.com [172.16.50.19]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i7GIxSEE009216; Mon, 16 Aug 2004 14:59:29 -0400 Received: from saguaro (saguaro.lan [192.168.64.2]) by localhost.localdomain (8.12.11/8.12.10) with SMTP id i7GIxNEh009351; Mon, 16 Aug 2004 11:59:23 -0700 Date: Mon, 16 Aug 2004 18:59:00 -0000 From: Kevin Buettner To: Mark Kettenis Cc: gdb@sources.redhat.com Subject: Re: non-decr_pc_after_break i386 targets Message-Id: <20040816115923.31ccb77d@saguaro> In-Reply-To: <200408141934.i7EJY4mc001084@elgar.kettenis.dyndns.org> References: <200408141934.i7EJY4mc001084@elgar.kettenis.dyndns.org> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00220.txt.bz2 On Sat, 14 Aug 2004 21:34:04 +0200 (CEST) Mark Kettenis wrote: > However, this also reveals a flaw in the way we handle > decr_pc_after_break. Currently it's part of the architecture vector, > which essentially means that we consider it part of the ISA. However, > the above shows that it also depends on the target interface. So it > seems we should make it possible for the target vector to override the > default set by the architecture vector. > > To people agree with this analysis? Yes, I agree. Kevin