llvm-svn: 122009

llvm-svn: 122008

llvm-svn: 122006

llvm-svn: 121988

interface.

llvm-svn: 121981

llvm-svn: 121973

llvm-svn: 121971

llvm-svn: 121970

the MCCodeEmitter, which seems like a better organization.
 - Also, cleaned up some magic constants while in the area.

llvm-svn: 121953

2. Fixed EmitLocalCommonSymbol for ELF (Yes, they exist. :)
   Test added.

llvm-svn: 121951

 - Treaty talks on the non-proliferation of MC objects broke down.

llvm-svn: 121949

llvm-svn: 121910

llvm-svn: 121904

llvm-svn: 121880

llvm-svn: 121875

With this we don't need the EffectiveSize field anymore. Without that field
LayoutFragment only updates offsets and we don't need to invalidate the
current fragment when it is relaxed (only the ones following it).

This is also a very small improvement in the accuracy of the layout info as
we now use the after relaxation size immediately.

llvm-svn: 121857

Since we now don't update addresses so early, we might relax a bit more than
we need to. This is simillar to the issue in PR8467.

llvm-svn: 121856

llvm-svn: 121851

set for interworking to work properly. rdar://8755956

llvm-svn: 121778

Test has fixme, to move to .s -> .o test when AsmParser works better.

llvm-svn: 121732

llvm-svn: 121496

llvm-svn: 121471

llvm-svn: 121461

f:
        .cfi_startproc
        nop
        .cfi_endproc

assembled (on ELF).

llvm-svn: 121434

llvm-svn: 121426

Fix an issue in some Thumb fixups, where the effective PC address needs to be 4-byte aligned when calculating
the offset.  Add a new fixup flag to represent this, and use it for the one fixups that I have a testcase for needing
this.  It's quite likely that the other Thumb fixups will need this too, and to have their fixup encoding logic
adjusted accordingly.

llvm-svn: 121408

llvm-svn: 121404

llvm-svn: 121402

Added test to check bl __aeabi_read_tp gets emitted properly for ELF/ASM
as well as ELF/OBJ (including fixup)

Also added support for ELF::R_ARM_TLS_IE32

llvm-svn: 121312

llvm-svn: 121308

llvm-svn: 121226

thumb vs. arm mode differences in WriteNopData().

llvm-svn: 121219

before:
        4 assembler - Number of assembler layout and relaxation steps
    78563 assembler - Number of emitted assembler fragments
  8693904 assembler - Number of emitted object file bytes
   271223 assembler - Number of evaluated fixups
330771677 assembler - Number of fragment layouts
     5958 assembler - Number of relaxed instructions
  2508361 mcexpr    - Number of MCExpr evaluations

real	0m26.123s
user	0m25.694s
sys	0m0.388s

after:

      4 assembler - Number of assembler layout and relaxation steps
  78563 assembler - Number of emitted assembler fragments
8693904 assembler - Number of emitted object file bytes
 271223 assembler - Number of evaluated fixups
 231507 assembler - Number of fragment layouts
   5958 assembler - Number of relaxed instructions
2508361 mcexpr    - Number of MCExpr evaluations

real	0m2.500s
user	0m2.113s
sys	0m0.273s

And yes, the outputs are identical :-)

llvm-svn: 121207

Fix absolute recording of differences of symbols in two sections. Reduced from ctor_dtor_count-2.cpp.

llvm-svn: 121152

llvm-svn: 121114

llvm-svn: 121107

llvm-svn: 121085

actuall addresses in a .o file, so it is better to let the MachO writer compute
it.

This is good for two reasons. First, areas that shouldn't care about
addresses now don't have access to it. Second, the layout of each section
is independent. I should use this in a subsequent commit to speed it up.

Most of the patch is just removing the section address computation. The two
interesting parts are the change on how we handle padding in the end
of sections and how MachO can get the address of a-b when a and b are in
different sections.

Since now the expression evaluation normally doesn't know the section address,
it will think that a-b needs relocation and let the MachO writer know. Once
it has computed the section addresses, it calls back the expression evaluation
with the section addresses to resolve these expressions.

The remaining problem is the handling of padding. Currently it will create
a special alignment fragment at the end. Since that fragment doesn't update
the alignment of the section, it needs the real address to be computed.

Since now the layout will not compute a-b with a and b in different sections,
the only effect that the special alignment fragment has is update the
address size of the section. This can also be done by the MachO writer.

llvm-svn: 121076

llvm-svn: 121072

llvm-svn: 121050