[MC] Avoid UAF in WinCOFFObjectWriter with weak symbols.

When using weak symbols, the WinCOFFObjectWriter keeps a list (`WeakDefaults`)
that's used to make names unique. This list should be reset wh

[MC] Avoid UAF in WinCOFFObjectWriter with weak symbols.

When using weak symbols, the WinCOFFObjectWriter keeps a list (`WeakDefaults`)
that's used to make names unique. This list should be reset when the object
writer is reset, because otherwise reuse of the object writer can result in
freed symbols being accessed. With some added output, this becomes clear when
using `llc` in `--run-twice` mode:

```
$ ./llc --compile-twice -mtriple=x86_64-pc-win32 trivial.ll -filetype=obj

DefineSymbol::WeakDefaults
- .weak.foo.default
- .weak.bar.default

DefineSymbol::WeakDefaults
- .weak.foo.default
- áÑJij⌂ p§┼Ø┐☺
- .debug_macinfo.dw
- .weak.bar.default
```

This does not seem to leak into the output object file though, so I couldn't
come up with a test. I added one that just does `--run-twice` (and verified
that it does access freed memory), which should result in detecting the
invalid memory accesses when running under ASAN.

Observed in a Julia PR where we started using weak symbols:
https://github.com/JuliaLang/julia/pull/45649

Reviewed By: mstorsjo

Differential Revision: https://reviews.llvm.org/D129840

show more ...

[MC] [Win64EH] Check that the SEH unwind opcodes match the actual instructions

It's a fairly common issue that the generating code incorrectly marks
instructions as narrow or wide; check that the in

[MC] [Win64EH] Check that the SEH unwind opcodes match the actual instructions

It's a fairly common issue that the generating code incorrectly marks
instructions as narrow or wide; check that the instruction lengths
add up to the expected value, and error out if it doesn't. This allows
catching code generation bugs.

Also check that prologs and epilogs are properly terminated, to
catch other code generation issues.

Differential Revision: https://reviews.llvm.org/D125647

show more ...

Implement support for __llvm_addrsig for MachO in llvm-mc

The __llvm_addrsig section is a section that the linker needs for safe icf.
This was not yet implemented for MachO - this is the implementat

Implement support for __llvm_addrsig for MachO in llvm-mc

The __llvm_addrsig section is a section that the linker needs for safe icf.
This was not yet implemented for MachO - this is the implementation.
It has been tested with a safe deduplication implementation inside lld.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D123751

show more ...

[COFF] Move section name encoding into BinaryFormat

Large COFF section names are moved into the string table and the
section header field is the offset into the string table encoded in
ASCII for off

[COFF] Move section name encoding into BinaryFormat

Large COFF section names are moved into the string table and the
section header field is the offset into the string table encoded in
ASCII for offset smaller than 7 digits and in base64 for larger
offsets.

The operation of taking the string table offsets is done in a few
places in the codebase, so it is helpful to move this operation into
`BinaryFormat` so that it can be shared everywhere it's done.

So this patch takes the implementation of this operation from
`llvm/lib/MC/WinCOFFObjectWriter.cpp` and moves it into `BinaryFormat`.

Reviewed By: jhenderson, rnk

Differential Revision: https://reviews.llvm.org/D118793

show more ...

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

[COFF] [ARM64] Create symbols with regular intervals for relocations against temporary symbols

For relocations against temporary symbols (that don't persist in
the object file), we normally adjust t

[COFF] [ARM64] Create symbols with regular intervals for relocations against temporary symbols

For relocations against temporary symbols (that don't persist in
the object file), we normally adjust them to reference the start of
the section.

For adrp relocations, the immediate offset from the referenced
symbol is stored in the opcode as the 21 bit signed immediate; this
means that the symbol referenced must be within +/- 1 MB from the
referenced symbol.

Create label symbols with regular intervals (1 MB intervals). For
relocations against temporary symbols, pick the preceding added
offset symbol and make the relocation against that instead of
against the start of the section.

This should fix the root issue behind
https://bugs.llvm.org/show_bug.cgi?id=52378.

Differential Revision: https://reviews.llvm.org/D114340

show more ...

[COFF] Fix ARM and ARM64 REL32 relocations to be relative to the end of the relocation

This matches how they are defined on X86.

This should fix the relative lookup tables pass for COFF, allowing
i

[COFF] Fix ARM and ARM64 REL32 relocations to be relative to the end of the relocation

This matches how they are defined on X86.

This should fix the relative lookup tables pass for COFF, allowing
it to be reenabled.

Differential Revision: https://reviews.llvm.org/D102217

show more ...

ELFObjectWriter: Make STT_FILE precede associated local symbols

[COFF] Aliases resolve directly to defined external targets

Avoid introducing unnecessary indirection for weak-external references.

We only need to introduce ".weak.<SYMBOL>.default" when referenci

[COFF] Aliases resolve directly to defined external targets

Avoid introducing unnecessary indirection for weak-external references.

We only need to introduce ".weak.<SYMBOL>.default" when referencing a
symbol that is defined, but not external.

Reviewed By: mstorsjo

Differential Revision: https://reviews.llvm.org/D88305

show more ...

[MC] [COFF] Make sure that weak external symbols are undefined symbols

For comdats (e.g. caused by -ffunction-sections), Section is already
set here; make sure it's null, for the weak external symbo

[MC] [COFF] Make sure that weak external symbols are undefined symbols

For comdats (e.g. caused by -ffunction-sections), Section is already
set here; make sure it's null, for the weak external symbol to be undefined.

This fixes PR46779.

Differential Revision: https://reviews.llvm.org/D84507

show more ...

[COFF] Fix endianness of .llvm.call-graph-profile section data

[COFF] Add cg_profile directive and .llvm.call-graph-profile section

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D83597

MCObjectWriter.h - remove Endian.h/EndianStream.h/raw_ostream.h includes. NFC

Push these includes down to the the writers that actually need them, a number of which were implicitly relying on the MC

MCObjectWriter.h - remove Endian.h/EndianStream.h/raw_ostream.h includes. NFC

Push these includes down to the the writers that actually need them, a number of which were implicitly relying on the MCObjectWriter.h.

show more ...

[MC] Rename MCSection*::getSectionName() to getName(). NFC

A pending change will merge MCSection*::getName() to MCSection::getName().

[COFF] Assign unique names to autogenerated .weak.<name>.default symbols

These symbols need to be external (MSVC tools error out if a weak
external points at a symbol that isn't external; this was t

[COFF] Assign unique names to autogenerated .weak.<name>.default symbols

These symbols need to be external (MSVC tools error out if a weak
external points at a symbol that isn't external; this was tried before
but had to be reverted in bc5b7217dceecd3eec69593026a9e38dfbfd6908,
and this was originally explicitly fixed in
732eeaf2a930ad2755cb4eb5d99a3deae0de4a72).

If multiple object files have weak symbols with defaults, their
defaults could cause linker errors due to duplicate definitions,
unless the names of the defaults are unique.

GNU binutils handles this by appending the name of another symbol
from the same object file to the name of the default symbol. Try
to implement something similar; before writing the object file,
locate a symbol that should have a unique name and use the name of
that one for making the weak defaults unique.

Differential Revision: https://reviews.llvm.org/D75989

show more ...

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...

Revert "[COFF] Make the autogenerated .weak.<name>.default symbols static"

This reverts commit 7ca86ee6494d4307333b300bae80e42df4a5140f.

Apparently this change causes MS link.exe to error out with

Revert "[COFF] Make the autogenerated .weak.<name>.default symbols static"

This reverts commit 7ca86ee6494d4307333b300bae80e42df4a5140f.

Apparently this change causes MS link.exe to error out with
"LNK1235: corrupt or invalid COFF symbol table".

show more ...

[COFF] Make the autogenerated .weak.<name>.default symbols static

If we have references to the same extern_weak in multiple objects,
all of them would generate external symbols with the same name. M

[COFF] Make the autogenerated .weak.<name>.default symbols static

If we have references to the same extern_weak in multiple objects,
all of them would generate external symbols with the same name. Make
them static to avoid duplicate definitions; nothing should need to
refer to this symbol outside of the current object.

GCC/binutils seems to handle the same by not using a fixed string
for the ".default" suffix, but instead using the name of some other
defined external symbol from the same object (which is supposed to
be unique among objects unless there's other duplicate definitions).

Differential Revision: https://reviews.llvm.org/D71711

show more ...

Unify the two CRC implementations

David added the JamCRC implementation in r246590. More recently, Eugene
added a CRC-32 implementation in r357901, which falls back to zlib's
crc32 function if prese

Unify the two CRC implementations

David added the JamCRC implementation in r246590. More recently, Eugene
added a CRC-32 implementation in r357901, which falls back to zlib's
crc32 function if present.

These checksums are essentially the same, so having multiple
implementations seems unnecessary. This replaces the CRC-32
implementation with the simpler one from JamCRC, and implements the
JamCRC interface in terms of CRC-32 since this means it can use zlib's
implementation when available, saving a few bytes and potentially making
it faster.

JamCRC took an ArrayRef<char> argument, and CRC-32 took a StringRef.
This patch changes it to ArrayRef<uint8_t> which I think is the best
choice, and simplifies a few of the callers nicely.

Differential revision: https://reviews.llvm.org/D68570

llvm-svn: 374148

show more ...

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013

show more ...

MC: correct the emission of weak aliases in COFF

The weak alias should have the characteristics set to
`IMAGE_EXTERN_WEAK_SEARCH_ALIAS` to indicate that the weak external here
is a symbol alias and

MC: correct the emission of weak aliases in COFF

The weak alias should have the characteristics set to
`IMAGE_EXTERN_WEAK_SEARCH_ALIAS` to indicate that the weak external here
is a symbol alias and that the symbol is aliased to a locally defined
symbol. We were previously setting the characteristics to
`IMAGE_EXTERN_WEAK_SEARCH_LIBRARY` which indicates that the symbol
should be looked for in the libraries.

llvm-svn: 364370

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

llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)

Summary: The convenience wrapper in STLExtras is available since rL342102.

Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb

Subscr

llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)

Summary: The convenience wrapper in STLExtras is available since rL342102.

Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb

Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits

Differential Revision: https://reviews.llvm.org/D52573

llvm-svn: 343163

show more ...

Initialize the address-significance table fragment's layout order.

This fragment is created after layout, which is where the order
normally gets set.

Should fix a test failure under msan.

llvm-svn

Initialize the address-significance table fragment's layout order.

This fragment is created after layout, which is where the order
normally gets set.

Should fix a test failure under msan.

llvm-svn: 340516

show more ...

MC: Don't align COFF section contents.

Aligning section contents is not required, but only
recommended, by the specification. Microsoft's documentation says
(https://docs.microsoft.com/en-us/windows

MC: Don't align COFF section contents.

Aligning section contents is not required, but only
recommended, by the specification. Microsoft's documentation says
(https://docs.microsoft.com/en-us/windows/desktop/debug/pe-format#section-table-section-headers):
"For object files, the value should be aligned on a 4-byte boundary
for best performance."

However, according to my measurements, aligning section contents has
a neutral to negative effect on performance.

I measured the median run time of 100 links of Chromium's
base_unittests on Linux with lld-link and on Windows with link.exe with
both aligned and unaligned sections. On Linux I didn't see a measurable
performance difference, and on Windows the link was slightly faster
with unaligned sections (presumably because on Windows the bottleneck
is I/O).

Also, the sections created by cl.exe are unaligned, so we should expect
tools to broadly accept unaligned sections.

Differential Revision: https://reviews.llvm.org/D51149

llvm-svn: 340514

show more ...