Re: [RFC] Allow overloaded general functions

[Joel Brobecker <brobecker@adacore.com>]

> > For Ada, we handled that issue by rewriting the breakpoint string
> > into a canonical form that allows us to uniquely identify the location
> > of each of them. From memory, it should look like this:
> > 
> >     addstring.pp:ADD:16
> 
> In pascal, you could  also have some (fairly rare) case where this
> would not be enough: you could simulate 'templates' (does this
> concept also mean something in C++ or Ada?)

Ah, yes. In Ada, the C++ templates are called "generics" (generic
package, or generic subprogram), and indeed, this can be a problem.

The reason this hasn't been a problem in Ada is because I gave you
a simplified version of the story. Without entering too much into
details, Ada entities have a fully-qualified name. For instance,
if variable Foo is defined in Package Pck, the the fully qualified
name is Pck.Foo.  Now, generics are not compiled, only the actual
instances.  And the fully qualified name depends on the scope where
the generic is instantiated. For instance, let's say that Package
Pck is a generic, and that it is instantiated in package Bar using
the following statement:

        package My_Instance is new Pck (...);

The fully qualified name for our procedure Foo is then: Bar.My_Instance.Foo.

Now, going back to the actual issue, we store the fully qualified name
in our cannonical version (or, in GDB terms, the SYMBOL_PRINT_NAME).
That, in itself, handles the case of generics.  The filename and line
number additions are only necessary to handle overloading, ie cases
where two functions have the same fully qualfied name:

        package Pck is
           procedure Print (F : Float);
           procedure Print (I : Integer);
        end Pck;

Now, back to Pascal:

> by simply writing an include file (called add.inc) like this:
[...]
> In such a case all three versions would have the same
>   add.inc:ADD:3
> identifier...
[...]
>   But as you said, this case would only be marginal, and your
> suggestion should allow to treat most cases successfully.

I don't think it's marginal enough that we should ignore it.
Generics are a very common practice in Ada, and I don't see why
it wouldn't be as common in Pascal.

>   The only option that would (maybe) give a more deterministic
> behavior for pascal would be to associate each sub-breakpoint to
> the real mangled assembler label that is always unique (at least for
> interface defined functions).

Yes, that's my thought as well - we can use the SYMBOL_LINKAGE_NAME
in the cannonical form. However, we need to be a little careful, here,
because we also need to be able to print something friendly when the
user ask for the list of breakpoints:

   (gdb) info break
   Num     Type           Disp Enb Address    What
   1       breakpoint     keep y   0x080495df in foo.one.call_me at pck.adb:5
   2       breakpoint     keep y   0x080495d3 in foo.two.call_me at pck.adb:5

In the "What" column, we don't want:

   in foo__one__call_me.1 at pck.adb:5
   in foo__two__call_me.2 at pck.adb:5

Also, we need to make sure that we are able to re-evaluate correctly
the breakpoint later on.  For instance, the ".DIGIT" suffix that the
Ada compiler adds at the end of nested procedures can confuse the
symbol lookup routine (not sure if this is the case or not in this
example, but that's only a technical details).

-- 
Joel