This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:

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:


(or, said different in a general way: FILE:FUNCTION_NAME:LINE_NO).

Feedback about this approach was not entirely enthousiastic,
unfortunately, largely because I was using that form for Ada only,
which was a divergence that Daniel wanted to avoid if possible.
But also, when I proposed to see if that form could be generalized
to all languages , Daniel pointed out:

> I think the entire concept of a location specification which is both
> canonical and user-inputable is on its last legs.  If you want to
> identify just one line of one homonym, what about one inlined instance
> of that line?  One instantiation in a particular shared library?
> I've looked at the problem before but never got anywhere.

This was part of a very small private discussion because I wasn't
sure how bad Daniel was feeling about my patch.

I was hoping to be able to look at this problem again in the near
future, and since then nothing :-(.

I can propose the following: We can look again at working from
the Ada approach (and patch) and make it work for all languages
instead of just Ada. We can use this canonical form, or any way
we find convenient, to specify the breakpoint location. As Daniel
points out, it won't cover all possible cases and a more powerful
approach will eventually be needed if we want to support some of
them. But in the meantime, we will be able to insert breakpoints
on homonyms in both Pascal and Ada (and possibly C++) for the vast
majority of cases.

Daniel, what do you think?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]