<div dir="ltr"><div dir="ltr">Thanks for the comments Jordan!<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 13 Jan 2020 at 18:01, Jordan Rupprecht <<a href="mailto:rupprecht@google.com">rupprecht@google.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Which tool(s) and feature(s) would you most want this for? I personally think this should just be another output style for llvm-readobj. Does anybody have any different opinion there?<br></div></blockquote><div>I mean... almost every single binutil this might replace (readelf, objdump, nm, size, strings) could be described as "a program to read object files". So a different output style for llvm-readobj sounds fine. "llvm-readobj --machine"?</div></div></div></blockquote><div>Yeah, that was my thoughts mostly, although I'd probably go with "--output-stlye=json" or whatever, and deprecate "--elf-output-style". That would a) avoid any weird interactions between the --elf-output-style switch and the --machine (or whatever) switch, and b) allow other languages to be added later if the need arose.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">How might this interact with obj2yaml? Could the new output ultimately be used to replace it?<br></div></blockquote><div>I see this as very separate from obj2yaml -- I view that and yaml2obj as a 1:1 mapping between object files and text; in theory you can pipe back and forth forever and always get the same result (modulo unimportant bit differences), whereas llvm-readobj --machine should be an inspection tool that can be filtered/adjusted accordingly (only query certain types of sections, only print relocations, etc.)</div></div></div></blockquote><div>If we adopted YAML as the machine readable format, should there ultimately be any difference between obj2yaml and llvm-readobj --output-style=yaml --all? It seems to me not really, hence the thought. But maybe others have a different overall thought on what the latter might produce.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Is there a priority for a specific format (e.g. ELF, DWARF, COFF)?<br></div></blockquote><div>Is DWARF support necessary since llvm-dwarfdump already exists?</div></div></div></blockquote><div>Indeed, llvm-dwarfdump already exists, but like llvm-readobj, its output isn't always that amenable to machine-reading (see for example --debug-line output). Hence my question. <br></div></div></div>