From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14575 invoked by alias); 26 Dec 2007 06:00:38 -0000 Received: (qmail 14565 invoked by uid 22791); 26 Dec 2007 06:00:38 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 26 Dec 2007 06:00:33 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 821642A9678; Wed, 26 Dec 2007 01:00:31 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IpwyxDOB3y1S; Wed, 26 Dec 2007 01:00:31 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 77D462A9652; Wed, 26 Dec 2007 01:00:30 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id D9AFAE7ACA; Wed, 26 Dec 2007 10:00:22 +0400 (RET) Date: Wed, 26 Dec 2007 11:04:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [RFC/RFA] Introduce new struct parse_context Message-ID: <20071226060022.GD28163@adacore.com> References: <20071217064213.GC9022@adacore.com> <20071221043608.GJ6154@adacore.com> <20071222062223.GT6154@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i 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/msg00412.txt.bz2 > > 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. Using an Ada program named foo: % gdb foo (gdb) b foo Breakpoint 1 at 0x1000278c: file foo.adb, line 4. (gdb) run Starting program: /kern.a/brobecke/head/ex/foo Error in re-setting breakpoint 1: Function "foo" not defined. Program exited normally. procedure "Foo" is the name of the main subprogram, the equivalent of "main" in C. The difference with C is that Ada entity names follow an encoding - for instance, in our case, the Ada mode in GDB understood that "foo" was the main subprogram, and that its real (aka "linkage") name is actually "_ada_foo". As soon as the program was started, the loader mapped the shared libraries, and that caused all breakpoints to be re-evaluated. This is done using the following sequence: breakpoint_re_set_one -> Set current_language global to breakpoint language -> Re-evaluation of the breakpoint location -> Reset current_language to intial value This works well most of the time, but not always. What happens sometimes is that the current_language gets unexpectedly switched up from under our feet as a side-effect of calling select_frame(). I have faced this type of problem in the past before, and we discussed the idea of having the language be a parameter of the parsing routine, but an easy workaround was also available and so the work-around was installed and the idea postponed. Unfortunately in this case, I turned the problem in everyway possible, and I couldn't find an easy work-around. I actually think that this is a fortunate thing, as it forces us to move forward in fixing the weakness in that part of the GDB technology. Later on, Ulrich also mentioned that the language was not the only parameter that influences the parsing, there is also the input_radix. The solution is to get rid of using the global current_language to parse any expression, but to pass it as a parameter of the parsing routine. Same for the input_radix. Because there will be more than one such parameters to pass, we decided to create a new structure that holds them all, and pass that structure to the parse routine. This is a simple change on paper, but will require large updates in the sources, because most callers of the various routines have also been assuming that the current_language should be used. So these routines should also be updated to take an extra parameter as the parse_context. This in turn means that the callers' callers also need to be updated, etc etc etc, until we reach the command routine. I hope this clarifies the problem we're trying to solve, and the designed escape. I am planning to start working on the code aspect this week, while things are quiet at the office, and will work on documentation with you in parallel. -- Joel