From patchwork Sun Jan 25 19:48:28 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Evans X-Patchwork-Id: 4804 Received: (qmail 21943 invoked by alias); 25 Jan 2015 19:52:03 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 18627 invoked by uid 89); 25 Jan 2015 19:50:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f44.google.com Received: from mail-pa0-f44.google.com (HELO mail-pa0-f44.google.com) (209.85.220.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sun, 25 Jan 2015 19:50:21 +0000 Received: by mail-pa0-f44.google.com with SMTP id rd3so7669545pab.3 for ; Sun, 25 Jan 2015 11:49:16 -0800 (PST) X-Received: by 10.70.44.205 with SMTP id g13mr28997183pdm.4.1422215356072; Sun, 25 Jan 2015 11:49:16 -0800 (PST) Received: from seba.sebabeach.org.gmail.com (173-13-178-53-sfba.hfc.comcastbusiness.net. [173.13.178.53]) by mx.google.com with ESMTPSA id ok6sm7862334pdb.96.2015.01.25.11.49.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Jan 2015 11:49:15 -0800 (PST) From: Doug Evans To: gdb-patches@sourceware.org, brobecker@adacore.com Subject: [PATCH 1/5] Remove struct main_type.vptr_{fieldno, basetype}: finish TYPE_SPECIFIC_FIELD kind handling Date: Sun, 25 Jan 2015 11:48:28 -0800 Message-ID: MIME-Version: 1.0 X-IsSubscribed: yes Hi. The handling of TYPE_SPECIFIC_FIELD in copy_type_recursive, while maybe correct, leaves one wondering. So I've added handling of the remaining possibilities. Joel, I tried to create a testcase to exercise the handling of TYPE_SPECIFIC_GNAT_STUFF but couldn't. The issue is having a value in the value history get preserved when the objfile gets unloaded, and then trying to use that value: If we don't properly preserve type_specific.gnat_stuff what happens? I looked at the code and it seems safe to just reinit the field with INIT_GNAT_SPECIFIC, but another pair of eyes would help. 2015-01-24 Doug Evans * gdbtypes.c (copy_type_recursive): Handle all TYPE_SPECIFIC_FIELD kinds. diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c index 6d3c084..f528cb7 100644 --- a/gdb/gdbtypes.c +++ b/gdb/gdbtypes.c @@ -4185,18 +4185,35 @@ copy_type_recursive (struct objfile *objfile, copy_type_recursive (objfile, TYPE_VPTR_BASETYPE (type), copied_types); + /* Maybe copy the type_specific bits. NOTE drow/2005-12-09: We do not copy the C++-specific bits like base classes and methods. There's no fundamental reason why we can't, but at the moment it is not needed. */ - if (TYPE_CODE (type) == TYPE_CODE_FLT) - TYPE_FLOATFORMAT (new_type) = TYPE_FLOATFORMAT (type); - else if (TYPE_CODE (type) == TYPE_CODE_STRUCT - || TYPE_CODE (type) == TYPE_CODE_UNION - || TYPE_CODE (type) == TYPE_CODE_NAMESPACE) - INIT_CPLUS_SPECIFIC (new_type); + switch (TYPE_SPECIFIC_FIELD (type)) + { + case TYPE_SPECIFIC_NONE: + break; + case TYPE_SPECIFIC_FUNC: + INIT_FUNC_SPECIFIC (new_type); + TYPE_CALLING_CONVENTION (new_type) = TYPE_CALLING_CONVENTION (type); + TYPE_NO_RETURN (new_type) = TYPE_NO_RETURN (type); + TYPE_TAIL_CALL_LIST (new_type) = NULL; + break; + case TYPE_SPECIFIC_FLOATFORMAT: + TYPE_FLOATFORMAT (new_type) = TYPE_FLOATFORMAT (type); + break; + case TYPE_SPECIFIC_CPLUS_STUFF: + INIT_CPLUS_SPECIFIC (new_type); + break; + case TYPE_SPECIFIC_GNAT_STUFF: + INIT_GNAT_SPECIFIC (new_type); + break; + default: + gdb_assert_not_reached ("bad type_specific_kind"); + } return new_type; }