[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