From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89568 invoked by alias); 18 May 2017 11:21:27 -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 89003 invoked by uid 89); 18 May 2017 11:21:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=UD:dtd X-HELO: mail-pg0-f66.google.com Received: from mail-pg0-f66.google.com (HELO mail-pg0-f66.google.com) (74.125.83.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 18 May 2017 11:21:23 +0000 Received: by mail-pg0-f66.google.com with SMTP id h64so5643924pge.3 for ; Thu, 18 May 2017 04:21:27 -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=iv3qJ2BCrO2G9PupkWNpaLOiIlrz8hOIS3knYspl6uw=; b=r1ZF7qfukMVWzb8IoBtFcRQSFQreqCfOBLND/ViJipqZo0CnLKng5gxpG2tTydfF5x CxEbeQKH3yIWoyUZBxgL0EtCuwZOsVT/UYVHe3GYbejLyafWYzzDgxW9boAoVHrgktda Xl+LvoTRkflIqa0Tmn39HRLB5hxOLCc/EZBx7NSLPJC2NyO5FoBOvQzvsHuCVkYAovrR ezRfv7pKsdtj4wdPLquj21bwKSsPsE5UkXUPrIYzhT64RC/22OobX+/m+Gncd9/LnXyI Cg/IT4IrXqQ1F4nNRbhdkxcwXb2Sq01OcTofC4Qbz80PuJWm2V/zVUlK6VSE0w24rceL vNKA== X-Gm-Message-State: AODbwcCVrKD2zR3BclroN39gSdAyUej1oOl8Jde0EoF5hnYrQ19dYLR+ A4hUWZU3bTIYHg== X-Received: by 10.98.68.2 with SMTP id r2mr3897041pfa.45.1495106485726; Thu, 18 May 2017 04:21:25 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id v45sm11714528pgn.56.2017.05.18.04.21.23 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 18 May 2017 04:21:25 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: Philipp Rudo , gdb-patches@sourceware.org Subject: Re: [RFC 4/7] Share code in initialize_tdesc_ functions References: <1494518105-15412-1-git-send-email-yao.qi@linaro.org> <20170511205504.cnufjdz6ehnml5wv@localhost> <20170516140217.1f2d3c64@ThinkPad> <148caa86-619a-9941-071b-7f38c817db33@redhat.com> Date: Thu, 18 May 2017 11:21:00 -0000 In-Reply-To: <148caa86-619a-9941-071b-7f38c817db33@redhat.com> (Pedro Alves's message of "Wed, 17 May 2017 16:43:20 +0100") Message-ID: <867f1e8l75.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/msg00416.txt.bz2 Pedro Alves writes: Hi Philipp and Pedro, Thanks for your comments. >> This function is actually the part I like least of your implementation. = Its >> way to long and barely readable. The way I understand, it is needed to = create >> unique macro and function names. So why don't you simply use the filena= me of >> the XML file where the feature is defined? It already is unique. Or us= e an >> gdbarch hook so every architecture can decide for itself how to name the= m? > > Agreed. I was reading the patch and thinking how there must be a better > way to handle this. I dislike my implementation either. I thought about using xml feature file name to distinguish features with the same name. However it doesn't work because the file name is lost after processing xi:include. GDB processes XML target descriptions in two steps, 1) process xi:include, copy feature xml files into a buffer, 2) parse the buffer with gdb-target.dtd then, All tdesc_features are created in step 2, and GDB doesn't know what file is this feature from. For example, there is an XML target description, after step 1, the buffer contains XML contents from 32bit-core.xml, ... GDB starts parse it in buffer, but doesn't know where is this feature from. I'll think about gdbarch hook you suggested. --=20 Yao (=E9=BD=90=E5=B0=A7)