From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21068 invoked by alias); 15 May 2003 22:19:42 -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 21021 invoked from network); 15 May 2003 22:19:40 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.163.213.212) by sources.redhat.com with SMTP; 15 May 2003 22:19:40 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id AD87D354C; Thu, 15 May 2003 15:19:39 -0700 (PDT) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h4FMJc812037; Thu, 15 May 2003 15:19:38 -0700 Date: Thu, 15 May 2003 22:19:00 -0000 Message-Id: <200305152219.h4FMJc812037@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: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: [branch patch] core files as symfiles In-Reply-To: Elena Zannoni's message of Thursday, 15 May 2003 18:05:48 -0400 <16068.3900.457800.96561@localhost.redhat.com> X-Antipastobozoticataclysm: Bariumenemanilow X-SW-Source: 2003-05/txt/msg00264.txt.bz2 > Did we settle on this being the solution though? I think the > /proc/PID/auxv approach is a bit cleaner. We're talking about core files, so what you mean is an NT_AUXV note that would give the same information that /proc/PID/auxv would give for a live process. It remains to see whether the auxv approach will be accepted in the kernel. If that is done, then the corelow.c patch will be superfluous. I would like feedback on the implementation issue of this patch regardless. That is, if anyone sees any potential problems with adding the core bfd as a symfile (AFAIK it's a no-op to all cases but the new vsyscall issues), or with my specific code changes. Then I can address any nits, and verify that it is a safe change for gdb generically speaking. It is useful to know ASAP that this very simple change works acceptably, even if it turns out not to be necessary in the end. Using the core file's phdrs (which is what happens implicitly using this patch) has the benefit that it works now, i.e. with kernel support already merged into Linux 2.5, and with gdb code I have already finished enough to be in submittable form. If the generic auxv exporting support is not accepted in the kernel, then it is quite likely that some other way to know the vsyscall DSO address in a live process (e.g. via /proc/PID/maps) *will* be accepted, but no other core dump changes will go in and the existing phdrs will be the only method for the core dump case. Thanks, Roland