-----Message d'origine----- De : Joel Brobecker [mailto:brobecker@adacore.com] Envoyé : Wednesday, October 01, 2008 3:16 AM À : Pierre Muller; gdb-patches@sourceware.org Objet : Re: [RFA/DWARF2] Handle nested subprograms in CU pc bound calculation
Actually, now that I think of it, a slightly cleaner approach would probably be to extend the language vector to add a flag set to non-zero for the languages that want nested-subprogram handling. The only slight issue is that the CU references the language enum, which means we need to go from that enum to the language_defn to
get access to the flag.
I think you should stick with a language test in the DWARF reader.
OK. Would the following kind of patch be what you have in mind? Or would you prefer that the function simply take a language, rather than a CU. Or actually no function at all?
2008-09-30 Joel Brobecker brobecker@adacore.com
* dwarf2read.c (dwarf2_handle_nested_subprograms_p): Newfunction. (add_partial_subprogram): Replace check of Ada language by call to dwarf2_handle_nested_subprograms_p. (dwarf2_get_subprogram_pc_bounds, load_partial_dies): Likewise.
This looks fine for me!
This is only just for comments, as there is still one question open: For Ada, we store the symbols for nested subprograms in the global context. This allows us to break on these functions even when these functions are not defined in the current context. Do we want to do the same with Pascal? Right now, I left this functionality out... In Ada, we have found it to be extremely convenient to not have to be inside the enclosing function before we can insert the breakpoint. When there are ambiguities (say two functions have a nested subprogram with the same name), the ambiguity can be resolved using the fully qualified name.
I believe that, at least with the Free Pascal compiler and stabs debugging format (which is the format I worked on), all nested subprograms where also in the global context and thus I would not mind to do the same for pascal language.
I must confess that I stopped working for the Free Pascal compiler more or less when the dwarf debugging format was added, and I almost don't know anything about that format... The only thing that I can tell, is that last time I checked Free Pascal (version 2.2.0 windows 32bit target) with -gw (dwarf debugging format) I still got lots of errors while trying to load the compiler inside gdb :(
I know even less about GNU pascal compiler, but as this compiler is base on the GNU multi-language compiler, I would except it to behave closer to GNU C++ or GNU Ada.
I must confess that I don't even know if the full specification would work for pascal in case the same name is used globally and as a nested procedure (I do know that you are allowed to reuse a name defined globally as a local procedure, function or variable inside a function, but I don't know if the (gdb) break GlobalFuntion.LocalFunction would work)
Feedback from both Free Pascal and GNU pascal developers would be useful here and more generally on pascal dwarf support.
Tested on x86-linux, no regression (but I don't have a Pascal compiler).
The pascal testsuite is ridiculously tiny (I only wrote a few very basic tests) and there is nothing about nested functions/procedures in it. So there is nothing to expect on this side.
By the way, it would probably be useful to repeat the tests with different debugging formats. How can this be done in your testsuite directory?
Pierre Muller Pascal language support maintainer for GDB