From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20946 invoked by alias); 19 May 2017 14:27:03 -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 19492 invoked by uid 89); 19 May 2017 14:27:01 -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=H*RU:sk:static., Hx-spam-relays-external:sk:static., H*r:sk:clients, *c X-HELO: mail-yb0-f195.google.com Received: from mail-yb0-f195.google.com (HELO mail-yb0-f195.google.com) (209.85.213.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 May 2017 14:26:59 +0000 Received: by mail-yb0-f195.google.com with SMTP id d72so2560292ybh.0 for ; Fri, 19 May 2017 07:27:03 -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=d8r8+xriEGCgDMeP3jUtBrIlFJogI6yT295xHAbkzIY=; b=XQPJA5BjWjV2n/t4C5/mdtoeRfTWtV1Dax8nMFp6HotkF+LaJKqlLCTJTDUoUbgP7j 51kSKn0j/WD2AhAKmiyp6nZ9APXzXomH1yT6fMxwqZwDtAZUm94vX4fYecgIdCKPIRyL ihq/SOfjBVGtIHh2cMQUQdojiTBjCZCZpjVoe/D7F0YhS/UrGZ6aadx4Em1tLnFzHJEo eyV6K3MagCyxsok/YXj+tJRCOmlMkWgyT7tdArSv8CgAUhLhl1NaQS+S1mezadxYL8FH ZTgTYysYm+NmBP4YEeTBU42wZPng44S0B6TKZOeIC16eKrSftLY2G01DU20DNt07pDKR svNA== X-Gm-Message-State: AODbwcD89VeQIDfOV/eeJW/swjAnDt5IiqKj+fVNM/H9REI6ySHflsN3 HZlzE/BaSgo6og== X-Received: by 10.37.64.202 with SMTP id n193mr8329814yba.148.1495204021585; Fri, 19 May 2017 07:27:01 -0700 (PDT) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id s199sm3230142ywg.11.2017.05.19.07.27.00 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 19 May 2017 07:27:01 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [RFC 6/7] Lazily and dynamically create i386-linux target descriptions 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> <2688beca-29b9-6ab3-4281-a6c1070da177@redhat.com> Date: Fri, 19 May 2017 14:27:00 -0000 In-Reply-To: <2688beca-29b9-6ab3-4281-a6c1070da177@redhat.com> (Pedro Alves's message of "Fri, 19 May 2017 11:15:08 +0100") Message-ID: <868tlszzv4.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-05/txt/msg00448.txt.bz2 Pedro Alves writes: > 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, anyw= ay? > These changes are about GDB, but we still need manually-written xml files because GDBserver still needs it. There are still some benefits, - GDB binary becomes smaller, see https://sourceware.org/ml/gdb-patches/2017-05/msg00299.html - We don't have to generate a lot of gdb/features/*.c files, so don't need to include them. In i386-linux, we only need features/i386/i386-avx-mpx-avx512-pku-linux.c and all other i386*linux.c can be removed. > 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. > I try to stop using the approach we pre-generate them (both xml files and c 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. I do plan to do GDBserver side, but I don't have a clear picture on how to do it yet. I post this RFC, because this is only about GDB. This series can make GDB better and keep GDBserver unchanged, it is still a progress to me. > >> 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. >>=20 >> 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. >>=20 >> 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? ARM, MIPS, I386 and S390 have this problem to different extents. I can take GDBserver into account at this stage. I did it last month, but gave up because it was too brain-damaging. Let me try again. --=20 Yao (=E9=BD=90=E5=B0=A7)