From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19032 invoked by alias); 9 Oct 2003 00:45:56 -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 19024 invoked from network); 9 Oct 2003 00:45:55 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 9 Oct 2003 00:45:55 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id C50A8357B; Wed, 8 Oct 2003 17:45:54 -0700 (PDT) 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 h990jsN2012577; Wed, 8 Oct 2003 17:45:54 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id h990jsUS012573; Wed, 8 Oct 2003 17:45:54 -0700 Date: Thu, 09 Oct 2003 00:45:00 -0000 Message-Id: <200310090045.h990jsUS012573@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Elena Zannoni Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO In-Reply-To: Elena Zannoni's message of Wednesday, 8 October 2003 19:36:01 -0400 <16260.40801.147331.587525@localhost.redhat.com> X-Shopping-List: (1) Salubrious bruisers (2) Officious insects (3) Puerile swindlers (4) Sunburnt luscious compassion guilt X-SW-Source: 2003-10/txt/msg00280.txt.bz2 > If the AT_ENTRY value is correct for PIE, gdb will need it. Yes, it's correct in all cases. You can be sure of this because it's the only way the user entry point gets run by the dynamic linker, so if it were wrong, the programs wouldn't run. > You maybe are thinking that the tag is a parameter? If so the > return value will need to differ depending on what you are looking > for, and you will need a void* parameter (yuck!). I don't know what you are talking about here. bfd_vma is the only appropriate type for all of the values in question. > As I understood it, you will have a to_get_entry_point() and a > to_get_vsyscall_entry(), which then will query the target (via > to_query) for the auxv vector blocks and "parse" that. I have never suggested to_get_vsyscall_entry and don't anticipate wanting it. I proposed to_read_aux_vector, and we have been discussing using to_query to serve the same purpose with a different calling convention. For the vsyscall purpose, I don't think any other target_ops addition is useful or desireable. The code to check for AT_SYSINFO_EHDR will be in the linux-tdep function used for SOLIB_ADD or something like that (still being hashed out, but that seems like the place for it). to_get_entry_point seems like it might be a reasonable generic addition since it's a generic issue that could apply to any kind of executable and target in theory. However, it might be desireable to frame it in terms of a standard to_query request just so that remote.c and all the other target code need not be touched, only the backends that can use the auxv fetching and remote stubs that have a way to produce an answer. There is the contrary example of to_find_memory_regions, but that is notably wholly unsupported by the remote protocol (i.e. no stub has the option of implementing it even if it knows how). The choice here is an issue for gdb hackers, that I don't have any feelings about myself (just these observations).