[llvm-readobj][ELF] Test multivalued rpath entries and alter the output for readobj to emphasize the single valued nature of NEEDED, SONAME, USED etc. #96562
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ut for readobj to emphasize the single valued nature of NEEDED, SONAME, USED etc. In the context of llvm#95976 it became clear that the output for readobj implied multi valued entries in several cases in the elf headers that the documentation only allowed for a single value. DT_NEEDED is the example here where the value is an offset into the string table without any sort of separator that could give you multiple entries. This patch alters the LLVM output so that the single valued nature is emphasized. For example the output was: ``` DynamicSection [ (35 entries) Tag Type Name/Value 0x000000000000001D RUNPATH Library runpath: [$ORIGIN/../lib:] 0x0000000000000001 NEEDED Shared library: [libm.so.6] 0x0000000000000001 NEEDED Shared library: [libz.so.1] 0x0000000000000001 NEEDED Shared library: [libzstd.so.1] ``` and is now ``` Tag Type Name/Value 0x000000000000001D RUNPATH Library runpath: [$ORIGIN/../lib:] 0x0000000000000001 NEEDED Shared library: libm.so.6 0x0000000000000001 NEEDED Shared library: libz.so.1 0x0000000000000001 NEEDED Shared library: libzstd.so.1 ``` This pr also tests that multi-valued rpaths are handled correctly in the JSON case (i.e. they become proper lists) like: ``` { "Tag": 15, "Type": "RPATH", "Value": 9, "Path": [ "x", "w", "U" ] }, ``` when separated by :
|
@llvm/pr-subscribers-lld @llvm/pr-subscribers-llvm-binary-utilities Author: Fred Grim (feg208) ChangesIn the context of #95976 it became clear that the output for readobj implied multi valued entries in several cases in the elf headers that the documentation only allowed for a single value. DT_NEEDED is the example here where the value is an offset into the string table without any sort of separator that could give you multiple entries. This patch alters the LLVM output so that the single valued nature is emphasized. For example the output was: and is now This pr also tests that multi-valued rpaths are handled correctly in the JSON case (i.e. they become proper lists) like: when separated by : Patch is 25.49 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/96562.diff 4 Files Affected:
diff --git a/llvm/test/tools/llvm-readobj/ELF/dynamic-malformed.test b/llvm/test/tools/llvm-readobj/ELF/dynamic-malformed.test
index d160ea87208c3..05be15775e9e7 100644
--- a/llvm/test/tools/llvm-readobj/ELF/dynamic-malformed.test
+++ b/llvm/test/tools/llvm-readobj/ELF/dynamic-malformed.test
@@ -100,15 +100,15 @@ ProgramHeaders:
# BAD-STRING-LLVM-NEXT: 0x0000000000000005 STRTAB 0x1000
# BAD-STRING-LLVM-NEXT: 0x000000000000000A STRSZ 1 (bytes)
# BAD-STRING-LLVM-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb2: it goes past the end of the table (0xb1)
-# BAD-STRING-LLVM-NEXT: 0x0000000000000001 NEEDED Shared library: [<?>]
+# BAD-STRING-LLVM-NEXT: 0x0000000000000001 NEEDED Shared library: <?>
# BAD-STRING-LLVM-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb3: it goes past the end of the table (0xb1)
-# BAD-STRING-LLVM-NEXT: 0x000000007FFFFFFF FILTER Filter library: [<?>]
+# BAD-STRING-LLVM-NEXT: 0x000000007FFFFFFF FILTER Filter library: <?>
# BAD-STRING-LLVM-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb4: it goes past the end of the table (0xb1)
-# BAD-STRING-LLVM-NEXT: 0x000000007FFFFFFD AUXILIARY Auxiliary library: [<?>]
+# BAD-STRING-LLVM-NEXT: 0x000000007FFFFFFD AUXILIARY Auxiliary library: <?>
# BAD-STRING-LLVM-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb5: it goes past the end of the table (0xb1)
-# BAD-STRING-LLVM-NEXT: 0x000000007FFFFFFE USED Not needed object: [<?>]
+# BAD-STRING-LLVM-NEXT: 0x000000007FFFFFFE USED Not needed object: <?>
## Note: there is no "string table at offset 0xb0..." warning here, because it was printed earlier.
-# BAD-STRING-LLVM-NEXT: 0x000000000000000E SONAME Library soname: [<?>]
+# BAD-STRING-LLVM-NEXT: 0x000000000000000E SONAME Library soname: <?>
# BAD-STRING-LLVM-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb7: it goes past the end of the table (0xb1)
# BAD-STRING-LLVM-NEXT: 0x000000000000000F RPATH Library rpath: [<?>]
# BAD-STRING-LLVM-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb8: it goes past the end of the table (0xb1)
@@ -121,15 +121,15 @@ ProgramHeaders:
# BAD-STRING-GNU-NEXT: 0x0000000000000005 (STRTAB) 0x1000
# BAD-STRING-GNU-NEXT: 0x000000000000000a (STRSZ) 1 (bytes)
# BAD-STRING-GNU-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb2: it goes past the end of the table (0xb1)
-# BAD-STRING-GNU-NEXT: 0x0000000000000001 (NEEDED) Shared library: [<?>]
+# BAD-STRING-GNU-NEXT: 0x0000000000000001 (NEEDED) Shared library: <?>
# BAD-STRING-GNU-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb3: it goes past the end of the table (0xb1)
-# BAD-STRING-GNU-NEXT: 0x000000007fffffff (FILTER) Filter library: [<?>]
+# BAD-STRING-GNU-NEXT: 0x000000007fffffff (FILTER) Filter library: <?>
# BAD-STRING-GNU-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb4: it goes past the end of the table (0xb1)
-# BAD-STRING-GNU-NEXT: 0x000000007ffffffd (AUXILIARY) Auxiliary library: [<?>]
+# BAD-STRING-GNU-NEXT: 0x000000007ffffffd (AUXILIARY) Auxiliary library: <?>
# BAD-STRING-GNU-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb5: it goes past the end of the table (0xb1)
-# BAD-STRING-GNU-NEXT: 0x000000007ffffffe (USED) Not needed object: [<?>]
+# BAD-STRING-GNU-NEXT: 0x000000007ffffffe (USED) Not needed object: <?>
# BAD-STRING-GNU-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb6: it goes past the end of the table (0xb1)
-# BAD-STRING-GNU-NEXT: 0x000000000000000e (SONAME) Library soname: [<?>]
+# BAD-STRING-GNU-NEXT: 0x000000000000000e (SONAME) Library soname: <?>
# BAD-STRING-GNU-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb7: it goes past the end of the table (0xb1)
# BAD-STRING-GNU-NEXT: 0x000000000000000f (RPATH) Library rpath: [<?>]
# BAD-STRING-GNU-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb8: it goes past the end of the table (0xb1)
@@ -199,8 +199,8 @@ ProgramHeaders:
# BAD-STRTAB-ERR2: warning: '[[FILE]]': unable to parse DT_STRTAB: virtual address is not in any segment: 0x2000000
# BAD-STRTAB-LLVM: LoadName: <Not found>
# BAD-STRTAB: warning: '[[FILE]]': string table was not found
-# BAD-STRTAB-LLVM-NEXT: 0x0000000000000001 NEEDED Shared library: [<?>]
-# BAD-STRTAB-GNU-NEXT: 0x0000000000000001 (NEEDED) Shared library: [<?>]
+# BAD-STRTAB-LLVM-NEXT: 0x0000000000000001 NEEDED Shared library: <?>
+# BAD-STRTAB-GNU-NEXT: 0x0000000000000001 (NEEDED) Shared library: <?>
# BAD-STRTAB: NeededLibraries [
# BAD-STRTAB: <?>
# BAD-STRTAB: ]
@@ -313,15 +313,15 @@ ProgramHeaders:
# NOT-TERMINATED-LLVM: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb4: the string table is not null-terminated
# NOT-TERMINATED: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb0: the string table is not null-terminated
-# NOT-TERMINATED-NEXT: {{[(]?}}NEEDED{{[)]?}} Shared library: [<?>]
+# NOT-TERMINATED-NEXT: {{[(]?}}NEEDED{{[)]?}} Shared library: <?>
# NOT-TERMINATED-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb1: the string table is not null-terminated
-# NOT-TERMINATED-NEXT: {{[(]?}}FILTER{{[)]?}} Filter library: [<?>]
+# NOT-TERMINATED-NEXT: {{[(]?}}FILTER{{[)]?}} Filter library: <?>
# NOT-TERMINATED-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb2: the string table is not null-terminated
-# NOT-TERMINATED-NEXT: {{[(]?}}AUXILIARY{{[)]?}} Auxiliary library: [<?>]
+# NOT-TERMINATED-NEXT: {{[(]?}}AUXILIARY{{[)]?}} Auxiliary library: <?>
# NOT-TERMINATED-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb3: the string table is not null-terminated
-# NOT-TERMINATED-NEXT: {{[(]?}}USED{{[)]?}} Not needed object: [<?>]
+# NOT-TERMINATED-NEXT: {{[(]?}}USED{{[)]?}} Not needed object: <?>
# NOT-TERMINATED-GNU-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb4: the string table is not null-terminated
-# NOT-TERMINATED-NEXT: {{[(]?}}SONAME{{[)]?}} Library soname: [<?>]
+# NOT-TERMINATED-NEXT: {{[(]?}}SONAME{{[)]?}} Library soname: <?>
# NOT-TERMINATED-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb5: the string table is not null-terminated
# NOT-TERMINATED-NEXT: {{[(]?}}RPATH{{[)]?}} Library rpath: [<?>]
# NOT-TERMINATED-GREQ-NEXT: warning: '[[FILE]]': string table at offset 0xb0: unable to read the string at 0xb6: the string table is not null-terminated
@@ -390,11 +390,11 @@ ProgramHeaders:
## as normal. Since the file ends with a zero byte, strings are dumped, but if it didn't,
## we'd get <?> printed instead. The important bit is that we don't get the past the end warning.
-# BEFORE-THE-EOF: {{[(]?}}NEEDED{{[)]?}} Shared library: [test.soabc]
-# BEFORE-THE-EOF-NEXT: {{[(]?}}FILTER{{[)]?}} Filter library: [est.soabc]
-# BEFORE-THE-EOF-NEXT: {{[(]?}}AUXILIARY{{[)]?}} Auxiliary library: [st.soabc]
-# BEFORE-THE-EOF-NEXT: {{[(]?}}USED{{[)]?}} Not needed object: [t.soabc]
-# BEFORE-THE-EOF-NEXT: {{[(]?}}SONAME{{[)]?}} Library soname: [.soabc]
+# BEFORE-THE-EOF: {{[(]?}}NEEDED{{[)]?}} Shared library: test.soabc
+# BEFORE-THE-EOF-NEXT: {{[(]?}}FILTER{{[)]?}} Filter library: est.soabc
+# BEFORE-THE-EOF-NEXT: {{[(]?}}AUXILIARY{{[)]?}} Auxiliary library: st.soabc
+# BEFORE-THE-EOF-NEXT: {{[(]?}}USED{{[)]?}} Not needed object: t.soabc
+# BEFORE-THE-EOF-NEXT: {{[(]?}}SONAME{{[)]?}} Library soname: .soabc
# BEFORE-THE-EOF-NEXT: {{[(]?}}RPATH{{[)]?}} Library rpath: [soabc]
# BEFORE-THE-EOF-NEXT: {{[(]?}}RUNPATH{{[)]?}} Library runpath: [oabc]
# BEFORE-THE-EOF-NEXT: {{[(]?}}NULL{{[)]?}} 0x0
@@ -406,11 +406,11 @@ ProgramHeaders:
# PAST-THE-EOF: warning: '[[FILE]]': the dynamic string table at 0xb0 goes past the end of the file (0x2c0) with DT_STRSZ = 0x211
# PAST-THE-EOF: warning: '[[FILE]]': string table was not found
-# PAST-THE-EOF: {{[(]?}}NEEDED{{[)]?}} Shared library: [<?>]
-# PAST-THE-EOF-NEXT: {{[(]?}}FILTER{{[)]?}} Filter library: [<?>]
-# PAST-THE-EOF-NEXT: {{[(]?}}AUXILIARY{{[)]?}} Auxiliary library: [<?>]
-# PAST-THE-EOF-NEXT: {{[(]?}}USED{{[)]?}} Not needed object: [<?>]
-# PAST-THE-EOF-NEXT: {{[(]?}}SONAME{{[)]?}} Library soname: [<?>]
+# PAST-THE-EOF: {{[(]?}}NEEDED{{[)]?}} Shared library: <?>
+# PAST-THE-EOF-NEXT: {{[(]?}}FILTER{{[)]?}} Filter library: <?>
+# PAST-THE-EOF-NEXT: {{[(]?}}AUXILIARY{{[)]?}} Auxiliary library: <?>
+# PAST-THE-EOF-NEXT: {{[(]?}}USED{{[)]?}} Not needed object: <?>
+# PAST-THE-EOF-NEXT: {{[(]?}}SONAME{{[)]?}} Library soname: <?>
# PAST-THE-EOF-NEXT: {{[(]?}}RPATH{{[)]?}} Library rpath: [<?>]
# PAST-THE-EOF-NEXT: {{[(]?}}RUNPATH{{[)]?}} Library runpath: [<?>]
# PAST-THE-EOF-NEXT: {{[(]?}}NULL{{[)]?}} 0x0
diff --git a/llvm/test/tools/llvm-readobj/ELF/dynamic-tags.test b/llvm/test/tools/llvm-readobj/ELF/dynamic-tags.test
index d05eed0f89cc6..e25f64ca22027 100644
--- a/llvm/test/tools/llvm-readobj/ELF/dynamic-tags.test
+++ b/llvm/test/tools/llvm-readobj/ELF/dynamic-tags.test
@@ -13,7 +13,7 @@
# LLVM64:DynamicSection [ (61 entries)
# LLVM64-NEXT: Tag Type Name/Value
-# LLVM64-NEXT: 0x0000000000000001 NEEDED Shared library: [D]
+# LLVM64-NEXT: 0x0000000000000001 NEEDED Shared library: D
# LLVM64-NEXT: 0x0000000000000002 PLTRELSZ 16 (bytes)
# LLVM64-NEXT: 0x0000000000000003 PLTGOT 0x1000
# LLVM64-NEXT: 0x0000000000000004 HASH 0x1000
@@ -26,8 +26,8 @@
# LLVM64-NEXT: 0x000000000000000B SYMENT 2439 (bytes)
# LLVM64-NEXT: 0x000000000000000C INIT 0x1000
# LLVM64-NEXT: 0x000000000000000D FINI 0x1000
-# LLVM64-NEXT: 0x000000000000000E SONAME Library soname: [U]
-# LLVM64-NEXT: 0x000000000000000F RPATH Library rpath: [f]
+# LLVM64-NEXT: 0x000000000000000E SONAME Library soname: U
+# LLVM64-NEXT: 0x000000000000000F RPATH Library rpath: [x:w:U]
# LLVM64-NEXT: 0x0000000000000010 SYMBOLIC 0x1234567890ABCDEF
# LLVM64-NEXT: 0x0000000000000011 REL 0x1000
# LLVM64-NEXT: 0x0000000000000012 RELSZ 16 (bytes)
@@ -67,9 +67,9 @@
# LLVM64-NEXT: 0x000000006FFFFFFD VERDEFNUM 0
# LLVM64-NEXT: 0x000000006FFFFFFE VERNEED 0x1000
# LLVM64-NEXT: 0x000000006FFFFFFF VERNEEDNUM 0
-# LLVM64-NEXT: 0x000000007FFFFFFD AUXILIARY Auxiliary library: [D]
-# LLVM64-NEXT: 0x000000007FFFFFFE USED Not needed object: [U]
-# LLVM64-NEXT: 0x000000007FFFFFFF FILTER Filter library: [U]
+# LLVM64-NEXT: 0x000000007FFFFFFD AUXILIARY Auxiliary library: D
+# LLVM64-NEXT: 0x000000007FFFFFFE USED Not needed object: U
+# LLVM64-NEXT: 0x000000007FFFFFFF FILTER Filter library: U
# LLVM64-NEXT: 0x0000000012345678 <unknown:>0x12345678 0x8765432187654321
# LLVM64-NEXT: 0x000000006ABCDEF0 <unknown:>0x6abcdef0 0x9988776655443322
# LLVM64-NEXT: 0x0000000076543210 <unknown:>0x76543210 0x5555666677778888
@@ -78,7 +78,7 @@
# GNU64:Dynamic section at offset {{.*}} contains 61 entries:
# GNU64-NEXT: Tag Type Name/Value
-# GNU64-NEXT: 0x0000000000000001 (NEEDED) Shared library: [D]
+# GNU64-NEXT: 0x0000000000000001 (NEEDED) Shared library: D
# GNU64-NEXT: 0x0000000000000002 (PLTRELSZ) 16 (bytes)
# GNU64-NEXT: 0x0000000000000003 (PLTGOT) 0x1000
# GNU64-NEXT: 0x0000000000000004 (HASH) 0x1000
@@ -91,8 +91,8 @@
# GNU64-NEXT: 0x000000000000000b (SYMENT) 2439 (bytes)
# GNU64-NEXT: 0x000000000000000c (INIT) 0x1000
# GNU64-NEXT: 0x000000000000000d (FINI) 0x1000
-# GNU64-NEXT: 0x000000000000000e (SONAME) Library soname: [U]
-# GNU64-NEXT: 0x000000000000000f (RPATH) Library rpath: [f]
+# GNU64-NEXT: 0x000000000000000e (SONAME) Library soname: U
+# GNU64-NEXT: 0x000000000000000f (RPATH) Library rpath: [x:w:U]
# GNU64-NEXT: 0x0000000000000010 (SYMBOLIC) 0x1234567890abcdef
# GNU64-NEXT: 0x0000000000000011 (REL) 0x1000
# GNU64-NEXT: 0x0000000000000012 (RELSZ) 16 (bytes)
@@ -132,9 +132,9 @@
# GNU64-NEXT: 0x000000006ffffffd (VERDEFNUM) 0
# GNU64-NEXT: 0x000000006ffffffe (VERNEED) 0x1000
# GNU64-NEXT: 0x000000006fffffff (VERNEEDNUM) 0
-# GNU64-NEXT: 0x000000007ffffffd (AUXILIARY) Auxiliary library: [D]
-# GNU64-NEXT: 0x000000007ffffffe (USED) Not needed object: [U]
-# GNU64-NEXT: 0x000000007fffffff (FILTER) Filter library: [U]
+# GNU64-NEXT: 0x000000007ffffffd (AUXILIARY) Auxiliary library: D
+# GNU64-NEXT: 0x000000007ffffffe (USED) Not needed object: U
+# GNU64-NEXT: 0x000000007fffffff (FILTER) Filter library: U
# GNU64-NEXT: 0x0000000012345678 (<unknown:>0x12345678) 0x8765432187654321
# GNU64-NEXT: 0x000000006abcdef0 (<unknown:>0x6abcdef0) 0x9988776655443322
# GNU64-NEXT: 0x0000000076543210 (<unknown:>0x76543210) 0x5555666677778888
@@ -216,9 +216,11 @@
# JSON64-NEXT: {
# JSON64-NEXT: "Tag": 15,
# JSON64-NEXT: "Type": "RPATH",
-# JSON64-NEXT: "Value": 5,
+# JSON64-NEXT: "Value": 9,
# JSON64-NEXT: "Path": [
-# JSON64-NEXT: "f"
+# JSON64-NEXT: "x",
+# JSON64-NEXT: "w",
+# JSON64-NEXT: "U"
# JSON64-NEXT: ]
# JSON64-NEXT: },
# JSON64-NEXT: {
@@ -506,7 +508,7 @@ Sections:
Type: SHT_STRTAB
Address: 0x1000
Size: 0x10
- Content: "004400550066007700"
+ Content: "004400550066007700783A773A5500"
- Name: .dynamic
Type: SHT_DYNAMIC
Address: 0x1010
@@ -540,7 +542,7 @@ Sections:
- Tag: DT_SONAME
Value: 0x3
- Tag: DT_RPATH
- Value: 0x5
+ Value: 0x9
- Tag: DT_SYMBOLIC
Value: [[SYMBOLIC=0x1234567890abcdef]]
- Tag: DT_REL
@@ -659,7 +661,7 @@ ProgramHeaders:
# LLVM32:DynamicSection [ (61 entries)
# LLVM32-NEXT: Tag Type Name/Value
-# LLVM32-NEXT: 0x00000001 NEEDED Shared library: [D]
+# LLVM32-NEXT: 0x00000001 NEEDED Shared library: D
# LLVM32-NEXT: 0x00000002 PLTRELSZ 16 (bytes)
# LLVM32-NEXT: 0x00000003 PLTGOT 0x1000
# LLVM32-NEXT: 0x00000004 HASH 0x1000
@@ -672,8 +674,8 @@ ProgramHeaders:
# LLVM32-NEXT: 0x0000000B SYMENT 2439 (bytes)
# LLVM32-NEXT: 0x0000000C INIT 0x1000
# LLVM32-NEXT: 0x0000000D FINI 0x1000
-# LLVM32-NEXT: 0x0000000E SONAME Library soname: [U]
-# LLVM32-NEXT: 0x0000000F RPATH Library rpath: [f]
+# LLVM32-NEXT: 0x0000000E SONAME Library soname: U
+# LLVM32-NEXT: 0x0000000F RPATH Library rpath: [x:w:U]
# LLVM32-NEXT: 0x00000010 SYMBOLIC 0x12345678
# LLVM32-NEXT: 0x00000011 REL 0x1000
# LLVM32-NEXT: 0x00000012 RELSZ 16 (bytes)
@@ -713,9 +715,9 @@ ProgramHeaders:
# LLVM32-NEXT: 0x6FFFFFFD VERDEFNUM 0
# LLVM32-NEXT: 0x6FFFFFFE VERNEED 0x1000
# LLVM32-NEXT: 0x6FFFFFFF VERNEEDNUM 0
-# LLVM32-NEXT: 0x7FFFFFFD AUXILIARY Auxiliary library: [D]
-# LLVM32-NEXT: 0x7FFFFFFE USED Not needed object: [U]
-# LLVM32-NEXT: 0x7FFFFFFF FILTER Filter library: [U]
+# LLVM32-NEXT: 0x7FFFFFFD AUXILIARY Auxiliary library: D
+# LLVM32-NEXT: 0x7FFFFFFE USED Not needed object: U
+# LLVM32-NEXT: 0x7FFFFFFF FILTER Filter library: U
# LLVM32-NEXT: 0x12345678 <unknown:>0x12345678 0x87654321
# LLVM32-NEXT: 0x6ABCDEF0 <unknown:>0x6abcdef0 0x99887766
# LLVM32-NEXT: 0x76543210 <unknown:>0x76543210 0x55556666
@@ -724,7 +726,7 @@ ProgramHeaders:
# GNU32:Dynamic section at offset 0x84 contains 61 entries:
# GNU32-NEXT: Tag Type Name/Value
-# GNU32-NEXT: 0x00000001 (NEEDED) Shared library: [D]
+# GNU32-NEXT: 0x00000001 (NEEDED) Shared library: D
# GNU32-NEXT: 0x00000002 (PLTRELSZ) 16 (bytes)
# GNU32-NEXT: 0x00000003 (PLTGOT) 0x1000
# GNU32-NEXT: 0x00000004 (HASH) 0x1000
@@ -737,8 +739,8 @@ ProgramHeaders:
# GNU32-NEXT: 0x0000000b (SYMENT) 2439 (bytes)
# GNU32-NEXT: 0x0000000c (INIT) 0x1000
# GNU32-NEXT: 0x0000000d (FINI) 0x1000
-# GNU32-NEXT: 0x0000000e (SONAME) Library soname: [U]
-# GNU32-NEXT: 0x0000000f (RPATH) Library rpath: [f]
+# GNU32-NEXT: 0x0000000e (SONAME) Library soname: U
+# GNU32-NEXT: 0x0000000f (RPATH) Library rpath: [x:w:U]
# GNU32-NEXT: 0x00000010 (SYMBOLIC) 0x12345678
# GNU32-NEXT: 0x00000011 (REL) 0x1000
# GNU32-NEXT: 0x00000012 (RELSZ) 16 (bytes)
@@ -778,9 +780,9 @@ ProgramHeaders:
# GNU32-NEXT: 0x6ffffffd (VERDEFNUM) 0
# GNU32-NEXT: 0x6ffffffe (VERNEED) 0x1000
# GNU32-NEXT: 0x6fffffff (VERNEEDNUM) 0
-# GNU32-NEXT: 0x7ffffffd (AUXILIARY) Auxiliary library: [D]
-# GNU32-NEXT: 0x7ffffffe (USED) Not needed object: [U]
-# GNU32-NEXT: 0x7fffffff (FILTER) Filter library: [U]
+# GNU32-NEXT: 0x7ffffffd (AUXILIARY) Auxiliary library: D
+# GNU32-NEXT: 0x7ffffffe (USED) Not needed object: U
+# GNU32-NEXT: 0x7fffffff (FILTER) Filter library: U
# GNU32-NEXT: 0x12345678 (<unknown:>0x12345678) 0x87654321
# GNU32-NEXT: 0x6abcdef0 (<unknown:>0x6abcdef0) 0x99887766
# GNU32-NEXT: 0x76543210 (<unknown:>0x76543210) 0x55556666
@@ -854,7 +856,7 @@ Sections:
# PHENTSIZE-LLVM: DynamicSection [ (61 entries)
# PHENTSIZE-LLVM-NEXT: Tag Type Name/Value
-# PHENTSIZE-LLVM-NEXT: 0x0000000000000001 NEEDED Shared library: [<?>]
+# PHENTSIZE-LLVM-NEXT: 0x0000000000000001 NEEDED Shared library: <?>
# PHENTSIZE-LLVM-NEXT: 0x0000000000000002 PLTRELSZ 16 (bytes)
# PHENTSIZE-LLVM-NEXT: 0x0000000000000003 PLTGOT 0x1000
# PHENTSIZE-LLVM-NEXT: 0x0000000000000004 HASH 0x1000
@@ -867,7 +869,7 @@ Sections:
# PHENTSIZE-LLVM-NEXT: 0x000000000000000B SYMENT 2439 (bytes)
# PHENTSIZE-LLVM-NEXT: 0x000000000000000C INIT 0x1000
# PHENTSIZE-LLVM-NEXT: 0x000000000000000D FINI 0x1000
-# PHENTSIZE-LLVM-NEXT: 0x000000000000000E SONAME Library soname: [<?>]
+# PHENTSIZE-LLVM-NEXT: 0x000000000000000E SONAME Library soname: <?>
# PHENTSIZE-LLVM-NEXT: 0x000000000000000F RPATH Library rpath: [<?>]
# PHENTSIZE-LLVM-NEXT: 0x0000000000000010 SYMBOLIC 0x1234567890ABCDEF
# PHENTSIZE-LLVM-NEXT: 0x0000000000000011 REL 0x1000
@@ -908,9 +910,9 @@ Sections:
# PHENTSIZE-LLVM-NEXT: 0x000000006FFFFFFD VERDEFNUM 0
# PHENTSIZE-LLVM-NEXT: 0x000000006FFFFFFE VERNEED 0x1000
# PHENTSIZE-LLVM-NEXT: 0x000000006FFFFFFF VERNEEDNUM 0
-# PHENTSIZE-LLVM-NEXT: 0x000000007FFFFFFD AUXILIARY Auxiliary library: [<?>]
-# PHENTSIZE-LLVM-NEXT: 0x000000007FFFFFFE USED Not needed object: [<?>]
-# PHENTSIZE-LLVM-NEXT: 0x000000007FFFFFFF FILTER Filter...
[truncated]
|
ilovepi
reviewed
Jun 24, 2024
jh7370
reviewed
Jun 25, 2024
Yeah there were a couple busted tests. Rolled them up |
jh7370
approved these changes
Jun 26, 2024
|
LGTM |
|
The output now differs from what GNU readelf/objdump generates. There is a tool in yocto which processes |
kraj
added a commit
to YoeDistro/poky
that referenced
this pull request
Jun 27, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 Signed-off-by: Khem Raj <[email protected]>
Ah, sorry, that was my mistake: the intent was this only impacted LLVM/JSON output. I didn't realise the code was shared with GNU style. @feg208, could you revert and look at redoing this to not impact GNU output, please? (GNU output should generally match GNU readelf output, for compatibility). Aside: @kraj, if there are multiple e.g. NEEDED entries in an ELF, does GNU readelf produce separate entries, each with a single-element list? If so, this feels like a bug in the GNU readelf tool to me, and I wonder if we could get the behaviour changed there to make more sense. |
halstead
pushed a commit
to yoctoproject/poky
that referenced
this pull request
Jun 27, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 (From OE-Core rev: abc8ca7b27917dd0ed5bd03c60b1202ee97a862a) Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
halstead
pushed a commit
to openembedded/openembedded-core
that referenced
this pull request
Jun 27, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
halstead
pushed a commit
to yoctoproject/poky
that referenced
this pull request
Jun 27, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 (From OE-Core rev: cde1a55099c46c585d8dc115ac64bae388847aae) Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
halstead
pushed a commit
to openembedded/openembedded-core
that referenced
this pull request
Jun 27, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
halstead
pushed a commit
to yoctoproject/poky
that referenced
this pull request
Jun 27, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 (From OE-Core rev: cde1a55099c46c585d8dc115ac64bae388847aae) Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
halstead
pushed a commit
to yoctoproject/poky
that referenced
this pull request
Jun 27, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 (From OE-Core rev: 90097966996f5654610100c7b17d381e7dd0b020) Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
halstead
pushed a commit
to openembedded/openembedded-core
that referenced
this pull request
Jun 27, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
It seems there is one entry per line |
mmitchel
pushed a commit
to distro-core-curated-mirrors/poky-contrib
that referenced
this pull request
Jun 28, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 (From OE-Core rev: f053f2c36755fd9a9f55df7556325a0fa86daae9) Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Alexandre Belloni <[email protected]>
halstead
pushed a commit
to yoctoproject/poky
that referenced
this pull request
Jun 30, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 (From OE-Core rev: 90097966996f5654610100c7b17d381e7dd0b020) Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
halstead
pushed a commit
to yoctoproject/poky
that referenced
this pull request
Jun 30, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 (From OE-Core rev: 90097966996f5654610100c7b17d381e7dd0b020) Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
halstead
pushed a commit
to yoctoproject/poky
that referenced
this pull request
Jul 1, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 (From OE-Core rev: 90097966996f5654610100c7b17d381e7dd0b020) Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
halstead
pushed a commit
to yoctoproject/poky
that referenced
this pull request
Jul 1, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 (From OE-Core rev: 90097966996f5654610100c7b17d381e7dd0b020) Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
halstead
pushed a commit
to yoctoproject/poky
that referenced
this pull request
Jul 1, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 (From OE-Core rev: 90097966996f5654610100c7b17d381e7dd0b020) Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
halstead
pushed a commit
to yoctoproject/poky
that referenced
this pull request
Jul 1, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 (From OE-Core rev: 90097966996f5654610100c7b17d381e7dd0b020) Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
halstead
pushed a commit
to yoctoproject/poky
that referenced
this pull request
Jul 1, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 (From OE-Core rev: 11ea8dc57f275057e19db564e6c55d2baea980b0) Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
halstead
pushed a commit
to openembedded/openembedded-core
that referenced
this pull request
Jul 1, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
daregit
pushed a commit
to daregit/yocto-combined
that referenced
this pull request
Jul 1, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 (From OE-Core rev: 11ea8dc57f275057e19db564e6c55d2baea980b0) Signed-off-by: Khem Raj <raj.khemgmail.com> Signed-off-by: Richard Purdie <richard.purdielinuxfoundation.org>
Can this be reverted?
I don't think the brackets in the readelf output are ever to be interpreted as "this is a list of multiple values". |
Feel free to do so, since @feg208 has not seen/has ignored my previous request. I'd still like the additional testing, but that can be relanded separately.
Thanks. I found it confusing in llvm-readobj LLVM style output, but less so in the GNU style output. |
serge-sans-paille
added a commit
that referenced
this pull request
Jul 3, 2024
…the output for readobj to emphasize the single valued nature of NEEDED, SONAME, USED etc. (#96562)" Reverted due to output change that breaks downstream project, see #96562 (comment) This reverts commit 161e168.
daregit
pushed a commit
to daregit/yocto-combined
that referenced
this pull request
Jul 3, 2024
LLVM has changed the ELF header dump format [1], the code in oe_libinstall relied upon the format and processed the SONAME inside square brackets e.g. 0x000000000000000e (SONAME) Library soname: libreadline.so.8 with older readelf from ( llvm <19 or GNU binutils objdump ) we get 0x000000000000000e (SONAME) Library soname: [libreadline.so.8] The check in oe_libinstall will now trip over ELF files read by llvm-readelf from llvm19+ To make it portable which works across GNU binutils and LLVM tools switch to using objdump -p to dump the ELF file and modify the regexp accordingly, as an aside, the post processing expression is simplified too [1] llvm/llvm-project#96562 (From OE-Core rev: 11ea8dc57f275057e19db564e6c55d2baea980b0) Signed-off-by: Khem Raj <raj.khemgmail.com> Signed-off-by: Richard Purdie <richard.purdielinuxfoundation.org>
lravenclaw
pushed a commit
to lravenclaw/llvm-project
that referenced
this pull request
Jul 3, 2024
…ut for readobj to emphasize the single valued nature of NEEDED, SONAME, USED etc. (llvm#96562) In the context of llvm#95976 it became clear that the output for readobj implied multi valued entries in several cases in the elf headers that the documentation only allowed for a single value. DT_NEEDED is the example here where the value is an offset into the string table without any sort of separator that could give you multiple entries. This patch alters the LLVM output so that the single valued nature is emphasized. For example the output was: ``` DynamicSection [ (35 entries) Tag Type Name/Value 0x000000000000001D RUNPATH Library runpath: [$ORIGIN/../lib:] 0x0000000000000001 NEEDED Shared library: [libm.so.6] 0x0000000000000001 NEEDED Shared library: [libz.so.1] 0x0000000000000001 NEEDED Shared library: [libzstd.so.1] ``` and is now ``` Tag Type Name/Value 0x000000000000001D RUNPATH Library runpath: [$ORIGIN/../lib:] 0x0000000000000001 NEEDED Shared library: libm.so.6 0x0000000000000001 NEEDED Shared library: libz.so.1 0x0000000000000001 NEEDED Shared library: libzstd.so.1 ``` This pr also tests that multi-valued rpaths are handled correctly in the JSON case (i.e. they become proper lists) like: ``` { "Tag": 15, "Type": "RPATH", "Value": 9, "Path": [ "x", "w", "U" ] }, ``` when separated by :
lravenclaw
pushed a commit
to lravenclaw/llvm-project
that referenced
this pull request
Jul 3, 2024
…the output for readobj to emphasize the single valued nature of NEEDED, SONAME, USED etc. (llvm#96562)" Reverted due to output change that breaks downstream project, see llvm#96562 (comment) This reverts commit 161e168.
kbluck
pushed a commit
to kbluck/llvm-project
that referenced
this pull request
Jul 6, 2024
…the output for readobj to emphasize the single valued nature of NEEDED, SONAME, USED etc. (llvm#96562)" Reverted due to output change that breaks downstream project, see llvm#96562 (comment) This reverts commit 161e168.
AlexisPerry
pushed a commit
to llvm-project-tlp/llvm-project
that referenced
this pull request
Jul 9, 2024
…ut for readobj to emphasize the single valued nature of NEEDED, SONAME, USED etc. (llvm#96562) In the context of llvm#95976 it became clear that the output for readobj implied multi valued entries in several cases in the elf headers that the documentation only allowed for a single value. DT_NEEDED is the example here where the value is an offset into the string table without any sort of separator that could give you multiple entries. This patch alters the LLVM output so that the single valued nature is emphasized. For example the output was: ``` DynamicSection [ (35 entries) Tag Type Name/Value 0x000000000000001D RUNPATH Library runpath: [$ORIGIN/../lib:] 0x0000000000000001 NEEDED Shared library: [libm.so.6] 0x0000000000000001 NEEDED Shared library: [libz.so.1] 0x0000000000000001 NEEDED Shared library: [libzstd.so.1] ``` and is now ``` Tag Type Name/Value 0x000000000000001D RUNPATH Library runpath: [$ORIGIN/../lib:] 0x0000000000000001 NEEDED Shared library: libm.so.6 0x0000000000000001 NEEDED Shared library: libz.so.1 0x0000000000000001 NEEDED Shared library: libzstd.so.1 ``` This pr also tests that multi-valued rpaths are handled correctly in the JSON case (i.e. they become proper lists) like: ``` { "Tag": 15, "Type": "RPATH", "Value": 9, "Path": [ "x", "w", "U" ] }, ``` when separated by :
bherrera
pushed a commit
to misttech/mist-os
that referenced
this pull request
Sep 18, 2024
llvm/llvm-project#96562 changed the format. Change-Id: If0a90b77fae2f85a9be151a78cb3e7c9945e0a32 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1115672 Commit-Queue: Auto-Submit <[email protected]> Fuchsia-Auto-Submit: Petr Hosek <[email protected]> Reviewed-by: Paul Kirth <[email protected]>
bherrera
pushed a commit
to misttech/integration
that referenced
this pull request
Sep 18, 2024
llvm/llvm-project#96562 changed the format. Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1115672 Original-Revision: 9455f1eafac3410ada61364d82a646a454dca255 GitOrigin-RevId: b80782abd94d904ef99a7afb02ed2611ff5e4839 Change-Id: I0597ce36d53808478a9837113d8c51ea40f3e434
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the context of #95976 it became clear that the output for readobj implied multi valued entries in several cases in the elf headers that the documentation only allowed for a single value. DT_NEEDED is the example here where the value is an offset into the string table without any sort of separator that could give you multiple entries. This patch alters the LLVM output so that the single valued nature is emphasized. For example the output was:
and is now
This pr also tests that multi-valued rpaths are handled correctly in the JSON case (i.e. they become proper lists) like:
when separated by :