Add JSON output skeleton to llvm-readelf

[Jaysonyan]

Summary

This change adds JSON output to llvm-readelf. It is enabled through the --elf-output-style
option which now supports JSON in addition to the existing LLVM and GNU. This patch
just lays out the needed infrastructure and skeleton code but doesn't include any
implementation.

The major change was the need for a json printer that can be instantiated at the top level
of llvm-readobj. Since llvm-readobj uses ScopedPrinter this change adds a JSONScopedPrinter
as well as a ScopedPrinterBase which both ScopedPrinter and JSONScopedPrinter both
inherit from.

Corresponding RFC: https://lists.llvm.org/pipermail/llvm-dev/2021-September/152994.html

[jhenderson]

Some high-level comments:

1. Please include a link to the RFC email thread where this was discussed, in your commit/patch description, for ease of reference.
2. Please make sure to create your diff with full context, using -U999999 when you make the diff.
3. Please make sure to clang-format all your changes.
4. I think it makes sense to split this down even further than you have done. I'd start with literally just adding the option and skeleton dumping structure, without any implementation of the dump at all. Your later patches can then flesh out each individual dump option. This also means that you can have lots of child patches that base off this one, which are entirely independent, so it doesn't matter what order they get implemented or committed in.
5. You should update the llvm-readobj and llvm-readelf .rst files in llvm/docs/CommandGuide to discuss the new output mode, perhaps adding something like "Not all options are currently supported by this mode" or something to that effect.

Also, if you wish to add other commits in a series, that are built on top of this patch, you can use the "Edit Related Revisions" option. These will then appear in a new tab in the revision summary panel called "Stack", so that it's possible to get a quick overview of where things are.

Regarding the overall output appearance, it seems to me like you should have the JSON for a file formatted as a single JSON object, with each output variety in its own child object, labelled according to the option name or similar. Since llvm-readobj and llvm-readelf also both support multiple input files, you need a strategy for how these might be dumped. My instinct says that you actually have the dump output for a file added as child members to a top-level object, labelled by their file names. Finally, you should give some thought to how archive members are printed. I think you could either have them printed as individual objects within a JSON object representing the whole archive, or just as regular files, but with the names disambiguated. I've gone with the latter approach below:

{
    "object.o" : {
        "file-header" : { <output for file header> },
        "section-headers" : { <section header table> }
    },
    "archive.a(member1.o)": {
        "file-header" : { <output for file header> },
        "section-headers" : { <section header table> }
    },
    "archive.a(member2.o)": {
        "file-header" : { <output for file header> },
        "section-headers" : { <section header table> }
    }
}

I hope the reasoning for this is clear, but if you've got other ideas, I'm happy to discuss them.

[Jaysonyan]

Thanks for all the feedback! I was working on updating the patch according to your comments and I've been thinking about what you've mentioned about handling multiple object files and archives.

Finally, you should give some thought to how archive members are printed. I think you could either have them printed as individual objects within a JSON object representing the whole archive, or just as regular files, but with the names disambiguated. I've gone with the latter approach below:

Regarding the structure of outputting archives, I am leaning towards your first suggestion which is outputting each archive member as a child object within an overall JSON object. I think this would allow the output to be consumed easier since then there's no need to parse the names of archive member to determine what archive it falls under. Given your example I would like to produce this:

{
    "object.o" : {
        "file-header" : { <output for file header> },
        "section-headers" : { <section header table> }
    },
    "archive.a" : {
        "member1.o": {
            "file-header" : { <output for file header> },
            "section-headers" : { <section header table> }
        },
        "member2.o": {
            "file-header" : { <output for file header> },
            "section-headers" : { <section header table> }
        },
    }
}

In terms of outputting as a single JSON object I agree that this seems like the right approach and it also pokes some holes into my current implementation. Since we would need to print things like the outer {} or object file names we need to output JSON at a higher level than just the JSONELFDumper. Since the json::OStream being used does validation that you are outputting valid json we would need to use the same json::OStream for any time we print since it will need to have the correct context (ex: ensuring you are printing attributes inside a parent object). To avoid needing to pass a json::OStream to every method that needs printing I'm considering creating a subclass of ScopedPrinter called JSONScopedPrinter which holds on to a json::OStream rather than a raw_ostream that way we can just create a JSONScopedPrinter and pass it as a ScopedPrinter to all necessary functions since they already accept a ScopedPrinter. This would allow me to still use the same json::OStream for all printing while also not heavily impacting the existing functions.

I'm hoping this sounds reasonable and I'm interested if you have any alternative ideas.

[jhenderson]

Thinking about it further, I think the JSON output stream is conceptually a higher-level output style than just for ELF files. In particular, you could imagine the future support being added for e.g. COFF and Mach-O objects (they'd have a different internal layout, but they'd still be objects to be printed using the JSON printer). Given that, it makes sense for this printer to be owned higher up the stack, i.e. as you're suggesting, where the ScopedPrinter currently lives. You'd still want a JSON object dumper implementation. Thus, you'd have two levels: your "ScopedPrinter" replacement would be responsible for printing the outer braces and object names (and handle archives probably too, although from a pure design aesthetic, an ArchiveDumper class might be nicer to handle this), with then individual ObjDumper instances handling printing the contenst of an object (including its corresponding outer braces). This is then nice, because the ObjDumper could be used to print a JSON object of the relevant type in other situations, not just within the outer ScopedPrinter instance. Ultimately, this sounds more-or-less like what you're proposing, which is great.

One other thought I had: I think we may need to be careful about duplicate objects in the input list: at the moment, they are dumped once per instance, i.e. llvm-readobj input.o input.o prints input.o twice. We probably should replicate this behaviour, which means we can't use object names as keys directly. I think this means we actually want a top-level array, with a name field in each object, which slightly breaks my design idea above. Alternatively, you could have something like:

[
  {
    "object.o" : {
      ... # Contents of object.o
    },
  }
...
]

There's essentially the same issue with archives: it's potentially possible for an archive to have two members with the same name.

[Jaysonyan]

Add a base class ScopedPrinterBase and concrete class JSONScopedPrinter.
Update llvm-readobj to utilize the base class and concrete classes JSONScopedPrinter
and ScopedPrinter.

[jhenderson]

llvm/docs/CommandGuide/llvm-readelf.rst

74 ↗

(On Diff #384231)

I'd be inclined to remove the "not all options are..." bit, as that's already the case for GNU versus LLVM style, and it will avoid the comment rotting as functionality is added.

llvm/docs/CommandGuide/llvm-readobj.rst

189–190 ↗

(On Diff #384231)

Same comments.

llvm/include/llvm/Support/JSONScopedPrinter.h

24 ↗

(On Diff #384231)

Please add a blank line between the constructor and this function.

74 ↗

(On Diff #384231)

I'm not sure you need this particular function. const std::string & should implicitly convert to StringRef. (I see it was there before, but I'd see whether you can delete this overload entirely).

78 ↗

(On Diff #384231)

Ditto. const char * implicitly converts to StringRef.

113 ↗

(On Diff #384231)

Nit: delete blank line at end of class.

115 ↗

(On Diff #384231)

Nit: delete this blank line too.

llvm/include/llvm/Support/ScopedPrinter.h

82 ↗

(On Diff #384231)

Do you need this and the classof functions? As far as I can tell, they aren't used anywhere.

99–100 ↗

(On Diff #384231)

Up to you, but I don't think there's a particular need to make this constructor protected, since the class is an abstract class, so can't be directly instantiated.

103 ↗

(On Diff #384231)

Slight naming quibble: at the moment, it's not clear why ScopedPrinter is not the base class, and why JSONScopedPrinter is a sibling class (shares same base class) and not a derived class of ScopedPrinter. I'd make ScopedPrinter the base class, and call this derived class something else. Perhaps UnstructuredScopedPrinter or PlainScopedPrinter (other ideas welcome)?

llvm/tools/llvm-readobj/COFFDumper.cpp

250 ↗

(On Diff #384231)

Do you need this case purely because you're avoiding changing COFFDumper to own a ScopedPrinterBase rather than a ScopedPrinter, or does the COFFDumper make use of functionality not in the base class? If the former, just change to using the base class all the way. If the latter, that suggests there's something not quite right with our design, as ideally the dumpers shouldn't need to know which variety of dumper they're using - what functionality is in the subclass?

624 ↗

(On Diff #384231)

It looks to me like you've clang-formatted the whole file. Don't do this as part of this patch - only format the bits of the file you've changed (you may be able to get away with a separate patch to reformat the whole file though).

llvm/tools/llvm-readobj/ELFDumper.cpp

805

In a similar manner to the COFF dumper earlier, it would be ideal if you could avoid the cast, and just pass a ScopedPrinterBase instance into the ELFDumper constructors. This would allow you to avoid many of the changes you've made where you pass in a ScopedPrinter now, and decouple the printer style from the actual scoped printer (in some cases, this may be all you need to get some functions to work for JSON style).

7424

Don't bother with these sorts of comments: they don't add any long-term benefit (and will rot very quickly).

llvm/tools/llvm-readobj/ObjDumper.cpp

84 ↗

(On Diff #384231)

Perhaps do this slightly differently, so that we can leave a clear TODO here for JSON output:

if (auto *W = dyn_cast<JSONScopedPrinter>(WriterBase))
  continue; // TODO: implement for JSON printer.
ScopedPrinter *W = cast<ScopedPrinter>(WriterBase);

Ideally of course, we'd find a way to avoid needing the casting at all. This might be achievable by splitting the iteration away from the printing: keep the iteration in this function, but have a printStringListEntry function that is called per iteration, and is a virtual function in the ScopedPrinterBase class, implemented in the subclasses.

136 ↗

(On Diff #384231)

For this and the similar printSectionsAsHex, I wonder if it would make sense to make this a virtual function that the JSONELFDumper implements differently, again to avoid the casting. Thoughts?

llvm/tools/llvm-readobj/llvm-readobj.cpp

336–346

How about the following:

1. Add a printFileHeader() function to the ScopedPrinterBase interface. For the JSONScopedPrinter, it does the objectBegin calls etc. For the ScopedPrinter, it does the LLVM/filename count checks (it might even do the later Format/Arch pritning too in this case).
2. Add a endFile() function which is a noop for ScopedPrinter but for the JSONScopedPrinter does the objectEnd calls etc.

This will avoid needing additional checks for opts::JSON, and helps hide some of the details a little further - ideally once you've created a ScopedPrinterBase instance, you should be able to avoid ever referencing the subclasses.

348

I don't think you need this cast here?

632

I think it's probably fine to just leave this called Writer - the fact that it's a base class shouldn't be important to the later code.

634

In a similar manner to my earlier comment about files, how about startOutput and endOutput functions?

640

You should be able to avoid some of the changes with pointer versus reference, by doing *WriterBase.get();

[Jaysonyan]

llvm/include/llvm/Support/ScopedPrinter.h

82 ↗

(On Diff #384231)

I believe this is needed to perform dyn_cast. I was following the guide here: https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html

103 ↗

(On Diff #384231)

I agree, the naming feels a bit weird right now. I held off on renaming this class and making any changes to the interface since the ScopedPrinter is used outside of llvm-readobj and I didn't want this change to affect any other tool. Although if this is something that you think is fine to do, I'd be happy to change it. I think PlainScopedPrinter seems like an appropriate name.

llvm/tools/llvm-readobj/ObjDumper.cpp

136 ↗

(On Diff #384231)

I was hesitant to change too much of the ScopedPrinter interface to cater too closely to the needs of llvm-readobj since its used elsewhere as well.

llvm/tools/llvm-readobj/llvm-readobj.cpp

336–346

Similar to my feeling about adding a printSectionAsString and printSectionAsHex to the base class, I'm hesitant about adding methods to meet specific needs of llvm-readobj.

I assumed it would be nice to keep ScopedPrinter somewhat primitive but I'm interested if you have any thoughts on this?

[jhenderson]

To collate the common topics into one place, regarding additional virtual functions etc. I didn't register that ScopedPrinter is used outside the llvm-readobj code. Given that it is, I agree that modifying the base class to provide additional virtual functions would be undesirable. However, I did have another idea. Given that we ideally want a ScopedPrinter that has an interface suitable for llvm-readobj, how about we do the following:

1. Leave the original ScopedPrinter largely untouched, except making the common methods like printNumber virtual, adding a virtual destructor etc.
2. Within the llvm-readobj tree, create a new ReadobjScopedPrinter which is just an extension of the former, but with the additional methods added needed by llvm-readobj. This could be pure virtual, or provide default implementations of the extension functions.
3. Change all usages of ScopedPrinter to ReadobjScopedPrinter within the llvm-readobj code.
4. Change JSONScopedPrinter to derive from ReadobjScopedPrinter and implement the additional functions (and move it into the llvm-readobj code).

I'm not 100% happy with this last point. I feel like there's something in the Design Patterns space that would allow us to keep the JSON scoped printer generic, and provide a specialisation of it within llvm-readobj, but I haven't figured out how you'd get the llvm-readobj specific bit of the interface to work in this case yet.

llvm/include/llvm/Support/ScopedPrinter.h

82 ↗

(On Diff #384231)

Yes, you're right: I meant to come back and delete this comment after seeing the casting later on.

[Jaysonyan]

4. Change JSONScopedPrinter to derive from ReadobjScopedPrinter and implement the additional functions (and move it into the llvm-readobj code).

One thing that makes this implementation plan difficult is that JSONScopedPrinter needs to output valid json. There are some methods offered by ScopedPrinter that would make it difficult to ensure a JSONScopedPrinter prints valid json while still offering these methods. The most notable is startLine() which provides direct access to the underlying raw_ostream. If the JSONScopedPrinter inherits from ScopedPrinter I don't believe there is a way around not offering this method.

All implementations of ObjDumper utilize methods such as startLine() or perform other operations that may be undesirable/invalid to in json such as not enclosing each method in its own child object or having duplicate object keys (ex COFFDumper::printCOFFExports). So it may be preferable to keep the current structure and have ObjDumper implementations rely on a specific printer-type. Since passing a JSONScopedPrinter to any dumper that isn't the JSONELFDumper would likely produce invalid json.

[Jaysonyan]

Update readelf and readobj docs wording
Misc formatting and renaming changes

[Jaysonyan]

@jhenderson I was wondering if you had any more thoughts on the design on ScopedPrinter/ ScopedPrinterBase/JSONScopedPrinter? As I see it right now, it's not very feasible to treat ScopedPrinter and JSONScopedPrinter uniformly due to the usage of methods like startLine(). So a parent-child structure between ScopedPrinter and JSONScopedPrinter might not be suitable.

[jhenderson]

In D111658#3117315, @Jaysonyan wrote:

@jhenderson I was wondering if you had any more thoughts on the design on ScopedPrinter/ ScopedPrinterBase/JSONScopedPrinter? As I see it right now, it's not very feasible to treat ScopedPrinter and JSONScopedPrinter uniformly due to the usage of methods like startLine(). So a parent-child structure between ScopedPrinter and JSONScopedPrinter might not be suitable.

Sorry, I'm a little bit busy, and have a number of other reviews that are calling for my attention too. I haven't had a chance to give this too much further thought yet. One initial thought I had was that things like printLine might just be a no-op for JSON output, although I think it might be nicer if we could wrap these sorts of calls behind another interface suitable for generic llvm-readobj usage. Unfortunately, I don't have the time right now to take a look at all usages, to see if there's a way we could represent such functions in a cleaner manner. I'll try to come back to this later this week, or next week, if I can.

[Jaysonyan]

In D111658#3117710, @jhenderson wrote:

Sorry, I'm a little bit busy, and have a number of other reviews that are calling for my attention too. I haven't had a chance to give this too much further thought yet. One initial thought I had was that things like printLine might just be a no-op for JSON output, although I think it might be nicer if we could wrap these sorts of calls behind another interface suitable for generic llvm-readobj usage. Unfortunately, I don't have the time right now to take a look at all usages, to see if there's a way we could represent such functions in a cleaner manner. I'll try to come back to this later this week, or next week, if I can.

That's totally understandable and I appreciate the time you're taking to review this change. For the sake of saving time, I'll provide all of my thoughts on the design as well as my reasoning behind them in the hopes that it could save some back and forth.

I think that having JSONScopedPrinter as a subclass of ScopedPrinter would have more downsides than upsides without major refactoring to how we interact with ScopedPrinter in llvm-readobj. I believe the biggest driving force to having JSONScopedPrinter as a subclass to ScopedPrinter is with the hope that each implementation of ObjDumper can be agnostic to the type of ScopedPrinter it is using (json or regular). Although I don't believe that this is possible for a few reasons:

1. ScopedPrinter has a few template methods. I know template and virtual methods don't mix well. I'm not sure if there is a way around this that LLVM has used but I thought it'd be valuable to bring up if this is an issue.
2. The startLine() method as mentioned previously, provides access to the underlying raw_ostream. While it is possible to provide this functionality in the JSONScopedPrinter (through calling json::OStream::rawValueBegin), it would be non-trivial to ensure that the usage of this results in valid json (we would also need to find a way to call json::OStream::rawValueEnd afterwards). Alternatively, making startline() in JSONScopedPrinter an no-op may result in necessary information being omitted.
3. The structure of json can trip up certain usage of ScopedPrinter. One example is attributes inside of lists, here is an example of code inside LLVMElfDumper:

template <class ELFT> void LLVMELFDumper<ELFT>::printSectionHeaders() {
  ...
  if (opts::SectionSymbols) {
    ListScope D(W, "Symbols");
    ...
    for (const Elf_Sym &Sym : Symbols) {
      ...
      printSymbol(...);
    }
  ...
}

void LLVMELFDumper<ELFT>::printSymbol(...) {
  ...
  DictScope Group(W, "Symbol");
  W.printNumber("Name", FullSymbolName, Symbol.st_name);
  W.printHex("Value", Symbol.st_value);
  ...
}

So with a ScopedPrinter this could produce something like:

Symbols [
  Symbol {
    Name: foo (1)
    Value: 0x0
  }
  Symbol {
    Name: bar (2)
    Value: 0x0
  }
]

Although the equivalent json would not be valid due to attributes inside of a list:

"Symbols": [
  "Symbol": {
    "Name": "foo",
    "Value": "0x0"
  },
  "Symbol": {
    "Name": "bar",
    "Value": "0x0"
  }
]

So for these reasons I don't think we'd be able to have ScopedPrinter-agnostic ObjDumper implementation without significant refactors to how we interact with ScopedPrinter to ensure we're printing valid json while maintaining the current LLVM format remains unchanged. And if we don't receive this benefit I believe the downsides of having JSONScopedPrinter inherit from ScopedPrinter (JSONScopedPrinter needing offer all methods ScopedPrinter offers, many of which would be unused) outweigh the benefits.

Ultimately I think it would be ideal to reach a point where an ObjDumper can be printer-agnostic but it would require non-trivial refactors in most ObjDumper implementations to reach that point. And since currently our only need is for llvm-readelf to output json, I believe the current implementation is sufficient for addressing our needs.

[Jaysonyan]

In D111658#3121940, @Jaysonyan wrote:

I think that having JSONScopedPrinter as a subclass of ScopedPrinter would have more downsides than upsides without major refactoring to how we interact with ScopedPrinter in llvm-readobj. I believe the biggest driving force to having JSONScopedPrinter as a subclass to ScopedPrinter is with the hope that each implementation of ObjDumper can be agnostic to the type of ScopedPrinter it is using (json or regular). Although I don't believe that this is possible for a few reasons:

Since making this comment I've been thinking of possible solutions to these problems. I've uploaded D114052: Add JSONScopedPrinter as a subclass to ScopedPrinter with history stack and D114053: Add JSONScopedPrinter as a subclass to ScopedPrinter with array output which are two approaches that attempt to solve the 3 issues laid out in this comment. Hopefully either of those 2 PRs (or this one) will be a sufficient solution to meet our needs.

[jhenderson]

In D111658#3136536, @Jaysonyan wrote:

In D111658#3121940, @Jaysonyan wrote:

I think that having JSONScopedPrinter as a subclass of ScopedPrinter would have more downsides than upsides without major refactoring to how we interact with ScopedPrinter in llvm-readobj. I believe the biggest driving force to having JSONScopedPrinter as a subclass to ScopedPrinter is with the hope that each implementation of ObjDumper can be agnostic to the type of ScopedPrinter it is using (json or regular). Although I don't believe that this is possible for a few reasons:

Since making this comment I've been thinking of possible solutions to these problems. I've uploaded D114052: Add JSONScopedPrinter as a subclass to ScopedPrinter with history stack and D114053: Add JSONScopedPrinter as a subclass to ScopedPrinter with array output which are two approaches that attempt to solve the 3 issues laid out in this comment. Hopefully either of those 2 PRs (or this one) will be a sufficient solution to meet our needs.

Thanks for thinking about this, and sorry for not coming back sooner (I've been dealing with deadlines, but am now free for a bit, so hopefully will have a bit more time). I quite like the "history stack" idea of the two new approaches, and I think the solutions to the other cases are viable. Note however that your two new diffs appear to be identical? Either that or I'm missing where the problem 3 approach differs in the implementation.

Do you have a preference for an approach of the three?

[Jaysonyan]

In D111658#3136905, @jhenderson wrote:

Thanks for thinking about this, and sorry for not coming back sooner (I've been dealing with deadlines, but am now free for a bit, so hopefully will have a bit more time). I quite like the "history stack" idea of the two new approaches, and I think the solutions to the other cases are viable. Note however that your two new diffs appear to be identical? Either that or I'm missing where the problem 3 approach differs in the implementation.

Do you have a preference for an approach of the three?

The interface for ScopedPrinter can broadly be split into 2 categories. The first is methods that creates scopes, the second is printing values inside those scopes. The first categories consists of objectBegin(), arrayBegin(), objectBegin(attr), arrayBegin(attr) (and their respective end methods). The second category are methods such as printString(Label, Value) which print actual values, usually as a key-value pair. The goal for both the history
stack and array output approach is that when printing key-value pairs its inside the context of an object and when printing single values (ex: arrays, object, number, string), its inside the context of arrays.

The history stack approach utilizes saved context to conditionally output surrounding {} inside objectBegin(attr)/arrayBegin(attr) when inside the context of an array.
The array output approach doesn't hold on to any context but will rather always output arrays and enclosing {} for both objectBegin()/arrayBegin() and for all key-value pairs it will always output enclosing {}. This ensures all calls to ScopedPrinter output single values and will always be in the context of an array.

Personally I prefer the history stack approach as well, but recognize the duplicated work of keeping a history stack inside both JSONScopedPrinter and json::OStream. The benefit of the array output is that it doesn't need to do any of this work but it comes at the expense of a somewhat unintuitive output.

[jhenderson]

In D111658#3139223, @Jaysonyan wrote:

In D111658#3136905, @jhenderson wrote:

Thanks for thinking about this, and sorry for not coming back sooner (I've been dealing with deadlines, but am now free for a bit, so hopefully will have a bit more time). I quite like the "history stack" idea of the two new approaches, and I think the solutions to the other cases are viable. Note however that your two new diffs appear to be identical? Either that or I'm missing where the problem 3 approach differs in the implementation.

Do you have a preference for an approach of the three?

The interface for ScopedPrinter can broadly be split into 2 categories. The first is methods that creates scopes, the second is printing values inside those scopes. The first categories consists of objectBegin(), arrayBegin(), objectBegin(attr), arrayBegin(attr) (and their respective end methods). The second category are methods such as printString(Label, Value) which print actual values, usually as a key-value pair. The goal for both the history
stack and array output approach is that when printing key-value pairs its inside the context of an object and when printing single values (ex: arrays, object, number, string), its inside the context of arrays.

The history stack approach utilizes saved context to conditionally output surrounding {} inside objectBegin(attr)/arrayBegin(attr) when inside the context of an array.
The array output approach doesn't hold on to any context but will rather always output arrays and enclosing {} for both objectBegin()/arrayBegin() and for all key-value pairs it will always output enclosing {}. This ensures all calls to ScopedPrinter output single values and will always be in the context of an array.

Personally I prefer the history stack approach as well, but recognize the duplicated work of keeping a history stack inside both JSONScopedPrinter and json::OStream. The benefit of the array output is that it doesn't need to do any of this work but it comes at the expense of a somewhat unintuitive output.

Thanks. I'm not too fussed by this duplication, if there's no practical way of avoiding it, and I agree that the output is more logical in this form. I'm going to start reviewing the "history stack" version now.

llvm/test/tools/llvm-readobj/ELF/file-headers.test

 # RUN: not llvm-readelf --file-headers %t.invalid1 2>&1 \
 # RUN:  | FileCheck %s --implicit-check-not=warning: -DFILE=%t.invalid1 \
 # RUN:    -DSECHDRCOUNT=8192 -DSECHDRSTRTABINDEX=12288 --check-prefix=INVALID-GNU
+# RUN: not llvm-readelf --elf-output-style=JSON --file-headers %t.invalid1 2>&1 \
+# RUN:  | FileCheck %s --implicit-check-not=warning: -DFILE=%t.invalid1 \
+# RUN:    -DSECHDRCOUNT=8192 -DSECHDRSTRTABINDEX=12288 --check-prefix=INVALID-JSON
 
 # INVALID-LLVM:      File: [[FILE]]
 # INVALID-LLVM-NEXT: Format: elf64-unknown

 # INVALID-GNU-NEXT:   Section header string table index: [[SECHDRSTRTABINDEX]]
 # INVALID-GNU-NEXT: error: '[[FILE]]': unable to continue dumping, the file is corrupt: section header table goes past the end of the file: e_shoff = 0x1000
 
+# INVALID-JSON:      {
+# INVALID-JSON-NEXT:   "ElfHeader": {
+# INVALID-JSON-NEXT:     "Ident": {
+# INVALID-JSON-NEXT:       "Magic": [
+# INVALID-JSON-NEXT:         "7F",
+# INVALID-JSON-NEXT:         "45",
+# INVALID-JSON-NEXT:         "4C",
+# INVALID-JSON-NEXT:         "46"
+# INVALID-JSON-NEXT:       ],
+# INVALID-JSON-NEXT:       "Class": "ELF64",
+# INVALID-JSON-NEXT:       "DataEncoding": "2's complement, little endian",
+# INVALID-JSON-NEXT:       "FileVersion": 1,
+# INVALID-JSON-NEXT:       "OS/ABI": "UNIX - System V",
+# INVALID-JSON-NEXT:       "ABIVersion": 0,
+# INVALID-JSON-NEXT:       "Unused": [
+# INVALID-JSON-NEXT:         "0",
+# INVALID-JSON-NEXT:         "0",
+# INVALID-JSON-NEXT:         "0",
+# INVALID-JSON-NEXT:         "0",
+# INVALID-JSON-NEXT:         "0",
+# INVALID-JSON-NEXT:         "0",
+# INVALID-JSON-NEXT:         "0"
+# INVALID-JSON-NEXT:       ]
+# INVALID-JSON-NEXT:     },
+# INVALID-JSON-NEXT:     "Type": "Relocatable",
+# INVALID-JSON-NEXT:     "Machine": "None",
+# INVALID-JSON-NEXT:     "Version": "0x1",
+# INVALID-JSON-NEXT:     "Entry": "0",
+# INVALID-JSON-NEXT:     "ProgramHeaderOffset": "0",
+# INVALID-JSON-NEXT:     "SectionHeaderOffset": "4096",
+# INVALID-JSON-NEXT:     "FlagsRaw": "0x0",
+# INVALID-JSON-NEXT:     "HeaderSize": "64",
+# INVALID-JSON-NEXT:     "ProgramHeaderEntrySize": "0",
+# INVALID-JSON-NEXT:     "ProgramHeaderCount": "0",
+# INVALID-JSON-NEXT:     "SectionHeaderEntrySize": "64",
+# INVALID-JSON-NEXT:     "SectionHeaderCount": "[[SECHDRCOUNT]]",
+# INVALID-JSON-NEXT:     "StringTableSectionIndex": "[[SECHDRSTRTABINDEX]]"
+# INVALID-JSON-NEXT: error: '[[FILE]]': unable to continue dumping, the file is corrupt: section header table goes past the end of the file: e_shoff = 0x1000
+
 --- !ELF
 FileHeader:
   Class:     ELFCLASS64

 # RUN:  | FileCheck %s -DFILE=%t.invalid1 -DSECHDRCOUNT=8192 -DSECHDRSTRTABINDEX=12288 --check-prefix=INVALID-LLVM
 # RUN: not llvm-readelf -a %t.invalid1 2>&1 \
 # RUN:  | FileCheck %s -DFILE=%t.invalid1 -DSECHDRCOUNT=8192 -DSECHDRSTRTABINDEX=12288 --check-prefix=INVALID-GNU
+# RUN: not llvm-readelf --elf-output-style=JSON -a %t.invalid1 2>&1 \
+# RUN:  | FileCheck %s -DFILE=%t.invalid1 -DSECHDRCOUNT=8192 -DSECHDRSTRTABINDEX=12288 --check-prefix=INVALID-JSON
 
 ## Check what we print when e_shnum == 0, e_shstrndx == SHN_XINDEX and the section header table can't be read.
 

 # RUN:  | FileCheck %s -DFILE=%t.invalid2 -DSECHDRCOUNT="<?>" -DSECHDRSTRTABINDEX="<?>" --check-prefix=INVALID-LLVM
 # RUN: not llvm-readelf --file-headers %t.invalid2 2>&1 \
 # RUN:  | FileCheck %s -DFILE=%t.invalid2 -DSECHDRCOUNT="<?>" -DSECHDRSTRTABINDEX="<?>" --check-prefix=INVALID-GNU
+# RUN: not llvm-readelf --elf-output-style=JSON --file-headers %t.invalid2 2>&1 \
+# RUN:  | FileCheck %s -DFILE=%t.invalid2 -DSECHDRCOUNT="<?>" -DSECHDRSTRTABINDEX="<?>" --check-prefix=INVALID-JSON

llvm/test/tools/llvm-readobj/ELF/groups.test

 # RUN: llvm-readobj -g %t.o | FileCheck %s
 # RUN: llvm-readobj --elf-section-groups %t.o | FileCheck %s
 # RUN: llvm-readelf -g %t.o | FileCheck --check-prefix=GNU %s
+# RUN: llvm-readelf --elf-output-style=JSON -g %t.o | FileCheck --check-prefix=JSON %s
 
 # CHECK:      Groups {
 # CHECK-NEXT:   Group {

 # GNU-NEXT:  [    5] .text.bar
 # GNU-NEXT:  [    6] .rela.text.bar
 
+# JSON:        "Groups": [
+# JSON-NEXT:     {
+# JSON-NEXT:       "Group": {
+# JSON-NEXT:         "Name": ".group",
+# JSON-NEXT:         "Index": "1",
+# JSON-NEXT:         "Link": 7,
+# JSON-NEXT:         "Info": 1,
+# JSON-NEXT:         "Type": "COMDAT",
+# JSON-NEXT:         "Signature": "foo",
+# JSON-NEXT:         "SectionsInGroup": [
+# JSON-NEXT:           {
+# JSON-NEXT:             "Name": ".text.foo",
+# JSON-NEXT:             "Index": "3"
+# JSON-NEXT:           },
+# JSON-NEXT:           {
+# JSON-NEXT:             "Name": ".rela.text.foo",
+# JSON-NEXT:             "Index": "4"
+# JSON-NEXT:           }
+# JSON-NEXT:         ]
+# JSON-NEXT:       }
+# JSON-NEXT:     },
+# JSON-NEXT:     {
+# JSON-NEXT:       "Group": {
+# JSON-NEXT:         "Name": ".group1",
+# JSON-NEXT:         "Index": "2",
+# JSON-NEXT:         "Link": 7,
+# JSON-NEXT:         "Info": 2,
+# JSON-NEXT:         "Type": "COMDAT",
+# JSON-NEXT:         "Signature": "bar",
+# JSON-NEXT:         "SectionsInGroup": [
+# JSON-NEXT:           {
+# JSON-NEXT:             "Name": ".text.bar",
+# JSON-NEXT:             "Index": "5"
+# JSON-NEXT:           },
+# JSON-NEXT:           {
+# JSON-NEXT:             "Name": ".rela.text.bar",
+# JSON-NEXT:             "Index": "6"
+# JSON-NEXT:           }
+# JSON-NEXT:         ]
+# JSON-NEXT:       }
+# JSON-NEXT:     }
+# JSON-NEXT:   ]
+
 --- !ELF
 FileHeader:
   Class: ELFCLASS64

 # RUN: yaml2obj %s -DMEMBER2=.text.foo -o %t.dup.o
 # RUN: llvm-readobj --section-groups %t.dup.o 2>&1 | FileCheck %s -DFILE=%t.dup.o --check-prefix=DUP-LLVM
 # RUN: llvm-readelf --section-groups %t.dup.o 2>&1 | FileCheck %s -DFILE=%t.dup.o --check-prefix=DUP-GNU
+# RUN: llvm-readelf --elf-output-style=JSON --section-groups %t.dup.o 2>&1 | FileCheck %s -DFILE=%t.dup.o --check-prefix=DUP-JSON
 
 # DUP-LLVM:      Group {
 # DUP-LLVM-NEXT:   Name: .group

 # DUP-GNU-NEXT:    [    3]   .text.foo
 # DUP-GNU-NEXT:    [    6]   .rela.text.bar
 
+# DUP-JSON:       "Group": {
+# DUP-JSON-NEXT:    "Name": ".group",
+# DUP-JSON-NEXT:    "Index": "1",
+# DUP-JSON-NEXT:    "Link": 7,
+# DUP-JSON-NEXT:    "Info": 1,
+# DUP-JSON-NEXT:    "Type": "COMDAT",
+# DUP-JSON-NEXT:    "Signature": "foo",
+# DUP-JSON-NEXT:    "SectionsInGroup": [
+# DUP-JSON-NEXT:      {
+# DUP-JSON-NEXT:        "Name": ".text.foo",
+# DUP-JSON-NEXT:        "Index": "3"
+# DUP-JSON-NEXT:      },
+# DUP-JSON-NEXT:      {
+# DUP-JSON-NEXT:        "Name": ".rela.text.foo",
+# DUP-JSON-NEXT:        "Index": "4"
+# DUP-JSON-NEXT:      }
+# DUP-JSON-NEXT:    ]
+# DUP-JSON-NEXT:  }
+# DUP-JSON:       "Group": {
+# DUP-JSON-NEXT:    "Name": ".group1",
+# DUP-JSON-NEXT:    "Index": "2",
+# DUP-JSON-NEXT:    "Link": 7,
+# DUP-JSON-NEXT:    "Info": 2,
+# DUP-JSON-NEXT:    "Type": "COMDAT",
+# DUP-JSON-NEXT:    "Signature": "bar",
+# DUP-JSON-NEXT:    "SectionsInGroup": [
+# DUP-JSON-NEXT:       warning: '[[FILE]]': section with index 3, included in the group section with index 1, was also found in the group section with index 2
+# DUP-JSON-EMPTY:
+# DUP-JSON-NEXT:        "Name": ".text.foo",
+# DUP-JSON-NEXT:        "Index": "3"
+# DUP-JSON-NEXT:      },
+# DUP-JSON-NEXT:      {
+# DUP-JSON-NEXT:        "Name": ".rela.text.bar",
+# DUP-JSON-NEXT:        "Index": "6"
+# DUP-JSON-NEXT:      }
+# DUP-JSON-NEXT:    ]
+# DUP-JSON-NEXT:  }
+
 ## Check what we do when we are unable to dump the signature symbol name.
 ## In this case the index of the string table section, linked to the symbol table used by a group section,
 ## is broken (section does not exist).

 # RUN:   FileCheck -DFILE=%t.symtab.o %s --check-prefix=SYMTAB-LLVM --implicit-check-not=warning:
 # RUN: llvm-readelf --section-groups %t.symtab.o 2>&1 | \
 # RUN:   FileCheck -DFILE=%t.symtab.o %s --check-prefix=SYMTAB-GNU --implicit-check-not=warning:
+# RUN: llvm-readelf --elf-output-style=JSON --section-groups %t.symtab.o 2>&1 | \
+# RUN:   FileCheck -DFILE=%t.symtab.o %s --check-prefix=SYMTAB-JSON --implicit-check-not=warning:
 
 # SYMTAB-LLVM:      Groups {
 # SYMTAB-LLVM-NEXT: warning: '[[FILE]]': unable to get the string table for SHT_SYMTAB section with index 7: invalid section index: 255

 # SYMTAB-GNU-NEXT:      [    5]   .text.bar
 # SYMTAB-GNU-NEXT:      [    6]   .rela.text.bar
 
+# SYMTAB-JSON:        warning: '[[FILE]]': unable to get the string table for SHT_SYMTAB section with index 7: invalid section index: 255
+# SYMTAB-JSON:       "Group": {
+# SYMTAB-JSON-NEXT:    "Name": ".group",
+# SYMTAB-JSON-NEXT:    "Index": "1",
+# SYMTAB-JSON-NEXT:    "Link": 7,
+# SYMTAB-JSON-NEXT:    "Info": 1,
+# SYMTAB-JSON-NEXT:    "Type": "COMDAT",
+# SYMTAB-JSON-NEXT:    "Signature": "<?>",
+# SYMTAB-JSON-NEXT:    "SectionsInGroup": [
+# SYMTAB-JSON-NEXT:      {
+# SYMTAB-JSON-NEXT:        "Name": ".text.foo",
+# SYMTAB-JSON-NEXT:        "Index": "3"
+# SYMTAB-JSON-NEXT:      },
+# SYMTAB-JSON-NEXT:      {
+# SYMTAB-JSON-NEXT:        "Name": ".rela.text.foo",
+# SYMTAB-JSON-NEXT:        "Index": "4"
+# SYMTAB-JSON-NEXT:      }
+# SYMTAB-JSON-NEXT:    ]
+# SYMTAB-JSON-NEXT:  }
+# SYMTAB-JSON:       "Group": {
+# SYMTAB-JSON-NEXT:    "Name": ".group1",
+# SYMTAB-JSON-NEXT:    "Index": "2",
+# SYMTAB-JSON-NEXT:    "Link": 7,
+# SYMTAB-JSON-NEXT:    "Info": 2,
+# SYMTAB-JSON-NEXT:    "Type": "COMDAT",
+# SYMTAB-JSON-NEXT:    "Signature": "<?>",
+# SYMTAB-JSON-NEXT:    "SectionsInGroup": [
+# SYMTAB-JSON-NEXT:      {
+# SYMTAB-JSON-NEXT:        "Name": ".text.bar",
+# SYMTAB-JSON-NEXT:        "Index": "5"
+# SYMTAB-JSON-NEXT:      },
+# SYMTAB-JSON-NEXT:      {
+# SYMTAB-JSON-NEXT:        "Name": ".rela.text.bar",
+# SYMTAB-JSON-NEXT:        "Index": "6"
+# SYMTAB-JSON-NEXT:      }
+# SYMTAB-JSON-NEXT:    ]
+# SYMTAB-JSON-NEXT:  }
+
 ## This tests the behavior for two more cases when we are unable to dump the signature symbol name.
 ## In the first case we link the group section to the section with index 255, which does not exist.
 ## We check that a warning is reported when we are unable to locate the symbol table.

 # RUN:   FileCheck -DFILE=%t.symtab2.o %s --check-prefix=SIGNATURE-LLVM --implicit-check-not=warning:
 # RUN: llvm-readelf --section-groups %t.symtab2.o 2>&1 | \
 # RUN:   FileCheck -DFILE=%t.symtab2.o %s --check-prefix=SIGNATURE-GNU --implicit-check-not=warning:
+# RUN: llvm-readelf --elf-output-style=JSON --section-groups %t.symtab2.o 2>&1 | \
+# RUN:   FileCheck -DFILE=%t.symtab2.o %s --check-prefix=SIGNATURE-JSON --implicit-check-not=warning:
 
 # SIGNATURE:      Groups {
 # SIGNATURE-LLVM: warning: '[[FILE]]': unable to get the symbol table for SHT_GROUP section with index 1: invalid section index: 255

 # SIGNATURE-GNU-NEXT:     [    5]   .text.bar
 # SIGNATURE-GNU-NEXT:     [    6]   .rela.text.bar
 
+# SIGNATURE-JSON:       warning: '[[FILE]]': unable to get the symbol table for SHT_GROUP section with index 1: invalid section index: 255
+# SIGNATURE-JSON-NEXT:  warning: '[[FILE]]': unable to get the signature symbol for SHT_GROUP section with index 2: section [index 1] has invalid sh_entsize: expected 24, but got 4
+# SIGNATURE-JSON:       "Group": {
+# SIGNATURE-JSON-NEXT:    "Name": ".group",
+# SIGNATURE-JSON-NEXT:    "Index": "1",
+# SIGNATURE-JSON-NEXT:    "Link": 255,
+# SIGNATURE-JSON-NEXT:    "Info": 1,
+# SIGNATURE-JSON-NEXT:    "Type": "COMDAT",
+# SIGNATURE-JSON-NEXT:    "Signature": "<?>",
+# SIGNATURE-JSON-NEXT:    "SectionsInGroup": [
+# SIGNATURE-JSON-NEXT:      {
+# SIGNATURE-JSON-NEXT:        "Name": ".text.foo",
+# SIGNATURE-JSON-NEXT:        "Index": "3"
+# SIGNATURE-JSON-NEXT:      },
+# SIGNATURE-JSON-NEXT:      {
+# SIGNATURE-JSON-NEXT:        "Name": ".rela.text.foo",
+# SIGNATURE-JSON-NEXT:        "Index": "4"
+# SIGNATURE-JSON-NEXT:      }
+# SIGNATURE-JSON-NEXT:    ]
+# SIGNATURE-JSON-NEXT:  }
+# SIGNATURE-JSON:       "Group": {
+# SIGNATURE-JSON-NEXT:    "Name": ".group1",
+# SIGNATURE-JSON-NEXT:    "Index": "2",
+# SIGNATURE-JSON-NEXT:    "Link": 1,
+# SIGNATURE-JSON-NEXT:    "Info": 2,
+# SIGNATURE-JSON-NEXT:    "Type": "COMDAT",
+# SIGNATURE-JSON-NEXT:    "Signature": "<?>",
+# SIGNATURE-JSON-NEXT:    "SectionsInGroup": [
+# SIGNATURE-JSON-NEXT:      {
+# SIGNATURE-JSON-NEXT:        "Name": ".text.bar",
+# SIGNATURE-JSON-NEXT:        "Index": "5"
+# SIGNATURE-JSON-NEXT:      },
+# SIGNATURE-JSON-NEXT:      {
+# SIGNATURE-JSON-NEXT:        "Name": ".rela.text.bar",
+# SIGNATURE-JSON-NEXT:        "Index": "6"
+# SIGNATURE-JSON-NEXT:      }
+# SIGNATURE-JSON-NEXT:    ]
+# SIGNATURE-JSON-NEXT:  }
+
 ## Check we report a warning when the content of the group section is empty or can't be read.
 ## In both cases we are unable to read the section group flag and dump it as 0.
 

 # RUN:   FileCheck -DFILE=%t.secsize.o %s --check-prefix=CONTENT-LLVM --implicit-check-not=warning:
 # RUN: llvm-readelf --section-groups %t.secsize.o 2>&1 | \
 # RUN:   FileCheck -DFILE=%t.secsize.o %s --check-prefix=CONTENT-GNU --implicit-check-not=warning:
+# RUN: llvm-readelf --elf-output-style=JSON --section-groups %t.secsize.o 2>&1 | \
+# RUN:   FileCheck -DFILE=%t.secsize.o %s --check-prefix=CONTENT-JSON --implicit-check-not=warning:
 
 # CONTENT-LLVM:      Groups {
 # CONTENT-LLVM-NEXT: warning: '[[FILE]]': unable to read the section group flag from the SHT_GROUP section with index 1: the section is empty

 # CONTENT-GNU-NEXT:  (unknown) group section [    2] `.group1' [bar] contains 0 sections:
 # CONTENT-GNU-NEXT:    [Index]    Name
 
+# CONTENT-JSON:      warning: '[[FILE]]': unable to read the section group flag from the SHT_GROUP section with index 1: the section is empty
+# CONTENT-JSON-NEXT: warning: '[[FILE]]': unable to get the content of the SHT_GROUP section with index 2: section [index 2] has an invalid sh_size (1) which is not a multiple of its sh_entsize (4)
+# CONTENT-JSON:       "Group": {
+# CONTENT-JSON-NEXT:    "Name": ".group",
+# CONTENT-JSON-NEXT:    "Index": "1",
+# CONTENT-JSON-NEXT:    "Link": 7,
+# CONTENT-JSON-NEXT:    "Info": 1,
+# CONTENT-JSON-NEXT:    "Type": "(unknown)",
+# CONTENT-JSON-NEXT:    "Signature": "foo",
+# CONTENT-JSON-NEXT:    "SectionsInGroup": []
+# CONTENT-JSON-NEXT:  }
+# CONTENT-JSON:       "Group": {
+# CONTENT-JSON-NEXT:    "Name": ".group1",
+# CONTENT-JSON-NEXT:    "Index": "2",
+# CONTENT-JSON-NEXT:    "Link": 7,
+# CONTENT-JSON-NEXT:    "Info": 2,
+# CONTENT-JSON-NEXT:    "Type": "(unknown)",
+# CONTENT-JSON-NEXT:    "Signature": "bar",
+# CONTENT-JSON-NEXT:    "SectionsInGroup": []
+# CONTENT-JSON-NEXT:  }
+
 ## Check that we emit a warning when we are unable to read the group section name or the name of a member.
 
 # RUN: yaml2obj %s -DGROUP1SHNAME=0xAAAA -DTEXTBARSHNAME=0xBBBB -o %t.name.o

 # RUN:   FileCheck -DFILE=%t.name.o %s --check-prefix=NAME-LLVM --implicit-check-not=warning:
 # RUN: llvm-readelf --section-groups %t.name.o 2>&1 | \
 # RUN:   FileCheck -DFILE=%t.name.o %s --check-prefix=NAME-GNU --implicit-check-not=warning:
+# RUN: llvm-readelf --elf-output-style=JSON --section-groups %t.name.o 2>&1 | \
+# RUN:   FileCheck -DFILE=%t.name.o %s --check-prefix=NAME-JSON --implicit-check-not=warning:
 
 # NAME-LLVM:      Groups {
 # NAME-LLVM-NEXT: warning: '[[FILE]]': unable to get the name of SHT_GROUP section with index 1: a section [index 1] has an invalid sh_name (0xaaaa) offset which goes past the end of the section name string table

 # NAME-GNU-NEXT:     [    5]   <?>
 # NAME-GNU-NEXT:     [    6]   .rela.text.bar
 
+# NAME-JSON:        warning: '[[FILE]]': unable to get the name of SHT_GROUP section with index 1: a section [index 1] has an invalid sh_name (0xaaaa) offset which goes past the end of the section name string table
+# NAME-JSON-NEXT:   warning: '[[FILE]]': unable to get the name of SHT_PROGBITS section with index 5: a section [index 5] has an invalid sh_name (0xbbbb) offset which goes past the end of the section name string table
+# NAME-JSON:       "Group": {
+# NAME-JSON-NEXT:    "Name": "<?>",
+# NAME-JSON-NEXT:    "Index": "1",
+# NAME-JSON-NEXT:    "Link": 7,
+# NAME-JSON-NEXT:    "Info": 1,
+# NAME-JSON-NEXT:    "Type": "COMDAT",
+# NAME-JSON-NEXT:    "Signature": "foo",
+# NAME-JSON-NEXT:    "SectionsInGroup": [
+# NAME-JSON-NEXT:      {
+# NAME-JSON-NEXT:        "Name": ".text.foo",
+# NAME-JSON-NEXT:        "Index": "3"
+# NAME-JSON-NEXT:      },
+# NAME-JSON-NEXT:      {
+# NAME-JSON-NEXT:        "Name": ".rela.text.foo",
+# NAME-JSON-NEXT:        "Index": "4"
+# NAME-JSON-NEXT:      }
+# NAME-JSON-NEXT:    ]
+# NAME-JSON-NEXT:  }
+# NAME-JSON:       "Group": {
+# NAME-JSON-NEXT:    "Name": ".group1",
+# NAME-JSON-NEXT:    "Index": "2",
+# NAME-JSON-NEXT:    "Link": 7,
+# NAME-JSON-NEXT:    "Info": 2,
+# NAME-JSON-NEXT:    "Type": "COMDAT",
+# NAME-JSON-NEXT:    "Signature": "bar",
+# NAME-JSON-NEXT:    "SectionsInGroup": [
+# NAME-JSON-NEXT:      {
+# NAME-JSON-NEXT:        "Name": "<?>",
+# NAME-JSON-NEXT:        "Index": "5"
+# NAME-JSON-NEXT:      },
+# NAME-JSON-NEXT:      {
+# NAME-JSON-NEXT:        "Name": ".rela.text.bar",
+# NAME-JSON-NEXT:        "Index": "6"
+# NAME-JSON-NEXT:      }
+# NAME-JSON-NEXT:    ]
+# NAME-JSON-NEXT:  }
+
 ## Check we report a warning then the section index of a section group member is invalid.
 
 # RUN: yaml2obj %s -DMEMBER1=0xEE -DMEMBER2=0xFF -o %t.member.index.o

 # RUN:   FileCheck -DFILE=%t.member.index.o %s --check-prefix=MEMBER-LLVM --implicit-check-not=warning:
 # RUN: llvm-readelf --section-groups %t.member.index.o 2>&1 | \
 # RUN:   FileCheck -DFILE=%t.member.index.o %s --check-prefix=MEMBER-GNU --implicit-check-not=warning:
+# RUN: llvm-readelf --elf-output-style=JSON --section-groups %t.member.index.o 2>&1 | \
+# RUN:   FileCheck -DFILE=%t.member.index.o %s --check-prefix=MEMBER-JSON --implicit-check-not=warning:
 
 # MEMBER-LLVM:      Groups {
 # MEMBER-LLVM-NEXT: warning: '[[FILE]]': unable to get the section with index 238 when dumping the SHT_GROUP section with index 1: invalid section index: 238

 # MEMBER-GNU-NEXT:     [  255]   <?>
 # MEMBER-GNU-NEXT:     [    6]   .rela.text.bar
 
+# MEMBER-JSON:       warning: '[[FILE]]': unable to get the section with index 238 when dumping the SHT_GROUP section with index 1: invalid section index: 238
+# MEMBER-JSON-NEXT:  warning: '[[FILE]]': unable to get the section with index 255 when dumping the SHT_GROUP section with index 2: invalid section index: 255
+# MEMBER-JSON:      "Group": {
+# MEMBER-JSON-NEXT:   "Name": ".group",
+# MEMBER-JSON-NEXT:   "Index": "1",
+# MEMBER-JSON-NEXT:   "Link": 7,
+# MEMBER-JSON-NEXT:   "Info": 1,
+# MEMBER-JSON-NEXT:   "Type": "COMDAT",
+# MEMBER-JSON-NEXT:   "Signature": "foo",
+# MEMBER-JSON-NEXT:   "SectionsInGroup": [
+# MEMBER-JSON-NEXT:     {
+# MEMBER-JSON-NEXT:       "Name": ".text.foo",
+# MEMBER-JSON-NEXT:       "Index": "3"
+# MEMBER-JSON-NEXT:     },
+# MEMBER-JSON-NEXT:     {
+# MEMBER-JSON-NEXT:       "Name": "<?>",
+# MEMBER-JSON-NEXT:       "Index": "238"
+# MEMBER-JSON-NEXT:     }
+# MEMBER-JSON-NEXT:   ]
+# MEMBER-JSON-NEXT: }
+# MEMBER-JSON:      "Group": {
+# MEMBER-JSON-NEXT:   "Name": ".group1",
+# MEMBER-JSON-NEXT:   "Index": "2",
+# MEMBER-JSON-NEXT:   "Link": 7,
+# MEMBER-JSON-NEXT:   "Info": 2,
+# MEMBER-JSON-NEXT:   "Type": "COMDAT",
+# MEMBER-JSON-NEXT:   "Signature": "bar",
+# MEMBER-JSON-NEXT:   "SectionsInGroup": [
+# MEMBER-JSON-NEXT:     {
+# MEMBER-JSON-NEXT:       "Name": "<?>",
+# MEMBER-JSON-NEXT:       "Index": "255"
+# MEMBER-JSON-NEXT:     },
+# MEMBER-JSON-NEXT:     {
+# MEMBER-JSON-NEXT:       "Name": ".rela.text.bar",
+# MEMBER-JSON-NEXT:       "Index": "6"
+# MEMBER-JSON-NEXT:     }
+# MEMBER-JSON-NEXT:   ]
+# MEMBER-JSON-NEXT: }
+
 ## Check warnings that are reported when the st_name field of the signature symbol goes past the end of the string table.
 
 ## We set the content of the string table to '0061626300' ('\0abc\0') to fixup the size of the string table.

 # RUN:   FileCheck -DFILE=%t.signame.o %s --check-prefixes=SIGNAME1-WARN,SIGNAME1-LLVM --implicit-check-not=warning:
 # RUN: llvm-readelf --section-groups %t.signame.o 2>&1 | \
 # RUN:   FileCheck -DFILE=%t.signame.o %s --check-prefixes=SIGNAME1-WARN,SIGNAME1-GNU --implicit-check-not=warning:
+# RUN: llvm-readelf --elf-output-style=JSON --section-groups %t.signame.o 2>&1 | \
+# RUN:   FileCheck -DFILE=%t.signame.o %s --check-prefixes=SIGNAME1-WARN,SIGNAME1-JSON --implicit-check-not=warning:
 
 # SIGNAME1-WARN: warning: '[[FILE]]': unable to get the name of the symbol with index 2: st_name (0x5) is past the end of the string table of size 0x5
 

 # SIGNAME1-GNU: COMDAT group section [    1] `.group' [] contains 2 sections:
 # SIGNAME1-GNU: COMDAT group section [    2] `.group1' [<?>] contains 2 sections:
 
+# SIGNAME1-JSON: "Signature": ""
+# SIGNAME1-JSON: "Signature": "<?>"
+
 ## Check we report a warning when the string table that contains the signature symbol name is not null-terminated.
 
 # RUN: yaml2obj %s -DSTRTABCONTENT="0061626361" -DSYM1STNAME=4 -DSYM2STNAME=5 -o %t.signame2.o

 # RUN:   FileCheck -DFILE=%t.signame2.o %s --check-prefixes=SIGNAME2-WARN,SIGNAME2-LLVM --implicit-check-not=warning:
 # RUN: llvm-readelf --section-groups %t.signame2.o 2>&1 | \
 # RUN:   FileCheck -DFILE=%t.signame2.o %s --check-prefixes=SIGNAME2-WARN,SIGNAME2-GNU --implicit-check-not=warning:
+# RUN: llvm-readelf --elf-output-style=JSON --section-groups %t.signame2.o 2>&1 | \
+# RUN:   FileCheck -DFILE=%t.signame2.o %s --check-prefixes=SIGNAME2-WARN,SIGNAME2-JSON --implicit-check-not=warning:
 
 # SIGNAME2-WARN: warning: '[[FILE]]': unable to get the string table for SHT_SYMTAB section with index 7: SHT_STRTAB string table section [index 8] is non-null terminated
 

 
 # SIGNAME2-GNU: COMDAT group section [    1] `.group' [<?>] contains 2 sections:
 # SIGNAME2-GNU: COMDAT group section [    2] `.group1' [<?>] contains 2 sections:
+
+# SIGNAME2-JSON: "Signature": "<?>"
+# SIGNAME2-JSON: "Signature": "<?>"

llvm/test/tools/llvm-readobj/ELF/output-style.test

 ## Error for an unknown output style.
 RUN: not llvm-readobj --elf-output-style=unknown 2>&1 | FileCheck %s
 
-CHECK: error: --elf-output-style value should be either 'LLVM' or 'GNU'
+CHECK: error: --elf-output-style value should be either 'LLVM', 'GNU', or 'JSON'

llvm/tools/llvm-readobj/ELFDumper.cpp

 #include "llvm/Support/Format.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/FormattedStream.h"
+#include "llvm/Support/JSON.h"
 #include "llvm/Support/LEB128.h"
 #include "llvm/Support/MSP430AttributeParser.h"
 #include "llvm/Support/MSP430Attributes.h"

   ScopedPrinter &W;
 };
 
+template <typename ELFT> class JSONELFDumper : public ELFDumper<ELFT> {
+  json::OStream JOS;
+
+public:
+  LLVM_ELF_IMPORT_TYPES_ELFT(ELFT)
+
+  JSONELFDumper(const object::ELFObjectFile<ELFT> &ObjF, ScopedPrinter &Writer)
+      : ELFDumper<ELFT>(ObjF, Writer), JOS(Writer.getOStream(), 2) {
+    assert(&this->W.getOStream() == &llvm::fouts());
+    JOS.objectBegin();
+  }
+  ~JSONELFDumper() { JOS.objectEnd(); }
+
+  void printFileHeaders() override;
+  void printGroupSections() override;
+  void printRelocations() override;
+  void printSectionHeaders() override;
+  void printSymbols(bool PrintSymbols, bool PrintDynamicSymbols) override;
+  void printHashSymbols() override;
+  void printSectionDetails() override;
+  void printDependentLibs() override;
+  void printDynamicTable() override;
+  void printDynamicRelocations() override;
+  void printSymtabMessage(const Elf_Shdr *Symtab, size_t Offset,
+                          bool NonVisibilityBitsUsed) const override;
+  void printProgramHeaders(bool PrintProgramHeaders,
+                           cl::boolOrDefault PrintSectionMapping) override;
+  void printVersionSymbolSection(const Elf_Shdr *Sec) override;
+  void printVersionDefinitionSection(const Elf_Shdr *Sec) override;
+  void printVersionDependencySection(const Elf_Shdr *Sec) override;
+  void printHashHistograms() override;
+  void printCGProfile() override;
+  void printBBAddrMaps() override;
+  void printAddrsig() override;
+  void printNotes() override;
+  void printELFLinkerOptions() override;
+  void printStackSizes() override;
+
+private:
+  void printRelrReloc(const Elf_Relr &R) override;
+  void printRelRelaReloc(const Relocation<ELFT> &R,
+                         const RelSymbol<ELFT> &RelSym) override;
+  void printSymbol(const Elf_Sym &Symbol, unsigned SymIndex,
+                   DataRegion<Elf_Word> ShndxTable,
+                   Optional<StringRef> StrTable, bool IsDynamic,
+                   bool NonVisibilityBitsUsed) const override;
+  void printDynamicRelocHeader(unsigned Type, StringRef Name,
+                               const DynRegionInfo &Reg) override;
+
+  void printProgramHeaders() override;
+  void printSectionMapping() override;
+
+  void printStackSizeEntry(uint64_t Size,
+                           ArrayRef<std::string> FuncNames) override;
+  void printMipsGOT(const MipsGOTParser<ELFT> &Parser) override;
+  void printMipsPLT(const MipsGOTParser<ELFT> &Parser) override;
+  void printMipsABIFlags() override;
+
+  template <typename T, typename TEnum>
+  std::string printEnum(T Value, ArrayRef<EnumEntry<TEnum>> EnumValues) const {
+    for (const EnumEntry<TEnum> &EnumItem : EnumValues)
+      if (EnumItem.Value == Value)
+        return std::string(EnumItem.AltName);
+    return to_hexString(Value, false);
+  }
+
+  template <typename T, typename TEnum>
+  void printFlags(T Value, ArrayRef<EnumEntry<TEnum>> EnumValues,
+                  TEnum EnumMask1 = {}, TEnum EnumMask2 = {},
+                  TEnum EnumMask3 = {}) {
+    JOS.attributeArray("Flags", [&]() {
+      for (const EnumEntry<TEnum> &Flag : EnumValues) {
+        if (Flag.Value == 0)
+          continue;
+        TEnum EnumMask{};
+        if (Flag.Value & EnumMask1)
+          EnumMask = EnumMask1;
+        else if (Flag.Value & EnumMask2)
+          EnumMask = EnumMask2;
+        else if (Flag.Value & EnumMask3)
+          EnumMask = EnumMask3;
+        bool IsEnum = (Flag.Value & EnumMask) != 0;
+        if ((!IsEnum && (Value & Flag.Value) == Flag.Value) ||
+            (IsEnum && (Value & EnumMask) == Flag.Value)) {
+          JOS.value(Flag.AltName);
+        }
+      }
+    });
+  }
+};
+
 } // end anonymous namespace
 
 namespace llvm {

 createELFDumper(const ELFObjectFile<ELFT> &Obj, ScopedPrinter &Writer) {
   if (opts::Output == opts::GNU)
     return std::make_unique<GNUELFDumper<ELFT>>(Obj, Writer);
+  else if (opts::Output == opts::JSON)
+    return std::make_unique<JSONELFDumper<ELFT>>(Obj, Writer);
   return std::make_unique<LLVMELFDumper<ELFT>>(Obj, Writer);
 }
 

   W.printFlags("Flags 1", Flags->flags1, makeArrayRef(ElfMipsFlags1));
   W.printHex("Flags 2", Flags->flags2);
 }
+
+template <class ELFT> void JSONELFDumper<ELFT>::printFileHeaders() {
+  const Elf_Ehdr &E = this->Obj.getHeader();
+  JOS.attributeBegin("ElfHeader");
+  JOS.objectBegin();
+  {
+    JOS.attributeBegin("Ident");
+    JOS.objectBegin();
+    JOS.attributeArray("Magic", [&]() {
+      for (const unsigned char &MagicByte :
+           makeArrayRef(E.e_ident).slice(ELF::EI_MAG0, 4)) {
+        JOS.value(to_hexString(MagicByte));
+      }
+    });
+    JOS.attribute("Class",
+                  printEnum(E.e_ident[ELF::EI_CLASS], makeArrayRef(ElfClass)));
+    JOS.attribute("DataEncoding", printEnum(E.e_ident[ELF::EI_DATA],
+                                            makeArrayRef(ElfDataEncoding)));
+    JOS.attribute("FileVersion", E.e_ident[ELF::EI_VERSION]);
+
+    auto OSABI = makeArrayRef(ElfOSABI);
+    if (E.e_ident[ELF::EI_OSABI] >= ELF::ELFOSABI_FIRST_ARCH &&
+        E.e_ident[ELF::EI_OSABI] <= ELF::ELFOSABI_LAST_ARCH) {
+      switch (E.e_machine) {
+      case ELF::EM_AMDGPU:
+        OSABI = makeArrayRef(AMDGPUElfOSABI);
+        break;
+      case ELF::EM_ARM:
+        OSABI = makeArrayRef(ARMElfOSABI);
+        break;
+      case ELF::EM_TI_C6000:
+        OSABI = makeArrayRef(C6000ElfOSABI);
+        break;
+      }
+    }
+    JOS.attribute("OS/ABI", printEnum(E.e_ident[ELF::EI_OSABI], OSABI));
+    JOS.attribute("ABIVersion", E.e_ident[ELF::EI_ABIVERSION]);
+    JOS.attributeArray("Unused", [&]() {
+      for (const auto &byte : makeArrayRef(E.e_ident).slice(ELF::EI_PAD)) {
+        JOS.value(to_hexString(byte));
+      }
+    });
+    JOS.objectEnd();
+    JOS.attributeEnd();
+  }
+  std::string TypeStr;
+  if (const EnumEntry<unsigned> *Ent = getObjectFileEnumEntry(E.e_type)) {
+    TypeStr = Ent->Name.str();
+  } else {
+    if (E.e_type >= ET_LOPROC)
+      TypeStr = "Processor Specific";
+    else if (E.e_type >= ET_LOOS)
+      TypeStr = "OS Specific";
+    else
+      TypeStr = "Unknown";
+  }
+  JOS.attribute("Type", TypeStr);
+  JOS.attribute("Machine",
+                printEnum(E.e_machine, makeArrayRef(ElfMachineType)));
+  JOS.attribute("Version", "0x" + to_hexString(E.e_version));
+  JOS.attribute("Entry", to_hexString(E.e_entry));
+  JOS.attribute("ProgramHeaderOffset", to_string(E.e_phoff));
+  JOS.attribute("SectionHeaderOffset", to_string(E.e_shoff));
+
+  if (E.e_machine == EM_MIPS) {
+    printFlags(E.e_flags, makeArrayRef(ElfHeaderMipsFlags),
+               unsigned(ELF::EF_MIPS_ARCH), unsigned(ELF::EF_MIPS_ABI),
+               unsigned(ELF::EF_MIPS_MACH));
+  } else if (E.e_machine == EM_AMDGPU) {
+    switch (E.e_ident[ELF::EI_ABIVERSION]) {
+    case 0:
+      // ELFOSABI_AMDGPU_PAL, ELFOSABI_AMDGPU_MESA3D support *_V3 flags.
+      LLVM_FALLTHROUGH;
+    case ELF::ELFABIVERSION_AMDGPU_HSA_V3:
+      printFlags(E.e_flags, makeArrayRef(ElfHeaderAMDGPUFlagsABIVersion3),
+                 unsigned(ELF::EF_AMDGPU_MACH));
+      break;
+    case ELF::ELFABIVERSION_AMDGPU_HSA_V4:
+      printFlags(E.e_flags, makeArrayRef(ElfHeaderAMDGPUFlagsABIVersion4),
+                 unsigned(ELF::EF_AMDGPU_MACH),
+                 unsigned(ELF::EF_AMDGPU_FEATURE_XNACK_V4),
+                 unsigned(ELF::EF_AMDGPU_FEATURE_SRAMECC_V4));
+      break;
+    }
+  } else if (E.e_machine == EM_RISCV)
+    printFlags(E.e_flags, makeArrayRef(ElfHeaderRISCVFlags));
+  else if (E.e_machine == EM_AVR)
+    printFlags(E.e_flags, makeArrayRef(ElfHeaderAVRFlags));
+
+  JOS.attribute("FlagsRaw", "0x" + to_hexString(E.e_flags));
+  // TODO: Handle uint16_t
+  JOS.attribute("HeaderSize", to_string(E.e_ehsize));
+  JOS.attribute("ProgramHeaderEntrySize", to_string(E.e_phentsize));
+  JOS.attribute("ProgramHeaderCount", to_string(E.e_phnum));
+  JOS.attribute("SectionHeaderEntrySize", to_string(E.e_shentsize));
+  JOS.attribute("SectionHeaderCount",
+                getSectionHeadersNumString(this->Obj, this->FileName));
+  JOS.attribute("StringTableSectionIndex",
+                getSectionHeaderTableIndexString(this->Obj, this->FileName));
+  JOS.objectEnd();
+  JOS.attributeEnd();
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printGroupSections() {
+  std::vector<GroupSection> V = this->getGroups();
+  DenseMap<uint64_t, const GroupSection *> Map = mapSectionsToGroups(V);
+  JOS.attributeArray("Groups", [&]() {
+    for (const GroupSection &G : V) {
+      JOS.objectBegin();
+      JOS.attributeBegin("Group");
+      JOS.objectBegin();
+      JOS.attribute("Name", G.Name);
+      // TODO: handle uint64_t
+      JOS.attribute("Index", to_string(G.Index));
+      JOS.attribute("Link", G.Link);
+      JOS.attribute("Info", G.Info);
+      JOS.attribute("Type", getGroupType(G.Type));
+      JOS.attribute("Signature", G.Signature);
+      JOS.attributeArray("SectionsInGroup", [&]() {
+        for (const GroupMember &GM : G.Members) {
+          const GroupSection *MainGroup = Map[GM.Index];
+          JOS.objectBegin();
+          if (MainGroup != &G)
+            this->reportUniqueWarning(
+                "section with index " + Twine(GM.Index) +
+                ", included in the group section with index " +
+                Twine(MainGroup->Index) +
+                ", was also found in the group section with index " +
+                Twine(G.Index));
+          JOS.attribute("Name", GM.Name);
+          // TODO: handle uint64_t
+          JOS.attribute("Index", to_string(GM.Index));
+          JOS.objectEnd();
+        }
+      });
+      JOS.objectEnd();
+      JOS.attributeEnd();
+      JOS.objectEnd();
+    }
+  });
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printRelocations() {
+  // TODO: Implement
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printSectionHeaders() {
+  // TODO: Implement
+}
+
+template <class ELFT>
+void JSONELFDumper<ELFT>::printSymbols(bool PrintSymbols,
+                                       bool PrintDynamicSymbols) {
+  // TODO: Implement
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printHashSymbols() {
+  // TODO: Implement
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printSectionDetails() {
+  // TODO: Implement
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printDependentLibs() {
+  // TODO: Implement
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printDynamicTable() {
+  // TODO: Implement
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printDynamicRelocations() {
+  // TODO: Implement
+}
+
+template <class ELFT>
+void JSONELFDumper<ELFT>::printSymtabMessage(const Elf_Shdr *Symtab,
+                                             size_t Offset,
+                                             bool NonVisibilityBitsUsed) const {
+  // TODO: Implement
+}
+
+template <class ELFT>
+void JSONELFDumper<ELFT>::printProgramHeaders(
+    bool PrintProgramHeaders, cl::boolOrDefault PrintSectionMapping) {
+  // TODO: Implement
+}
+
+template <class ELFT>
+void JSONELFDumper<ELFT>::printVersionSymbolSection(const Elf_Shdr *Sec) {
+  // TODO: Implement
+}
+
+template <class ELFT>
+void JSONELFDumper<ELFT>::printVersionDefinitionSection(const Elf_Shdr *Sec) {
+  // TODO: Implement
+}
+
+template <class ELFT>
+void JSONELFDumper<ELFT>::printVersionDependencySection(const Elf_Shdr *Sec) {
+  // TODO: Implement
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printHashHistograms() {
+  // TODO: Implement
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printCGProfile() {
+  // TODO: Implement
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printBBAddrMaps() {
+  // TODO: Implement
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printAddrsig() {
+  // TODO: Implement
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printNotes() {
+  // TODO: Implement
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printELFLinkerOptions() {
+  // TODO: Implement
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printStackSizes() {
+  // TODO: Implement
+}
+
+template <class ELFT>
+void JSONELFDumper<ELFT>::printMipsGOT(const MipsGOTParser<ELFT> &Parser) {
+  // TODO: Implement
+}
+
+template <class ELFT>
+void JSONELFDumper<ELFT>::printMipsPLT(const MipsGOTParser<ELFT> &Parser) {
+  // TODO: Implement
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printMipsABIFlags() {
+  // TODO: Implement
+}
+
+template <class ELFT>
+void JSONELFDumper<ELFT>::printRelrReloc(const Elf_Relr &R) {
+  // TODO: Implement
+}
+
+template <class ELFT>
+void JSONELFDumper<ELFT>::printRelRelaReloc(const Relocation<ELFT> &R,
+                                            const RelSymbol<ELFT> &RelSym) {
+  // TODO: Implement
+}
+
+template <class ELFT>
+void JSONELFDumper<ELFT>::printSymbol(const Elf_Sym &Symbol, unsigned SymIndex,
+                                      DataRegion<Elf_Word> ShndxTable,
+                                      Optional<StringRef> StrTable,
+                                      bool IsDynamic,
+                                      bool NonVisibilityBitsUsed) const {
+  // TODO: Implement
+}
+
+template <class ELFT>
+void JSONELFDumper<ELFT>::printDynamicRelocHeader(unsigned Type, StringRef Name,
+                                                  const DynRegionInfo &Reg) {
+  // TODO: Implement
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printProgramHeaders() {
+  // TODO: Implement
+}
+
+template <class ELFT> void JSONELFDumper<ELFT>::printSectionMapping() {
+  // TODO: Implement
+}
+
+template <class ELFT>
+void JSONELFDumper<ELFT>::printStackSizeEntry(uint64_t Size,
+                                              ArrayRef<std::string> FuncNames) {
+  // TODO: Implement
+}

llvm/tools/llvm-readobj/llvm-readobj.h

 extern bool RawRelr;
 extern bool CodeViewSubsectionBytes;
 extern bool Demangle;
-enum OutputStyleTy { LLVM, GNU };
+enum OutputStyleTy { LLVM, GNU, JSON };
 extern OutputStyleTy Output;
 } // namespace opts
 

llvm/tools/llvm-readobj/llvm-readobj.cpp

       opts::Output = opts::OutputStyleTy::LLVM;
     else if (V == "GNU")
       opts::Output = opts::OutputStyleTy::GNU;
+    else if (V == "JSON")
+      opts::Output = opts::OutputStyleTy::JSON;
     else
-      error("--elf-output-style value should be either 'LLVM' or 'GNU'");
+      error("--elf-output-style value should be either 'LLVM', 'GNU', or 'JSON'");
   }
   opts::GnuHashTable = Args.hasArg(OPT_gnu_hash_table);
   opts::HashSymbols = Args.hasArg(OPT_hash_symbols);