[PATCH] D93760: [obj2yaml] - Dump the content of a broken GNU hash table properly.

[George Rimar via Phabricator via llvm-commits]

This revision was automatically updated to reflect the committed changes.
grimar marked an inline comment as done.
Closed by commit rGb8cb1802a8a2: [obj2yaml] - Dump the content of a broken GNU hash table properly. (authored by grimar).

Changed prior to commit:
  https://reviews.llvm.org/D93760?vs=313539&id=313668#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93760

Files:
  llvm/test/tools/obj2yaml/ELF/gnu-hash-section.yaml
  llvm/tools/obj2yaml/elf2yaml.cpp


Index: llvm/tools/obj2yaml/elf2yaml.cpp
===================================================================
--- llvm/tools/obj2yaml/elf2yaml.cpp
+++ llvm/tools/obj2yaml/elf2yaml.cpp
@@ -1271,9 +1271,9 @@
 
   ELFYAML::GnuHashHeader Header;
   DataExtractor::Cursor Cur(0);
-  uint32_t NBuckets = Data.getU32(Cur);
+  uint64_t NBuckets = Data.getU32(Cur);
   Header.SymNdx = Data.getU32(Cur);
-  uint32_t MaskWords = Data.getU32(Cur);
+  uint64_t MaskWords = Data.getU32(Cur);
   Header.Shift2 = Data.getU32(Cur);
 
   // Set just the raw binary content if we were unable to read the header
Index: llvm/test/tools/obj2yaml/ELF/gnu-hash-section.yaml
===================================================================
--- llvm/test/tools/obj2yaml/ELF/gnu-hash-section.yaml
+++ llvm/test/tools/obj2yaml/ELF/gnu-hash-section.yaml
@@ -54,9 +54,12 @@
 # INVALID-NEXT: - Name:        .gnu.hash.broken.maskwords
 # INVALID-NEXT:   Type:        SHT_GNU_HASH
 # INVALID-NEXT:   Content:     '00000000000000000100000000000000'
-# INVALID-NEXT: - Name:        .gnu.hash.broken.nbuckets
+# INVALID-NEXT: - Name:        .gnu.hash.broken.nbuckets.a
 # INVALID-NEXT:   Type:        SHT_GNU_HASH
 # INVALID-NEXT:   Content:     '01000000000000000000000000000000'
+# INVALID-NEXT: - Name:        .gnu.hash.broken.nbuckets.b
+# INVALID-NEXT:   Type:        SHT_GNU_HASH
+# INVALID-NEXT:   Content:     FFFFFFFF000000000100000000000000{{$}}
 # INVALID-NEXT: - Name:        .gnu.hash.hashvalues.ok
 # INVALID-NEXT:   Type:        SHT_GNU_HASH
 # INVALID-NEXT:   Header:
@@ -108,9 +111,9 @@
     BloomFilter: []
     HashBuckets: []
     HashValues:  []
-## Case 4: NBuckets field is broken, it says that the number of entries
+## Case 4(a): NBuckets field is broken, it says that the number of entries
 ## in the hash buckets is 1, but it is empty.
-  - Name:  .gnu.hash.broken.nbuckets
+  - Name:  .gnu.hash.broken.nbuckets.a
     Type:  SHT_GNU_HASH
     Header:
       SymNdx: 0x0
@@ -120,6 +123,18 @@
     BloomFilter: []
     HashBuckets: []
     HashValues:  []
+## Case 4(b): NBuckets = 0xFFFFFFFF is incorrect. The result will cause 32-bit
+## unsigned overflows if we keep intermediate expressions uint32_t.
+  - Name:  .gnu.hash.broken.nbuckets.b
+    Type:  SHT_GNU_HASH
+    Header:
+      SymNdx: 0x0
+      Shift2: 0x0
+      MaskWords: 0x1
+      NBuckets:  0xFFFFFFFF
+    BloomFilter: []
+    HashBuckets: []
+    HashValues:  []
 ## Case 5: Check that we use the various properties to dump the data when it
 ## has a size that is a multiple of 4, but fallback to dumping the whole section
 ## using the "Content" property otherwise.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D93760.313668.patch
Type: text/x-patch
Size: 2630 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20201224/45662329/attachment.bin>