Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Pierre Muller" <muller@ics.u-strasbg.fr>
To: "'Daniël Mantione'" <daniel.mantione@freepascal.org>,
	"'FPC Core Developer List'" <core@freepascal.org>
Cc: <gpc@gnu.de>, <gdb-patches@sourceware.org>
Subject: RE: [Core] [RFA/DWARF2] Handle nested subprograms in CU pc bound  calculation
Date: Thu, 02 Oct 2008 09:07:00 -0000	[thread overview]
Message-ID: <00a101c9246e$22ebc8d0$68c35a70$@u-strasbg.fr> (raw)
In-Reply-To: <alpine.DEB.1.00.0810020831550.13206@idefix.wisa.be>

  Hi Daniel,


> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Daniël Mantione
> Envoyé : Thursday, October 02, 2008 8:43 AM
> À : FPC Core Developer List
> Cc : Pierre Muller; gpc@gnu.de; gdb-patches@sourceware.org
> Objet : Re: [Core] [RFA/DWARF2] Handle nested subprograms in CU pc
> bound calculation
> 
> 
> 
> Op Wed, 1 Oct 2008, schreef Joel Brobecker:
> 
> > The answer to the question above lies in the Pascal parser. But when
> > there are homonyms, how do you specify in your program exactly which
> > one you mean? And does GDB provide the same method for distinguishing
> > these homonyms?
> >
> > (need to relearn Pascal one of these days...)
> 
> Pascal has a stack based symbol resolving (we call it the symtablestack
> in
> the compiler). For example take for example the following program:
> 
> program my_program;
> 
> uses unit_a,unit_b,unit_c;
> 
> var a:integer;
> 
> procedure main_procedure;
> 
>    var a:integer;
> 
>    procedure sub_procedure;
> 
>    var a:integer;
> 
>    begin
>      a:=1;
>      main_procedure.a:=1;
>      my_program.a:=1;
>      unit_a.a:=1;
>      unit_b.a:=1;
>      unit_c.a:=1;
>    end;
> 
> begin
> end;

  Daniel, did you really try to compile this?
  Both Free Pascal 1.0.10 and 2.2.0 fail to compile
on the 'main_procedure.a:=1;' line.
 
> So each procedure context can redefine identifiers.
> 
> Inside sub_procedure, the symtablestack will look like:
> 
> unit_a
> unit_b
> unit_c
> my_program
> main_procedure
> sub_procedure

  The stack is correct, but the problem is that
if main_procedure would be a function, then
main_function would be usable inside sub_procedure 
either as a nested call by adding an explicit main_function()
even if the function has no parameters, or to
set the return value of main_function function.

  Thus main_function. is not allowed 
at least not for versions <= 2.2.0.
  Did that change in 2.2.2?

  

> When searching for a symbol, the compiler will search the symbol tables
> bottom to top, starting at sub_procedure, ending at unit_a, the first
> symbol found is used. GDB would need to implement the same behaviour in
> it's Pascal mode.

  The main current problem is that GDB knows nothing about
the used or loaded units ...
  In stabs, I believe that there is no information on that...
Does dwarf have something about this?

  Of course, we could try to demangle the assembler labels used 
to extract unit name, but I seem to remember that, at least for 
Free Pascal, that mangling scheme is version dependent, which 
will not simplify things :(

  I also vaguely remember that GPC did not, at least for a 
while, add anything to the procedure/function names
declared in the interface part of units, as in C language.
  This had the big drawback of preventing to have the 
same global function/procedure in two different units
that is normally allowed according to pascal syntax.
  Could someone from the GPC development team
tell us if this limitation is still in place or if it
has been lifted?


  Thanks for the answers,


Pierre Muller
Pascal language support maintainer for GDB






  reply	other threads:[~2008-10-02  9:07 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-30 15:28 Joel Brobecker
2008-09-30 15:43 ` Daniel Jacobowitz
2008-09-30 16:56   ` Joel Brobecker
2008-09-30 17:05     ` Daniel Jacobowitz
2008-09-30 15:43 ` Pierre Muller
2008-09-30 17:07   ` Joel Brobecker
2008-09-30 17:39     ` Daniel Jacobowitz
2008-10-01  1:16       ` Joel Brobecker
2008-10-01  7:43         ` Pierre Muller
2008-10-01  8:33           ` [Core] " Jonas Maebe
2008-10-01 16:40           ` Joel Brobecker
2008-10-01 21:56             ` [Core] " Jonas Maebe
2008-10-02  6:45             ` Daniël Mantione
2008-10-02  9:07               ` Pierre Muller [this message]
2008-10-02 10:36                 ` Daniël Mantione
2008-10-03  0:31                   ` Joel Brobecker
2008-09-30 16:58 ` Joel Brobecker

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='00a101c9246e$22ebc8d0$68c35a70$@u-strasbg.fr' \
    --to=muller@ics.u-strasbg.fr \
    --cc=core@freepascal.org \
    --cc=daniel.mantione@freepascal.org \
    --cc=gdb-patches@sourceware.org \
    --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