[PATCH] D114225: Add JSONScopedPrinter to llvm-readelf

[Jayson Yan via Phabricator via llvm-commits]

Jaysonyan marked an inline comment as done.
Jaysonyan added inline comments.


================
Comment at: llvm/tools/llvm-readobj/llvm-readobj.cpp:340
 
-  if (opts::Output == opts::LLVM || opts::InputFilenames.size() > 1 || A) {
-    Writer.startLine() << "\n";
-    Writer.printString("File", FileStr);
-  }
-  if (opts::Output == opts::LLVM) {
-    Writer.printString("Format", Obj.getFileFormatName());
-    Writer.printString("Arch", Triple::getArchTypeName(Obj.getArch()));
-    Writer.printString(
-        "AddressSize",
-        std::string(formatv("{0}bit", 8 * Obj.getBytesInAddress())));
-    Dumper->printLoadName();
-  }
+  Dumper->printFileSummary(FileStr, Obj, opts::InputFilenames, A);
 
----------------
jhenderson wrote:
> Jaysonyan wrote:
> > jhenderson wrote:
> > > I guess there's a subtle behaviour change as a result of this patch, which wouldn't hurt to be called out in the commit description, but I otherwise think is fine: if a user had exactly one non-ELF object/archive (e.g. a COFF object), and they had previously specified `--elf-output-style=GNU` (or run using llvm-readelf, which has that as the default), they would previously have had no file summary, but now they'd get the default summary, provided by the ObjDumper class. Similarly, if they'd had more than one input, or the objects were in an archive, they'd before have had just the `File` part of the summary, but now they have the full file summary.
> > I placed the same `opts::InputFilenames.size() > 1 || A` check inside `GNUELFDumper::printFileSummary` method so I think the behaviour is the same.
> > 
> > Before, if the `opts::Output` is `LLVM` both `if(...)` statements would trigger. Now the `ObjDumper::printFileSummary` performs all the work in both if statements and would be called for any `Dumper` that is not `GNUELFDumper` or `JSONELFDumper` which should be any case where `opts::Output` is `LLVM`.
> > 
> > And the `GNUELFDumper::printFileSummary` only prints the `File` part and still does the multiple inputs / archive check. 
> No, I don't think the behaviour is the same. Non-ELF objects (e.g. COFF/XCOFF etc) won't use the *ELFDumper classes, regardless of the `--elf-output-style` option's value. This is unchanged from before. The difference is that the `opts::Output` value now doesn't have a direct impact on the output (which is good), and only picks the dumper class to use for ELF objects. This means non-ELF objects will always have the default file summary behaviour.
> 
> I think this is a good behaviour change (GNU output style should have no effect for non-ELF objects), but it needs highlighting, as said already.
Sorry, don't mean to drag this on but I wanted to ensure we're on the same page.

`opts::Output` by default is initialized to `LLVM` so if `--elf-output-style` is not specified, then `opts::Output` will be `LLVM`. So I believe that even beforehand non-ELF objects would still have file summary information. Looking at a readobj tests with COFF [[ https://github.com/llvm/llvm-project/blob/main/lld/test/COFF/hello32.test#L8 | here ]] it looks like it's printing file summary info despite not being an ELF object.


================
Comment at: llvm/tools/llvm-readobj/llvm-readobj.cpp:613-615
+  std::unique_ptr<ListScope> D;
+  if (opts::Output == opts::JSON)
+    D = std::make_unique<ListScope>(*Writer.get());
----------------
jhenderson wrote:
> Jaysonyan wrote:
> > jhenderson wrote:
> > > To recap: we only need this scope for JSON, so that there is a top-level object, ensuring we always have valid JSON in the output. What's stopping us making the ListScope a member of the `JSONScopedPrinter` class, so that the scoping is added on construction/destruction of the Writer?
> > > 
> > > Taking it from another point of view, if you had another piece of client code using `JSONScopedPrinter`, would they expect the output to be a valid JSON object, without additional changes, or expect to need to provide the outer object wrapping themselves? If the former, the scoping belongs to the `JSCONScopedPrinter`.
> > I think providing an optional `ListScope`/`DictScope` constructor could be a nice quality-of-life improvement, but I think there should still be a way to construct a `JSONScopedPrinter` without `{}`/`[]` already added. Since technically, `"string"` is still valid json so I wouldn't want to remove the option to output json that don't have an outermost `[]`/`{}`.
> Yes, I see your point, and agree with you. Are you suggesting deferring to a separate patch, or as part of the original JSONScopedPrinter patch? I suggest the latter, because it will directly improve the code here, in my opinion.
Updated the JSONScopedPrinter patch to add this and use that change here. 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114225/new/

https://reviews.llvm.org/D114225