From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26216 invoked by alias); 23 Oct 2007 10:21:10 -0000 Received: (qmail 26208 invoked by uid 22791); 23 Oct 2007 10:21:09 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate8.de.ibm.com (HELO mtagate8.de.ibm.com) (195.212.29.157) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 23 Oct 2007 10:21:07 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate8.de.ibm.com (8.13.8/8.13.8) with ESMTP id l9NAL4XT270950 for ; Tue, 23 Oct 2007 10:21:04 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9NAL4EW2191500 for ; Tue, 23 Oct 2007 12:21:04 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9NAL3dC000816 for ; Tue, 23 Oct 2007 12:21:04 +0200 Received: from bbkeks.boeblingen.de.ibm.com (dyn-9-152-248-41.boeblingen.de.ibm.com [9.152.248.41]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l9NAL2dd000758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2007 12:21:03 +0200 Message-ID: <471DCAAB.7080603@de.ibm.com> Date: Tue, 23 Oct 2007 10:31:00 -0000 From: Markus Deuling User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Eli Zaretskii CC: gdb-patches@sourceware.org, uweigand@de.ibm.com Subject: Re: [rfc] [17/17] Get rid of current_gdbarch in go32-nat.c References: <470DE4C1.9070509@de.ibm.com> <471C3E2C.3010509@de.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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/msg00533.txt.bz2 H Eli, Eli Zaretskii schrieb: >> >>> 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? please see my explanation below. > 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. You're right. This is the original posting from august this year: http://sourceware.org/ml/gdb-patches/2007-08/msg00034.html > >> 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? current_gdbarch will disappear somewhen and GDB will work on a per-frame architecture base. There should be no need to have some global variables for keeping track of current architecture, etc anymore (which is for my opinion very fault-prone anyway). There is not only an advantage with our "combined binaries" which consist of two different architectures in one binary. At the end one should be able to build GDB with all (nearly all ?!?) targets enabled and then debug all kinds of supported binaries without the need to recompile or even restart it. This is a cool feature ;-) Whereas I cannot imagine a scenario where GDB debugs for example an x86 binary and a PowerPC binary in one session. Thats the reason to replace current_gdbarch piece by piece by appropriate other methods like get_frame_arch or get_regcache_arch or (what is still under discussion) via a gdbarch pointer in struct objfiles. I'm not familiar with the particularities of DJGPP but I hope I was able to answer your question. -- Markus Deuling GNU Toolchain for Linux on Cell BE deuling@de.ibm.com