This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB scope does not work quite right for Pascal


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]