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




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
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]