[PATCH] D142479: [AIX] support 64bit global symbol table for big archive

James Henderson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 2 00:53:57 PST 2023


jhenderson added inline comments.


================
Comment at: llvm/include/llvm/Object/Archive.h:408
   uint64_t LastChildOffset = 0;
+  SmallString<0> GlobalSymbolTableBuf;
 
----------------
DiggerLin wrote:
> jhenderson wrote:
> > I think it's unlikely that this buffer is ever going to be "small", so it seems likely that it would just be better to store this a `std::string` ultimately.
> there are null characters between each symbol name to separate the symbol names in the  global symbol table, I do not think we can use the std::string to store it.
> 
> and the base class of SmallString is SmallVector, According to the comment in the SmallVector.h, "SmallVectors are used for buffering bitcode output - which can exceed 4GB.", 
> there are null characters between each symbol name to separate the symbol names in the global symbol table, I do not think we can use the std::string to store it.

`std::string` is perfectly capable of storing null bytes. You just can't use the `std::string(const char *)` constructor to build it (you need to use one which takes a size too).

> and the base class of SmallString is SmallVector, According to the comment in the SmallVector.h, "SmallVectors are used for buffering bitcode output - which can exceed 4GB.",

Have you read the [[ https://llvm.org/docs/ProgrammersManual.html#string-like-containers | Programmer's Manual ]]? FWIW, I couldn't figure out from that which is the more appropriate to use. I guess in the end, it'll depend on how you end up populating it as to which is better.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142479



More information about the llvm-commits mailing list