RFC: Adding a fixed format output mode to readelf

[Nick Alcock]

On 26 Feb 2021, Mike Frysinger via Binutils told this:

> On 26 Feb 2021 17:03, Nick Clifton via Binutils wrote:
>>    PR 27309 got me thinking about readelf's output, and whilst it is
>>    true that we do not make any guarantees about the format or contents
>>    of the output it appears that other packages are becoming reliant
>>    upon its currently established behaviour.
>> 
>>    So I was wondering whether it would be a good idea to introduce
>>    some kind of fixed format output option, and what exactly this
>>    format might look like.  Do you have any opinions on the matter ?
>
> having an official machine readable output format would be nice.  it's def
> true that a number of scripts out there have already grown dependencies on
> various output modes of readelf for lack of alternatives.

The JSON output mode in iproute2's tools is really useful for simple
automated realtime response stuff, fwiw.

> the --format mode only works well though when there's not repeated fields,
> and the data is simple (e.g. just printable ASCII).  unfortunately ELFs
> are the opposite of this :).  for example, if the user wanted to dump all
> DT_NEEDED or DT_RPATH tags, how would those be shown in a way that is
> reliable and parseable ?
>
> JSON would handle both of these issues.  but i think in the low-level tool
> space that we occupy, there's a general aversion towards things like JSON,

I don't know why. The JSON format spec is a horror, but that's only if
you have to parse all its quirks. Simply generating valid JSON (when you
can decide not to emit any of the badly-specified quirks) is easy
enough.

(FWIW, though it is only a very minor part of things, I would be happy
to add a JSON output mode to ctf_dump(), which both objdump and readelf
use.)

> so i'm not confident how well it'd be adopted, which would kind of defeat
> the purpose of doing this in the first place.  i think the biggest reason
> for JSON dislike is that there is no standard tool for parsing the format,
> so people have to use something higher level (like python) or something a
> bit non-standard (like jq), or something terrible (like sed/awk + regex).

I find it surprising that nobody thinks jq *is* a standard tool by now.
(My only complaint about jq is that its syntax for doing complicated
stuff is *also* incredibly confusing...)

Another interesting thing for exploring JSON and related formats is
nushell. It's completely bizarre if you think of it as a shell, but if
you think of it as a structured data explorer... it's still not as good
as a hurd translator from/to JSON would be, but it's better than any
alternative I can remember seeing.