This is the mail archive of the gdb-patches@sourceware.org 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: [Core] [RFA/DWARF2] Handle nested subprograms in CU pc bound calculation


  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






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