Currently, `TargetLoweringObjectFileELF::getSectionForConstant` produce `.<section>.hot` or `.<section>.unlikely` for a constant with non-empty section prefix. This PR changes the implementation add trailing dot when section prefix is not empty, to disambiguate `.hot` as a hotness prefix from `.hot` as a (pure C) variable name. Relevant discussions are in https://github.com/llvm/llvm-project/pull/148985#discussion_r2221141273 and https://github.com/llvm/llvm-project/pull/148985#discussion_r2233382641 and
Those are metadata sections for ELF but was not properly set for COFF.
The object file format specific derived classes are used in context like MCStreamer and MCObjectTargetWriter where the type is statically known. We don't use isa/dyn_cast and we want to eliminate MCSection::SectionVariant in the base class.
The object file format specific derived classes are used in context like MCStreamer and MCObjectTargetWriter where the type is statically known. We don't use isa/dyn_cast and we want to eliminate MCSection::SectionVariant in the base class.
The object file format specific derived classes are used in context like MCStreamer and MCObjectTargetWriter where the type is statically known. We don't use isa/dyn_cast and we want to eliminate MCSection::SectionVariant in the base class.
These are identified by misc-include-cleaner. I've filtered out those that break builds. Also, I'm staying away from llvm-config.h, config.h, and Compiler.h, which likely cause platform- or compiler-specific build failures.
This PR is part of #123870. The pseudo probe desc emission code can be reused by other target.
Unlike other formats, the GOFF object file format uses a 2 dimensional structure to define the location of data. For example, the equivalent of the ELF .text section is made up of a Section Definition (SD) and a class (Element Definition; ED). The name of the SD symbol depends on the application, while the class has the predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively. Data can be placed into this structure in 2 ways. First, the data (in a text record) can be associated with an ED symbol. To refer to data, a Label Definition (LD) is used to give an offset into the data a name. When binding, the whole data is pulled into the resulting executable, and the addresses given by the LD symbols are resolved. The alternative is to use a Part Definition (PR). In this case, the data (in a text record) is associated with the part. When binding, only the data of referenced PRs is pulled into the resulting binary. Both approaches are used. SD, ED, and PR elements are modeled by nested MCSectionGOFF instances, while LD elements are associated with MCSymbolGOFF instances. At the binary level, a record called "External Symbol Definition" (ESD) is used. The ESD has a type (SD, ED, PR, LD), and depending on the type a different subset of the fields is used.
This annotates the `Twine` passed to the constructors of the various DiagnosticInfo subclasses with `[[clang::lifetimebound]]`, which causes us to warn when we would try to print the twine after it had already been destructed. We also update `DiagnosticInfoUnsupported` to hold a `const Twine &` like all of the other DiagnosticInfo classes, since this warning allows us to clean up all of the places where it was being used incorrectly.