From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6190 invoked by alias); 31 Jan 2004 00:11:30 -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 6182 invoked from network); 31 Jan 2004 00:11:29 -0000 Received: from unknown (HELO localhost.redhat.com) (66.187.230.200) by sources.redhat.com with SMTP; 31 Jan 2004 00:11:29 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id F257E2B92; Fri, 30 Jan 2004 19:08:01 -0500 (EST) Message-ID: <401AF1E1.7040908@gnu.org> Date: Sat, 31 Jan 2004 00:11:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: Roland McGrath Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [PATCH] auxv support References: <200401302351.i0UNp4hk018577@magilla.sf.frob.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg00771.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? I'd start with corefile.exp, and then delete. Alternatively: http://sources.redhat.com/ml/gdb-patches/2004-01/msg00610.html where I've parked my bigcore.exp test - it compares the output from the core file with that of the running program (but note, this will have PIE have to be re-aranged for pie). >> 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? Yes, it's a bug - GDB should correctly display the name of all auxv entries for the system it is running on (if we don't do this, no one will ever notice, and the auxv table will never be updated ;-). > 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. If you can do this wow. Look at the >> 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 >