From: Pierre Muller <pierre@idefix.wisa.be>
To: "Oldham, Adam" <adam.oldham@marconi.com>,
"'Andrew Cagney'" <ac131313@cygnus.com>,
Daniel Jacobowitz <drow@mvista.com>
Cc: Maurice Lombardi <Maurice.Lombardi@ujf-grenoble.fr>,
gdb@sources.redhat.com, core@freepascal.org, gpc@gnu.de
Subject: Re: GDB scope does not work quite right for Pascal
Date: Fri, 12 Oct 2001 16:38:00 -0000 [thread overview]
Message-ID: <3.0.6.32.20011013014346.00b8dd40@idefix.wisa.be> (raw)
Message-ID: <20011012163800.FWgSpIthzne3nKyOUCMfb_tltdhPuUnBNFbShOsWRbE@z> (raw)
In-Reply-To: <A3E34B558F5CD211B4980008C7A4A99003883EC6@sparrow.gso.mcs.marconi.com>
At 14:18 12/10/01 -0400, Oldham, Adam wrote:
>Yes, I saw some of these threads, but nothing seemed to shed light on fixes
>for the scoping of this. It is good to know Ada does this as well so that
>maybe us Ada/Pascal people can get together and come up with a fix.
>
>I submitted code that demonstrates this with my bug report as well....
After some testing on both GNU C and GNU Pascal
I discovered that they both use the same method (on djgpp i386 target)
The calling frame pointer is passed to the nested function
in %ecx register and stored in -4(%ebp) in the function prologue
(which does not seem to be handled by skip_prologue function,
at least I didn't find anything in version 5.0 sources)
So the parent frame is placed in %ecx and
stored at offset -4 for GNU gcc or gpc
while it is pushed at offset 8 in Free Pascal code.
Using -gstabs+ I saw nothing generated to explain the meaning
of the %ecx parameter or the -4(%ebp) location.
Checking the prologue for this movl %ecx,offset(%ebp)
isn't probably sufficient to tell that we are in a nested proc...
Moreover this is processor specific, which is bad...
Stabs does give info about nesting in the stabs concerning the
Consider the following source:
int
test ()
{
int i = 1;
int j;
int local ()
{
return j+1;
};
j = i+1;
return local ();
}
int
main ()
{
printf(" result of test() is %d \n",test());
return 0;
}
This generates
.stabs "local:f(0,1),local,test",36,0,8,_local.3
The ,local,test indicates that local is nested inside test function.
But this is not enough as I don't know what happens for instance
if parameters are passed by registers...
Adding some debug info concerning the location of the
parent frame seems like a good idea, no ?
The Free Pascal approach to use a pseudo parameter called
'parent_ebp' seems to not be applicable to C as this would
be a valid C local variable name. Maybe something beginning
with a dollar like for the classes?
A similar problem exists for With statements in pascal.
Stabs defines even a specific stab number for this but this
is also unsupported for now.
next parent reply other threads:[~2001-10-12 16:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <A3E34B558F5CD211B4980008C7A4A99003883EC6@sparrow.gso.mcs.m arconi.com>
2002-02-01 4:29 ` levi [this message]
2001-10-12 16:38 ` Pierre Muller
[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
2002-02-01 4:29 ` levi
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
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=3.0.6.32.20011013014346.00b8dd40@idefix.wisa.be \
--to=pierre@idefix.wisa.be \
--cc=Maurice.Lombardi@ujf-grenoble.fr \
--cc=ac131313@cygnus.com \
--cc=adam.oldham@marconi.com \
--cc=core@freepascal.org \
--cc=drow@mvista.com \
--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