RE: [RFC] Allow overloaded general functions

["Pierre Muller" <muller@ics.u-strasbg.fr>]

  Hi Joel,

Thanks for working on this issue.

> -----Message d'origine-----
> De : Joel Brobecker [mailto:brobecker@adacore.com]
> Envoyé : Thursday, September 18, 2008 2:34 AM
> À : Pierre Muller (gmail)
> Cc : gdb-patches@sourceware.org
> Objet : Re: [RFC] Allow overloaded general functions
> 
> On Fri, Mar 28, 2008 at 05:22:03PM +0100, Pierre Muller (gmail) wrote:
> > I tried to write a patch that allows to
> > set a breakpoint at each overloaded version of a procedure or
> function,
> > which is a fairly common feature in pascal language.
> 
> Sorry for being so late in replying to this, but I was really REALLY
> hoping to look at the same sort of issue for Ada as well before
> answering. Bad luck, I have been so tied up that I never found
> the time.
> 
> Nevertheless, I don't believe that Pascal and Ada are the only
> languages
> affected. Not sure how the C++ mode handles overloading in GDB, buti
> presumably, C++ should have the same issue - perhaps the user is
> expected to fully qualify his entity?
> 
> I suggest you have a look at a patch I sent last January:
> 
>     http://www.sourceware.org/ml/gdb-patches/2008-01/msg00008.html
> 
> The way we handle overloading is by creating several breakpoints that
> have only one location, as opposed to multiple-location breakpoints.
> Just like you.  If creating several breakpoints is easier in the short
> term, I really think we should try to transition towards multiple-
> location
> breakpoint when we can.
> 
> The problem, as you have found out, is when we re-evaluate each
> breakpoint we just created. Using your example:
> 
> > [2] ADD at addstring.pp:16
> > [3] ADD at addlongint.pp:17
> > [4] ADD at addint.pp:17
> 
> Since you chose "all", you created 3 breakpoints. I'll number them
> 1, 2 and 3 in the order above.  When you "run" your program, or when
> a new shared library is mapped, you need to re-evaluate each of them,
> meaning we need to verify that the actual address hasn't changed.
> If you do not add some kind of information in each breakpoint to
> say which instance it is refering to, then you'll never be able
> to determine that breakpoint 2 is at addlongint.pp:17.
> 
> 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?)
by simply writing an include file (called add.inc) like this:

line 1)  function add(x,y : add_type) : add_type;
line 2)   
line 3)  begin
line 4)    add := x + y;
line 5)  end;

and include that file in several units, add_real, add_integer, add_string:

line  1)  unit add_real;
line  2)  
line  3)  interface
line  4)  type add_type = real;
line  5)  
line  6)  {$i addh.inc}
line  7)  
line  8)  implementation
line  9)  
line 10)  {$i add.inc}
line 11)  
line 12)  end.

In such a case all three versions would have the same
  add.inc:ADD:3
identifier...

   In fact even adding the name of the argument types or return type
wouldn't help here as all are 'add_type'.

  But as you said, this case would only be marginal, and your
suggestion should allow to treat most cases successfully.

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

  To summarize, I agree that your patch would probably
resolve most issues and as such I think that it is a step in the good
direction.



Pierre Muller
Pascal language support maintainer for GDB