<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 10, 2020 at 3:56 AM James Henderson <<a href="mailto:jh7370.2008@my.bristol.ac.uk">jh7370.2008@my.bristol.ac.uk</a>> wrote:<br></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">

Are people still interested in this? If so, what is the typical use case you’d use the result of this project for? Why would this be better than the existing llvm-readobj output (if applicable)?<br></div></blockquote><div>llvm-readobj produces human readable output, which is not always great for being machine readable. json comes to mind as a more machine-parse-friendly format, although it may not be the best one.</div><div>I'm not sure we have a need *right now* -- we have tools that parse binutils output and work fine -- but if this tool existed, we would surely tell people they could use it instead of trying to parse a human readable tool for any new uses. Or if they scratch their heads trying to update a regex that parses a binutil, tell them to switch.</div><div></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">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><br></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">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 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></div></div>