From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14031 invoked by alias); 15 Sep 2008 21:14:49 -0000 Received: (qmail 14014 invoked by uid 22791); 15 Sep 2008 21:14:49 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 15 Sep 2008 21:14:10 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id D633F10CED; Mon, 15 Sep 2008 21:14:07 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id A498A10CEB; Mon, 15 Sep 2008 21:14:07 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KfLOY-00087R-Kv; Mon, 15 Sep 2008 17:14:06 -0400 Date: Mon, 15 Sep 2008 21:14:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: bauerman@br.ibm.com, gdb-patches@sourceware.org Subject: Re: [PATCH/RFC] auxv entries Message-ID: <20080915211406.GA30767@caradoc.them.org> Mail-Followup-To: Mark Kettenis , bauerman@br.ibm.com, gdb-patches@sourceware.org References: <200809142127.m8ELR9eX025288@brahms.sibelius.xs4all.nl> <1221438784.17278.18.camel@localhost.localdomain> <200809150920.m8F9KVTI023217@brahms.sibelius.xs4all.nl> <200809152022.m8FKMbbt017028@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809152022.m8FKMbbt017028@brahms.sibelius.xs4all.nl> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00341.txt.bz2 On Mon, Sep 15, 2008 at 10:22:37PM +0200, Mark Kettenis wrote: > Here is the promised diff. Tested on Linux on amd64 (which doesn't > say a lot since it is little-endian). > > ok? I think the layout of the aux vector is a strange combination of an architecture property and a target property. We can read it via gdbserver too; the remote protocol manual says it's just 'Access the target's "auxiliary vector"'. The comments on procfs_auxv_parse imply that it depends on the host GDB in native Solaris debugging. But on Linux it depends on the debuggee, not the debugger. Is there some way we can differentiate based on gdbarch or osabi? -- Daniel Jacobowitz CodeSourcery