Port JSON output format for llvm-dwarfdump

[PiJoules]

llvm-readelf/obj supports --elf-output-style= with JSON as one of the values which makes parsing readelf output much easier. Having the same for llvm-dwarfdump would also be nice to have.

[llvmbot]

@llvm/issue-subscribers-tools-llvm-dwarfdump

Author: None (PiJoules)

`llvm-readelf/obj` supports `--elf-output-style=` with JSON as one of the values which makes parsing readelf output much easier. Having the same for `llvm-dwarfdump` would also be nice to have.

[llvmbot]

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

1. Check that no other contributor is working on this issue. If someone is assigned to the issue or claimed to be working on it, ping the person. After one week without a response, the assignee may be changed.
2. Leave a comment indicating that you are working on the issue, or just create a pull request after following the steps below. Mention this issue in the description of the pull request.
3. Fix the issue locally.
4. Run the test suite locally. Remember that the subdirectories under test/ create fine-grained testing targets, so you can e.g. use make check-clang-ast to only run Clang's AST tests.
5. Create a Git commit.
6. Run git clang-format HEAD~1 to format your changes.
7. Open a pull request to the upstream repository on GitHub. Detailed instructions can be found in GitHub's documentation. Mention this issue in the description of the pull request.

If you have any further questions about this issue, don't hesitate to ask via a comment in the thread below.

[llvmbot]

@llvm/issue-subscribers-good-first-issue

Author: None (PiJoules)

`llvm-readelf/obj` supports `--elf-output-style=` with JSON as one of the values which makes parsing readelf output much easier. Having the same for `llvm-dwarfdump` would also be nice to have.

[woruyu]

Hi! I'd like to work on this issue. Can you assign it to me? Thank you!@PiJoules

[jh7370]

@woruyu, I have assigned this ticket to you. However, I caution that this is probably not as simple as @PiJoules imagines, because the llvm-dwarfdump printing is spread throughout the debug info library and isn't currently in a particularly structured format, unlike the llvm-readobj output that the JSON output built on top of it. I suspect it could take multiple weeks to months to tackle, especially if you aren't familiar with the DWARF file format. That being said, it is a "good first issue" in the sense that I think it's a good opportunity to become familiar with DWARF and the related LLVM code.

Feel free to take a look, but before starting implementing, I think you should post an RFC on our Discourse forum which describes how you'd like the output to look before actually doing the implementation. See https://llvm.org/docs/DeveloperPolicy.html#proposing-major-changes-rfcs for more details.

If you'd prefer not to work on this after all, please let us know here, so that we can unassign you.

[woruyu]

@jh7370 Thanks! I'm happy to give it a try.
In some of my previous work, I’ve dealt with DWARF at a low level — specifically, manually parsing the .debug_line section from ELF files using a state machine to map machine code addresses to source line numbers.
I’ll start by studying the existing llvm-dwarfdump infrastructure and will post an RFC on Discourse outlining the proposed output format before moving on to implementation.

[jh7370]

@jh7370 Thanks! I'm happy to give it a try. In some of my previous work, I’ve dealt with DWARF at a low level — specifically, manually parsing the .debug_line section from ELF files using a state machine to map machine code addresses to source line numbers. I’ll start by studying the existing llvm-dwarfdump infrastructure and will post an RFC on Discourse outlining the proposed output format before moving on to implementation.

Sounds good! I'd focus on dumping the different DWARF section types as a first attempt and don't try to implement printing for every section at once. Also, consider how to split the changes into small, easily reviewable chunks rather than having a big monolithic PR with all the changes at once.

[woruyu]

@jh7370 Thanks! I'm happy to give it a try. In some of my previous work, I’ve dealt with DWARF at a low level — specifically, manually parsing the .debug_line section from ELF files using a state machine to map machine code addresses to source line numbers. I’ll start by studying the existing llvm-dwarfdump infrastructure and will post an RFC on Discourse outlining the proposed output format before moving on to implementation.

Sounds good! I'd focus on dumping the different DWARF section types as a first attempt and don't try to implement printing for every section at once. Also, consider how to split the changes into small, easily reviewable chunks rather than having a big monolithic PR with all the changes at once.

Thanks for the guidance — I’ll start by focusing on a few key DWARF sections (e.g. .debug_info, .debug_line) and plan the initial structure accordingly. I’ll also make sure to split the changes into small, reviewable patches rather than one big PR.

[PiJoules]

Echoing what @jh7370 mentioned, yeah I also think an RFC is good and small incremental changes are nice to review. By no means do I expect this to be done very quickly over a weekend. Definitely reach out if you have any questions.

[woruyu]

Hello, @jh7370 @PiJoules

My Observations and Suggestions on DWARF JSON Output

I did a rough read-through of both llvm-dwarfdump and llvm-readelf, focusing on .debug_line dumping logic.

Observations:

• In llvm-dwarfdump, the output logic is tightly embedded within different class. For example:
  • DWARFDebugLine::Row::dump(raw_ostream &)
  • DWARFDebugLine::Prologue::dump(raw_ostream &)
• In llvm-dwarfdump, there is no abstraction separating data from presentation. Output logic is directly embedded in DWARF structures, so adding JSON support would involve duplicating or rewriting formatting logic inside those classes.
• In contrast, llvm-readelf is more structured in this regard:
  • It uses dedicated dumper classes such as JSONELFDumper and formatter utilities like ScopedPrinter.
  • These abstractions cleanly separate data interpretation from output generation, making it easier to support multiple output formats.
• However, llvm-objdump and llvm-dwarfdump currently lack such abstractions for DWARF, and there’s no equivalent to JSONELFDumper or ScopedPrinter to represent output formatting logic in a reusable or extensible way.
• So, I meet problem.

Design Options I'm Considering:

1. Minimal Intrusive Approach(I prefer this)

• Add dumpJSON() methods directly inside the existing DWARF structures (e.g., DWARFDebugLine::Row).
• ✅ Pros: Small code delta, doesn’t interfere with current text-based dumping.
• ❌ Cons: Continues mixing presentation and data logic; not scalable or clean long-term.

2. Abstracted Dumper Layer (like readelf, but for me, It's tricky to handle)

• Introduce a DWARFScopedPrinter or DWARFJSONELFDumper which receives parsed DWARF structures and renders them as JSON.
• ✅ Pros: Clear separation of concerns; scalable to other sections (e.g., .debug_info, .debug_pubnames).
• ❌ Cons: Requires larger refactor of dumping paths.

Right now, I’m leaning toward prototyping option 1 on .debug_line to validate its usefulness.

Let me know what you think — especially whether there's precedent or preference for how to extend llvm-dwarfdump in this way.

[jh7370]

Thanks @woruyu. I think my thoughts reflect your own. That's especially the case because the structure of DWARF varies quite dramatically between the different sections, so I suspect you'd have a hard-time making a clean abstraction.

CC'ing @dwblaikie, @igorkudrin, @adrian-prantl, @JDevlieghere in case any of them have more thoughts.