From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23510 invoked by alias); 23 Apr 2003 23:02:08 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23503 invoked from network); 23 Apr 2003 23:02:08 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 23 Apr 2003 23:02:08 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h3NN26K07000; Wed, 23 Apr 2003 16:02:06 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] handling of 'operator' in cp_find_first_component References: <20030422032152.GA5033@nevyn.them.org> From: David Carlton Date: Wed, 23 Apr 2003 23:45:00 -0000 In-Reply-To: <20030422032152.GA5033@nevyn.them.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-04/txt/msg00454.txt.bz2 On Mon, 21 Apr 2003 23:21:52 -0400, Daniel Jacobowitz said: > As Daniel Berlin pointed out, the demangler is behaving correctly. > The return type is part of the mangled signature in this case, and > must be. I'm actually curious why it must be, but that's another issue; it simply is the case that it's part of the mangled signature, so the demangler is behaving correctly. > However, for GDB's purposes, is it _necessary_ or _useful_ to have > said mangled name? If not, for another project I already have a > cplus_demangle wrapper which plays with the resulting names. > Adapting it to detect and remove return types would probably be > easy. I suspect that it's not useful (I'll talk more about that downthread); whether or not it's useful, I'm pretty sure that, right now, it's actively harmful. We have code in GDB that deals with function names; that code assumes that the function names doesn't have certain characteristics. So if the demangler is returning "int foo(int)" then I bet that "break foo" doesn't work for us. I would be tempted to put the code to not give return types in the demangler itself, though, rather than in a post-processor: that seems to me to be more reliable and more efficient. > I am not strong in this area of C++, but as far as I know this should > suffice; the demangled name of such a function will always include the > template parameters; and the template-id must be unique in the program > (right? Not sure if the ODR comes into play here or not) so either > there is only one possible return value or the template parameters > uniquely identify the return value. > i.e. you can't have a program with > int foo (int) > and > long foo (int) > in it! That's my attitude, too. Template parameters and argument types can distinguish functions; return types can't. At least I assume so; on the other hand, presumably the ABI authors had a reason for including return types in the demangled name in this situation. But even if there are some strange boundary cases where it's necessary to disambiguate functions, I still think that, right now, GDB is much more likely to be hurt than to be helped by having return types in there. > That said, I still think your patch is OK; on the condition that it > handles the test case the comment you're removing refers to. Something > like: > int foo > or whatever it was in the right syntax. Does it, and can you add that > to the maint.exp tests? It should handle them, but you're right, I should include such examples in the maint.exp tests. I'll go off and generate some examples first before checking it in. David Carlton carlton@math.stanford.edu