From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 36B7C3858D28 for ; Tue, 22 Aug 2023 12:17:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 36B7C3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E0A9811FB; Tue, 22 Aug 2023 05:18:16 -0700 (PDT) Received: from [10.2.78.54] (e120077-lin.cambridge.arm.com [10.2.78.54]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6566D3F740; Tue, 22 Aug 2023 05:17:35 -0700 (PDT) Message-ID: <7f29c2b4-c4bb-ddb5-3f98-52da7abdf041@arm.com> Date: Tue, 22 Aug 2023 13:17:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: Replacement for "objdump -d -l"? Content-Language: en-GB To: Nick Clifton , ASSI , binutils@sourceware.org References: <87a5v24s61.fsf@Rainer.invalid> From: "Richard Earnshaw (lists)" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3493.3 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,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: On 15/08/2023 15:15, Nick Clifton via Binutils wrote: > Hi ASSI, > >> Lastly, it seem brittle to parse the output as clearly it is meant to be >> human readable and might change in future versions > > Correct. > >> (aside from the fact >> there doesn't seem to be a documentation of the current format for >> crying out loud). > > Because the output format has evolved rather than being specified by a > standard. > > But to be fair, the output format does not change that much, and > it could be documented if there really was a need. > > >> I'd be much more content with a format that was >> designed to be machine readable and fully documented (again llvm has an >> objdump that produces YAML).  Is there something like that in binutils I >> can use? > > No, but it would be nice to have. > > A fixed, extensible, machine readable output format would be much > appreciated > as a new feature for objdump.  All it really needs is someone with the > time, > knowledge and motivation to write it. > > Cheers >   Nick > I think if we were ever to specify a machine-readable format for the output, we'd probably want to use some structured dumping format, rather than try to specify the current format more precisely. That would avoid a lot of parsing problems for readers and also give us a chance of being able to add new features without breaking every tool that reads the output. R.