From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-145139-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 66090 invoked by alias); 29 Jan 2018 18:18:54 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Received: (qmail 66069 invoked by uid 89); 29 Jan 2018 18:18:54 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=UD:dtd, justification, DOCTYPE, !DOCTYPE
X-HELO: mail-wm0-f42.google.com
Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com) (74.125.82.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Jan 2018 18:18:52 +0000
Received: by mail-wm0-f42.google.com with SMTP id b21so35559844wme.4        for <gdb-patches@sourceware.org>; Mon, 29 Jan 2018 10:18:52 -0800 (PST)
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-language         :content-transfer-encoding;        bh=3iyfk/tKr89XVriMUPPI/JU3q5aB6j7of7o9DfN+/ys=;        b=YTVgHYQvkyKPi66jKZEJuFd7o+SMkpKi5+wMj37Pr9BTFI0f5Tk3adBN+B42HmeqJN         iCCOMbgeWAOfJmyOx5CiPbx1GsEdEYNNz8fT25jrOZ1EtyrCJlt8oLotcp825bZYeslz         cXICl5qxqXQ+RCBJZIQeSyy6m8dfugme8rQTNGRxO/HOFL4muiXxW3xLiluBXBrpGxn7         w6JaO9feSR6qr5Ej7617hZIxCwGJITZsa9k5tWn7PgUCEzb5REAHT4SyFehvFQ+3YnuD         hBzA2lPpDxZtWJtnX0wTBcD2RuFvWwThKy0aInq3N+BRQ2VEGoq0/84+zzagMhwU8FbW         tZrA==
X-Gm-Message-State: AKwxytejKxDsFMhchzzBb1d9RIg5wFq606mJ0Cg6+1/d5wyXccdiKoNP	vMJxJozCcwDWkxM+OyfnOmE2fSgMnkY=
X-Google-Smtp-Source: AH8x224XSAwab4l9rMJUSUcC/deb1txAxJmpibqwaF/8wi1osEZaMHc5dYdHKUvQtCxw9ZV2EUtRKQ==
X-Received: by 10.28.112.15 with SMTP id l15mr18621044wmc.119.1517249930696;        Mon, 29 Jan 2018 10:18:50 -0800 (PST)
Received: from ?IPv6:2001:8a0:f915:7500:56ee:75ff:fe8d:232b? ([2001:8a0:f915:7500:56ee:75ff:fe8d:232b])        by smtp.gmail.com with ESMTPSA id z12sm10298291wrz.20.2018.01.29.10.18.49        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);        Mon, 29 Jan 2018 10:18:49 -0800 (PST)
Subject: Re: [PATCH v2 0/8] Remove XML files from gdbserver
To: Alan Hayward <Alan.Hayward@arm.com>, "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
References: <7C97CC6A-92CB-4702-820D-206022F07102@arm.com>
Cc: nd <nd@arm.com>
From: Pedro Alves <palves@redhat.com>
Message-ID: <cd346e62-8225-c09b-ac31-f3565c563072@redhat.com>
Date: Mon, 29 Jan 2018 18:18:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <7C97CC6A-92CB-4702-820D-206022F07102@arm.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SW-Source: 2018-01/txt/msg00613.txt.bz2

On 01/24/2018 09:26 AM, Alan Hayward wrote:
> In exisiting code, gdbserver uses C code auto generated from xml files to
> create target descriptions. When sending an xml description to GDB, it
> creates an xml containing just the name of the original xml file.
> Upon receipt, GDB reads and parses a local copy of xml file.

Huh?  What do you mean reads and parses a _local copy_?
That's false AFAICS.

GDB fetches named file from the server, not from the local filesystem.
E.g., on x86-64:

Sending packet: $qXfer:features:read:target.xml:0,fff#7d...Packet received: l<?xml version="1.0"?><!DOCTYPE target SYSTEM "gdb-target.dtd"><target><architecture>i386:x86-64</architecture><osabi>GNU/Linux</osabi><xi:include href="64bit-core.xml"/><xi:include href="64bit-sse.xml"/><xi:include href="64bit-linux.xml"/><xi:include href="64bit-segments.xml"/><xi:include href="64bit-avx.xml"/></target>
Sending packet: $qXfer:features:read:64bit-core.xml:0,fff#75...Packet received: l<?xml version="1.0"?>\n<!-- Copyright (C) 2010-2018 Free Software Foundation, Inc.\n\n     Copying and distribution of this file, with or without modification,\n     are permitted in any medium without royalty provided the copyright\n     notice and this notice are preserved.  -->\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.i386.core">\n  <flags id="i386_eflags" size="4">\n    <field name="CF" start="0" end="0"/>\n    <field name="" start="1" end="1"/>\n    <field name="PF" start="2" end=[12 bytes omitted]
Sending packet: $qXfer:features:read:64bit-sse.xml:0,fff#17...Packet received: l<?xml version="1.0"?>\n<!-- Copyright (C) 2010-2018 Free Software Foundation, Inc.\n\n     Copying and distribution of this file, with or without modification,\n     are permitted in any medium without royalty provided the copyright\n     notice and this notice are preserved.  -->\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.i386.sse">\n  <vector id="v4f" type="ieee_single" count="4"/>\n  <vector id="v2d" type="ieee_double" count="2"/>\n  <vector id="v16i8" type="int8" count="16"/>\n  <vec[12 bytes omitted]
Sending packet: $qXfer:features:read:64bit-linux.xml:0,fff#fc...Packet received: l<?xml version="1.0"?>\n<!-- Copyright (C) 2010-2018 Free Software Foundation, Inc.\n\n     Copying and distribution of this file, with or without modification,\n     are permitted in any medium without royalty provided the copyright\n     notice and this notice are preserved.  -->\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.i386.linux">\n  <reg name="orig_rax" bitsize="64" type="int" regnum="57"/>\n</feature>\n
Sending packet: $qXfer:features:read:64bit-segments.xml:0,fff#32...Packet received: l<?xml version="1.0"?>\n<!-- Copyright (C) 2016-2018 Free Software Foundation, Inc.\n\n     Copying and distribution of this file, with or without modification,\n     are permitted in any medium without royalty provided the copyright\n     notice and this notice are preserved.  -->\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.i386.segments">\n  <reg name="fs_base" bitsize="64" type="int"/>\n  <reg name="gs_base" bitsize="64" type="int"/>\n</feature>\n
Sending packet: $qXfer:features:read:64bit-avx.xml:0,fff#1b...Packet received: l<?xml version="1.0"?>\n<!-- Copyright (C) 2010-2018 Free Software Foundation, Inc.\n\n     Copying and distribution of this file, with or without modification,\n     are permitted in any medium without royalty provided the copyright\n     notice and this notice are preserved.  -->\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.i386.avx">\n  <reg name="ymm0h" bitsize="128" type="uint128"/>\n  <reg name="ymm1h" bitsize="128" type="uint128"/>\n  <reg name="ymm2h" bitsize="128" type="uint128"/>[11 bytes omitted]


Above we see GDB processing the xi:includes by subsequently fetching the
xi:included files from the server.

There is already some support in gdbserver for baking in the XML
code directly in gdbserver instead of reading it from (gdbserver's)
filesystem:

  /* `desc->xmltarget' defines what to return when looking for the
     "target.xml" file.  Its contents can either be verbatim XML code
     (prefixed with a '@') or else the name of the actual XML file to
     be used in place of "target.xml".

     This variable is set up from the auto-generated
     init_registers_... routine for the current target.  */

  if (strcmp (annex, "target.xml") == 0)
    {
      const char *ret = tdesc_get_features_xml ((target_desc*) desc);

      if (*ret == '@')
	return ret + 1;
      else
	annex = ret;
    }

Can you please clarify the rationale for the series?

The current justification doesn't look very convincing to me.  This
is going to be probably something around dynamic generation of XML
descriptions based on CPU optional features, instead of having
to have gdbserver carry a bunch of different XML files for each possible
combination of optional features.  (I.e., a continuation of Yao's
earlier work).

I haven't read the patches, but it's likely that you should need
to tweak the individual patches' rationales too.

Thanks,
Pedro Alves