From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32307 invoked by alias); 24 Oct 2007 19:23:13 -0000 Received: (qmail 32299 invoked by uid 22791); 24 Oct 2007 19:23:12 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (213.8.233.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 24 Oct 2007 19:23:06 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-229-232-46.inter.net.il [84.229.232.46]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id JFA05141 (AUTH halo1); Wed, 24 Oct 2007 21:22:39 +0200 (IST) Date: Wed, 24 Oct 2007 19:24:00 -0000 Message-Id: From: Eli Zaretskii To: Daniel Jacobowitz CC: deuling@de.ibm.com, gdb-patches@sourceware.org, uweigand@de.ibm.com In-reply-to: <20071024114745.GA18617@caradoc.them.org> (message from Daniel Jacobowitz on Wed, 24 Oct 2007 07:47:45 -0400) 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> <471DCAAB.7080603@de.ibm.com> <20071023211528.GA5996@caradoc.them.org> <20071024114745.GA18617@caradoc.them.org> 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/msg00607.txt.bz2 > Date: Wed, 24 Oct 2007 07:47:45 -0400 > From: Daniel Jacobowitz > Cc: deuling@de.ibm.com, gdb-patches@sourceware.org, uweigand@de.ibm.com > > A gdbarch includes lots of information. Some examples: > > - What registers are available, including pseudo-registers and > emulated registers. E.g., if DJGPP supports running binaries > with and without MMX support available more than one gdbarch might > be needed. > > - The sizes of basic types. E.g., if some versions of DJGPP used > a 64-bit long double and other versions used an 80-bit long double. > This transition seems to happen on many platforms at least once. > > - Mapping of debug info numbers to register numbers. E.g., if two > compilers used different numbers this might be handled by setting > a different function pointer in the gdbarch depending on the loaded > binary. Thanks, I'm convinced. Btw, the above sounds like something that would be good to have in gdbint.texinfo, if you get my drift ;-)