From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32723 invoked by alias); 25 Sep 2008 09:52:36 -0000 Received: (qmail 32564 invoked by uid 22791); 25 Sep 2008 09:52:35 -0000 X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 25 Sep 2008 09:51:46 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id m8P9pIHc020631 ; Thu, 25 Sep 2008 11:51:19 +0200 (CEST) Received: from mailserver.u-strasbg.fr (ms1.u-strasbg.fr [IPv6:2001:660:2402::141]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id m8P9pIkc031362 ; Thu, 25 Sep 2008 11:51:18 +0200 (CEST) Received: from d620muller (www-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id m8P97ST8016335 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Thu, 25 Sep 2008 11:07:28 +0200 (CEST) (envelope-from muller@ics.u-strasbg.fr) From: "Pierre Muller" To: "'Joel Brobecker'" Cc: References: <47ed1b31.0af6660a.3ddc.ffffb9c5@mx.google.com> <20080918003342.GA3651@adacore.com> In-Reply-To: <20080918003342.GA3651@adacore.com> Subject: RE: [RFC] Allow overloaded general functions Date: Thu, 25 Sep 2008 09:52:00 -0000 Message-ID: <000801c91eee$255ad7d0$70108770$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.u-strasbg.fr [IPv6:2001:660:2402::153]); Thu, 25 Sep 2008 11:51:19 +0200 (CEST) X-Virus-Status: Clean Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00498.txt.bz2 Hi Joel, Thanks for working on this issue. > -----Message d'origine----- > De=A0: Joel Brobecker [mailto:brobecker@adacore.com] > Envoy=E9=A0: Thursday, September 18, 2008 2:34 AM > =C0=A0: Pierre Muller (gmail) > Cc=A0: gdb-patches@sourceware.org > Objet=A0: Re: [RFC] Allow overloaded general functions >=20 > 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. >=20 > 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. >=20 > 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? >=20 > I suggest you have a look at a patch I sent last January: >=20 > http://www.sourceware.org/ml/gdb-patches/2008-01/msg00008.html >=20 > 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. >=20 > The problem, as you have found out, is when we re-evaluate each > breakpoint we just created. Using your example: >=20 > > [2] ADD at addstring.pp:16 > > [3] ADD at addlongint.pp:17 > > [4] ADD at addint.pp:17 >=20 > 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. >=20 > 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: >=20 > 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)=20=20=20 line 3) begin line 4) add :=3D 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)=20=20 line 3) interface line 4) type add_type =3D real; line 5)=20=20 line 6) {$i addh.inc} line 7)=20=20 line 8) implementation line 9)=20=20 line 10) {$i add.inc} line 11)=20=20 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