From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id A893C3858005 for ; Thu, 10 Aug 2023 18:56:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A893C3858005 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-99bccc9ec02so177689266b.2 for ; Thu, 10 Aug 2023 11:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1691693797; x=1692298597; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NL3LrsRl1pEVrhbKOMk3ldzwjEyORjbK8LGgec31sCw=; b=aQczXKImUhK8UjcpJX6DfpgwIMtFeRfXiKtVTi2T9S4sh2y0K4FbMEojgBK8xLQQ8p xPGBBQbCzocLYlxISLvpczCYD52fDx0Pwqs0KtOMYQ96gQN2qMooI2otin4TSAsvVGXM 3ReX8HioAOpZF8riWyqD5RRXdvdVSt98RpN7HmiQyx7c3UmzsixwYmfyr3Jz6W2Ggbv6 9QOjtLZ6Z9elybLMEXqK66++fxr/MZoKqueDM6JN29QVStLsaYQg5OdH48UTEamkZ+/S N87CKhE5n5+VddE3WcxHbHCO8PtqUZ3gg1FdZnPJOTrDiE/uSFZVSIEVcRYrKTqr+++8 jdVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691693797; x=1692298597; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NL3LrsRl1pEVrhbKOMk3ldzwjEyORjbK8LGgec31sCw=; b=Vy0zztWVi1KUmcqI1dDsLwUXW8VY3FhYRcWZYUJZSGlkrehstJYrrQHWmUNpIFyMAf 50Nybqvmw+w6yDk/7S2qfZNKHx1wSHAvNa9nDvKKJ1GMIzHmqR16TjVrXlf78TB1Mopu WsGD4iVZMKmVPFpYT0XPQ3oAhBX7lVyyirdNmnbQUXdVOT6LGKU8XX/7s57tSrXoiWBk 3V60oU4xaWQER/VSJdtHc/RYwxrheXyIuvv8KKmT3HH3x9SBTZeJQXjpGjAZnNfTl0HG 3UYzvzwA8F+h7DlmWLwYREL+c+ALNMlYELogSoOesuHcS6oYL8/fBrQAm2c61BXGsCep rHZw== X-Gm-Message-State: AOJu0Yx39ETXJ/FpdKv9GxyzMsy/HumEl/fGuTnjxmVtBwv/r0M6Nn+K xdZlx5BYg85F5AVPxiampIn6xeF6zPGHh9qa4V+xmg== X-Google-Smtp-Source: AGHT+IGUHdGk3Rw33pOz4+y1oZG2cYZjrJQ0htJLqDHUNQNB7nAVVDSSATbf/4lgcNMgueZ/n5uEBBrCiSkuhDVLMhk= X-Received: by 2002:a17:907:7855:b0:993:d7cf:f58 with SMTP id lb21-20020a170907785500b00993d7cf0f58mr3105094ejc.2.1691693797251; Thu, 10 Aug 2023 11:56:37 -0700 (PDT) MIME-Version: 1.0 References: <20230809175337.1108580-1-greg.savin@sifive.com> <40cf6dfd-7948-095f-249a-9bac83ff923c@FreeBSD.org> In-Reply-To: <40cf6dfd-7948-095f-249a-9bac83ff923c@FreeBSD.org> From: Greg Savin Date: Thu, 10 Aug 2023 11:56:25 -0700 Message-ID: Subject: Re: [PATCH] Re-map value of NT_RISCV_CSR to not collide with the value of NT_RISCV_VECTOR in Linux kernel header file 'include/uapi/linux/elf.h' To: John Baldwin Cc: gdb-patches@sourceware.org, binutils@sourceware.org, palmer@dabbelt.com, greentime.hu@sifive.com, Andrew Burgess Content-Type: multipart/alternative; boundary="000000000000dac6450602962780" X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: --000000000000dac6450602962780 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Initially I tried reusing 0x900 for NT_RISCV_VECTOR, and leaving NT_RISCV_CSR in place with its original 0x900 value, and this was resulting in compile errors of "duplicate case values within a switch statement." So I figured having duplicate NT_* values was a "no no" at least in the standards of the GDB project. I'm guessing that particular compile error can be treated as a warning, but that GDB intentionally chooses compile flags to treat the duplicate case values as a hard error (?) --Greg On Thu, Aug 10, 2023 at 11:39=E2=80=AFAM John Baldwin wro= te: > On 8/9/23 10:53 AM, Greg Savin via Gdb-patches wrote: > > Linux kernel's file 'include/uapi/linux/elf.h' declares the value 0x900 > > for NT_RISCV_VECTOR, and does not have a definition for NT_RISCV_CSR, n= or > > does it use the value 0x901 for any note type. This patch is intended > > as a way to resolve the disagreement/collision between Linux and > binutils, > > over the meaning of 0x900 in the context of note types. > > > > --- > > include/elf/common.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/include/elf/common.h b/include/elf/common.h > > index ffa6b60bd2b..0bbe245519e 100644 > > --- a/include/elf/common.h > > +++ b/include/elf/common.h > > @@ -713,7 +713,7 @@ > > /* note name must be "LINUX". = */ > > #define NT_LARCH_LBT 0xa04 /* LoongArch Binary > Translation registers */ > > /* note name must be "CORE". */ > > -#define NT_RISCV_CSR 0x900 /* RISC-V Control and > Status Registers */ > > +#define NT_RISCV_CSR 0x901 /* RISC-V Control and > Status Registers */ > > /* note name must be "LINUX". = */ > > #define NT_SIGINFO 0x53494749 /* Fields of siginfo_t. */ > > #define NT_FILE 0x46494c45 /* Description of mapped > files. */ > > If there aren't any active uses of NT_RISCV_CSR "in the wild", then it > might be > better to just remove it entirely? > > It looks like commit e214f8db56f65531b0a5ec296c42339dcaa5af31 adding > LoongArch > constants inadvertently changed the comment for this note from "CORE" (a > binutils note) to "LINUX" (a Linux kernel note). > > The log message adding NT_RISCV_CSR is clearer (though the comment in > common.h > is wrong and should be "GDB" it seems): > > commit db6092f3aec43ea4d10efc5ff74274f04cdc0ad6 > Author: Andrew Burgess > Date: Fri Nov 27 14:04:16 2020 +0000 > > bfd/binutils: add support for RISC-V CSRs in core files > > Adds support for including RISC-V control and status registers into > core files. > > The value for the define NT_RISCV_CSR is set to 0x900, this > corresponds to a patch I have proposed for the Linux kernel here: > > > http://lists.infradead.org/pipermail/linux-riscv/2020-December/003910.html > > As I have not yet heard if the above patch will be accepted into the > kernel or not I have set the note name string to "GDB", and the note > type to NT_RISCV_CSR. > > This means that if the above patch is rejected from the kernel, and > the note type number 0x900 is assigned to some other note type, we > will still be able to distinguish between the GDB produced > NT_RISCV_CSR, and the kernel produced notes, where the name would be > set to "CORE". > > Seems like the kernel patch died on the vine (no responses to the patch). > GDB does support writing this out still though via the ".reg.riscv-csr" > pseudo section, so changing this would break debugging bare metal core > dumps. You can however, just re-use 0x900 for NT_RISCV_VECTOR without > this patch. The different note name is sufficient to differentiate the > two. > > -- > John Baldwin > > --000000000000dac6450602962780--