This option prints the name of the DLL that gets imported, when linking
against an import library.
This is implemented using the same strategy as GNU dlltool does; looking
for the contents of .idata$6 or .idata$7 chunks. The right section name
to check for is chosen by identifying whether the library is GNU or LLVM
style. In the case of GNU import libraries, the DLL name is in an
.idata$7 chunk. However there are also other chunks with that section
name (for entries for the IAT or ILT); identify these by looking for
whether a chunk contains relocations.
Alternatively, one could also just look for .idata$2 chunks, look for
relocations at the right offset, and locate data at the symbol that the
relocation points at (which may be in the same or in another object
file).
This matches what MS lib.exe does (and llvm-ar too); when adding files
to an archive, MS lib.exe stores the file name as it was given on the
command line, whereas llvm-lib rewrote it into a relative path name,
relative to the archive location. Such a rewrite makes sense for thin
archives, but not for regular archives. (MS lib.exe doesn't support
producing thin archives; that's an LLVM extension - see the
thin-relative.test testcase.)
The behaviour to rewrite these paths was added in
451c2ef199e9c5163007ac32e2d426fbfb37e664; it is unclear why it was
chosen to do the rewriting for non-thin archives as well. This quirk is
even pointed out in a code comment - but neither the code review at
https://reviews.llvm.org/D57842 nor the linked bug report at
https://crbug.com/41440160 mentions why this is done for all archives,
not only thin ones.
Therefore, assume that this only was done out of convenience, and change
llvm-lib to not adjust the paths for non-thin archives.
Normally, the actual member names doesn't matter for non-thin archives;
however for short import libraries, where each member is named e.g.
"foo.dll", the names do matter. If using llvm-lib to merge two import
libraries (as a non-thin library), preserve the original names rather
than making the member names relative.
This can be used with /llvmlibthin to create thin archives without an
index, which is a prerequisite for porting
https://reviews.llvm.org/D117284 to lld-link.
Creating files like this is already possible with `llvm-ar rcS`, so this
doesn't add additional problems.
Apologies for the large change, I looked for ways to break this up and
all of the ones I saw added real complexity. This change focuses on the
option's prefixed names and the array of prefixes. These are present in
every option and the dominant source of dynamic relocations for PIE or
PIC users of LLVM and Clang tooling. In some cases, 100s or 1000s of
them for the Clang driver which has a huge number of options.
This PR addresses this by building a string table and a prefixes table
that can be referenced with indices rather than pointers that require
dynamic relocations. This removes almost 7k dynmaic relocations from the
`clang` binary, roughly 8% of the remaining dynmaic relocations outside
of vtables. For busy-boxing use cases where many different option tables
are linked into the same binary, the savings add up a bit more.
The string table is a straightforward mechanism, but the prefixes
required some subtlety. They are encoded in a Pascal-string fashion with
a size followed by a sequence of offsets. This works relatively well for
the small realistic prefixes arrays in use.
Lots of code has to change in order to land this though: both all the
option library code has to be updated to use the string table and
prefixes table, and all the users of the options library have to be
updated to correctly instantiate the objects.
Some follow-up patches in the works to provide an abstraction for this
style of code, and to start using the same technique for some of the
other strings here now that the infrastructure is in place.
This is a follow-up to #115567. Emit an error for invalid function
names, similar to MSVC's `lib.exe` behavior.
Returning an error from `writeImportLibrary` exposed bugs in error
handling by its callers, which have been addressed in this patch.
Normally, when doing renamed imports, we do this by providing a
weak alias, towards another regular import, for the symbol we
want to actually import. In a def file, this looks like this:
regularfunc
renamedfunc == regularfunc
However, if we want to link against a function in a DLL, where we
(intentionally) don't provide a regular import for that symbol
with the name in its DLL, doing the renamed import with a weak
alias doesn't work, as there's no symbol that the weak alias can
point towards.
We can't make up such an import either, as we may intentionally
not want to provide a regular import for that name.
This situation can either be resolved by using the "long" import
library format (as e.g. produced by GNU dlltool), or by using the
new short import library name type "export as".
This patch implements it by using the "export as" name type.
When producing a renamed import, defer emitting it until all regular
imports have been produced. If the renamed import refers to a
symbol that does exist as a regular import entry, produce a
weak alias, just as before. (This implementation also avoids needing
to know whether the symbol that the alias points towards actually
is prefixed or not, too.)
If the renamed import points at a symbol that isn't otherwise
available (or is available as a renamed symbol itself), generate
an "export as" import entry.
This name type is new, and is normally used in ARM64EC import
libraries, but can also be used for other architectures.
On i386, regular C level symbols are given an underscore prefix
in the symbols on the object file level. However, the exported
names from DLLs usually don't have this leading underscore.
When specified in a def file like "symbol == dllname", the "dllname"
is the name of the exported symbol from the DLL, which will be
linked against from an object file symbol named "_symbol"
(on i386).
The mechanism where one symbol is redirected to another one in
an import library is implemented with weak aliases. In that case,
we need to have the object file symbol level name for the target
of the import, as we make one object file symbol point at another
one. Therefore, we added an underscore to the ImportName field.
(This mechanism, with weak aliases, only works as long as the
target also is exported as is, in that form - this issue is
dealt with in a later commit.)
For clarity, for potentially handling the import renaming in
other ways, store the ImportName field unprefixed, containing
the actual name to import from the DLL.
When creating the aliases, add the prefix as needed. This requires
passing an extra AddUnderscores parameter to the writeImportLibrary
function; this is a temporary measure, until alias creation is
reworked in a later commit.
This doesn't preserve the corner case of checking !isDecorated()
before adding the prefix. This corner case isn't tested by any
of our existing tests, and only would trigger for
fastcall/vectorcall/MS C++ functions - while these kinds of
renames primarily are used in mingw-w64-crt import libraries
(which primarily handle cdecl and stdcall functions).
To support auto-conversion on z/OS text files need to be opened as text files. These changes will fix a number of LIT failures due to text files not being converted to the internal code page.
update a number of tools so they open the text files as text files
add support in the cat.py to open a text file as a text file (Windows will continue to treat all files as binary so new lines are handled correctly)
add env var definitions to enable auto-conversion in the lit config file.
It turns out that the previous name is vaguely misleading.
When operating on a def file like "symbolname == dllname", that is
supposed to make an import library entry, that when the symbol
"symbolname" links against this, it imports the DLL symbol "dllname"
from the referenced DLL. This doesn't need to involve any alias, and it
doesn't need to imply that "dllname" is available on its own as a
separate symbol in the import library at all.
GNU dlltool implements import libraries in the form of "long import
library", where each member is a regular object file with section chunks
that compose the relevant .idata section pieces. There, this kind of
import renaming does not involve any form of aliases, but the right
.idata section just gets a different string than the symbol name.
Add new target and a new -n option allowing to specify native module
definition file, similar to how -defArm64Native works in llvm-lib. This
also changes archive format to use K_COFF like non-mingw targets. It's
required on ARM64EC, but it should be fine for other targets too.
This can be used to create import libraries that contain both ARM64EC
and native exports. The implementation follows observed MSVC lib.exe
behaviour. It's ignored on targets other than ARM64EC.
Summary:
llvm-ar is symlinked as llvm-ranlib and will act as ranlib when invoked in that mode. llvm-ar since [[ 4f2cfbe531 | compiler/llvm-project@4f2cfbe ]] supports the -X options, but doesn't seem to accept them when running as llvm-ranlib.
In AIX OS , according to https://www.ibm.com/docs/en/aix/7.2?topic=r-ranlib-command
-X mode Specifies the type of object file ranlib should examine. The mode must be one of the following:
32
Processes only 32-bit object files
64
Processes only 64-bit object files
32_64, any
Processes both 32-bit and 64-bit object files
The default is to process 32-bit object files (ignore 64-bit objects). The mode can also be set with the OBJECT_MODE environment variable. For example, OBJECT_MODE=64 causes ranlib to process any 64-bit objects and ignore 32-bit objects. The -X flag overrides the OBJECT_MODE variable.
Reviewers: James Henderson, MaskRay, Stephen Peckham
Differential Revision: https://reviews.llvm.org/D142660
This reverts commit 4e3b89483a6922d3f48670bb1c50a37f342918c6, with
fixes for places I'd missed updating in lld and lldb. I've also
renamed OptionVisibility::Default to "DefaultVis" to avoid ambiguity
since the undecorated name has to be available anywhere Options.inc is
included.
Original message follows:
This splits OptTable's "Flags" field into "Flags" and "Visibility",
updates the places where we instantiate Option tables, and adds
variants of the OptTable APIs that use Visibility mask instead of
Include/Exclude flags.
We need to do this to clean up a bunch of complexity in the clang
driver's option handling - there's a whole slew of flags like
CoreOption, NoDriverOption, and FlangOnlyOption there today to try to
handle all of the permutations of flags that the various drivers need,
but it really doesn't scale well, as can be seen by things like the
somewhat recently introduced CLDXCOption.
Instead, we'll provide an additive model for visibility that's
separate from the other flags. For things like "HelpHidden", which is
used as a "subtractive" modifier for option visibility, we leave that
in "Flags" and handle it as a special case.
Note that we don't actually update the users of the Include/Exclude
APIs here or change the flags that exist in clang at all - that will
come in a follow up that refactors clang's Options.td to use the
increased flexibility this change allows.
Differential Revision: https://reviews.llvm.org/D157149
This splits OptTable's "Flags" field into "Flags" and "Visibility",
updates the places where we instantiate Option tables, and adds
variants of the OptTable APIs that use Visibility mask instead of
Include/Exclude flags.
We need to do this to clean up a bunch of complexity in the clang
driver's option handling - there's a whole slew of flags like
CoreOption, NoDriverOption, and FlangOnlyOption there today to try to
handle all of the permutations of flags that the various drivers need,
but it really doesn't scale well, as can be seen by things like the
somewhat recently introduced CLDXCOption.
Instead, we'll provide an additive model for visibility that's
separate from the other flags. For things like "HelpHidden", which is
used as a "subtractive" modifier for option visibility, we leave that
in "Flags" and handle it as a special case.
Note that we don't actually update the users of the Include/Exclude
APIs here or change the flags that exist in clang at all - that will
come in a follow up that refactors clang's Options.td to use the
increased flexibility this change allows.
Differential Revision: https://reviews.llvm.org/D157149
All command-line tools using `llvm::opt` create an enum of option IDs and a table of `OptTable::Info` object. Most of the tools use the same ID (`OPT_##ID`), kind (`Option::KIND##Class`), group ID (`OPT_##GROUP`) and alias ID (`OPT_##ALIAS`). This patch extracts that common code into canonical macros. This results in fewer changes when tweaking the `OPTION` macros emitted by the TableGen backend.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D157028
This requires being able to opt out from adding the leading underscores
in COFFModuleDefinition. Normally it is added automatically for I386
type targets. We could either move the decision entirely to all
callers, letting the caller check the machine type and decide whether
underscores should be added, or keep the logic mostly as is, but allowing
opting out from the behaviour on I386.
I went with keeping the interface as is for now.
Differential Revision: https://reviews.llvm.org/D152363
In llvm-lib cases, the MinGW specific behaviours shouldn't be
enabled.
Not adding any tests to check the corner case behaviours, as this
simply was a mistake when this codepath was added in
395ec4458fb7fc700551f7017c0a395d68c55873 / D144765.
Differential Revision: https://reviews.llvm.org/D152362
llvm-dlltool tolerates unknown options as long as they are plain
flags, but if given the parameter value as a separate argument,
e.g. "--temp-prefix foo", it fails to ignore it.
Differential Revision: https://reviews.llvm.org/D152361
Add comments about unclear bool arguments to functions, switch to
hasArg instead of getLastArg for cases where we don't need to check
the argument's value.
Differential Revision: https://reviews.llvm.org/D152360
Similar to D125411, but for ARM64X.
ARM64X PE binaries are hybrids containing both ARM64EC and pure ARM64
variants in one file. They are usually linked by passing separate
ARM64EC and ARM64 object files to linker. Linked binaries use ARM64
machine and contain additional CHPE metadata in their load config.
CHPE metadata support is not part of this patch, I plan to send that later.
Using ARM64X as a machine type of object files themselves is somewhat
ambiguous, but such files are allowed by MSVC. It treats them as ARM64
or ARM64EC object, depending on the context. Such objects can be
produced with cvtres.exe -machine:arm64x.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D148517
ARM64EC allows having both pure ARM64 objects and ARM64EC in the
same archive. This allows using single static library for linking
pure ARM64, pure ARM64EC or mixed modules (what MS calls ARM64X:
a single module that may be used in both modes). To achieve that,
such static libraries need two separated symbol maps. The usual map
contains only pure ARM64 symbols, while a new /<ECSYMBOLS>/ section
contains EC symbols. EC symbols map has very similar format to the
usual map, except it doesn't contain object offsets and uses offsets
from regular map instead. This is true even for pure ARM64EC static
library: it will simply have 0 symbols in the symbol map.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D143541
We currently just use GNU format for llvm-lib. This mostly works, but
ARM64EC needs an additional section that does not really fit GNU format.
This patch implements writing in COFF format (as in, it's what archive
reader considers as K_COFF). This mostly requires symbol emitting symbol
map. Note that, just like in case of MSVC, symbols are de-duplicated in
both usual symbol table and the new symbol map.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D143540
.def file, functionality supported by 'lib'. This incompatibility is
breaking clang based Windows openmp builds. This revision adds
basic support for this feature to llvm-lib by cloning the corresponding
code from 'dlltool'.
Differential Revision:https://reviews.llvm.org/D144765
The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC warning about the fact it is deprecated, because it is used
in `isl` from where it is included by Polly.
This isn't strictly needed, but this matches how MSVC lib.exe writes to
archives, so this makes llvm-lib more compatible and simplifies comparing
output between tools.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D143536
This avoids recomputing string length that is already known at compile time.
It has a slight impact on preprocessing / compile time, see
https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u
This a recommit of e953ae5bbc313fd0cc980ce021d487e5b5199ea4 and the subsequent fixes caa713559bd38f337d7d35de35686775e8fb5175 and 06b90e2e9c991e211fecc97948e533320a825470.
The above patchset caused some version of GCC to take eons to compile clang/lib/Basic/Targets/AArch64.cpp, as spotted in aa171833ab0017d9732e82b8682c9848ab25ff9e.
The fix is to make BuiltinInfo tables a compilation unit static variable, instead of a private static variable.
Differential Revision: https://reviews.llvm.org/D139881
Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4 (part 2)"
Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4"
GCC build hangs on this bot https://lab.llvm.org/buildbot/#/builders/37/builds/19104
compiling CMakeFiles/obj.clangBasic.dir/Targets/AArch64.cpp.d
The bot uses GNU 11.3.0, but I can reproduce locally with gcc (Debian 12.2.0-3) 12.2.0.
This reverts commit caa713559bd38f337d7d35de35686775e8fb5175.
This reverts commit 06b90e2e9c991e211fecc97948e533320a825470.
This reverts commit e953ae5bbc313fd0cc980ce021d487e5b5199ea4.
This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
