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
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
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
The non lazy atoms generated in the stubs pass use an image cache to
hold all of the pointers. On arm archs, this is the __got section,
but on x86 archs it should be __nl_symbol_ptr.
rdar://problem/24572729
llvm-svn: 260271
The magic file which contained these symbols inherited from archive
which meant that the resolver didn't add the required atoms as archive
members only get added when referenced. Instead we now inherit from
SimpleFile which always links in the atoms needed.
The second issue was in the handling of these symbols when we emit
the MachO. The mach header symbol needs to be in the atom list as
it gets an offset (0), and being in the atom list makes sure it is
emitted to the symbol table. DSO handles are not emitted to the
symbol table.
rdar://problem/24450654
llvm-svn: 259574
An upcoming patch will use this to create lists of ObjC methods.
Adding it now to reduce the amount of code in that patch.
Test cases will follow in the other patch too.
llvm-svn: 259440
This pass currently emits an objc image info section if one is required.
This section contains the aggregated version and flags for all of the input
files.
llvm-svn: 258197
This is to enable isa<> support for any files which need it.
It will be used in an upcoming patch to differentiate MachOFile from other implicitly generated files.
Reviewed by Lang Hames.
Differential Revision: http://reviews.llvm.org/D16103
llvm-svn: 257830
This is called from the resolver on each file we decide we actually want to use.
Future commits will make use of this to extract useful information from the files and do
error checking against the context. For example, ensure that files are the same arch as
each other.
Reviewed by Lang Hames.
Differential Revision: http://reviews.llvm.org/D16093
llvm-svn: 257814
In a UI such as XCode, it can group the headers for a library with that library.
This is done in the CMakeLists.txt for the library itself by setting the path(s)
as ADDITIONAL_HEADER_DIRS.
LLVM already does this for all of its libraries, so just adding this to lld to
make things easier. Should be NFC.
llvm-svn: 257002
In a UI such as XCode, LLVM source files are in 'libraries' while clang
files are in 'clang libraries'.
This change moves the lld source to 'lld libraries' to make code browsing easier.
It should be NFC as the build itself is still the same, just the structure in a
UI differs.
llvm-svn: 257001
We had some DEBUG prints these passes, but add more so that its clear where we are dumping
things, and what state we are in when we do so.
I'll be adding more and more DEBUG printing to try make it easier to observe whats going on
without having to attach a debugger.
llvm-svn: 255805
Add PT_PHDR segment depending on its availability in linker script's
PHDRS command, fallback if no linker script is given.
Handle FILEHDR, PHDRS and FLAGS attributes of program header.
Differential Revision: http://reviews.llvm.org/D11589
llvm-svn: 244743
Add method to query segments for specified output section name.
Return error if the section is assigned to unknown segment.
Check matching of sections to segments during layout on the subject of correctness.
NOTE: no actual functionality of using custom segments is implemented.
Differential Revision: http://reviews.llvm.org/D10359
llvm-svn: 239719
This patch provides generation of .ARM.exidx & .ARM.extab sections which are
used for unwinding. The patch adds new content type typeARMExidx for atoms from
.ARM.exidx section and integration of atoms with such type to the ELF
ReaderWriter. exidx.test has been added with checking of contents of .ARM.exidx
section and .ARM.extab section.
Differential Revision: http://reviews.llvm.org/D9324
llvm-svn: 236873
loadFile could load mulitple files just because yaml has a feature for
putting multiple documents in one file.
Designing a linker around what yaml can do seems like a bad idea to
me. This patch changes it to read a single file.
There are further improvements to be done to the api and they
will follow shortly.
llvm-svn: 235724
The function took either StringRef or Twine. Since string literals are
ambiguous when resolving the overloading, many code calls used this
function with explicit type conversion. That led awkward code like
make_dynamic_error_code(Twine("Error occurred")).
This patch adds a function definition for string literals, so that
you can directly call the function with literals.
llvm-svn: 234841
I believe this patch eliminates all remaining uses of _context
or _linkingContext variable names. Consistent naming improves
readability.
llvm-svn: 234645
The Native file format was designed to be the fastest on-memory or
on-disk file format for object files. The problem is that no one
is working on that. No LLVM tools can produce object files in
the Native, thus the feature of supporting the format is useless
in the linker.
This patch removes the Native file support. We can add it back
if we really want it in future.
llvm-svn: 234641
It's not our business to resolve those undefined symbols.
We just trust the linker will load the library and its dependencies
correctly, which is actually what happens, modulo bugs in the dynamic
linker itself.
PR: 23035
Differential Revision: http://reviews.llvm.org/D8886
llvm-svn: 234378
Pete Cooper