Sorry, I missed the notification mail.
llvm/include/llvm/MC/SectionKind.h:
/// Exclude - This section will be excluded from the final executable or
/// shared library. Only valid for ELF / COFF targets.
Exclude,
llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp:
For ELF:
static unsigned getELFSectionFlags(SectionKind K, const Triple &T) {
...
if (K.isExclude())
Flags |= ELF::SHF_EXCLUDE;
SHF_EXCLUDE: This section is excluded from input to the link-edit of an executable or shared object. This flag is ignored if the SHF_ALLOC flag is also set, or if relocations exist against the section.
For COFF:
getCOFFSectionFlags(SectionKind K, const TargetMachine &TM) {
...
else if (K.isExclude())
Flags |=
COFF::IMAGE_SCN_LNK_REMOVE | COFF::IMAGE_SCN_MEM_DISCARDABLE;
IMAGE_SCN_LNK_REMOVE: The section will not become part of the image. This is valid only for object files.
If we set section to exclude kind, they will still live in object file and will be discarded when linker read them from object file. Regarding “thin link”, is that ThinLTO? I don’t think they will affect any LTO behavior.
IIUC
reproduce
is for reproducing the link, not the compilation. Are you saying that combiningreproduce
with the-fembed-bitcode
or-mllvm -lto-embed-bitcode
during a build would allow one to reproduce both compilation and linking?
Yes. We have cmd/bitcode to recompile it to object file and know how those objects are linked to executable. Thus reproducing part of compilation and whole linking is possible. I use part of compilation since we can only reproduce bitcode → object file.