From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17750 invoked by alias); 26 Sep 2008 19:07:10 -0000 Received: (qmail 17359 invoked by uid 22791); 26 Sep 2008 19:07:09 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 26 Sep 2008 19:06:35 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 40D782A96D7; Fri, 26 Sep 2008 15:06:33 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7gtrIDstnMSk; Fri, 26 Sep 2008 15:06:33 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id D48D92A95E7; Fri, 26 Sep 2008 15:06:32 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id AEBBDE7ACD; Fri, 26 Sep 2008 12:06:30 -0700 (PDT) Date: Fri, 26 Sep 2008 19:07:00 -0000 From: Joel Brobecker To: Pierre Muller Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Allow overloaded general functions Message-ID: <20080926190630.GA3814@adacore.com> References: <47ed1b31.0af6660a.3ddc.ffffb9c5@mx.google.com> <20080918003342.GA3651@adacore.com> <000801c91eee$255ad7d0$70108770$@u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000801c91eee$255ad7d0$70108770$@u-strasbg.fr> User-Agent: Mutt/1.4.2.2i 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/msg00522.txt.bz2 > > 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