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

["Pierre Muller" <muller at ics dot u-strasbg dot fr>]

> -----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): New
> function.
>         (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