From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 1u2wNiocyF/cegAAWB0awg (envelope-from ) for ; Wed, 02 Dec 2020 17:58:50 -0500 Received: by simark.ca (Postfix, from userid 112) id D38E91F0AB; Wed, 2 Dec 2020 17:58:50 -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 112391E552 for ; Wed, 2 Dec 2020 17:58:50 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8F839396E43E; Wed, 2 Dec 2020 22:58:49 +0000 (GMT) Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) by sourceware.org (Postfix) with ESMTPS id 86310396E43C for ; Wed, 2 Dec 2020 22:58:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 86310396E43C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jimw@sifive.com Received: by mail-ej1-x642.google.com with SMTP id bo9so491300ejb.13 for ; Wed, 02 Dec 2020 14:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W4SBuZjBeXdhJDigGomQpwRdxt1hQ7VUMnJQmz2DQrc=; b=S5U4QsXLOT5i2fW9WdS3ci4RrrRpUsFV17dIWgSEeXtPWTNrYTDf9kRjM4zeV4zbRW RkxCyh6oYXhSbNkly5duBeE4UNloNMBq8pUD1nfDkGj0Bhz2z0zOctLXXd/Gtl+duaYH bqv4vnM8HNcjUr8ahy0M5Zr+UAH/mZBtGkX1hF9ei9jjcjiwx2D0T/N4dMxNlPqZHDoo FGtMEoCM9MW5yEzSNMQ/Pj+23O/VH68sPTzHMhulSljqPHtXHDDtvYbD4BJUb0xncS1L zWCAY/ahYJc6GxJ5FBJG2I+DGTT6QIQ580YNUfHXYNQ8mpxfX/4Dtt3RdKwjetKn+2yj tzEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W4SBuZjBeXdhJDigGomQpwRdxt1hQ7VUMnJQmz2DQrc=; b=XESCh+uHymjXCrce/5K0pAPR8LwsX8CxsrlvKPo6t+rqj2o5sWg3iRXq51O3aNQlrm HskbUzG+nIbePsRlvBHnlV8dyY/KqqS4OOOv89J2DkgeWFwLBnSYapgaMXfO5OQ9JiAL WdUSyYVPFWJs3yEFqjox7h8zUB3ENpJZYKlLSgE+k9x06bwJJO+5FAlHTPPz3Lu8Fej4 c2UvqKO4DwzZ++DwYFGKzNzrOQpvuWh7kJc7/b+6NfsgovqMkvhOXRgGrmBNim5DoKeW i/TKJq6+7gFryYK5uCFP04qs/GAml69cbH2TrVItXk4Y60QoA7kq9gEeTY0lBUDUf6YC 2BdA== X-Gm-Message-State: AOAM533NYZqBznIY1J12sCcASg4OS/hE7QZD5c++6YVeKJer3sixrwZ9 EYfdgm++R5Ble6loaewCKuJPOLO91sTj9DHyq4ZnPQ== X-Google-Smtp-Source: ABdhPJzWOZnrFnAnY09eEZ0pqM47QvJws4Loguayybfj1zRrrR8pu1cKQ8dPm4XjqxDVkBnKBCIhcbHwR46ku3xI9R8= X-Received: by 2002:a17:906:6546:: with SMTP id u6mr82875ejn.36.1606949926662; Wed, 02 Dec 2020 14:58:46 -0800 (PST) MIME-Version: 1.0 References: <4e0141d22b4b5bbf56e42d037f03f82485cf5bc4.1606930261.git.andrew.burgess@embecosm.com> <98c2b9bb-10bc-5141-19cf-0705e2e97ec0@linaro.org> In-Reply-To: <98c2b9bb-10bc-5141-19cf-0705e2e97ec0@linaro.org> From: Jim Wilson Date: Wed, 2 Dec 2020 14:58:35 -0800 Message-ID: Subject: Re: [PATCH 2/8] bfd/binutils: support for gdb target descriptions in the core file To: Luis Machado Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: , Cc: gdb-patches@sourceware.org, Binutils Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On Wed, Dec 2, 2020 at 10:21 AM Luis Machado via Gdb-patches < gdb-patches@sourceware.org> wrote: > For the constant, I find the magic number amusing, but I don't think 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. > > Should we go with the basic increasing ID instead? I think this would be > 7, right after NT_AUXV. > 7 is NT_FREEBSD_THRMISC which would prevent use of this on FreeBSD. I know this is primarily for bare metal core files, but it might be useful 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. We don't appear to have reserved ranges for NT_* values, though we sort of have a scheme for processor specific values, e.g. 0x1XX for ppc, 0x2XX for x86, 0x3XX for s390, etc. 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. So that leaves high values like ascii encodings of the NT_* name as safe for new uses. There are 3 of these already, this would be a fourth one. Jim