RFC: Adding a fixed format output mode to readelf

[Fangrui Song]

On 2021-02-26, Mike Frysinger via Binutils wrote:
>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.
>
>i added a --format option to the scanelf utility many moons ago because
>there was no other utility available that would provide stable output.
>but that's heavily tailored towards scanelf's operating mode (kind of a
>`find` for ELFs for distro packagers).
>
>only two options generally come to mind in this space: output a stable
>known format like JSON, or hoist it onto the user with a --format option
>(like what git log does).
>
>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,
>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).
>-mike

Speaking of JSON, perhaps folks may have an opinion on addr2line's JSON
output (if there is a desire to support that).

On LLVM land someone is trying https://reviews.llvm.org/D96883