Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: levi@localhost.nc3a.nato.int
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
Date: Fri, 01 Feb 2002 04:29:00 -0000	[thread overview]
Message-ID: <3BC720FC.90101@ujf-grenoble.fr> (raw)
Message-ID: <20020201042900.LNxbwhxcji6KPdcRcXCdsz5iqrdh8TEyf7c_GEG294A@z> (raw)
In-Reply-To: <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




  parent reply	other threads:[~2002-02-01 12:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20011012124403.21432.qmail@sourceware.cygnus.com>
2002-02-01  4:29 ` levi
2001-10-12  8:29   ` Pierre Muller
2001-10-12  9:58   ` Maurice Lombardi [this message]
2002-02-01  4:29     ` levi
2001-10-12 10:16       ` Daniel Jacobowitz
2002-02-01  4:29       ` levi
2001-10-12 10:40         ` Andrew Cagney
2002-02-01  4:29     ` levi
     [not found] <A3E34B558F5CD211B4980008C7A4A99003883EC6@sparrow.gso.mcs.m arconi.com>
2002-02-01  4:29 ` levi
2001-10-12 16:38   ` Pierre Muller
2001-10-12 11:21 Oldham, Adam
2002-02-01  4:29 ` levi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3BC720FC.90101@ujf-grenoble.fr \
    --to=levi@localhost.nc3a.nato.int \
    --cc=adam.oldham@marconi.com \
    --cc=core@freepascal.org \
    --cc=gdb@sources.redhat.com \
    --cc=gpc@gnu.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox