Cleanup LLVMMC headers

There's a few relevant forward declarations in there that may require downstream
adding explicit includes:

llvm/MC/MCContext.h no longer includes llvm/BinaryFormat/ELF.h, llv

Cleanup LLVMMC headers

There's a few relevant forward declarations in there that may require downstream
adding explicit includes:

llvm/MC/MCContext.h no longer includes llvm/BinaryFormat/ELF.h, llvm/MC/MCSubtargetInfo.h, llvm/MC/MCTargetOptions.h
llvm/MC/MCObjectStreamer.h no longer include llvm/MC/MCAssembler.h
llvm/MC/MCAssembler.h no longer includes llvm/MC/MCFixup.h, llvm/MC/MCFragment.h

Counting preprocessed lines required to rebuild llvm-project on my setup:
before: 1052436830
after: 1049293745

Which is significant and backs up the change in addition to the usual benefits of
decreasing coupling between headers and compilation units.

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D119244

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.

I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.

This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.

Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).

llvm-svn: 304787

show more ...

MC: Remove unused virtual function MCObjectWriter::isWeak. NFC.

llvm-svn: 299817

[MC] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 294526

Fix pr24486.

This extends the work done in r233995 so that now getFragment (in addition to
getSection) also works for variable symbols.

With that the existing logic to decide if a-b can be computed

Fix pr24486.

This extends the work done in r233995 so that now getFragment (in addition to
getSection) also works for variable symbols.

With that the existing logic to decide if a-b can be computed works even if
a or b are variables. Given that, the expression evaluation can avoid expanding
variables as aggressively and that in turn lets the relocation code see the
original variable.

In order for this to work with the asm streamer, there is now a dummy fragment
per section. It is used to assign a section to a symbol when no other fragment
exists.

This patch is a joint work by Maxim Ostapenko andy myself.

llvm-svn: 249303

show more ...

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 ...

Remove getData.

This completes the mechanical part of merging MCSymbol and MCSymbolData.

llvm-svn: 238617

Remove the MCSymbolData typedef.

The getData member function is next.

llvm-svn: 238611

Remove a trivial forwarding function. NFC.

llvm-svn: 238506

Return a MCSection from MCFragment::getParent().

Another step in merging MCSectionData and MCSection.

llvm-svn: 238162

MC: Use MCSymbol in MCObjectWriter::isWeak(), NFC

Continue to prefer `MCSymbol` when we need both.

llvm-svn: 237798

MC: Use MCSymbol in MCObject::IsSymbolRefDifferenceFullyResolvedImpl()

Transition one API from `MCSymbolData` to `MCSymbol`. The function
needs both, and the backpointer from `MCSymbolData` to `MCS

MC: Use MCSymbol in MCObject::IsSymbolRefDifferenceFullyResolvedImpl()

Transition one API from `MCSymbolData` to `MCSymbol`. The function
needs both, and the backpointer from `MCSymbolData` to `MCSymbol` is
going away.

llvm-svn: 237498

show more ...

Compute A-B when A or B is weak.

Similar to r235222, but for the weak symbol case.

In an "ideal" assembler/object format an expression would always refer to the
final value and A-B would only be co

Compute A-B when A or B is weak.

Similar to r235222, but for the weak symbol case.

In an "ideal" assembler/object format an expression would always refer to the
final value and A-B would only be computed from a section in the same
comdat as A and B with A and B strong.

Unfortunately that is not the case with debug info on ELF, so we need an
heuristic. Since we need an heuristic, we may as well use the same one as
gas:

* call weak_sym : produces a relocation, even if in the same section.
* A - weak_sym and weak_sym -A: don't produce a relocation if we can
compute it.

This fixes pr23272 and changes the fix of pr22815 to match what gas does.

llvm-svn: 235227

show more ...

Remove unnecessary uses of AliasedSymbol.

As pr19627 points out, every use of AliasedSymbol is likely a bug.

The main use was to avoid the oddity of a variable showing up as undefined. That
was fix

Remove unnecessary uses of AliasedSymbol.

As pr19627 points out, every use of AliasedSymbol is likely a bug.

The main use was to avoid the oddity of a variable showing up as undefined. That
was fixed in r233995, which made these calls nops.

llvm-svn: 234169

show more ...

Be consistent when deciding if a relocation is needed.

Before when deciding if we needed a relocation in A-B, we wore only checking
if A was weak.

This fixes the asymmetry.

The "InSet" argument sh

Be consistent when deciding if a relocation is needed.

Before when deciding if we needed a relocation in A-B, we wore only checking
if A was weak.

This fixes the asymmetry.

The "InSet" argument should probably be renamed to "ForValue", since InSet is
very MachO specific, but doing so in this patch would make it hard to read.

This fixes PR22815.

llvm-svn: 234165

show more ...

clang-format bits of code to make another patch readable.

llvm-svn: 233203

Fix fixup evaluation when deciding what to relocate with.

The previous logic was to first try without relocations at all
and failing that stop on the first defined symbol.

That was inefficient and

Fix fixup evaluation when deciding what to relocate with.

The previous logic was to first try without relocations at all
and failing that stop on the first defined symbol.

That was inefficient and incorrect in the case part of the
expression could be simplified and another part could not
(see included test).

We now stop the evaluation when we get to a variable whose value
can change (i.e. is weak).

llvm-svn: 233187

show more ...

Move [SU]LEB128 encoding to a utility header.

These functions are very generic. There's no reason for them to
be tied to MCObjectWriter.

llvm-svn: 161545

Fixed a crash in llvm-mc for Mach-O when a symbol difference expression uses a
symbol from an assignment. In this case the symbol did not have a fragment so
MCObjectWriter::IsSymbolRefDifferenceFull

Fixed a crash in llvm-mc for Mach-O when a symbol difference expression uses a
symbol from an assignment. In this case the symbol did not have a fragment so
MCObjectWriter::IsSymbolRefDifferenceFullyResolved() should not have been
calling IsSymbolRefDifferenceFullyResolvedImpl() with a NULL fragment and should
just have returned false in that case.

llvm-svn: 149442

show more ...

Add an option to pad an uleb128 to MCObjectWriter and remove the uleb128 encoding from the DWARF asm printer.

As a side effect we now print dwarf ulebs with .ascii directives.

llvm-svn: 143809

Gas is very inconsistent about when a relaxation/relocation is needed. Do
the right thing and stop trying to copy it. Fixes PR8944.

llvm-svn: 125648

Merge IsFixupFullyResolved and IsSymbolRefDifferenceFullyResolved. We now
have a single point where targets test if a relocation is needed.

llvm-svn: 122549

Merge isAbsolute into IsSymbolRefDifferenceFullyResolved.

llvm-svn: 122148

This is the last major patch to implement support for the .loc directive
and output the dwarf line number tables. This contains the code to emit and
encode the dwarf line tables from the previously

This is the last major patch to implement support for the .loc directive
and output the dwarf line number tables. This contains the code to emit and
encode the dwarf line tables from the previously gathered information in the
MCLineSection objects. This contains all the details to encode the line and
address deltas into the dwarf line table.

To do this an MCDwarfLineAddrFragment has been added.

Also this moves the interface code out of Mach-O streamer into
MCDwarf so it should be useable by other object file formats.

There is now one call to be made from an MCObjectStreamer
EmitInstruction() method:
MCLineEntry::Make(this, getCurrentSection());
to create a line entry after each instruction is assembled.

And one call call to be made from an MCObjectStreamer Finish() method:
MCDwarfFileTable::Emit(this, DwarfLineSection);
when getContext().hasDwarfFiles() is true and is passed a object file specific
MCSection where to emit the dwarf file and the line tables.

This appears to now be correct for 32-bit targets, at least x86. But the
relocation entries for 64-bit Darwin needs some further work which is next
up to work on. So for now the 64-bit Mach-O target does not output the
dwarf file and line tables.

llvm-svn: 115157

show more ...