From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12356 invoked by alias); 25 Mar 2009 22:33:44 -0000 Received: (qmail 12347 invoked by uid 22791); 25 Mar 2009 22:33:43 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Mar 2009 22:33:36 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2PMXYmX028064 for ; Wed, 25 Mar 2009 18:33:34 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2PMXSKK028417 for ; Wed, 25 Mar 2009 18:33:28 -0400 Received: from lindt.uglyboxes.com (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n2PMXUAa007282 for ; Wed, 25 Mar 2009 18:33:32 -0400 Message-ID: <49CAB139.8010100@redhat.com> Date: Wed, 25 Mar 2009 22:39:00 -0000 From: Keith Seitz User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: [RFC] Special casing dtors? Content-Type: multipart/mixed; boundary="------------050800060307020609030707" X-IsSubscribed: yes 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: 2009-03/txt/msg00573.txt.bz2 This is a multi-part message in MIME format. --------------050800060307020609030707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1140 Hi, I've been looking a bit at a patch (in Fedora) which fixes prms/1112, and I notice that both valops.c and linespec.c treat destructors as "special case"s -- but nowhere does it say WHY. I've searched through all the history I can find about this (including the Cygnus internal ueberbaum), and all I've been able to discover is that this has been in a LONG time (before 1990). So out of curiosity, I removed all those special cases, and lo! There were no new failures, and one new pass in the testsuite (on x86, CVS HEAD). Can anyone explain to me either why gdb treats dtors differently from "normal" methods or why we shouldn't commit something like the attached patch? Keith ChangeLog 2009-03-25 Keith Seitz * linespec.c (collect_methods): Delete. (add_matching_methods): Reove destructor special case. (find_method): Call find_methods directly instead of collect_methods. * valops.c (value_struct_elt): Remove destructor special cases. (check_field): Likewise. (value_struct_elt_for_reference): Likewise. (destructor_name_p): Remove misleading comment about dtors being "special cases". --------------050800060307020609030707 Content-Type: text/plain; name="dtor-special-case.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dtor-special-case.patch" Content-length: 4863 Index: linespec.c =================================================================== RCS file: /cvs/src/src/gdb/linespec.c,v retrieving revision 1.84 diff -u -p -r1.84 linespec.c --- linespec.c 3 Jan 2009 05:57:52 -0000 1.84 +++ linespec.c 25 Mar 2009 22:28:08 -0000 @@ -76,10 +76,6 @@ static struct symtabs_and_lines find_met struct type *t, struct symbol *sym_class); -static int collect_methods (char *copy, struct type *t, - struct symbol *sym_class, - struct symbol **sym_arr); - static NORETURN void cplusplus_error (const char *name, const char *fmt, ...) ATTR_NORETURN ATTR_FORMAT (printf, 2, 3); @@ -306,11 +302,6 @@ add_matching_methods (int method_counter else phys_name = TYPE_FN_FIELD_PHYSNAME (f, field_counter); - /* Destructor is handled by caller, don't add it to - the list. */ - if (is_destructor_name (phys_name) != 0) - continue; - sym_arr[i1] = lookup_symbol_in_language (phys_name, NULL, VAR_DOMAIN, language, @@ -1441,7 +1432,7 @@ find_method (int funfirstline, char ***c /* Find all methods with a matching name, and put them in sym_arr. */ - i1 = collect_methods (copy, t, sym_class, sym_arr); + i1 = find_methods (t, copy, SYMBOL_LANGUAGE (sym_class), sym_arr); if (i1 == 1) { @@ -1492,37 +1483,6 @@ find_method (int funfirstline, char ***c } } -/* Find all methods named COPY in the class whose type is T, and put - them in SYM_ARR. Return the number of methods found. */ - -static int -collect_methods (char *copy, struct type *t, - struct symbol *sym_class, struct symbol **sym_arr) -{ - int i1 = 0; /* Counter for the symbol array. */ - - if (destructor_name_p (copy, t)) - { - /* Destructors are a special case. */ - int m_index, f_index; - - if (get_destructor_fn_field (t, &m_index, &f_index)) - { - struct fn_field *f = TYPE_FN_FIELDLIST1 (t, m_index); - - sym_arr[i1] = - lookup_symbol (TYPE_FN_FIELD_PHYSNAME (f, f_index), - NULL, VAR_DOMAIN, (int *) NULL); - if (sym_arr[i1]) - i1++; - } - } - else - i1 = find_methods (t, copy, SYMBOL_LANGUAGE (sym_class), sym_arr); - - return i1; -} - /* Return the symtab associated to the filename given by the substring Index: valops.c =================================================================== RCS file: /cvs/src/src/gdb/valops.c,v retrieving revision 1.210 diff -u -p -r1.210 valops.c --- valops.c 20 Mar 2009 23:04:34 -0000 1.210 +++ valops.c 25 Mar 2009 22:28:09 -0000 @@ -1858,10 +1858,6 @@ value_struct_elt (struct value **argp, s /* C++: If it was not found as a data field, then try to return it as a pointer to a method. */ - - if (destructor_name_p (name, t)) - error (_("Cannot get value of destructor")); - v = search_struct_method (name, argp, args, 0, static_memfuncp, t); @@ -1877,32 +1873,6 @@ value_struct_elt (struct value **argp, s return v; } - if (destructor_name_p (name, t)) - { - if (!args[1]) - { - /* Destructors are a special case. */ - int m_index, f_index; - - v = NULL; - if (get_destructor_fn_field (t, &m_index, &f_index)) - { - v = value_fn_field (NULL, - TYPE_FN_FIELDLIST1 (t, m_index), - f_index, NULL, 0); - } - if (v == NULL) - error (_("could not find destructor function named %s."), - name); - else - return v; - } - else - { - error (_("destructor should not have any argument")); - } - } - else v = search_struct_method (name, argp, args, 0, static_memfuncp, t); @@ -2508,8 +2478,6 @@ classify_oload_match (struct badness_vec int destructor_name_p (const char *name, const struct type *type) { - /* Destructors are a special case. */ - if (name[0] == '~') { char *dname = type_name_no_tag (type); @@ -2548,14 +2516,6 @@ check_field (struct type *type, const ch /* C++: If it was not found as a data field, then try to return it as a pointer to a method. */ - /* Destructors are a special case. */ - if (destructor_name_p (name, type)) - { - int m_index, f_index; - - return get_destructor_fn_field (type, &m_index, &f_index); - } - for (i = TYPE_NFN_FIELDS (type) - 1; i >= 0; --i) { if (strcmp_iw (TYPE_FN_FIELDLIST_NAME (type, i), name) == 0) @@ -2651,12 +2611,6 @@ value_struct_elt_for_reference (struct t /* C++: If it was not found as a data field, then try to return it as a pointer to a method. */ - /* Destructors are a special case. */ - if (destructor_name_p (name, t)) - { - error (_("member pointers to destructors not implemented yet")); - } - /* Perform all necessary dereferencing. */ while (intype && TYPE_CODE (intype) == TYPE_CODE_PTR) intype = TYPE_TARGET_TYPE (intype); --------------050800060307020609030707--