Re: [Core] [RFA/DWARF2] Handle nested subprograms in CU pc bound calculation

["Daniël Mantione" <daniel.mantione@freepascal.org>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2991 bytes --]



Op Thu, 2 Oct 2008, schreef Pierre Muller:

>  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.

No, I didn't try to compile this.

>> 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.

Correct.

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

No, if this identifier is hidden in a local symtable as function result,
you have to use my_program.main_function.

>> 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 ...

I don't think it needs to. unit_a, unit_b and unit_c are valid Pascal 
identifiers inside the symbol table of my_program. It should be possible 
to generate debug information for these identifiers.

If GDB can handle sub_procedure as member of main_procedure, it should be 
able to handle "a" as member of unit_a, this is the same situation, I 
think?

>  In stabs, I believe that there is no information on that...
> Does dwarf have something about this?

Stabs is too limited for this. Dwarf could handle the full Pascal 
language, but it needs to be implemented in both debugger and compiler.

>  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 :(

Demangling should not be done at all, since the choice of the mangled name 
is at the discretion of the compiler. The ppu contains the correct mangled 
name for a certain procedure, but it is not guaranteed that you can go the 
other way. If the mangled name becomes too long (imagine a procedure with 
100 parameters), the compiler starts using CRC checksums as mangled name, 
you can never parse this.

All information the compiler has available is inside the ppu and the debug 
information is generated from it. We should simply place anything GDB 
needs into the debug information.

>  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 is correct, but making GDB support it correctly should have no 
negative impacts for GPC.

Daniël