Avoid custom code for sentinel traits in SimpleReference (the ilist node
for references to a SimpleDefinedAtom), since they'll soon/eventually
disappear from ilist entirely.
Rather than using a BumpPtrAllocator, this drops the lazy sentinel
characteristics and stores the sentinel directly in the ilist. This
unconditionally allocates the sentinel.
At first glance, this looks like it might increase memory usage
slightly, since an unreferenced SimpleDefinedAtom pays for a
6-pointer-sized sentinel even when its list of references is empty. In
practice, the sentinel was being lazily allocated at the first call to
DefinedAtom::begin/end anyway. I don't expect any real memory effects
here.
Moreover, this is an intermediate state. The ilist_*sentinel_traits are
being phased out.
As a preview of the final state: in lieu of a NodeTy sentinel, the ilist
will have a single, untemplated list_node_base that has next/prev
pointers. This base node will serve both as a sentinel and as a pointer
to the head of the list (the same memory layout as
ilist_half_embedded_sentinel_traits, but without the UB).
llvm-svn: 278521
Currently we do this when an atom is used, but we need to do it when a
dylib is referenced on the cmdline as this matches ld64.
This fixes much confusion over which maps are indexed with installName
vs path. There is likely other confusion so i'll be seeing if i can remove
path() completely in a future commit as path() shouldn't really be needed by anyone.
llvm-svn: 278396
This flag is implemented similarly to --reproduce in the ELF linker.
This patch implements /linkrepro by moving the cpio writer and associated
utility functions to lldCore, and using that implementation in both linkers.
One COFF-specific detail is that we store the object file from which the
resource files were created in our reproducer, rather than the resource
files themselves. This allows the reproducer to be used on non-Windows
systems for example.
Differential Revision: https://reviews.llvm.org/D22418
llvm-svn: 276719
With the llvm change in r266919 this is the matching needed change to the lld code
now that libObject’s getName() for symbols now returning Expected<...> .
llvm-svn: 266920
make_dynamic_error_code was used to create a std::error_code with
a std::string message. Now that we are migrating to llvm::Error,
there are no calls to these make_dynamic_error_code methods.
There is one single call to make_dynamic_error_code remaining, the one
inside GenericError::convertToErrorCode(). That method is only called
from File::doParse() which should be a temporary situation. We need
to work out how to deal with File::parse() caching the error result from
doParse(). Caching errors isn't supported in the new scheme, and probably
isn't needed here, but we need to work that out.
Once thats done, dynamic error and all utilities around it can be deleted.
llvm-svn: 264982
These methods weren't really throwing errors. The only error used
was that a file could not be found, which isn't really an error at all
as we are searching paths and libraries for a file. All of the callers
also ignored errors and just used the returned path if one was available.
Changing to return Optional<StringRef> as that actually reflects what
we are trying to do here: optionally find a given path.
llvm-svn: 264979
Pretty mechanical change here. Just replacing all the std::error_code() with
llvm::Error() and make_dynamic_error_code with make_error<GenericError>
llvm-svn: 264917
Adds a GenericError class to lld/Core which can carry a string. This is
analygous to the dynamic_error we currently use in lld/Core.
Use this GenericError instead of make_dynamic_error_code. Also, provide
an implemention of GenericError::convertToErrorCode which for now converts
it in to the dynamic_error_code we used to have. This will go away once
all the APIs are converted.
llvm-svn: 264910
searchArchivesToOverrideTentativeDefinitions and
searchSharedLibrariesToOverrideTentativeDefinitions are always false.
For the dead flags, we have a fairly large amount of code which is
never be executed.
http://reviews.llvm.org/D17791
llvm-svn: 264653
If the LHS of 'a = b' already had an atom in it then we wouldn't
call the destructor. This happens when we use something like
std::remove_if which is done in the CompactUnwindPass. Should fix
the leaks on the mach-o/unwind-info-simple-x86_64.yaml test case.
Lang and I are going to take a look at removing OwningAtomPtr in
favour of a std::unique_ptr but just trying to get the bots green
so we have a good baseline first.
llvm-svn: 264097
The AtomVector class is an internal detail of File so I moved it
to be protected in r264067. However, the MSVC bots don't like the
global declarations of type File::AtomVector in File.cpp so it needs
to go back to being public for now.
llvm-svn: 264070
This is a re-commit of r264022 with a fix for MSVC. The issue there was
that the code was running DefinedAtom::~Atom() for some value and instead
needed to cast to Atom before running ~Atom. Original commit message follows.
Currently each File contains an BumpPtrAllocator in which Atom's are
allocated. Some Atom's contain data structures like std::vector which
leak as we don't run ~Atom when they are BumpPtrAllocate'd.
Now each File actually owns its Atom's using an OwningAtomPtr. This
is analygous to std::unique_ptr and may be replaced by it if possible.
An Atom can therefore only be owned by a single File, so the Resolver now
moves them from one File to another. The MachOLinkingContext owns the File's
and so clears all the Atom's in ~MachOLinkingContext, then delete's all the
File's. This makes sure all Atom's have been destructed before any of the
BumpPtrAllocator's in which they run have gone away.
Should hopefully fix the remaining leaks. Will keep an eye on the bots to
make sure.
llvm-svn: 264067
This reverts commit r264022.
This breaks the Window's bots which don't like that i'm calling ~Atom when
the this pointer is a sublcass of Atom.
Reverting for now until I try find a better fix. I tried using std::unique_ptr with
a custom deleter as a quick fix, but it didn't work well in the YAML parser.
llvm-svn: 264023
Currently each File contains an BumpPtrAllocator in which Atom's are
allocated. Some Atom's contain data structures like std::vector which
leak as we don't run ~Atom when they are BumpPtrAllocate'd.
Now each File actually owns its Atom's using an OwningAtomPtr. This
is analygous to std::unique_ptr and may be replaced by it if possible.
An Atom can therefore only be owned by a single File, so the Resolver now
moves them from one File to another. The MachOLinkingContext owns the File's
and so clears all the Atom's in ~MachOLinkingContext, then delete's all the
File's. This makes sure all Atom's have been destructed before any of the
BumpPtrAllocator's in which they run have gone away.
Should hopefully fix the remaining leaks. Will keep an eye on the bots to
make sure.
llvm-svn: 264022
In trying to fix the leaks in the MachO lld codebase, we need to have
a better model for file and atom ownership. Having the context own
everything seems like the simplest model, so change all the passes to
allocate File's on the context instead of owning files as a member.
llvm-svn: 264004
The current code for processCIE and processFDE returns out if it sees
any references. The problem with this is that some references could be
explicit in the binary, while others are implicit as they can be
inferred from the content of the EHFrame itself.
This change walks the references we have against the references we
need, and verifies that all explicit references are in the correct place,
and generates any missing implicit ones.
Reviewed by Lang Hames and Nick Kledzik.
Differential Revision: http://reviews.llvm.org/D15439
llvm-svn: 263590
Now that DarwinLdDriver is the only derived class of Driver.
This patch merges them and actually removed the class because
they can now just be non-member functions. This change simplifies
a common header, Driver.h.
http://reviews.llvm.org/D17788
llvm-svn: 262502
CoreDriver implements a driver for a hypothetical platform.
It is intended to be used in unittests. However, it is actually
redundant because the features are tested using the real driver
for the real platforms. So we can remove this.
http://reviews.llvm.org/D17698
llvm-svn: 262421
UniversalDriver was used as a dispatcher to each platform-specific driver.
It had its own Options.td file. It was not just too much to parse only a
few options (we only want to parse -core, -flavor or argv[0]),
but also interpreted arguments too early. For example, if you invoke lld as
"lld -flavor gnu ... -help", then you'd get the UniversalDriver's help
message instead of GnuDriver's. This patch eliminates the use of Options
from the dispatcher.
http://reviews.llvm.org/D17686
llvm-svn: 262190
IIUC, range was an experiment to see how N3350 would work in LLD.
It turned out it didn't get traction, and it is basically duplicate
of iterator_range in ADT. We have only two occurrences of range,
and all of them are easily rewritten without it.
http://reviews.llvm.org/D17687
llvm-svn: 262171
