From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id BY4sE6JM/F/VFwAAWB0awg (envelope-from ) for ; Mon, 11 Jan 2021 08:03:30 -0500 Received: by simark.ca (Postfix, from userid 112) id 40A311EEEF; Mon, 11 Jan 2021 08:03:30 -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.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [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 C82BB1E590 for ; Mon, 11 Jan 2021 08:03:29 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A2234383F85E; Mon, 11 Jan 2021 13:03:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A2234383F85E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1610370208; bh=qhNlVJ1mvISpq3w/xUiVxm7huoRPnFgH6C/2Qa0ilds=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=B6dKLh/Kw4pExABMxXQ4h2/1nYSljZ9flhdZwUHLp4tQnJNc5amRzib/ojXeYxXG2 2bCKcWfi4JiZuIwrPyJFKwLmmmU9/ENlg1UjWUFLQzCf8immbv4rBgBGlRrVNykCgL hQrgbCNvVhNPSOuduQmP8xVznyoBAxfeUt+iawJQ= Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) by sourceware.org (Postfix) with ESMTPS id 77C24386184F for ; Mon, 11 Jan 2021 13:03:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 77C24386184F Received: by mail-qt1-x832.google.com with SMTP id v5so11098068qtv.7 for ; Mon, 11 Jan 2021 05:03:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qhNlVJ1mvISpq3w/xUiVxm7huoRPnFgH6C/2Qa0ilds=; b=DP1czVVMW4QMH4/LA4s6biQji45akEkJHK7nFy120w7+wj6dD8Im4Yz7bguZyPztqP afd/UMnqzo5HqwXgpZ48ywizVzOQnR49sN1vsijLiqU+X+1GsBpiKRau98zJWP8fGyQn YnPe2dUGyXiUWUgk+ikmpDMpE4fTS0abdu6V/KjNKrCmTp3h8xMcHjoOVH3v0/Bk0EYO itdrPM1VjAoLsHGTbkgKqQEGTL42gvNuKuVdTqxU3ny5TOuaY2O1IWySXgdLYoRIdWU2 nmqjUZpH3K+R+c4WXgZj1hFXWns424W7zuygDGWPqNBH3gcB4pxwEOmEewaB/MqJNNPv RmVw== X-Gm-Message-State: AOAM533r6Wo8ZpHZ7mPvAnimODDK3xj4wuNHzpqc28uvKPBgbgFLanbt O5W3e29Uy20Bx8CkhYEUJ9ebQln4Fuj5Vg== X-Google-Smtp-Source: ABdhPJz5byyo+x22LLrkngyjGKE0/SbTkJ1Biy4tJenRmZ64yOsX6znjVIhAdpVpy6GZOAsfYheF7Q== X-Received: by 2002:ac8:721a:: with SMTP id a26mr15242233qtp.223.1610370205954; Mon, 11 Jan 2021 05:03:25 -0800 (PST) Received: from ?IPv6:2804:7f0:8284:874d:20e9:a3d4:1db5:c30a? ([2804:7f0:8284:874d:20e9:a3d4:1db5:c30a]) by smtp.gmail.com with ESMTPSA id r22sm8297837qkk.67.2021.01.11.05.03.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Jan 2021 05:03:25 -0800 (PST) Subject: Re: [PATCH 2/8] bfd/binutils: support for gdb target descriptions in the core file To: Andrew Burgess , Binutils , gdb-patches@sourceware.org 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> <20210111101948.GA1151657@embecosm.com> Message-ID: <2c0b32da-1208-009c-2d2c-af6a41510f34@linaro.org> Date: Mon, 11 Jan 2021 10:03:21 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210111101948.GA1151657@embecosm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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: , From: Luis Machado via Gdb-patches Reply-To: Luis Machado Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Hi Andrew, On 1/11/21 7:19 AM, Andrew Burgess wrote: > * Andrew Burgess [2020-12-14 11:55:12 +0000]: > >> * Luis Machado [2020-12-03 09:16:33 -0300]: >> >>> On 12/2/20 7:58 PM, Jim Wilson wrote: >>>> On Wed, Dec 2, 2020 at 10:21 AM Luis Machado via Gdb-patches >>>> > 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. >>> >>> Sure, we should make this generic for all OS' to use. >>> >>> The processor-specific values are a good example of organized ID structure. >>> They're all pretty obvious to look at and to identify. >>> >>> 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. >>> >>> 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. >>> >>> 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 them >>> with the Linux ones, which is a bit misleading. >> >> What if I set aside the values 0xff000000 to 0xffffffff for non-os >> specific notes, the new comment and code might look like this: >> >> /* 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+. */ >> >> #define NT_GDB_TDESC 0xff000000 >> >> Thoughts? > > Ping! > > Any thoughts on the above suggestion (using constant 0xff000000) > compared to the original suggestion (using constant 0x54444553)? Sorry. I missed this reply. The new constant pattern (0xff000000) looks OK to me. > > Thanks, > Andrew > >> >> Thanks, >> Andrew