History log of /llvm-project/llvm/lib/Target/ARM/MCTargetDesc/ARMMachObjectWriter.cpp (Results 26 – 50 of 80)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 70bc5f13 19-Jun-2015 Alexander Kornienko <alexfh@google.com>

Fixed/added namespace ending comments using clang-tidy. NFC

The patch is generated using this command:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-c

Fixed/added namespace ending comments using clang-tidy. NFC

The patch is generated using this command:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
llvm/lib/


Thanks to Eugene Kosov for the original patch!

llvm-svn: 240137

show more ...


# 4915dd07 08-Jun-2015 Pete Cooper <peter_cooper@apple.com>

Remove includes of MCMachOSymbolFlags.h after it was deleted

llvm-svn: 239318


# 36e60e91 04-Jun-2015 Jim Grosbach <grosbach@apple.com>

MC: Clean up naming in MCObjectWriter. NFC.

s/WriteObject/writeObject/
s/RecordRelocation/recordRelocation/
s/IsSymbolRefDifferenceFullyResolved/isSymbolRefDifferenceFullyResolved/
s/Write8/write8/

MC: Clean up naming in MCObjectWriter. NFC.

s/WriteObject/writeObject/
s/RecordRelocation/recordRelocation/
s/IsSymbolRefDifferenceFullyResolved/isSymbolRefDifferenceFullyResolved/
s/Write8/write8/
s/WriteLE16/writeLE16/
s/WriteLE32/writeLE32/
s/WriteLE64/writeLE64/
s/WriteBE16/writeBE16/
s/WriteBE32/writeBE32/
s/WriteBE64/writeBE64/
s/Write16/write16/
s/Write32/write32/
s/Write64/write64/
s/WriteZeroes/writeZeroes/
s/WriteBytes/writeBytes/

llvm-svn: 239108

show more ...


# 7c76b4cc 04-Jun-2015 Jim Grosbach <grosbach@apple.com>

MC: Remove obsolete MachO UseAggressiveSymbolFolding.

Fix the FIXME and remove this old as(1) compat option. It was useful for
bringup of the integrated assembler to diff object files, but now it's

MC: Remove obsolete MachO UseAggressiveSymbolFolding.

Fix the FIXME and remove this old as(1) compat option. It was useful for
bringup of the integrated assembler to diff object files, but now it's
just causing more relocations than strictly necessary to be generated.

rdar://21201804

llvm-svn: 239084

show more ...


# 13760bd1 30-May-2015 Jim Grosbach <grosbach@apple.com>

MC: Clean up MCExpr naming. NFC.

llvm-svn: 238634


# 4d37b2a2 29-May-2015 Rafael Espindola <rafael.espindola@gmail.com>

Remove getData.

This completes the mechanical part of merging MCSymbol and MCSymbolData.

llvm-svn: 238617


# beb6060a 29-May-2015 Rafael Espindola <rafael.espindola@gmail.com>

Remove the MCSymbolData typedef.

The getData member function is next.

llvm-svn: 238611


# 3a5d3cce 28-May-2015 Rafael Espindola <rafael.espindola@gmail.com>

Remove a trivial forwarding function. NFC.

llvm-svn: 238506


# 61e724a8 26-May-2015 Rafael Espindola <rafael.espindola@gmail.com>

Stop using MCSectionData in MCMachObjectWriter.h.

llvm-svn: 238165


# 079027ea 26-May-2015 Rafael Espindola <rafael.espindola@gmail.com>

Stop using MCSectionData in MCExpr.h.

llvm-svn: 238163


# 7549f876 26-May-2015 Rafael Espindola <rafael.espindola@gmail.com>

Return a MCSection from MCFragment::getParent().

Another step in merging MCSectionData and MCSection.

llvm-svn: 238162


# 6e6820a7 25-May-2015 Rafael Espindola <rafael.espindola@gmail.com>

Stop forwarding getOrdinal and setOrdinal.

llvm-svn: 238139


# 08b8726d 20-May-2015 Duncan P. N. Exon Smith <dexonsmith@apple.com>

MC: Use MCSymbol in MachObjectWriter, NFC

Replace uses of `MCSymbolData` with `MCSymbol` where both are needed, so
we can remove the backpointer.

llvm-svn: 237799


# 99d8a8e8 20-May-2015 Duncan P. N. Exon Smith <dexonsmith@apple.com>

MC: Take MCSymbol in MachObjectWriter::getSymbolAddress(), NFC

Pass through an `MCSymbol` instead of an `MCSymbolData` so we can get
rid of the back pointer.

llvm-svn: 237750


# 2a404834 19-May-2015 Duncan P. N. Exon Smith <dexonsmith@apple.com>

MC: Use MCSymbol in MCAsmLayout::getSymbolOffset(), NFC

Continue to canonicalize on MCSymbol instead of MCSymbolData when both
are needed.

llvm-svn: 237749


# 6f482000 18-May-2015 Jim Grosbach <grosbach@apple.com>

MC: Clean up method names in MCContext.

The naming was a mish-mash of old and new style. Update to be consistent
with the new. NFC.

llvm-svn: 237594


# 6e23e5a6 16-May-2015 Duncan P. N. Exon Smith <dexonsmith@apple.com>

MC: Use MCSymbol in RelAndSymbol, NFC

Switch from `MCSymbolData` to `MCSymbol`.

llvm-svn: 237502


Revision tags: llvmorg-3.6.1, llvmorg-3.6.1-rc1
# 5560a4cf 14-Apr-2015 Rafael Espindola <rafael.espindola@gmail.com>

Use raw_pwrite_stream in the object writer/streamer.

The ELF object writer will take advantage of that in the next commit.

llvm-svn: 234950


# 49286e9f 09-Apr-2015 Rafael Espindola <rafael.espindola@gmail.com>

clang-format bits of code to make a followup patch easy to read.

llvm-svn: 234519


# 42335572 06-Apr-2015 Tim Northover <tnorthover@apple.com>

ARM: do not relax Thumb1 -> Thumb2 if only Thumb1 is available.

After recognising that a certain narrow instruction might need a relocation to
be represented, we used to unconditionally relax it to

ARM: do not relax Thumb1 -> Thumb2 if only Thumb1 is available.

After recognising that a certain narrow instruction might need a relocation to
be represented, we used to unconditionally relax it to a Thumb2 instruction to
permit this. Unfortunately, some CPUs (e.g. v6m) don't even have most Thumb2
instructions, so we end up emitting a completely invalid instruction.

Theoretically, ELF does have relocations for these situations; but they are
fairly unusable with such short ranges and the ABI document even says they're
documented "for completeness". So an error is probably better there too.

rdar://20391953

llvm-svn: 234195

show more ...


Revision tags: llvmorg-3.5.2, llvmorg-3.5.2-rc1, llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3, llvmorg-3.6.0-rc2
# 2658554a 19-Jan-2015 Rafael Espindola <rafael.espindola@gmail.com>

Add r224985 back with fixes.

The fixes are to note that AArch64 has additional restrictions on when local
relocations can be used. In particular, ld64 requires that relocations to
cstring/cfstrings

Add r224985 back with fixes.

The fixes are to note that AArch64 has additional restrictions on when local
relocations can be used. In particular, ld64 requires that relocations to
cstring/cfstrings use linker visible symbols.

Original message:

In an assembly expression like

bar:
.long L0 + 1

the intended semantics is that bar will contain a pointer one byte past L0.

In sections that are merged by content (strings, 4 byte constants, etc), a
single position in the section doesn't give the linker enough information.
For example, it would not be able to tell a relocation must point to the
end of a string, since that would look just like the start of the next.

The solution used in ELF to use relocation with symbols if there is a non-zero
addend.

In MachO before this patch we would just keep all symbols in some sections.

This would miss some cases (only cstrings on x86_64 were implemented) and was
inefficient since most relocations have an addend of 0 and can be represented
without the symbol.

This patch implements the non-zero addend logic for MachO too.

llvm-svn: 226503

show more ...


Revision tags: llvmorg-3.6.0-rc1
# 7244bb3c 14-Jan-2015 Rafael Espindola <rafael.espindola@gmail.com>

Revert "Add r224985 back with two fixes."

This reverts commit r225644 while I debug a regression.

llvm-svn: 226022


# d9c3e308 12-Jan-2015 Rafael Espindola <rafael.espindola@gmail.com>

Add r224985 back with two fixes.

One is that AArch64 has additional restrictions on when local relocations can
be used. We have to take those into consideration when deciding to put a L
symbol in th

Add r224985 back with two fixes.

One is that AArch64 has additional restrictions on when local relocations can
be used. We have to take those into consideration when deciding to put a L
symbol in the symbol table or not.

The other is that ld64 requires the relocations to cstring to use linker
visible symbols on AArch64.

Thanks to Michael Zolotukhin for testing this!

Remove doesSectionRequireSymbols.

In an assembly expression like

bar:
.long L0 + 1

the intended semantics is that bar will contain a pointer one byte past L0.

In sections that are merged by content (strings, 4 byte constants, etc), a
single position in the section doesn't give the linker enough information.
For example, it would not be able to tell a relocation must point to the
end of a string, since that would look just like the start of the next.

The solution used in ELF to use relocation with symbols if there is a non-zero
addend.

In MachO before this patch we would just keep all symbols in some sections.

This would miss some cases (only cstrings on x86_64 were implemented) and was
inefficient since most relocations have an addend of 0 and can be represented
without the symbol.

This patch implements the non-zero addend logic for MachO too.

llvm-svn: 225644

show more ...


# 04b37c40 06-Jan-2015 Lang Hames <lhames@gmail.com>

Revert r225048: It broke ObjC on AArch64.

I've filed http://llvm.org/PR22100 to track this issue.

llvm-svn: 225228


# 54b435ec 31-Dec-2014 Rafael Espindola <rafael.espindola@gmail.com>

Add r224985 back with a fix.

The issues was that AArch64 has additional restrictions on when local
relocations can be used. We have to take those into consideration when
deciding to put a L symbol i

Add r224985 back with a fix.

The issues was that AArch64 has additional restrictions on when local
relocations can be used. We have to take those into consideration when
deciding to put a L symbol in the symbol table or not.

Original message:

Remove doesSectionRequireSymbols.

In an assembly expression like

bar:
.long L0 + 1

the intended semantics is that bar will contain a pointer one byte past L0.

In sections that are merged by content (strings, 4 byte constants, etc), a
single position in the section doesn't give the linker enough information.
For example, it would not be able to tell a relocation must point to the
end of a string, since that would look just like the start of the next.

The solution used in ELF to use relocation with symbols if there is a non-zero
addend.

In MachO before this patch we would just keep all symbols in some sections.

This would miss some cases (only cstrings on x86_64 were implemented) and was
inefficient since most relocations have an addend of 0 and can be represented
without the symbol.

This patch implements the non-zero addend logic for MachO too.

llvm-svn: 225048

show more ...


1234