From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) by sourceware.org (Postfix) with ESMTPS id C534C3857026 for ; Mon, 7 Dec 2020 19:40:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C534C3857026 Received: by mail-qk1-x732.google.com with SMTP id u4so13673882qkk.10 for ; Mon, 07 Dec 2020 11:40:00 -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=DDE/Io2VDY4JJhuhWeFc5q2PlK8uH/DQpy/mYKJc9yg=; b=pwN1pSFsmgFUyR9nWSToVe1t4U+CtiJORy/LGYrWpankKy5X+Bb5hmbxwt2FH8Kxao M1Jo6c0fRNspncZuAxDk2Ezoj5fhPzSVcNnttTWTd8yPU+/kDwJbRRmgcZ9PRbp8ZnmP 1xLc6t/zURCg4KIyfu53Y1sn3Swrxf+CzCfddP691HDTQEDl8nKOLYkF8IZ+Ks/erRIQ J3LmNzBObJcSqjajlV+7MH5mqIICHQRWFlUwFfJ1KYR0DycV+lLcFOWADT81nxe4xIEx xMiROMa2kUekTBz2fUFUyT4PDaD4tdusiwPgviSYwSRYF0fYSdV6stbLm3b+gxsEDbh1 hHTw== X-Gm-Message-State: AOAM532tbJrzZYn0hZ1D25XeKL381jdthg1PunpAz4ijn1VOzJOOjbm4 Zu5YsBKijtbmt0HM2kNynWeCDA== X-Google-Smtp-Source: ABdhPJxEZhKh0njqCRDNGqipDxgHjgA6X8q/dIVQV77aoIH5F6im095+QtcM7D9qSRs6leW6pbzSkw== X-Received: by 2002:a37:4658:: with SMTP id t85mr25998222qka.210.1607370000233; Mon, 07 Dec 2020 11:40:00 -0800 (PST) Received: from ?IPv6:2804:7f0:8284:370e:cba:9844:31b8:6c2a? ([2804:7f0:8284:370e:cba:9844:31b8:6c2a]) by smtp.gmail.com with ESMTPSA id x124sm12395862qkc.25.2020.12.07.11.39.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Dec 2020 11:39:59 -0800 (PST) Subject: Re: [PATCH 5/8] gdb/riscv: introduce bare metal core dump support To: Andrew Burgess Cc: binutils@sourceware.org, gdb-patches@sourceware.org, Paul Mathieu , Fredrik Hederstierna References: <5ba628c1042f3000947a1f2a6f9e24cf46573fa3.1606930261.git.andrew.burgess@embecosm.com> <20201207151702.GK2729@embecosm.com> <36bed17a-6012-a5d9-a29c-64e9cbbef640@linaro.org> <20201207165836.GM2729@embecosm.com> <615830c3-4ccb-cfd6-3721-0123d6c4b56a@linaro.org> <20201207181136.GN2729@embecosm.com> <3595d9b8-e26c-5ed4-8906-4ee3519a120e@linaro.org> <20201207192359.GO2729@embecosm.com> From: Luis Machado Message-ID: <601f2195-db95-3864-c54d-8c6998cff00a@linaro.org> Date: Mon, 7 Dec 2020 16:39:56 -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: <20201207192359.GO2729@embecosm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 07 Dec 2020 19:40:02 -0000 On 12/7/20 4:23 PM, Andrew Burgess wrote: > * Luis Machado [2020-12-07 16:00:06 -0300]: > >> On 12/7/20 3:11 PM, Andrew Burgess wrote: >>> * Luis Machado [2020-12-07 14:24:33 -0300]: >>> >>>> On 12/7/20 1:58 PM, Andrew Burgess wrote: >>>>> * Luis Machado [2020-12-07 12:58:19 -0300]: >>>>> >>>>>> On 12/7/20 12:17 PM, Andrew Burgess wrote: >>>>>>> * Luis Machado [2020-12-02 15:12:26 -0300]: >>>>>>> >>>>>>>> CC-ing paulmathieu@google.com and fredrik.hederstierna@verisure.com, who >>>>>>>> were also looking into supporting bare metal ARM core files. >>>>>>>> >>>>>>>> Just a quick note... >>>>>>>> >>>>>>>> Back in October we pondered about this and it looked reasonable, at the >>>>>>>> time, to put some effort into documenting the format (unlike the current >>>>>>>> Linux core file format, which lacks good documentation). >>>>>>>> >>>>>>>> My take on it is that we need to settle on a format that works for multiple >>>>>>>> architectures. >>>>>>> >>>>>>> Hi Luis, >>>>>>> >>>>>>> Thanks for your feedback, I'd love to better understand what you are >>>>>>> proposing here. >>>>>> >>>>>> Sure. What I'm proposing here is the same I proposed in this thread about >>>>>> ARM bare metal core files... >>>>>> >>>>>> https://sourceware.org/pipermail/gdb-patches/2020-October/172617.html >>>>>> >>>>>> ... and also suggested by Simon here: >>>>>> >>>>>> https://sourceware.org/pipermail/gdb-patches/2020-October/172270.html >>>>>> >>>>>> In summary, we should document what a bare metal core file is, what pieces >>>>>> it is expected to contain (registers, target descriptions, hardware >>>>>> information, execution environment etc) and what format it will be in. >>>>>> >>>>>>> >>>>>>> Could you expand a little on why we need a format that supports >>>>>>> multiple architectures (i.e. what benefits will this bring)? And how >>>>>>> this would be different to the approach taken here >>>>>> >>>>>> Having a common format makes it easier to maintain the code and expand the >>>>>> features when needed. This is not different from the Linux core file we have >>>>>> today. The Linux core file is a common format. >>>>>> >>>>>> But unlike Linux core files, which have less than ideal documentation and >>>>>> specifications, we want to take this opportunity to start clean and to >>>>>> document everything required to have a proper bare metal core file. >>>>>> >>>>>> I think this initial definition and documentation will benefit developers >>>>>> moving forward. >>>>>> >>>>>> Does that make it more clear? >>>>> >>>>> Not really. I'll go read the various threads that you referenced and >>>>> see come back once I have more specific questions. >>>>> >>>>> Thanks for the pointers. >>>>> >>>>> Andrew >>>>> >>>> >>>> I'm sorry that did not clarify things, but there isn't much more than that >>>> really. All I'm suggesting (up to you to accept it) is that we >>>> clarify/coordinate with the interested parties on what is needed for bare >>>> metal core files and document it properly (I don't think code is proper >>>> documentation). >>> >>> Sure. >>> >>> What I don't understand is you talk about creating "a format that >>> works for multiple architectures". >>> >>> Current Linux/FreeBSD core files are a container (often ELF) with >>> NOTES containing additional information. >>> >>> By format are you suggesting we come up with something non-ELF? I >>> doubt this is the case, but if so, why would we want to do this? >>> >>> Or are you suggesting some kind of coordination for note >>> names/numbers? But I don't see how this is different to what we have >>> right now. >> >> Sorry, I think you're reading too deeply into what I said. >> >> All I've suggested is to let the interested parties know you're doing this >> work, get their feedback on the strategy for dumping data for bare metal >> targets (I've cc-ed two of them, so they can chime in), see if that works >> for them with little to no extra work, and document it in a formal way (say, >> in gdb.texinfo). >> >> That's it. I'm not talking about code, patch or implementation. I'm talking >> about a bare metal core file draft design that everyone is happy with, and >> based on which folks can go and implement what they want without having to >> dig into GDB's code for that. >> >> You have the RISC-V implementation (it looks good to me FWIW), that's fine. >> But what is it implementing? It is not documented anywhere, is it? It is >> just following whatever Linux is doing, which is already badly >> documented. > > Oh, OK! That's much smaller in scope then. > Indeed! It was never my goal to create more work for you. > Jim already asked about getting this documented in a different reply, > my plan is to document the RISC-V parts of this into the RISC-V elf > abi document (assuming the maintainers of that document accept such a > patch). Great. Apologies, I haven't been following the other bits too closely. I just replied to the ones I had immediate feedback on. > > I'll re-review Fredrik's v4 patch and see if there's anything we can > share there, though from my first look through we're basically doing > the same thing already as that's the only obvious approach to take > (assuming the goal is ELF + NOTES). I think it is pretty safe to assume ELF + NOTES at this point. > > I'll also reread your comments on numbering of the tdesc note and see > if there's a better number I can/should propose. That's probably a matter of personal taste. I've been frustrated before, trying to find the most logical new ID for a new NT_* constant and failing to parse the data.