TableGen: Fix ASAN error

[nhaehnle]

Summary

As a bonus, this arguably improves the code by making it simpler.

gcc 8 on Ubuntu 18.10 reports the following:

39667==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffffff8ae0 at pc 0x555555dbfc68 bp 0x7fffffff8760 sp 0x7fffffff8750

WRITE of size 8 at 0x7fffffff8ae0 thread T0

#0 0x555555dbfc67 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Alloc_hider::_Alloc_hider(char*, std::allocator<char>&&) /usr/include/c++/8/bits/basic_string.h:149
#1 0x555555dbfc67 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&) /usr/include/c++/8/bits/basic_string.h:542
#2 0x555555dbfc67 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > std::operator+<char, std::char_traits<char>, std::allocator<char> >(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&) /usr/include/c++/8/bits/basic_string.h:6009
#3 0x555555dbfc67 in searchableFieldType /home/nha/amd/build/san/llvm-src/utils/TableGen/SearchableTableEmitter.cpp:168
(...)

Address 0x7fffffff8ae0 is located in stack of thread T0 at offset 864 in frame

#0 0x555555dbef3f in searchableFieldType /home/nha/amd/build/san/llvm-src/utils/TableGen/SearchableTableEmitter.cpp:148

[kparzysz]

utils/TableGen/SearchableTableEmitter.cpp

168

How does the problem actually occur? utostr returns a temporary std::string which should exist until the sum is constructed. What object is used-after-scope?

[nhaehnle]

utils/TableGen/SearchableTableEmitter.cpp

168

Must be some temporary object (the ASAN dump calls it "unknown"). To be honest, I was surprised about it as well, but I don't really have the time to dig into it further.

[simon_tatham]

utils/TableGen/SearchableTableEmitter.cpp

168

I just did have a go at digging into it, because the line numbers in the backtrace make sense with respect to that header file on my nearest 18.10 box.

But it's happening in a move constructor for the type _Alloc_hider which is internal to libstdc++ (and contained in a string that's being move-constructed in turn by the operator+ doing one of the concatenations). At the point where I started having to understand someone else's C++ library internals I decided I didn't have the time either :-)

[kparzysz]

Thanks for the investigation. What concerns me a bit is that this isn't the only place where this pattern occurs, but hopefully it will be detected if it causes problems. It would be nice to have enough data to file a bug report against stdc++, but for now we can apply this workaround.

utils/TableGen/SearchableTableEmitter.cpp

if (isa<StringRecTy>(Field.RecType)) {
       if (Ctx == TypeInStaticStruct)
         return "const char *";
       if (Ctx == TypeInTempStruct)
         return "std::string";
       return "StringRef";
     } else if (BitsRecTy *BI = dyn_cast<BitsRecTy>(Field.RecType)) {
       unsigned NumBits = BI->getNumBits();
       if (NumBits <= 8)
-        NumBits = 8;
-      else if (NumBits <= 16)
-        NumBits = 16;
-      else if (NumBits <= 32)
-        NumBits = 32;
-      else if (NumBits <= 64)
-        NumBits = 64;
-      else
-        PrintFatalError(Twine("bitfield '") + Field.Name +
-                        "' too large to search");
-      return "uint" + utostr(NumBits) + "_t";
+        return "uint8_t";
+      if (NumBits <= 16)
+        return "uint16_t";
+      if (NumBits <= 32)
+        return "uint32_t";
+      if (NumBits <= 64)
+        return "uint64_t";
     } else if (Field.Enum || Field.IsIntrinsic || Field.IsInstruction)
       return "unsigned";
     PrintFatalError(Twine("Field '") + Field.Name + "' has unknown type '" +
                     Field.RecType->getAsString() + "' to search by");
   }
 
   void emitGenericTable(const GenericTable &Table, raw_ostream &OS);
   void emitGenericEnum(const GenericEnum &Enum, raw_ostream &OS);