RFC: Adding a fixed format output mode to readelf

Martin Liška mliska@suse.cz
Mon Mar 1 12:02:58 GMT 2021

On 2/27/21 2:24 AM, Fangrui Song wrote:
> 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

I do support the JSON format. I was handling a similar thing in the GCC compiler.
GCOV tool supports human readable format and an intermediate format. During the time
we moved the intermediate format into JSON. It's extensible format feasible
for output processing. Parsing a standard output is awkward and breaks easily.


More information about the Binutils mailing list