maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
169,013 Commits 23 Branches 0 Tags 2.2 GiB
Commit Graph

10 Commits

Author SHA1 Message Date
Ahmed Charles d779459f21 [C++11] Add #include's for OwningPtr. 
Allows removing #include's in LLVM while switching to std::unique_ptr.

llvm-svn: 202679
 2014-03-03 07:20:05 +00:00
Rafael Espindola 20d93679c7 Update for llvm api change. 
llvm-svn: 201109
 2014-02-10 20:24:27 +00:00
Rafael Espindola 8c13e51764 Update for llvm api change. 
llvm-svn: 200575
 2014-01-31 21:13:59 +00:00
Rafael Espindola 8fe1f37c55 Update for llvm api change. 
llvm-svn: 200443
 2014-01-30 02:49:58 +00:00
Rafael Espindola 6ba68f10c4 Update for llvm api change. 
llvm-svn: 199777
 2014-01-22 00:14:56 +00:00
Rafael Espindola 79e2d936fd Update for llvm api change. 
llvm-svn: 199752
 2014-01-21 16:09:55 +00:00
Rui Ueyama 170a1a892e Run clang-format on r197727. 
llvm-svn: 197788
 2013-12-20 07:48:29 +00:00
Nick Kledzik e555277780 [lld] Introduce registry and Reference kind tuple 
The main changes are in:
  include/lld/Core/Reference.h
  include/lld/ReaderWriter/Reader.h
Everything else is details to support the main change.

1) Registration based Readers
Previously, lld had a tangled interdependency with all the Readers.  It would
have been impossible to make a streamlined linker (say for a JIT) which
just supported one file format and one architecture (no yaml, no archives, etc).
The old model also required a LinkingContext to read an object file, which
would have made .o inspection tools awkward.

The new model is that there is a global Registry object. You programmatically 
register the Readers you want with the registry object. Whenever you need to 
read/parse a file, you ask the registry to do it, and the registry tries each 
registered reader.

For ease of use with the existing lld code base, there is one Registry
object inside the LinkingContext object. 


2) Changing kind value to be a tuple
Beside Readers, the registry also keeps track of the mapping for Reference
Kind values to and from strings.  Along with that, this patch also fixes
an ambiguity with the previous Reference::Kind values.  The problem was that
we wanted to reuse existing relocation type values as Reference::Kind values.
But then how can the YAML write know how to convert a value to a string? The
fix is to change the 32-bit Reference::Kind into a tuple with an 8-bit namespace
(e.g. ELF, COFFF, etc), an 8-bit architecture (e.g. x86_64, PowerPC, etc), and
a 16-bit value.  This tuple system allows conversion to and from strings with 
no ambiguities.

llvm-svn: 197727
 2013-12-19 21:58:00 +00:00
Rui Ueyama 6031c37050 Make error code variables to have narrower scope. 
llvm-svn: 196564
 2013-12-06 04:48:05 +00:00
Rui Ueyama 34efe77742 Move definitions to cpp file. No functionality change. 
llvm-svn: 196563
 2013-12-06 04:43:01 +00:00