From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108367 invoked by alias); 6 Nov 2017 11:49:55 -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 107994 invoked by uid 89); 6 Nov 2017 11:49:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=separated, H*r:sk:static. X-HELO: mail-wr0-f175.google.com Received: from mail-wr0-f175.google.com (HELO mail-wr0-f175.google.com) (209.85.128.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 06 Nov 2017 11:49:53 +0000 Received: by mail-wr0-f175.google.com with SMTP id l18so4847249wrc.3 for ; Mon, 06 Nov 2017 03:49: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:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=zlA2K66RjJhdcgaaCDJr1a2hrYsfchVzc4MmxevgQUc=; b=sAMRbg5S1KfyhQFVr9byUk4n1gS3QkMajBWs57Ttg1oz9RDQs+3LrmKAUTse3KAVku 1OhcIfnseB7tSkc7/YAuznos8UXi5JGuvwz8zA2qCn6jSg0jVAmm7sZsyrET0/BJSeLr RZezJQuNQCyj8FDqJV/Cv0rDBm9PNimYTvO4F6569UKd9Zypgkj1BFJwdameBYeuunKD EFGOf1RnLKCSPauvNhskvs02PsrIB1lHP7w7rd3OjHzTTzPt/7bQqzY3Gnw8JqEeJBga 9nl6i+7uHUMssnEsBtTzPBzx34W/qdzUdBS54dQRVrxwHR1kz6zW53rG4VIjraminowz vhNg== X-Gm-Message-State: AMCzsaXP/0L5fwoe2ac7KQprE5DDncnpDdhe0LK590PwqYJJ+uGuYANy mMpZ18AVn1ps/uSErWzmoZo1fA== X-Google-Smtp-Source: ABhQp+TGUh1EUpzRHw9Dtbt8/v+LiNT9D8+vx/L9KtcL/kCf1LaeqrXaVDGhAUR+FOqWCkYmx3DplQ== X-Received: by 10.223.191.10 with SMTP id p10mr10783589wrh.127.1509968990948; Mon, 06 Nov 2017 03:49:50 -0800 (PST) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id t18sm6092255wrg.49.2017.11.06.03.49.49 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 06 Nov 2017 03:49:50 -0800 (PST) From: Yao Qi To: Alan Hayward Cc: "gdb-patches\@sourceware.org" , nd Subject: Re: [PATCH 3/4] Use flexible target descriptors for aarch64 References: <86h8ugyenj.fsf@gmail.com> <8EE70574-8937-414B-9903-0E427D388B07@arm.com> Date: Mon, 06 Nov 2017 11:49:00 -0000 In-Reply-To: <8EE70574-8937-414B-9903-0E427D388B07@arm.com> (Alan Hayward's message of "Mon, 6 Nov 2017 10:06:27 +0000") Message-ID: <86a7zzwrs5.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-11/txt/msg00108.txt.bz2 Alan Hayward writes: > In the existing code, osabi is never set for aarch64 - the osabi line is = missing > from the .xml files. Some other architectures set to =E2=80=9CGNU/Linux= =E2=80=9D. I assumed > there was a reason aarch64 didn=E2=80=99t do this. I didn=E2=80=99t want = to change > this behaviour, Agreed, it should be a separated patch to address this, if needed. See PR 19895 "gdbserver target description on aarch64/arm doesn't specify osabi" > so instead in my code osabi is set to =E2=80=9C=E2=80=9D. However, setting osabi to "" in GDBserver may slightly change the the XML content GDB received from GDBserver. Without your changes, the XML contents received from GDBserver doesn't have "XXX", however with your changes, the XML contents have "". Can you confirm this? The change like this doesn't affect any GDB's behavior, because osabi in GDB side is still GDB_OSABI_UNKNOWN. On the other hand, "osabi" is an optional field, https://sourceware.org/gdb/current/onlinedocs/gdb/Target-Description-Format= .html so it is optional in "tdesc" too. IMO, we need to remove "tdesc->osabi !=3D NULL" from the assert, and let GDBserver only generate "XXX" when tdesc->osabi isn't NULL. What do you think? --=20 Yao (=E9=BD=90=E5=B0=A7)