From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100454 invoked by alias); 19 May 2017 10:15:43 -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 100124 invoked by uid 89); 19 May 2017 10:15:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=explosion X-HELO: mail-wr0-f169.google.com Received: from mail-wr0-f169.google.com (HELO mail-wr0-f169.google.com) (209.85.128.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 May 2017 10:15:16 +0000 Received: by mail-wr0-f169.google.com with SMTP id w50so14102392wrc.0 for ; Fri, 19 May 2017 03:15:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=16flCKqPdu1Ipmkt8J2fdtBDp7KZo6NvmOafo5Hpl7M=; b=tPZ+9g+gpK5YeRi4jBnw+3N+DsPU8aCA8bWSDEOmS0jR1nVyOnH42g7jenT3C+8Ngw wcxVKWdRU6zzanhEVr0RFa2ahtDZerXXhLTEtYNwPORBZ9FFMoJ/2zYguOb4t6/W37y3 rMTbX3YzBoiiq3HZM+MYntMBAns2r32ls69Ud03d2zKgsaCzmbjRoGJRx9zjCqHKQKZ0 rvTJd4R4K/s3NQuZ2wQr5V1GIMIdO71VqD0FhqIJZhd7fpg7qH40qzq2oBedGLBPpNup u10J56AXpQYT5wH0PRmQpmsHVNfJBztYb0AISXXD8UFC26z37ndTN0asJqUI0Babu+O4 PqRg== X-Gm-Message-State: AODbwcAyxE3eP+Vk+Dozbp1Wcyg+yVX9Bjureqr8YZq/nwhNbDfr/fvp BZu3yz9Nz2fTNbxVTGteHA== X-Received: by 10.223.178.150 with SMTP id g22mr2219883wrd.158.1495188910249; Fri, 19 May 2017 03:15:10 -0700 (PDT) Received: from [192.168.0.102] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id w16sm10928525wmw.10.2017.05.19.03.15.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 May 2017 03:15:09 -0700 (PDT) Subject: Re: [RFC 6/7] Lazily and dynamically create i386-linux target descriptions To: Yao Qi References: <1494518105-15412-1-git-send-email-yao.qi@linaro.org> <1494518105-15412-7-git-send-email-yao.qi@linaro.org> <86y3tu6vww.fsf@gmail.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <2688beca-29b9-6ab3-4281-a6c1070da177@redhat.com> Date: Fri, 19 May 2017 10:15:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <86y3tu6vww.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00433.txt.bz2 On 05/18/2017 04:12 PM, Yao Qi wrote: > Pedro Alves writes: > >>> + >>> + struct xml_and_mask array[] = { >>> + { "i386/i386-linux.xml", X86_XSTATE_SSE_MASK }, >>> + { "i386/i386-mmx-linux.xml", X86_XSTATE_X87_MASK }, >>> + { "i386/i386-avx-linux.xml", X86_XSTATE_AVX_MASK }, >>> + { "i386/i386-mpx-linux.xml", X86_XSTATE_MPX_MASK }, >>> + { "i386/i386-avx-mpx-linux.xml", X86_XSTATE_AVX_MPX_MASK }, >>> + { "i386/i386-avx-avx512-linux.xml", X86_XSTATE_AVX_AVX512_MASK }, >>> + { "i386/i386-avx-mpx-avx512-pku-linux.xml", >>> + X86_XSTATE_AVX_MPX_AVX512_PKU_MASK }, >> >> About these xml files. Is your idea that: >> >> #1 - we remove these xml description files at some point, keeping only >> the description fragments which are currently xi:included by the xml >> files above? >> #2 - or, we'll still continue adding new xml files and grow this >> list here? >> #3 - or, we'll keep the existing xml files as representative / legacy, >> and use them in the unit tests going forward, just to make sure >> the machinery builds correct descriptions? >> >> (I don't expect to answer to be #2, I just put it there for completeness.) > > In short, #2 and #3. > > IIUC, you are not against "continue adding new xml files" in #2, you are > against that we have to maintain the list here as we add new xml files. Well, I wasn't ever expecting we'd end up with #2. I guess I don't see the point of going through all of this if we end up with having to add manually-written xml descriptions covering all feature combinations, anyway? I could see keeping the xml files pushed in the tree, but make them generated instead? It could be gdb that generates them from that xml_and_mask array. We'd share the code with gdbserver, so that gdbserver would generate xml files on the fly to send to gdb. Or we could do the generation completely outside gdb, with some file describing the potential combinations (in spirit similar to that xml_and_mask array), much like we generate the syscall xml files. > Even we finished the transition for all ports to dynamic tdesc creation, > we still need to add new xml files to features/ directory for new > hardware features, because GDBserver needs them (regformats/*.dat need > them). We may add i386/i386-avx-mpx-avx512-linux.xml, GDB > doesn't need it, but GDBserver still needs it. Given we need to add > such .xml file, it is better to grow the list so that we can do the > test. So the answer is #2. Suppose one day, we don't need these XML > files to generate regformats/*.dat for GDBserver, we can remove all > i386-*linux.xml files except i386-avx-mpx-avx512-pku-linux.xml, but I > still want to move them to somewhere in testsuite directory to keep them > as tests. Then, it becomes #3. OK. But if there's no plan to do the gdbserver side of the work, I kind of call into question the more-complicated state we're getting into, for an indeterminately long time. > The purpose of this test is to make sure these lazily/dynamically > created tdesc (using create_feature_org_gnu_gdb_XXX functions) equal to > the tdesc created from XML files. The dynamic tdesc creation is still > new, needs more tests. > > During the process that we change other targets (amd64, arm, mips, etc) > to the dynamic tdesc creation, the lists like this are expected to be > added for each target. > > When we finish the transition to dynamic tdesc creation for all ports, > and dynamic tdesc creation is quite stable, we can remove all these > tests and lists, but I prefer to keeping the tests. I think most ports are not troublesome, WRT to explosion of target description feature set combinations. Maybe a better approach would be to fully transition an architecture all the way to dynamic generation, gdb and gdbserver? > > Before we remove these tests and lists, we still need to update the > lists when, > > 1) add a new port with target description, a new list should be added > in its -tdep.c file. > 2) add a new xml target description for the existing port, > > Let me think about how to generate this list instead of manually > maintain this list. Thanks, Pedro Alves