[llvm] [llvm-readobj][ELF] Fix broken JSON output with --dynamic-table (PR #95976)
James Henderson via llvm-commits
llvm-commits at lists.llvm.org
Thu Jun 20 00:50:29 PDT 2024
================
@@ -7365,6 +7367,19 @@ template <class ELFT> void LLVMELFDumper<ELFT>::printDynamicTable() {
W.startLine() << "]\n";
}
+template <class ELFT> void JSONELFDumper<ELFT>::printDynamicTable() {
+ Elf_Dyn_Range Table = this->dynamic_table();
+ ListScope L(this->W, "DynamicSection");
+ for (const auto &Entry : Table) {
+ DictScope D(this->W);
+ uintX_t Tag = Entry.getTag();
+ std::string Value = this->getDynamicEntry(Tag, Entry.getVal());
+ this->W.printHex("Tag", Tag);
+ this->W.printString("Value", Value);
+ this->W.printString("Type", this->Obj.getDynamicTagAsString(Tag));
----------------
jh7370 wrote:
I'm not opposed to having the type field, if you think it's useful for readability of the output.
As I understand JSON, I'm not sure we need a nested object for the Value field, because the individual DynamicTable entries can have different types for that field. In other words, I think it could look something like this:
```
...
"Value": 16
"Type": "PLTRELSZ"
...
"Value": ["A", "B"]
"RawValue":4321
"Type": "NEEDED"
...
"Value": 4096
"Type": "HASH"
```
Note that I've added "RawValue" for the case where the value isn't just the raw number in the dynamic table. For some dynamic entries, the value is the actual meaning. In other cases, it's a pointer to some other information stored somewhere. The "bytes" bit of the size is unnecessary, since the size values are implicitly in bytes.
A possible variation on my above suggestion is the following, where every entry has a "Value" member, which is the raw value stored in the dynamic table, and in the cases where that value has some interpreted meaning, there's an additional entry. In this way, a generic parser doesn't need to understand the tag types to be able to record the raw values, since all the "Value" entries have the same type.
```
"Type": "PLTRELSZ",
"Value": 16
...
"Type": "NEEDED",
"Value": 1234,
"Libraries": ["A", "B", "C"]
...
"Type": "SONAME",
"Value": 100,
"Name": "my-library"
```
(For simplicity in both examples, I've not included separate Tag/Type fields, but these can be included as per the current behaviour)
https://github.com/llvm/llvm-project/pull/95976
More information about the llvm-commits
mailing list