From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4915 invoked by alias); 1 Feb 2002 12:29:33 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 4817 invoked from network); 1 Feb 2002 12:29:30 -0000 Received: from unknown (HELO compc26.nc3a.nato.int) (195.169.112.86) by sources.redhat.com with SMTP; 1 Feb 2002 12:29:30 -0000 Received: from localhost.localdomain (localhost [127.0.0.1]) by compc26.nc3a.nato.int (Postfix) with ESMTP id CDC9D13F33; Fri, 1 Feb 2002 13:32:08 +0100 (CET) Mail-From: gpc-owner+M402@gnu.de Sun Oct 14 15:28:10 2001 Message-ID: <3BC720FC.90101@ujf-grenoble.fr> Date: Fri, 01 Feb 2002 04:29:00 -0000 From: levi@localhost.nc3a.nato.int User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: fr,it,en MIME-Version: 1.0 To: levi@localhost.nc3a.nato.int Cc: adam.oldham@marconi.com, gdb@sources.redhat.com, core@freepascal.org, gpc@gnu.de Subject: Re: GDB scope does not work quite right for Pascal References: <4.2.0.58.20011012170241.01770100@ics.u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by furon.ujf-grenoble. fr id f9CGvMF20216 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by goedel.fjf.gnu.de id PAA07367 X-Mailer: Perl5 Mail::Internet v1.42 X-SW-Source: 2002-02/txt/msg00002.txt.bz2 Message-ID: <20020201042900.LNxbwhxcji6KPdcRcXCdsz5iqrdh8TEyf7c_GEG294A@z> Pierre Muller wrote: > At 14:44 12/10/01 , vous avez écrit: > >> >Number: 222 >> >Category: gdb >> >Synopsis: GDB scope does not work quite right for Pascal >> >Confidential: no >> >Severity: non-critical >> >Priority: medium >> >Responsible: unassigned >> >State: open >> >Class: sw-bug >> >Submitter-Id: net >> >Arrival-Date: Fri Oct 12 05:48:01 PDT 2001 >> >Closed-Date: >> >Last-Modified: >> >Originator: Adam Oldham >> >Release: gdb 20010813 >> >Organization: >> >Environment: >> Mandrake 8.1, Kernel 2.4.8, glibc 2.2, Intel Platform >> >Description: >> Source is compiled with FPC (Free Pascal Compiler). This can happen >> with any source of pascal. and any pascal compiler: it happens also for gpc When you declare nested functions, gdb's >> scope does not allow the viewing of the variables that are from the >> parent function that should be within the scope. >> >How-To-Repeat: >> The simple program attached will produce the problem. When compiled >> and run, the correct output is displayed, but if you run GDB on it, >> and break on function test2 and print out int1 which is a global >> variable for the function test1, you receive: >> "No symbol "INT1" in current context." > > > There are several remarks to that bug report: > 1) I don't know at all how nested functions work in C > Are they allowed? AKAIK no, they are not allowed, and this is the root of the problem, since gdb is written mainly by/for C programmers. > Do they also use a paremt fram pushing method ? > If yes, can locals from the calling function be found in C? > Maybe someone from the gdb mailing list can answer that question. > If this is already implemented for C its probably easier to just take > the same method. > > 2) There is a solution, I implemented it in the IDE for Free Pascal > but it is rather complicated. > Let me try to explain this solution to everyone. > Nested functions in pascal get a hidden parameter that contains the > frame pointer (ebp value for i386 cpu) of the calling function. This > allows the > program to access correctly local variable of the function that called > the nested > function. This value is searched in the backtrace at the location where > the frame pointer are usually saved ( i.e. at offset 0 of the local ebp > value for i386) > If we find the corresponding frame (which is not always the first frame > above the current one) > then we can try if we find the unfound local symbol in that frame). > > To ease this search, I inserted a pseudo-parameter to the function > called > parent_ebp (in lower case, while normal Free Pascal symbols are uppercased) > that indicate the location of this parnt frame pointer. > > 3) As maintainer of the pascal language specific part of GDB, > I am of course willing to introduce this into the gdb sources, but I would > really like to get first some feedback from the gpc list. > Does gpc do anything about this calling frame hidden parameter ? > Could we agree to use the same method for both compiler > in order to get better support for Pascal ? Do'nt know, only Peter or Franck probably can tell. -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr