From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19484 invoked by alias); 29 Dec 2007 20:15:03 -0000 Received: (qmail 19473 invoked by uid 22791); 29 Dec 2007 20:15:01 -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; Sat, 29 Dec 2007 20:14:50 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-229-120-75.inter.net.il [84.229.120.75]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id EMM95810 (AUTH halo1); Sat, 29 Dec 2007 22:14:46 +0200 (IST) Date: Sat, 29 Dec 2007 22:44:00 -0000 Message-Id: From: Eli Zaretskii To: Joel Brobecker CC: gdb-patches@sourceware.org In-reply-to: <20071226060022.GD28163@adacore.com> (message from Joel Brobecker on Tue, 25 Dec 2007 22:00:22 -0800) Subject: Re: [RFC/RFA] Introduce new struct parse_context Reply-to: Eli Zaretskii References: <20071217064213.GC9022@adacore.com> <20071221043608.GJ6154@adacore.com> <20071222062223.GT6154@adacore.com> <20071226060022.GD28163@adacore.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-12/txt/msg00464.txt.bz2 > Date: Tue, 25 Dec 2007 22:00:22 -0800 > From: Joel Brobecker > Cc: gdb-patches@sourceware.org > > > > How about the following compromise: I describe again roughly what the > > > problem is and how I am going to address it. Then you can decide what > > > to add to gdbint, and where. > > > > Okay, let's try that. > > Great! Here is the problem - It shows up more often on mips-irix. Thanks for the detailed description. To document this, I'd go like this: Once upon a time, @value{GDBN} used a global variable called @code{current_language} to store the current source language. But this didn't always work, because @code{current_language} would sometimes get unexpectedly switched under our feet as a side-effect of calling functions such as @code{select_frame}. To resolve this difficulty, @value{GDBN} now passes the language as a parameter to routines that parse language-specific expressions. I would then describe the structure that will hold the language and the input radix, give a few examples of such routines, and explain when they are used by GDB. If there's some infrastructure involved here, beyond the above-mentioned structure, it should be documented as well. As to where to document this, I think the node "Language Support" is the right place. It already mentions `current_language', so it should be updated anyway if we are getting rid of that variable.