Machine Readable Format options? Try 2 without autoattachment.

[Nick Clifton]

Hi John,

> However, the world is awash with well defined human readable machine
> formats that could trivially be used. (eg. json, yaml, ...)

Well "trivial" might not be the right word here.  Especially for something
like disassemblies which tend to be quite complex to produce.

Talking of which, did you see the recent addition of ascii art flow
graphs to the disassembler's output ?  Maybe hooking into this feature
will allow the production of the kind of output that you are seeking.


> Ideally all and every bit of information that can be obtained from the
> binutil tools should be available in a machine readable form... (a
> well factored / deisgned sqlite db would be a dream...)

I am not familiar with these formats, so please excuse me if the
following question is silly - are these formats self documenting ?
By which I mean is it necessary to come up with a specification for
the contents of the documents and then code the tools to conform
to this specification ?  Or can the tools just dump bits of information
piecemeal into an output file ?


> https://groups.google.com/d/topic/llvm-dev/U-sTsZB-6ls/discussion
> 
> Is there any initiative afoot to producing machine readable output formats
> such as csv or json or yaml or...?

Well modulo that discussion thread - no.  Of course we are always willing
to review contributions that work towards this goal.  But I can say from 
a personal point of view that unless a Red Hat customer asks for this
feature, I am not going to be able to have the time to implement it.  :-(


> I did look at elfutils, I wasn't aware of them until Nick mentioned
> them, but they seem way behind in all aspects, including output
> formats.

Really - I had always thought they were up to date, if not leading the field.
But maybe they do not provide the kind of functionality that you really need.


> Would the maintainers object to a pull requests that added such a feature
> (probably easier than doing half baked parsers)?

Nope - we will happily review anything.  I assume that you are aware
of the requirement for an FSF copyright assignment notice though ?


> What would the preferred output format be?

Your choice.  If you are writing, you get to choose the format.


> What would the preferred command line interface be (eg. Instead of the
> usual bsd / posix / sysv ... options on --format= add --format=csv or
> something?)

For tools that have the --format option then adding a new alternative
to the list of formats makes sense.  For tools which do not already
have this option then I would suggest adding a slightly longer option
name:  --output-format=<json/sqlite/ascii>.


> Supposing you have a large body (>2000) object files * 4 tool chains *
> 20 products all compiled * 1000 unit tests all
> compiled--ffunction-sections --ddata-sections and linked
> --gc-sections...
> 
> Tell me which functions / macros / are in the source but never used anywhere?

Link them all with --print-gc-sections added to the command line and
capture the output...  Well that should work for functions anyway.  I
think that for unused macros you are going to need compiler help, not
linker help.

Cheers
  Nick