From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2473 invoked by alias); 23 Aug 2002 10:50:27 -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 2462 invoked from network); 23 Aug 2002 10:50:24 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.250) by sources.redhat.com with SMTP; 23 Aug 2002 10:50:24 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.5/8.12.5) with ESMTP id g7NAoFUo000474; Fri, 23 Aug 2002 12:50:15 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.5/8.12.5) with ESMTP id g7NAoFCD011698; Fri, 23 Aug 2002 12:50:15 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.5/8.12.5/Submit) id g7NAoEuU011695; Fri, 23 Aug 2002 12:50:14 +0200 (CEST) Date: Fri, 23 Aug 2002 05:41:00 -0000 Message-Id: <200208231050.g7NAoEuU011695@elgar.kettenis.dyndns.org> From: Mark Kettenis To: ac131313@ges.redhat.com CC: ac131313@ges.redhat.com, gdb-patches@sources.redhat.com In-reply-to: <3D651E09.8070601@ges.redhat.com> (message from Andrew Cagney on Thu, 22 Aug 2002 13:23:21 -0400) Subject: Re: [patch/rfc,RFA:doco] STORE_RETURN_VALUE with regcache References: <3D618F65.3000108@ges.redhat.com> <86lm71e6g9.fsf@elgar.kettenis.dyndns.org> <3D62A021.9040700@ges.redhat.com> <3D651E09.8070601@ges.redhat.com> X-SW-Source: 2002-08/txt/msg00749.txt.bz2 Date: Thu, 22 Aug 2002 13:23:21 -0400 From: Andrew Cagney > My idea for fixing this is illustrated by the following patch, but > perhaps there is a more elegant way to do this? I've so far not come up with anything better. The attached gets around the problem by dropping the sanity check -- it is easier to apply. The lack of a function will be detected (internal-error) but when it is first called. thoughts? Not really. Catching gdbarch problems on startup is certainly preferable to running into problems later, but I think in this case it's not really a problem. We'll be removing the deprecated functions somewhere in the future, so the problem will go away eventually. So, go ahead! Mark