From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69709 invoked by alias); 31 Mar 2017 13:55:45 -0000 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 Received: (qmail 69572 invoked by uid 89); 31 Mar 2017 13:55:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-wr0-f182.google.com Received: from mail-wr0-f182.google.com (HELO mail-wr0-f182.google.com) (209.85.128.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 Mar 2017 13:55:44 +0000 Received: by mail-wr0-f182.google.com with SMTP id w43so107074055wrb.0 for ; Fri, 31 Mar 2017 06:55:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=msetRfPtC0a3TCKlgdIH3ZoEs/Sr2gGlmyRKxhQdONA=; b=e6EzM+5/rAdUXFbhgATyf7kD6tmStGc/iMiaJGjR71QydLEV/t3jCJX1RjvN2SWJj4 sQeLoaKmgD7+TDLn5k0nbh0EaRiLIMomVNhjJRIWMfnwwJOPcYrSFwgj8/l6Zo4dEshJ GDd38NLW/XuhDM89u5cojbMN/Yar6sloNQUP/TyRECzvF1RQeCZpVC7ZUj2ouuPTLMfF FR8OYRUEUKUiLDikJXYCUFRYNjgIL9s9wzoCC+9fVpjr5nGyhoUPMMiN7/eHgzeP0wGS uFOAIZSkHKVTQxXTeOwJtwnGmxZDQ44SiWXUBqPnR3gg5lvKZ2nLpNEYUoH7CdDQCbUp +8Qw== X-Gm-Message-State: AFeK/H3UrekJ3cdB49CvTLkqPG7Esv1kqZ9KS7ovWpXPNB6d0fbLU/KW55OGCV39o5+CUw== X-Received: by 10.223.136.182 with SMTP id f51mr2903318wrf.134.1490968543134; Fri, 31 Mar 2017 06:55:43 -0700 (PDT) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id i130sm2999229wmf.26.2017.03.31.06.55.41 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 31 Mar 2017 06:55:42 -0700 (PDT) From: Yao Qi To: "Metzger\, Markus T" Cc: "gdb-patches\@sourceware.org" , "Wiederhake\, Tim" , "xdje42\@gmail.com" , "Joel Brobecker" Subject: Re: GDB 8.0 release/branching 2017-03-20 update References: <20170320201629.pbjzaqsnvs7dx7f2@adacore.com> <86inn1utkp.fsf@gmail.com> <86inmzvrbx.fsf@gmail.com> <86shm2u47t.fsf@gmail.com> <86wpbbnf1f.fsf@gmail.com> <86shlyoggb.fsf@gmail.com> <86mvc5o7o4.fsf@gmail.com> <86a885o0z2.fsf@gmail.com> <861stgo072.fsf@gmail.com> <86lgrn3uos.fsf@gmail.com> <86h92a4w86.fsf@gmail.com> Date: Fri, 31 Mar 2017 13:55:00 -0000 In-Reply-To: (Markus T. Metzger's message of "Thu, 30 Mar 2017 15:55:49 +0000") Message-ID: <86h929wnxi.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00542.txt.bz2 "Metzger, Markus T" writes: > I thought we need it because we may get RecordFullInstruction in the futu= re > that needs to store different data and install different functions. > > They will behave identical but will have different implementations. Do you have some concrete reasons that we may change Record{Full,Btrace,...}Instruction in C? I can't figure out the reason in the future we do the change, so I don't worry it now. > > Can they pretend to be the same type in Python? Suppose one day in the future, we really need such change. We can still have different C structs for different record methods, different PyTypeObject but with the same .tp_name "gdb.RecordInstruction" and different .tp_getset. I hacked GDB code, and find python doesn't complain that I call PyType_Ready with different PyTypeObject, but they have the same .tp_name. Everything works fine. If the change I do above is hacky, then we have to create sub-types of RecordInstruction for different record methods in C (gdb.priv.RecordFullinstruction for example?), but Python interface is still documented as returning type gdb.RecordInstruction. r =3D gdb.current_recording() insn =3D r.instruction_history print insn[0].pc print insn[0].sal and the in C code for .instruction_history, if (obj->method =3D=3D RECORD_METHOD_BTRACE) return recpy_bt_instruction_history (obj->ptid, closure); else if (obj->method =3D=3D RECORD_METHOD_FULL) { gdbpy_ref<> list (PyList_New (0)); fullpy_insn_object * const obj =3D PyObject_New (fullpy_insn_object, &fullpy_insn_type); if (obj =3D=3D NULL) return NULL; obj->insn.insn.pc =3D 11; obj->insn.insn.size =3D 22; PyList_Append (list.get (), (PyObject *) obj); return PyList_AsTuple (list.get ()); } return PyErr_Format (PyExc_NotImplementedError, _("Not implemented.")); Python code still uses insn[0] as the base type RecordInstruction, and Python code doesn't need to know the sub-types of RecordInstruction C code creates. We deliberately don't document these sub-types in GDB if we add them. IMO, not every python types we added in C are public types. --=20 Yao (=E9=BD=90=E5=B0=A7)