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