From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7950 invoked by alias); 22 Oct 2007 20:22:07 -0000 Received: (qmail 7942 invoked by uid 22791); 22 Oct 2007 20:22:07 -0000 X-Spam-Check-By: sourceware.org Received: from heller.inter.net.il (HELO heller.inter.net.il) (213.8.233.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 22 Oct 2007 20:22:02 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-163-251.inter.net.il [80.230.163.251]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id DXT40035 (AUTH halo1); Mon, 22 Oct 2007 22:21:25 +0200 (IST) Date: Mon, 22 Oct 2007 20:25:00 -0000 Message-Id: From: Eli Zaretskii To: Markus Deuling CC: gdb-patches@sourceware.org, uweigand@de.ibm.com In-reply-to: <471C3E2C.3010509@de.ibm.com> (message from Markus Deuling on Mon, 22 Oct 2007 08:07:40 +0200) Subject: Re: [rfc] [17/17] Get rid of current_gdbarch in go32-nat.c Reply-to: Eli Zaretskii References: <470DE4C1.9070509@de.ibm.com> <471C3E2C.3010509@de.ibm.com> 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: 2007-10/txt/msg00520.txt.bz2 > Date: Mon, 22 Oct 2007 08:07:40 +0200 > From: Markus Deuling > CC: gdb-patches@sourceware.org, uweigand@de.ibm.com > > > Sorry for asking this so late, but could you please explain the > > reason(s) why these changes are a good idea, i.e. what potential > > problem(s) are they trying to solve? If I tell you that the go32 > > (a.k.a. DJGPP) native build of GDB supports only a single > > architecture, would those reason(s) still hold? > > > > sorry for the late respone. I've been on vacation. > Please see here: http://sourceware.org/ml/gdb-patches/2007-10/msg00108.html Thanks for the pointer. Unfortunately, it does not answer my question above. Perhaps the earlier thread (to which it refers without stating a URL) does, in which case I'd like to read that earlier thread. > What I'll try to achieve is to get rid of the global variable current_gdbarch to have a real per-frame architecture. Yes, but why? It looks like getting rid of current_gdbarch is needed to support the situation where multiple architectures are supported in the same session (or maybe even in the same executable?). That is why I asked the second question above: the DJGPP native build of GDB supports only a single architecture, and will ever support only that single architecture. So the question is: is there any particular reason to get rid of current_gdbarch in go32-nat.c?