From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 787 invoked by alias); 11 Nov 2003 15:48:06 -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 766 invoked from network); 11 Nov 2003 15:48:05 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 11 Nov 2003 15:48:05 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 615E82B8F; Tue, 11 Nov 2003 10:48:03 -0500 (EST) Message-ID: <3FB104B3.4010803@redhat.com> Date: Tue, 11 Nov 2003 15:48:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [wip] "info auxv" References: <3FB01C47.1020502@redhat.com> <20031110232139.GA20227@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-11/txt/msg00211.txt.bz2 > On Mon, Nov 10, 2003 at 06:16:23PM -0500, Andrew Cagney wrote: > >> This work-in-progress is more questions than answers. >> >> - Common code in "procfs.c" (tested) and "inftarg.c" >> It makes me wonder if the native inferior code should be re-arranged >> (has this come up before?). >> >> - The new files "auxv.[hc]" for parsing the file. >> Perhaphs it belongs in "procfs.c" but that gets me back to the first >> question - could the native inferior code be better structured? > > >> + switch (auxv.type) >> + { >> + case AT_NULL: >> + name = "End of vector"; >> + break; > > > Just a comment - as Roland said, Ref: http://sources.redhat.com/ml/gdb-patches/2003-10/msg00265.html > the values in "elf/common.h" are not > authoritive, and I don't even think they match Solaris? Should this be > in common code? Note the "????" in that output: 2000 ??? 0x9f4 Adding some sort of table is a todo item. I'm mainly worried about the "auxv.h" interface. For instance, how to provide a generic mechanism for fetching the entry-point address. Should "auxv.h" "define an OS independant set of enums and then map that onto the real numbers" (ala signals), or assume AT_ENTRY is constant across platforms (it actually is), or export an auxv_entry_point_address() and handle it all internally. Andrew