From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id A4AFC3858D1E for ; Tue, 7 May 2024 15:43:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A4AFC3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A4AFC3858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715096624; cv=none; b=JrVzLbbA1i6oRttag3ShogGDO3piUZuiqxwY4VcIvt5zdwwBXXILuIutNlAsIizoPr0uC2q99wA7t4MKBjzlUCtYkBnI3vTQAvanbPymTpa/JqPKS/ZvN+buA4nfREerWrPWQBLIAet+eTz17Xsy//ULUAUS5owibPA3PqAGin0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715096624; c=relaxed/simple; bh=V8530FYlmLmlJfLiXK7ZvXIUFa6Q6LkCwnFH/Hbm468=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=t0aCWgQaJKAuA4EfnusKlaMBe+ZYO8ZY4v+2ndh528I5R2vYFjb8PIUuYqdjg0aiUNYCCWiDpJjqIX/lHc9kwh57WZngZd10Z1Yrx5xFt7Wn4xnwbGSlF13GFpY5zNPYYeXTzMcg5tb6sOp2ijENe1VVuGwDg+9+CRq9Z+gK0FA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1715096621; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rqBbjxTAnKuGo1rYtajGUWOcMVZlY8zIJkSMjNMp6YQ=; b=GXMhSyB5nXC2k/QHr22AL2OB67o4EPnP7jYkc7/RHWTn9Rwe0Ds9yoSzJqjQ271T3nyv2k Q9/9TGXPIFB68EyKb1U8EdKPzLPv3cyvMnlhuL9tiPxcxu7kcV0CGjj7i3vSf28NM4P+fY F6OWOCLc2N2iLIM9GM5bhQRQ4K2/I3Y= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-216-h5GUMBgQNhWusPiRV2M6NA-1; Tue, 07 May 2024 11:43:40 -0400 X-MC-Unique: h5GUMBgQNhWusPiRV2M6NA-1 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-34dc34c758fso1822992f8f.0 for ; Tue, 07 May 2024 08:43:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715096618; x=1715701418; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rqBbjxTAnKuGo1rYtajGUWOcMVZlY8zIJkSMjNMp6YQ=; b=YXFOqb0K1vlb7zIcTkvGcJWwNZVUU0EMgOVlY6eNkOE+3N2fNPTa4rOcfBLwBgBrTJ mPRR5HCRGDFmDP21F6y+BF8XjmlRxdX7kTSOxnlblACU/auBt1WHTsZcsurwxLffgy1H DguCRWeEIZIJYRj/ehOKo1J+I8hmxx5rPzSyib7eCg5LQPzn8nClmBoskvILW8YKG1He SsZxSfagB2oVOSLoIKW0pTFDpQO6OkV2YMuUDde0qYx0KedPC59OHZKudrpocyoBSc03 rPBpfhLeLFE72pe96z7vhpd8BcN6dcgOxD13s4PN34YcqfjM5aDaK12hm6HAb9+OSOSe DTBw== X-Forwarded-Encrypted: i=1; AJvYcCVzt9DeRrG0HOQj1zjnkfz6nzrBNih9y7ns1QvIFi/8EfGIsslWro2q8rpRxkmRi5e8EVgEDA7bkANdJWG+zw96F98YdTStv+iHLA== X-Gm-Message-State: AOJu0YyvOD4cZBIOlcGBe2P2Y2OrY42TK4X+JZNZPNefuos3Zn0KLngw iqaQV3Qucza7iwq4shBWYk7Run4Q/DCeMtudM/8zrORIaiQ0Wv8B5n9h3VrDKouYOHmm44vgxyy Twop2Y1l6FUYLPWQjI453mqXXhpd0O4dCgTwNXu6rRYYMIO3Tn0YQI3y6zSUV3Amg0Tk= X-Received: by 2002:a05:600c:3d86:b0:418:fe93:22d0 with SMTP id 5b1f17b1804b1-41f71ccc087mr1422095e9.11.1715096617538; Tue, 07 May 2024 08:43:37 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGDZoGm7KWqlw/Ui2Mk/PzKOIRugXBFFmMjHpAWU+GM7SdC6a49bYTKu/8MSXeZHFeqwq1wNA== X-Received: by 2002:a05:600c:3d86:b0:418:fe93:22d0 with SMTP id 5b1f17b1804b1-41f71ccc087mr1421785e9.11.1715096616641; Tue, 07 May 2024 08:43:36 -0700 (PDT) Received: from localhost ([31.111.84.240]) by smtp.gmail.com with ESMTPSA id y17-20020a5d4ad1000000b0034cfa17d74dsm13158611wrs.104.2024.05.07.08.43.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 May 2024 08:43:36 -0700 (PDT) From: Andrew Burgess To: Luis Machado , "Willgerodt, Felix" , "gdb-patches@sourceware.org" Cc: John Baldwin Subject: Re: [PATCHv5 05/11] gdbserver/x86: move no-xml code earlier in x86_linux_read_description In-Reply-To: <9e95c677-b640-43af-903b-b01a48d5ac67@arm.com> References: <6e7440d3bb04135432f9f18e0630ee1bca23e4d6.1714143669.git.aburgess@redhat.com> <9e95c677-b640-43af-903b-b01a48d5ac67@arm.com> Date: Tue, 07 May 2024 16:43:34 +0100 Message-ID: <87h6f9tyop.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Luis Machado writes: > On 4/29/24 15:34, Willgerodt, Felix wrote: >>> -----Original Message----- >>> From: Andrew Burgess >>> Sent: Freitag, 26. April 2024 17:02 >>> To: gdb-patches@sourceware.org >>> Cc: Andrew Burgess ; Willgerodt, Felix >>> ; John Baldwin >>> Subject: [PATCHv5 05/11] gdbserver/x86: move no-xml code earlier in >>> x86_linux_read_description >>> >>> This commit is part of a series that aims to share more of the x86 >>> target description reading/generation code between GDB and gdbserver. >>> >>> There are a huge number of similarities between the code in >>> gdbserver's x86_linux_read_description function and GDB's >>> x86_linux_nat_target::read_description function, and it is this >>> similarity that I plan, in a later commit, to share between GDB and >>> gdbserver. >>> >>> However, one thing that is different in x86_linux_read_description is >>> the code inside the '!use_xml' block. This is the code that handles >>> the case where gdbserver is not allowed to send an XML target >>> description back to GDB. In this case gdbserver uses some predefined, >>> fixed, target descriptions. >>> >>> First, it's worth noting that I suspect this code is not tested any >>> more. I couldn't find anything in the testsuite that tries to disable >>> XML target description support. And the idea of having a single >>> "fixed" target description really doesn't work well when we think >>> about all the various x86 extensions that exist. Part of me would >>> like to rip out the no-xml support in gdbserver (at least for x86), >>> and if a GDB connects that doesn't support XML target descriptions, >>> gdbserver can just give an error and drop the connection. GDB has >>> supported XML target descriptions for 16 years now, I think it would >>> be reasonable for our shipped gdbserver to drop support for the old >>> way of doing things. >> >> Interesting. I for one would +1 this. Slightly related: >> I wonder if anyone really builds GDB without libexpat anymore and >> if we couldn't even think of making it mandatory. (Which doesn't >> mean dropping the ball on supporting stubs without XML.) > > I'd support making xml descriptions mandatory for some targets. AArch64 and > 32-bit Arm both rely heavily on xml description for feature discovery. I might be wrong, but I don't think Felix was even suggesting we need to go that far. I think the suggestion was just that GDB itself should require libexpat, which would mean we have the potential to read XML target descriptions. This wouldn't mean that targets would be required to send XML target descriptions. My comment was specifically that x86 gdbserver should drop its no XML support, and if a user tries to connect with a no XML GDB then gdbserver would reject the connection. Moving to make libexpat a requirement would help in this case as a user would no longer be able to build a GDB which couldn't connect to an x86 gdbserver. > Off the top of my head, I think very old probes and the Linux Kernel's kgdb don't > support xml. I'm not sure how often kgdb gets used though, but falling back to a > default description should work for AArch64 and 32-bit Arm. I don't believe building GDB with libexpat support breaks the ability to connect to a target which doesn't support XML descriptions (if it does then that's a bug), so hopefully nobody else would be inconvenienced... except for those folk who are building GDB without libexpat support. I've added making these changes to my todo list, but I don't want to add them to this series. Thanks, Andrew