From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18651 invoked by alias); 30 Jan 2004 23:51: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 18628 invoked from network); 30 Jan 2004 23:51:06 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 30 Jan 2004 23:51:06 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 9898F357B; Fri, 30 Jan 2004 15:51:05 -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 i0UNp5Oi018581; Fri, 30 Jan 2004 15:51:05 -0800 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id i0UNp4hk018577; Fri, 30 Jan 2004 15:51:04 -0800 Date: Fri, 30 Jan 2004 23:51:00 -0000 Message-Id: <200401302351.i0UNp4hk018577@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Andrew Cagney Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [PATCH] auxv support In-Reply-To: Andrew Cagney's message of Friday, 30 January 2004 18:31:49 -0500 <401AE965.7020302@gnu.org> X-Shopping-List: (1) Sympathetic defiant ointment explosions (2) Mythical intravenous consoles (3) Reverent selector contributions (4) Dormant beef (5) Symbolical hand exhibitions X-SW-Source: 2004-01/txt/msg00770.txt.bz2 > The target vector update is fine. Sorry, I'm not entirely clear on how to read you. Should I commit the whole patch I posted now? (I'm not sure because you said "target vector update", and my patch includes to_xfer_partial target updates, to_make_corefile_notes target updates, and the `info auxv' user command.) > Would you be able to also knock up an "auxv.exp" test case? Sure! That is, I'd be happy to try. Is there an especially good existing test case to take as the canonical template for a test such as this? To be complete, a test should try a live process, try a real core file, and also try making a core file with gcore and then seeing that it matches the real process it was made from. Can you point me to an example of a test that elicits core dumps and examines them? > Something to run the command and, most notably, fail if "???" comes out > as the auxv entry name? That's not really a failure if it does. Some random kernel change that we have no reason to know or care about could cause that to be the case on some system. Do we want to make the gdb test suite complain whenever a new constant appears in nature that's not in our table? If all you intend is a sanity check that we're not reading garbage values, there are at least one or two AT_FOO tags that I think can be reliably expected to be seen on every system that has an auxv at all. So we could make sure those are there, or just make sure that at least some entries had names found. > Also, just file a bug reports that there isn't an equivalent MI auxv > command, and that those other commands need need documenting. I'll (or > someone) will need to come back to that. Will do. What about the remote protocol issue? Should I file a bug for that too? Conversely, I'd be happy to get that resolved right here and now, do the implementation work in remote.c and gdbserver. Thanks, Roland