From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18690 invoked by alias); 25 Feb 2004 20:38:49 -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 18674 invoked from network); 25 Feb 2004 20:38:47 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 25 Feb 2004 20:38:47 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 2CD63357B; Wed, 25 Feb 2004 12:38:42 -0800 (PST) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.9/8.12.9) with ESMTP id i1PKcfOi005920; Wed, 25 Feb 2004 12:38:41 -0800 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id i1PKceR4005916; Wed, 25 Feb 2004 12:38:40 -0800 Date: Wed, 25 Feb 2004 20:38:00 -0000 Message-Id: <200402252038.i1PKceR4005916@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Daniel Jacobowitz Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [PATCH] auxv support In-Reply-To: Daniel Jacobowitz's message of Tuesday, 24 February 2004 23:03:09 -0500 <20040225040309.GA21742@nevyn.them.org> X-Shopping-List: (1) Nonsensical infestation lesions (2) Incompetent sumptuous ablution remainders (3) Cretaceous Bog sodium (4) Ignominious crosswords X-SW-Source: 2004-02/txt/msg00743.txt.bz2 > Here's the board file I use to run locally, gross hacks and all. I can't figure out where to put this file and how to tell runtest to use it. > > However, on a system that does not support getting the auxv data, it shows > > three failures. What is the right thing to do about this? The difficulty > > is that the error from `info auxv' does not distinguish an error/bug in > > reading the data from the target code not supporting auxv access or from > > the native system not supporting the access even though the gdb target code > > does (e.g. Linux < 2.6). > > Perhaps arrange to distinguish in the error message? This sounds like it should be easy, but it's really not. The target-config-never-supports case and error cases are both indicated by target_read_partial returning -1. No other details are made available by the target interfaces. Even if we addressed the case of there not being any code around that does it at all, there are still the kernel (or stub) doesn't support it vs miscellaneous error cases. The backend or gdbserver code can potentially distinguish, i.e. failing open with ENOENT vs other errors or errors on read after open. But that would require passing back the failure mode in some distinguished way, rather than just -1. Thanks, Roland