llvm-svn: 99217

llvm-svn: 99216

MC: Change MCObjectWriter::RecordRelocation to take an MCFragment (instead of a MCDataFragment). Object files should only need the generic MCFragment features.

llvm-svn: 99205

llvm-svn: 99204

llvm-svn: 99203

llvm-svn: 99202

llvm-svn: 99031

llvm-svn: 98994

 - This is "extraordinarily" Darwin 'as' compatible. See the litany of FIXMEs littered about for more information.
 - There are a few cases which seem to clearly be 'as' bugs which I have left unsupported, and there is one cases where we diverge but should fix if it blocks diffing .o files (Darwin 'as' ends up widening a jump unnecessarily).
 - 403.gcc build, runs, and diffs equivalently to the 'as' built version now (using llvm-mc). However, it builds so slowly that I wouldn't recommend trying it quite yet. :)

llvm-svn: 98974

 - MCAssembler is now object-file independent, although we will surely need more work to fully support ELF/COFF.

llvm-svn: 98955

llvm-svn: 98954

llvm-svn: 98953

llvm-svn: 98952

llvm-svn: 98950

llvm-svn: 98949

llvm-svn: 98948

MCAssembler: Move ApplyFixup to the TargetAsmBackend, this is a target specific not object writer specific task.

llvm-svn: 98947

MC/Mach-O: Lift the fixup evaluation and application up (to the same place), and eliminate MCAsmFixup::FixedValue.

llvm-svn: 98944

MC/Mach-O: Factor out ExecutePostLayoutBinding, to separate the post-layout changes the object writer may need to make to the assembler from the actual .o writing.

llvm-svn: 98943

MC/Mach-O: Lift relocation emission logic a bit higher to separate evaluation / relocation handling from the actual .o writing.

llvm-svn: 98942

createAsmStreamer now takes ownership of the instprinter.

llvm-svn: 98939

MC/Mach-O: Add isScatteredFixupFullyResolved, which implements the correct algorithm (used on x86_64) for determining whether an evaluated fixup is fully resolved (doesn't need relocation).
 - Test cases will follow, once we have x86_64 relocation support.

llvm-svn: 98926

 - These find the defining symbol which identifies the containing atom for a symbol or address. They are currently very slow, but will be eliminated eventually.

llvm-svn: 98925

llvm-svn: 98924

MC/Mach-O: Factor out isSymbolLinkerVisible method; "linker visible" is a made up term to refer to non-temporary labels + temporary labels in sections-which-require symbols. For Darwin, it corresponds to symbols which effectively define an atom.

llvm-svn: 98923

MCValue: Change to holding MCSymbolRefExprs instead of MCSymbols, we will need this for accessing to symbol modifiers.

llvm-svn: 98791

MC/Darwin: Add a new target hook for whether the target uses "reliable" symbol differences, basically whether the assembler should attempt to understand atoms when using scattered symbols.

Also, avoid some virtual call overhead.

llvm-svn: 98789

should use CreateTempSymbol() if they don't care about the
name.

llvm-svn: 98712

 - Although it would be nice to allow this decoupling, the assembler needs to be able to reason about MCSymbolRefExprs in too many places to make this viable. We can use a target specific encoding of the variant if this becomes an issue.
 - This patch also extends llvm-mc to support parsing of the modifiers, as opposed to lumping them in with the symbol.

llvm-svn: 98592

MC/Mach-O/x86_64: Temporary labels in cstring sections require symbols (and external relocations, but we don't have x86_64 relocations yet).

llvm-svn: 98583

llvm-svn: 98582

allocated and thus not freed.  This is cool except that it contains
and std::string so the string data didn't get freed.  In any case
there is no reason to redundantly store the string data in the 
MCSymbol anyway, just make the MCSymbol ref the string data in the
MCContext StringMap.

llvm-svn: 98536

CreateTempSymbol vs GetOrCreateTemporarySymbol are
completely different.

llvm-svn: 98486

llvm-svn: 98464

llvm-svn: 98456

llvm-svn: 98454

llvm-svn: 98442

relative to the fragment address, not its offset. This was masked by the text
section normally being at address 0.

llvm-svn: 98420

compiler may not lead with the text section.

llvm-svn: 98418

 - The implementation is currently very brain dead and inefficient, but I have a
   clear plan on how to fix it.

 - The good news is, it works and correctly assembles 403.gcc (when built with
   Clang, at '-Os', '-Os -g', and '-O3'). Even better, at '-Os' and '-Os -g',
   the resulting binary is exactly equivalent to that when built with the system
   assembler. So it probably works! :)

llvm-svn: 98396