From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wJkLO0sm/F8gEwAAWB0awg (envelope-from ) for ; Mon, 11 Jan 2021 05:19:55 -0500 Received: by simark.ca (Postfix, from userid 112) id EE5BD1EEEF; Mon, 11 Jan 2021 05:19:55 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED, MAILING_LIST_MULTI,T_DKIM_INVALID,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id AC8931E4F4 for ; Mon, 11 Jan 2021 05:19:54 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 608A5385800B; Mon, 11 Jan 2021 10:19:54 +0000 (GMT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id 562BB385800B for ; Mon, 11 Jan 2021 10:19:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 562BB385800B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wm1-x332.google.com with SMTP id n16so10573164wmc.0 for ; Mon, 11 Jan 2021 02:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=pi+YGRjbWtmtMB5aJgmtanmO4ubdWB48beTby0SGPyg=; b=Emiy0uN/+Uhw+/m+8iQJNnj2TnbAPVOcbcTVvpgt1q0Sdr6eQv6VotgCku2U+qe+fj 88QNNjjO8VOM4W8mLTd6hD6TDHJjbUWBf2wxzj2pDlRN/20vRmzS7UQqE5e9gsO5uxN7 GVbAc7wC+L7JyX2sMxeVsah3KfA/z3XxOTzjYZjuJ3mfmAq5ULpdvfOgKMDyblrn6wQ4 VzOqZH9APBBpVKdq8ACR1X6oEGxYwmjIQ/7rP9fi5cqbTeuO22+J1BWMOXmEBRaqb1d8 g85XAsRG6trEt33EJDVBTbP+le05Y2Z4iHc3DJP0ddqdi3/rb0C7kq8quSXfhFQ/MDoS g+Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=pi+YGRjbWtmtMB5aJgmtanmO4ubdWB48beTby0SGPyg=; b=k+zYyUMdbBOZAllj39qoFhAyX1Tbq6mnowM1XNn38n5AzQnMlc/nDv0WO0ZB4EReW1 jirLriy+TzyT61a38wE24H1wIRK0sPbyoeIWtELTJ0D9HcOS1L0bqn86LFDCEv4UQw4h b+nYi6aG95jlY/va2yM1DJJw139WHUl7L7bhnj2HJhcXLw7uN5D+gT1skypWnwOy7MI4 T58+oKL6Y9WvLPtudPE0pQZ8irDISxqpdmowun3NpnM9wb9Il1QZRHFpCyOHHtqf0Ce+ p2ynpnhffqnMwwP3IR9Qm4l8glWVAZn7kkHqoWdHUHI1cIUTL74ApGFVpvQH+l7i10fe RJlQ== X-Gm-Message-State: AOAM533K9F3+bRc10LJlrLGp3MAMkSrSNCsJt2IJjZ9Ny76yqL5ry/EO JCUCdNVAOO9ce4H8jVATT333og== X-Google-Smtp-Source: ABdhPJzhMALpUbBAjNw8Q1v2mnqcTkEMXfyPjMf1pPUIURcD0l8+bDixn3uXXLHtCwEtY3MTjQOFzw== X-Received: by 2002:a05:600c:22d9:: with SMTP id 25mr13720176wmg.158.1610360390441; Mon, 11 Jan 2021 02:19:50 -0800 (PST) Received: from localhost (host86-166-129-230.range86-166.btcentralplus.com. [86.166.129.230]) by smtp.gmail.com with ESMTPSA id n189sm21488877wmf.20.2021.01.11.02.19.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Jan 2021 02:19:49 -0800 (PST) Date: Mon, 11 Jan 2021 10:19:48 +0000 From: Andrew Burgess To: Binutils , gdb-patches@sourceware.org Subject: Re: [PATCH 2/8] bfd/binutils: support for gdb target descriptions in the core file Message-ID: <20210111101948.GA1151657@embecosm.com> References: <4e0141d22b4b5bbf56e42d037f03f82485cf5bc4.1606930261.git.andrew.burgess@embecosm.com> <98c2b9bb-10bc-5141-19cf-0705e2e97ec0@linaro.org> <706a8b29-7c5c-a238-a78b-59637b8eb61b@linaro.org> <20201214115512.GI2945@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20201214115512.GI2945@embecosm.com> X-Operating-System: Linux/5.8.13-100.fc31.x86_64 (x86_64) X-Uptime: 10:18:08 up 33 days, 15:02, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" * Andrew Burgess [2020-12-14 11:55:12 +0000]: > * Luis Machado [2020-12-03 09:16:33 -0300]: >=20 > > On 12/2/20 7:58 PM, Jim Wilson wrote: > > > On Wed, Dec 2, 2020 at 10:21 AM Luis Machado via Gdb-patches > > > > wrot= e: > > >=20 > > > For the constant, I find the magic number amusing, but I don't th= ink it > > > does any good when you're trying to find out why that particular = magic > > > number was picked, and what the next number should be. > > >=20 > > > Should we go with the basic increasing ID instead? I think this > > > would be > > > 7, right after NT_AUXV. > > >=20 > > >=20 > > > 7 is NT_FREEBSD_THRMISC which would prevent use of this on FreeBSD.= =A0 I > > > know this is primarily for bare metal core files, but it might be use= ful > > > for linux and *bsd systems that have different register sets, because= of > > > different extensions, with vector versus without vector, or because > > > different hardware has different sets of implemented CSRs.=A0 We don't > > > appear to have reserved ranges for NT_* values, though we sort of hav= e a > > > scheme for processor specific values, e.g. 0x1XX for ppc, 0x2XX for x= 86, > > > 0x3XX for s390, etc.=A0 OS specific values tend to be low values below > > > 0x100 but above 6, with only FreeBSD starting at 7 and most others > > > starting at 10.=A0 So that leaves high values like ascii encodings of= the > > > NT_* name as safe for new uses.=A0 There are 3 of these already, this > > > would be a fourth one. > >=20 > > Sure, we should make this generic for all OS' to use. > >=20 > > The processor-specific values are a good example of organized ID struct= ure. > > They're all pretty obvious to look at and to identify. > >=20 > > If the OS-specific values are low ID's, then maybe we should start a new > > range of high values for the generic NT_* notes. That should make things > > more organized in the future, and folks will know what the next ID is. > >=20 > > I don't particularly think having 3 ascii encoded constants is a good > > motivation for having more. NT_PRXFPREG is Linux-specific, which is not > > good. > >=20 > > Otherwise, if we're sticking to the ascii encodings, we should document= that > > and group them together in their own section instead of just grouping t= hem > > with the Linux ones, which is a bit misleading. >=20 > What if I set aside the values 0xff000000 to 0xffffffff for non-os > specific notes, the new comment and code might look like this: >=20 > /* The range 0xff000000 to 0xffffffff is set aside for notes that > might be applicable for any OS. This range of values will > hopefully not conflict with OS specific, but architecture > agnostic notes, which tend to have low values, or architecture > specific notes that tend to have values in the range 0x100+. */ >=20 > #define NT_GDB_TDESC 0xff000000 >=20 > Thoughts? Ping! Any thoughts on the above suggestion (using constant 0xff000000) compared to the original suggestion (using constant 0x54444553)? Thanks, Andrew >=20 > Thanks, > Andrew