This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [RFC] Allow overloaded general functions
- From: "Pierre Muller" <muller at ics dot u-strasbg dot fr>
- To: "'Joel Brobecker'" <brobecker at adacore dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Thu, 25 Sep 2008 11:07:32 +0200
- Subject: RE: [RFC] Allow overloaded general functions
- References: <47ed1b31.0af6660a.3ddc.ffffb9c5@mx.google.com> <20080918003342.GA3651@adacore.com>
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