From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22888 invoked by alias); 11 Oct 2003 23:07:24 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 22874 invoked from network); 11 Oct 2003 23:07:19 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 11 Oct 2003 23:07:19 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id AFB482B89; Sat, 11 Oct 2003 19:06:54 -0400 (EDT) Message-ID: <3F888D0E.4010001@redhat.com> Date: Sat, 11 Oct 2003 23:07: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: Mark Kettenis Cc: gdb@sources.redhat.com Subject: Re: [RFC] Core files and the architecture vector References: <200310112207.h9BM7WW0010332@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00188.txt.bz2 > When a 32-bit executable > running on FreeBSD/amd64 or GNU/Linux x86-64 dumps, it produces an > 64-bit ELF core file. I think that's a kernel bug. A 32 bit emulation environment should emulate things right down to the binary format of a core dump :-) However ... > The problem I'm having, is that we have no clean seperation between > initalizing and activating an architecture vector; it's all done from > gdbarch.c:gdbarch_update_p(). Looking at the function, it seems as if > it's not quite so easy to seperate the two because of the > per-architecture swapped data. I've hacked around this by > unconditionally setting the architecture from CORE_BFD, fetching the > core architecture vector from CURRENT_GDBARCH, and reset the > architecture from EXEC_BFD if we have one; refer to the attached code > to see what I mean. > > Is this kosher? Do folks agree with this approach? Is this kosher? No. Is there a better way? No. GDBARCH methods that give the appearance of returning an architecture (without affecting global state) vis: struct gdbarch *gdbarch_from_file (); are going to be needed (however, right now they would only allow us to fool ourselves into thinking we're safe :-). A method like: struct gdbarch *deprecated_select_gdbarch_hack (struct gdbarch *); method might also be useful? Andrew PS: This is only going to get worse - target <>- thread <>- frame will have an equally messy transition. PPS: Suggest more "rude" comments about how dangerous this is.