|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
Gold plugin does not add pass to ThinLTO modules without useful symbols.
In this case ThinLTO can't create corresponding index file and some features, like CFI,
cannot be processes by backed correctly without index.
Given that we don't need the backed output we can request it to avoid
processing the module. This is implemented by this patch using new
"SkipModuleByDistributedBackend" flag.
Reviewers: pcc, tejohnson
Subscribers: mehdi_amini, inglorion, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D42995
llvm-svn: 325411 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | - Add MACH flags
- Add XNACK flag
- Add reserved flags
- Minor cleanups in docs
Differential Revision: https://reviews.llvm.org/D43356
llvm-svn: 325399 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This was originally reported as a bug with the symptom being "cvdump
crashes when printing an LLD-linked PDB that has an S_FILESTATIC record
in it". After some additional investigation, I determined that this was
a symptom of a larger problem, and in fact the real problem was in the
way we emitted the global PDB string table. As evidence of this, you can
take any lld-generated PDB, run cvdump -stringtable on it, and it would
return no results.
My hypothesis was that cvdump could not *find* the string table to begin
with. Normally it would do this by looking in the "named stream map",
finding the string /names, and using its value as the stream index. If
this lookup fails, then cvdump would fail to load the string table.
To test this hypothesis, I looked at the name stream map generated by a
link.exe PDB, and I emitted exactly those bytes into an LLD-generated
PDB. Suddenly, cvdump could read our string table!
This code has always been hacky and we knew there was something we
didn't understand. After all, there were some comments to the effect of
"we have to emit strings in a specific order, otherwise things don't
work". The key to fixing this was finally understanding this.
The way it works is that it makes use of a generic serializable hash map
that maps integers to other integers. In this case, the "key" is the
offset into a buffer, and the value is the stream number. If you index
into the buffer at the offset specified by a given key, you find the
name. The underlying cause of all these problems is that we were using
the identity function for the hash. i.e. if a string's offset in the
buffer was 12, the hash value was 12. Instead, we need to hash the
string *at that offset*. There is an additional catch, in that we have
to compute the hash as a uint32 and then truncate it to uint16.
Making this work is a little bit annoying, because we use the same hash
table in other places as well, and normally just using the identity
function for the hash function is actually what's desired. I'm not
totally happy with the template goo I came up with, but it works in any
case.
The reason we never found this bug through our own testing is because we
were building a /parallel/ hash table (in the form of an
llvm::StringMap<>) and doing all of our lookups and "real" hash table
work against that. I deleted all of that code and now everything goes
through the real hash table. Then, to test it, I added a unit test which
adds 7 strings and queries the associated values. I test every possible
insertion order permutation of these 7 strings, to verify that it really
does work as expected.
Differential Revision: https://reviews.llvm.org/D43326
llvm-svn: 325386 | 
| | 
| 
| 
| 
| 
| | cause garbage collector to run. This matches the behavior in C++ LTO API.
llvm-svn: 325303 | 
| | 
| 
| 
| 
| 
| 
| | If no debug info was applied to a function, its debug info shouldn't be
checked (it doesn't have any :).
llvm-svn: 325297 | 
| | 
| 
| 
| | llvm-svn: 325294 | 
| | 
| 
| 
| 
| 
| | It caused fails on some buildbots.
llvm-svn: 325227 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Analysis of fails in the case of out of memory errors can be tricky on
Windows. Such error emerges at the point where memory allocation function
fails, but manifests itself when null pointer is used. These two points
may be distant from each other. Besides, next runs may not exhibit
allocation error.
Usual programming practice does not require checking result of 'operator
new' because it throws 'std::bad_alloc' in the case of allocation error.
However, LLVM is usually built with exceptions turned off, so 'new' can
return null pointer. This change installs custom new handler, which causes
fatal error in the case of out of memory. The handler is installed
automatically prior to call to 'main' during construction of a static
object defined in 'lib/Support/ErrorHandling.cpp'. If the application does
not use this file, the handler may be installed manually by a call to
'llvm::install_out_of_memory_new_handler', declared in
'include/llvm/Support/ErrorHandling.h".
There are calls to C allocation functions, malloc, calloc and realloc.
They are used for interoperability with C code, when allocated object has
variable size and when it is necessary to avoid call of constructors. In
many calls the result is not checked against null pointer. To simplify
checks, new functions are defined in the namespace 'llvm' with the
same names as these C function. These functions produce fatal error if
allocation fails. User should use 'llvm::malloc' instead of 'std::malloc'
in order to use the safe variant. This change replaces 'std::malloc'
in the cases when the result of allocation function is not checked against
null pointer.
Finally, there are plain C code, that uses malloc and similar functions. If
the result is not checked, assert statements are added.
Differential Revision: https://reviews.llvm.org/D43010
llvm-svn: 325224 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Some ELF files produced by lld may have zero-size segment placeholders as shown
below. Since GNU_STACK Offset is 0, the current code makes it the lowest used
offset, and relocates all the segments over the ELF header. The resulting
binary is total garbage.
This change fixes how llvm-objcopy handles PT_PHDR properlly by treating ELF
headers and the program header table as segments to allow the layout algorithm
decide where those should go.
Author: vit9696
Differential Revision: https://reviews.llvm.org/D42872
llvm-svn: 325189 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
TypeID summaries are used by CFI and need to be serialized by ThinLTO
indexing for later use by LTO Backend.
Reviewers: tejohnson, pcc
Subscribers: mehdi_amini, inglorion, eraman, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D42611
llvm-svn: 325182 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | unified GetResources callback.
Having a single 'GetResources' callback will simplify adding new resources in
the future.
llvm-svn: 325180 | 
| | 
| 
| 
| 
| 
| 
| | Queries need to stay alive until each owner has set the values they are
responsible for.
llvm-svn: 325179 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | While there, change a bunch of helper functions to take references to
avoid adding calls to get().
This should conclude the bugpoint yak shaving.
llvm-svn: 325177 | 
| | 
| 
| 
| | llvm-svn: 325176 | 
| | 
| 
| 
| | llvm-svn: 325174 | 
| | 
| 
| 
| | llvm-svn: 325173 | 
| | 
| 
| 
| | llvm-svn: 325172 | 
| | 
| 
| 
| | llvm-svn: 325170 | 
| | 
| 
| 
| | llvm-svn: 325167 | 
| | 
| 
| 
| | llvm-svn: 325165 | 
| | 
| 
| 
| | llvm-svn: 325164 | 
| | 
| 
| 
| | llvm-svn: 325163 | 
| | 
| 
| 
| 
| 
| 
| | It can never be null and most callers were already using references or
std::unique_ptr.
llvm-svn: 325160 | 
| | 
| 
| 
| 
| 
| 
| | This simplifies most callers as they are already using references or
std::unique_ptr.
llvm-svn: 325155 | 
| | 
| 
| 
| | llvm-svn: 325100 | 
| | 
| 
| 
| | llvm-svn: 325099 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | The change implements constructor of DisassembleInfo to avoid duplication
of initialization code and gets rid of malloc/free where possible.
Differential Revision: https://reviews.llvm.org/D43003
llvm-svn: 325098 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
This protects calls to longjmp from transferring control to arbitrary
program points. Instead, longjmp calls are limited to the set of
registered setjmp return addresses.
This also implements /guard:nolongjmp to allow users to link in object
files that call setjmp that weren't compiled with /guard:cf. In this
case, the linker will approximate the set of address taken functions,
but it will leave longjmp unprotected.
I used the following program to test, compiling it with different -guard
flags:
  $ cl -c t.c -guard:cf
  $ lld-link t.obj -guard:cf
  #include <setjmp.h>
  #include <stdio.h>
  jmp_buf buf;
  void g() {
    printf("before longjmp\n");
    fflush(stdout);
    longjmp(buf, 1);
  }
  void f() {
    if (setjmp(buf)) {
      printf("setjmp returned non-zero\n");
      return;
    }
    g();
  }
  int main() {
    f();
    printf("hello world\n");
  }
In particular, the program aborts when the code is compiled *without*
-guard:cf and linked with -guard:cf. That indicates that longjmps are
protected.
Reviewers: ruiu, inglorion, amccarth
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43217
llvm-svn: 325047 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | If a function doesn't have an exact definition, don't apply debugify
metadata as it triggers a DIVerifier failure.
The issue is that it's invalid to have DILocations inside a DISubprogram
which isn't a definition ("scope points into the type hierarchy!").
llvm-svn: 325036 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | If the output file is not specified make the modifications in-place 
(like binutils objcopy does). In particular, this fixes 
the behavior of Clang -gsplit-dwarf (if Clang is configured to use llvm-objcopy), 
previously it was creating .dwo files, but still leaving *dwo* sections in 
the original binary.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D42873
llvm-svn: 324783 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | from the value stored in swift_version bits in the flags field in the
objc_image_info struct.  ABI version 3 thru 6 were previously added but this
code was not updated to print the Swift version.
rdar://35624067
llvm-svn: 324767 | 
| | 
| 
| 
| 
| 
| 
| 
| | Bugpoint will keep going even if the opt binary it's given doesn't
exist. It should at least alert the user, so it's clear why reductions
are failing.
llvm-svn: 324713 | 
| | 
| 
| 
| 
| 
| | More unique_ptr-ification, ranged for loops, etc.
llvm-svn: 324705 | 
| | 
| 
| 
| 
| 
| | This option isn't used anywhere, as far as I can tell.
llvm-svn: 324704 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | Handles were returned by addModule and used as keys for removeModule,
findSymbolIn, and emitAndFinalize. Their job is now subsumed by VModuleKeys,
which simplify resource management by providing a consistent handle across all
layers.
llvm-svn: 324700 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Fix the comments, use early exits, use unique_ptr, and use ranged for
loops.
This is in preparation for a global *variable* reducer, which, with any
luck will help us clean up test cases.
Differential Revision: https://reviews.llvm.org/D43084
llvm-svn: 324649 | 
| | 
| 
| 
| | llvm-svn: 324633 | 
| | 
| 
| 
| 
| 
| 
| 
| | When processing a dSYM bundle, use llvm::sys::path to join the different
path components instead of using a string with hard coded forward
slashes as separators.
llvm-svn: 324622 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | Before this patch, llvm-dwarfdump would reject `bundel.dSYM/` as input,
while `bundel.dSYM` was accepted. The reason is that `path::extension()`
returns an empty string for the former, leading to the argument not
being recognized as a dSYM bundle.
llvm-svn: 324621 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | This commit attempts to re-land the r324480 which was reverted in
r324493 because it broke the Windows bots. For now I disabled the two
update tests on Windows until I'm able to debug this.
Differential revision: https://reviews.llvm.org/D42880
llvm-svn: 324592 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The LTO opt level should not affect the codegen opt level, and indeed
it does not affect it in lld. Ideally the codegen opt level should
be controlled by an IR-level attribute based on the compile-time opt
level, but that hasn't been implemented yet.
Differential Revision: https://reviews.llvm.org/D43040
llvm-svn: 324557 | 
| | 
| 
| 
| 
| 
| 
| | Revert "[dsymutil][test] Check the updated dSYM instead of companion file."
Revert "[dsymutil] Upstream update feature."
llvm-svn: 324493 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Now that dsymutil can generate accelerator tables, we can upstream the
update logic that, as the name implies, updates the accelerator tables
in an existing dSYM bundle. In combination with `-minimize` this can be
used to remove redundant .debug_(inlines|pubtypes|pubnames).
Differential revision: https://reviews.llvm.org/D42880
llvm-svn: 324480 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | backends
Summary:
A recent fix to drop dead symbols (r323633) did not work for ThinLTO
distributed backends because we lose the WithGlobalValueDeadStripping
set on the index during the thin link. This patch adds a new flags
record to the bitcode format for the index, and serializes this flag
for the combined index (it would always be 0 for the per-module index
generated by the compile step, so no need to serialize the new flags
record there until/unless we add another flag that applies to the
per-module indexes).
Generally this flag should always be set for the distributed backends,
which are necessarily performed after the thin link. However, if we were
to simply set this flag on the index applied to the distributed backends
(invoked via clang), we would lose the ability to disable dead stripping
via -compute-dead=false for debugging purposes.
Reviewers: grimar, pcc
Subscribers: mehdi_amini, inglorion, eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D42799
llvm-svn: 324444 | 
| | 
| 
| 
| | llvm-svn: 324410 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | In particular this patch switches RTDyldObjectLinkingLayer to use
orc::SymbolResolver and threads the requried changse (ExecutionSession
references and VModuleKeys) through the existing layer APIs.
The purpose of the new resolver interface is to improve query performance and
better support parallelism, both in JIT'd code and within the compiler itself.
The most visibile change is switch of the <Layer>::addModule signatures from:
Expected<Handle> addModule(std::shared_ptr<ModuleType> Mod,
                           std::shared_ptr<JITSymbolResolver> Resolver)
to:
Expected<Handle> addModule(VModuleKey K, std::shared_ptr<ModuleType> Mod);
Typical usage of addModule will now look like:
auto K = ES.allocateVModuleKey();
Resolvers[K] = createSymbolResolver(...);
Layer.addModule(K, std::move(Mod));
See the BuildingAJIT tutorial code for example usage.
llvm-svn: 324405 | 
| | 
| 
| 
| | llvm-svn: 324232 | 
| | 
| 
| 
| 
| 
| | Differential Revision: https://reviews.llvm.org/D42414
llvm-svn: 324225 | 
| | 
| 
| 
| | llvm-svn: 324123 | 
| | 
| 
| 
| | llvm-svn: 324038 |