This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB scope does not work quite right for Pascal
- From: levi at localhost dot nc3a dot nato dot int
- To: levi at localhost dot nc3a dot nato dot int
- Cc: adam dot oldham at marconi dot com, gdb at sources dot redhat dot com,core at freepascal dot org, gpc at gnu dot de
- Date: Fri, 12 Oct 2001 18:57:32 +0200
- Subject: Re: GDB scope does not work quite right for Pascal
- Mail-from: gpc-owner+M402@gnu.de Sun Oct 14 15:28:10 2001
- References: <4.2.0.58.20011012170241.01770100@ics.u-strasbg.fr>
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