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

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

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 2575 bytes --]

Hello,

We just recently encountered a situation where GDB was emitting the following
warning:

| (gdb) b f1
| warning: (Internal error: pc 0x80495ce in read in psymtab, but not in symtab.)
| warning: (Internal error: pc 0x80495d1 in read in psymtab, but not in symtab.)
| warning: (Internal error: pc 0x80495d1 in read in psymtab, but not in symtab.)
| warning: (Internal error: pc 0x80495d1 in read in psymtab, but not in symtab.)
| Breakpoint 1 at 0x80495d1: file gen1.adb, line 3.



This happened after compiling the CU with -ffunction-sections, and
is related to the fact that f1 is a nested subprogram.  The code looks
like this:

    procedure Foo is
       procedure F1 is new Gen;
    begin
       ...

Here is what happens:

  1. When compiling with -ffunction-sections, the compiler is not
     providing the CU PC bounds (DW_AT_low_pc and DW_AT_high_pc).
     I would imagine that this is because functions might be removed
     later during the link, and thus bounds might be affected.

  2. As a result, GDB ends up having to compute the PC bounds itself
     by inspecting the children of the CU.  This is done inside
     get_scope_pc_bounds.  However, this function only handles
     non-nested functions.  As a result, after having determined
     the bounds of the main procedure Foo, it goes directly to
     the next sibling of that function, past the two nested
     subprograms.  The net effect is that the low/high PC range
     is too short, missing the range for our nested subprogram.

  3. Later, when the user inserts a breakpoint on the nested
     subprogram, GDB finds symbol f1, converts the associated
     psymtab into a symtab, and then tries to find the first
     "real" line of code, and so ends up searching the symtab
     associated to a PC inside our subprogram.  The search
     among known symtabs fails because of the incorrect PC bounds.
     So the next step is searching through the psymtabs, where
     we find the correct one, and realize that it has already
     been read in, meaning that the previous search should have
     found it -> warning.

The attached patch fixes this problem by handling nested subprograms.
Similarly to what was done earlier, I am limiting this to languages
that allow nested subprogram, which means only Ada for now. Other
languages should be unaffected.

2008-09-30  Joel Brobecker  <brobecker@adacore.com>
  
        * dwarf2read.c (dwarf2_get_subprogram_pc_bounds): New function.
        (get_scope_pc_bounds): Use it.

Tested on x86-linux. No regression. Any objection?

Thanks,
-- 
Joel

[-- Attachment #2: dwarf2read.c.diff --]
[-- Type: text/plain, Size: 2401 bytes --]

Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.284
diff -u -p -r1.284 dwarf2read.c
--- dwarf2read.c	23 Sep 2008 17:36:51 -0000	1.284
+++ dwarf2read.c	30 Sep 2008 14:54:29 -0000
@@ -3324,6 +3324,43 @@ dwarf2_get_pc_bounds (struct die_info *d
   return ret;
 }
 
+/* Assuming that DIE represents a subprogram DIE or a lexical block, get
+   its low and high PC addresses.  Do nothing if these addresses could not
+   be determined.  Otherwise, set LOWPC to the low address if it is smaller,
+   and HIGHPC to the high address if greater than HIGHPC.  */
+
+static void
+dwarf2_get_subprogram_pc_bounds (struct die_info *die,
+                                 CORE_ADDR *lowpc, CORE_ADDR *highpc,
+                                 struct dwarf2_cu *cu)
+{
+  CORE_ADDR low, high;
+  struct die_info *child = die->child;
+
+  if (dwarf2_get_pc_bounds (die, &low, &high, cu))
+    {
+      *lowpc = min (*lowpc, low);
+      *highpc = max (*highpc, high);
+    }
+
+  /* If the language does not allow nested subprograms (either inside
+     subprograms or lexical blocks), we're done.  */
+  if (cu->language != language_ada)
+    return;
+     
+  /* Check all the children of the given DIE.  If it contains nested
+     subprograms, then check their pc bounds.  Likewise, we need to
+     check lexical blocks as well, as they may also contain subprogram
+     definitions.  */
+  while (child && child->tag)
+    {
+      if (child->tag == DW_TAG_subprogram
+          || child->tag == DW_TAG_lexical_block)
+        dwarf2_get_subprogram_pc_bounds (child, lowpc, highpc, cu);
+      child = sibling_die (child);
+    }
+}
+
 /* Get the low and high pc's represented by the scope DIE, and store
    them in *LOWPC and *HIGHPC.  If the correct values can't be
    determined, set *LOWPC to -1 and *HIGHPC to 0.  */
@@ -3350,11 +3387,7 @@ get_scope_pc_bounds (struct die_info *di
 	{
 	  switch (child->tag) {
 	  case DW_TAG_subprogram:
-	    if (dwarf2_get_pc_bounds (child, &current_low, &current_high, cu))
-	      {
-		best_low = min (best_low, current_low);
-		best_high = max (best_high, current_high);
-	      }
+            dwarf2_get_subprogram_pc_bounds (child, &best_low, &best_high, cu);
 	    break;
 	  case DW_TAG_namespace:
 	    /* FIXME: carlton/2004-01-16: Should we do this for

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

[Daniel Jacobowitz]

On Tue, Sep 30, 2008 at 08:27:57AM -0700, Joel Brobecker wrote:
> Here is what happens:
> 
>   1. When compiling with -ffunction-sections, the compiler is not
>      providing the CU PC bounds (DW_AT_low_pc and DW_AT_high_pc).
>      I would imagine that this is because functions might be removed
>      later during the link, and thus bounds might be affected.

It should provide DW_AT_ranges instead.  Is it not doing that?  What
era compiler is this?

The patch is fine, either way.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Joel Brobecker]

> >   1. When compiling with -ffunction-sections, the compiler is not
> >      providing the CU PC bounds (DW_AT_low_pc and DW_AT_high_pc).
> >      I would imagine that this is because functions might be removed
> >      later during the link, and thus bounds might be affected.
> 
> It should provide DW_AT_ranges instead.  Is it not doing that?  What
> era compiler is this?

The compiler is based on GCC 4.1. I don't really know what GCC 4.3 does.
How would the range help with -ffunction-section, though? Does the
linker known how to remove one of the ranges when he discards an
unused function?

> The patch is fine, either way.

Thanks, will commit shortly.

-- 
Joel

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

[Daniel Jacobowitz]

On Tue, Sep 30, 2008 at 09:55:57AM -0700, Joel Brobecker wrote:
> > >   1. When compiling with -ffunction-sections, the compiler is not
> > >      providing the CU PC bounds (DW_AT_low_pc and DW_AT_high_pc).
> > >      I would imagine that this is because functions might be removed
> > >      later during the link, and thus bounds might be affected.
> > 
> > It should provide DW_AT_ranges instead.  Is it not doing that?  What
> > era compiler is this?
> 
> The compiler is based on GCC 4.1. I don't really know what GCC 4.3 does.
> How would the range help with -ffunction-section, though? Does the
> linker known how to remove one of the ranges when he discards an
> unused function?

It'd be reduced to an empty range, or at least moved to zero.  As long
as that isn't the list terminator it'd work OK.  If it is, some linker
smarts may be needed...

-- 
Daniel Jacobowitz
CodeSourcery

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

[Pierre Muller]

> The attached patch fixes this problem by handling nested subprograms.
> Similarly to what was done earlier, I am limiting this to languages
> that allow nested subprogram, which means only Ada for now. Other
> languages should be unaffected.

  Could you please also allow it for pascal language?
Nested functions/procedures are also allowed in pascal.
I wouldn't be surprised if modula-2 would also accept it,
but this would be to Gaius Mulley to confirm.
 


Pierre Muller
Pascal language support maintainer for GDB

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

[Joel Brobecker]

Hello Pierre,

> Could you please also allow it for pascal language?
> Nested functions/procedures are also allowed in pascal.

Up to now, I think only Pascal expressed interest in handling nested
subprograms besides Ada. The problem is that this change is not the only
piece of the whole puzzle. There are other changes, one of them
submitted recently, where we had to add some exceptions.  With that
in mind, I checked my patch in as is for now.

But now that we have another language interested in spending the CPU
time in handling these subprograms, we might want to introduce a new
function that, given a CU (or a language), return true if we should
handle nested subprogram, and use that function throughout, instead
of hard-coding the language test.

  static int
  dwarf2_handle_nested_subprograms (enum language lang)
  {
    return (lang == langauge_ada || lang == language_pascal);
  }

Would you like to do that? I can try to point out all the locations
where the check for Ada should be replaced by a call to this function.

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.

What do others think?

-- 
Joel

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

[Daniel Jacobowitz]

On Tue, Sep 30, 2008 at 10:06:48AM -0700, Joel Brobecker wrote:
> 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.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]

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

Tested on x86-linux, no regression (but I don't have a Pascal compiler).

-- 
Joel

[-- Attachment #2: pascal-nested.diff --]
[-- Type: text/plain, Size: 1796 bytes --]

diff -r 5c068b86064f dwarf2read.c
--- a/dwarf2read.c	Tue Sep 30 15:08:26 2008 -0700
+++ b/dwarf2read.c	Tue Sep 30 18:09:41 2008 -0700
@@ -1217,6 +1217,19 @@ dwarf2_resize_section (asection *sectp, 
                     sectp->name);
 }
 
+/* Return non-zero if the given CU may contains some nested subprograms
+   (in other words, subprograms defined inside another subprogram or
+   inside a lexical block).
+
+   The result is currently purely based on the compilation unit language,
+   and thus the content of the compilation unit itself is not checked.  */
+
+static int
+dwarf2_handle_nested_subprograms_p (struct dwarf2_cu *cu)
+{
+  return (cu->language == language_ada || cu->language == language_pascal);
+}
+
 /* Build a partial symbol table.  */
 
 void
@@ -2163,7 +2176,7 @@ add_partial_subprogram (struct partial_d
   if (! pdi->has_children)
     return;
 
-  if (cu->language == language_ada)
+  if (dwarf2_handle_nested_subprograms_p (cu))
     {
       pdi = pdi->die_child;
       while (pdi != NULL)
@@ -3345,7 +3358,7 @@ dwarf2_get_subprogram_pc_bounds (struct 
 
   /* If the language does not allow nested subprograms (either inside
      subprograms or lexical blocks), we're done.  */
-  if (cu->language != language_ada)
+  if (!dwarf2_handle_nested_subprograms_p (cu))
     return;
      
   /* Check all the children of the given DIE.  If it contains nested
@@ -5770,7 +5783,7 @@ load_partial_dies (bfd *abfd, gdb_byte *
 		      || last_die->tag == DW_TAG_interface_type
 		      || last_die->tag == DW_TAG_structure_type
 		      || last_die->tag == DW_TAG_union_type))
-	      || (cu->language == language_ada
+	      || (dwarf2_handle_nested_subprograms_p (cu)
 		  && (last_die->tag == DW_TAG_subprogram
 		      || last_die->tag == DW_TAG_lexical_block))))
 	{

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

[Pierre Muller]

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

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

[Jonas Maebe]

On 01 Oct 2008, at 09:42, Pierre Muller wrote:

> De : Joel Brobecker [mailto:brobecker@adacore.com]
>
>> 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?
>
>  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 :(

At least under Mac OS X, FPC with dwarf works fairly well. I believe  
it works ok under Linux too. I don't know about win32.

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

It doesn't work with FPC and stabs under 6.6-45.fc8rh at least  
(neither when using only upper case nor when using the casing as it  
appears in the source code). Was support for this only added in a  
later gdb version?


Jonas

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

[Joel Brobecker]

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

OK, I can commit this patch in a week or so to give people some time
to object.  We can deal with the other issues with a separate patch.

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

Seems reasonable.

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

I think we need to answer that question first before we go and start
spending the CPU time to scan for nested subprograms. Homonyms can
happen in the case you suggested, or in the case when two nested
subprograms have the same name.  Right now, when there is an ambiguity,
I understand that the debugger chooses one at random. Until we fix that,
adding nested subprograms whose name might overshadow library-level
subprograms is a bad idea in my opinion.

The answer to the question above lies in the Pascal parser. But when
there are homonyms, how do you specify in your program exactly which
one you mean? And does GDB provide the same method for distinguishing
these homonyms?

(need to relearn Pascal one of these days...)
-- 
Joel

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

[Jonas Maebe]

On 01 Oct 2008, at 18:39, Joel Brobecker wrote:

> The answer to the question above lies in the Pascal parser. But when
> there are homonyms, how do you specify in your program exactly which
> one you mean?

unitname.functionname

> And does GDB provide the same method for distinguishing
> these homonyms?

I don't think so. The main problem is that there is no common way of  
mangling procedure/function names in Pascal. FPC and GPC mangle them  
in different ways, and as far as I know gdb has no support to demangle  
either (it definitely does not support demangling FPC names).

For this reason, I always use either symbol names or sourcefile:linenr  
to place breakpoints.


Jonas

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

[Daniël Mantione]

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



Op Wed, 1 Oct 2008, schreef Joel Brobecker:

> The answer to the question above lies in the Pascal parser. But when
> there are homonyms, how do you specify in your program exactly which
> one you mean? And does GDB provide the same method for distinguishing
> these homonyms?
>
> (need to relearn Pascal one of these days...)

Pascal has a stack based symbol resolving (we call it the symtablestack in 
the compiler). For example take for example the following program:

program my_program;

uses unit_a,unit_b,unit_c;

var a:integer;

procedure main_procedure;

   var a:integer;

   procedure sub_procedure;

   var a:integer;

   begin
     a:=1;
     main_procedure.a:=1;
     my_program.a:=1;
     unit_a.a:=1;
     unit_b.a:=1;
     unit_c.a:=1;
   end;

begin
end;

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

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.

Daniël

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

[Pierre Muller]

  Hi Daniel,


> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Daniël Mantione
> Envoyé : Thursday, October 02, 2008 8:43 AM
> À : FPC Core Developer List
> Cc : Pierre Muller; gpc@gnu.de; gdb-patches@sourceware.org
> Objet : Re: [Core] [RFA/DWARF2] Handle nested subprograms in CU pc
> bound calculation
> 
> 
> 
> Op Wed, 1 Oct 2008, schreef Joel Brobecker:
> 
> > The answer to the question above lies in the Pascal parser. But when
> > there are homonyms, how do you specify in your program exactly which
> > one you mean? And does GDB provide the same method for distinguishing
> > these homonyms?
> >
> > (need to relearn Pascal one of these days...)
> 
> Pascal has a stack based symbol resolving (we call it the symtablestack
> in
> the compiler). For example take for example the following program:
> 
> program my_program;
> 
> uses unit_a,unit_b,unit_c;
> 
> var a:integer;
> 
> procedure main_procedure;
> 
>    var a:integer;
> 
>    procedure sub_procedure;
> 
>    var a:integer;
> 
>    begin
>      a:=1;
>      main_procedure.a:=1;
>      my_program.a:=1;
>      unit_a.a:=1;
>      unit_b.a:=1;
>      unit_c.a:=1;
>    end;
> 
> begin
> end;

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

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

  

> 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 ...
  In stabs, I believe that there is no information on that...
Does dwarf have something about this?

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

  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 had the big drawback of preventing to have the 
same global function/procedure in two different units
that is normally allowed according to pascal syntax.
  Could someone from the GPC development team
tell us if this limitation is still in place or if it
has been lifted?


  Thanks for the answers,


Pierre Muller
Pascal language support maintainer for GDB

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

[Daniël Mantione]

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

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

[Joel Brobecker]

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

OK.  Thanks to everyone who participated in the discussion. I pretty
much agree with the above.

Until then, I would suggest that we do not put the nested subprograms
in the global scope, as nested subprogram names might collide with
global functions that have the same name.  But if the Pascal users
feel differently, then it's easy to fix.

-- 
Joel

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

[Joel Brobecker]

> 2008-09-30  Joel Brobecker  <brobecker@adacore.com>
>   
>         * dwarf2read.c (dwarf2_get_subprogram_pc_bounds): New function.
>         (get_scope_pc_bounds): Use it.

This one is now in.

-- 
Joel