[WebAssembly] Allocate MCSymbolWasm data on MCContext (#85866)

Fixes #85578, a use-after-free caused by some `MCSymbolWasm` data being
freed too early.

Previously, `WebAssemblyAsmParser` owned t

[WebAssembly] Allocate MCSymbolWasm data on MCContext (#85866)

Fixes #85578, a use-after-free caused by some `MCSymbolWasm` data being
freed too early.

Previously, `WebAssemblyAsmParser` owned the data that is moved to
`MCContext` by this PR, which caused problems when handling module ASM,
because the ASM parser was destroyed after parsing the module ASM, but
the symbols persisted.

The added test passes locally with an LLVM build with AddressSanitizer
enabled.

Implementation notes:

* I've called the added method
<code>allocate<b><i>Generic</i></b>String</code> and added the second
paragraph of its documentation to maybe guide people a bit on when to
use this method (based on my (limited) understanding of the `MCContext`
class). We could also just call it `allocateString` and remove that
second paragraph.
* The added `createWasmSignature` method does not support taking the
return and parameter types as arguments: Specifying them afterwards is
barely any longer and prevents them from being accidentally specified in
the wrong order.
* This removes a _"TODO: Do the uniquing of Signatures here instead of
ObjectFileWriter?"_ since the field it's attached to is also removed.
Let me know if you think that TODO should be preserved somewhere.

show more ...

[llvm] Use StringRef::starts_with (NFC)

[SystemZ][z/OS] Add exception handling for XPLINK (#74638)

Adds emitting the exception table and the EH registers for XPLINK.

---------

Co-authored-by: Yusra Syeda <yusra.syeda@ibm.com>

[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::

[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

[llvm] Stop including llvm/ADT/DenseMapInfo.h (NFC)

Identified with clangd.

[MC] Restore default section classification to SectionKind::getReadOnly()

D133456 changed the default `Kind = SectionKind::getReadOnly();` to
`SectionKind::getText()` to work around a longstanding i

[MC] Restore default section classification to SectionKind::getReadOnly()

D133456 changed the default `Kind = SectionKind::getReadOnly();` to
`SectionKind::getText()` to work around a longstanding issue in producing
R_RISCV_{ADD,SUB}* relocations.

D155357 properly fixed the issue and the workaround is no longer needed.
getReadonly() actually matches BFD better as BFD doesn't set SEC_CODE to
a not-well-known section.

To the best of my knowledge, this change is un-testable after D155357
removed a `getKind().isText()` use.

show more ...

[XRay] Make xray_fn_idx entries PC-relative

As mentioned by commit c5d38924dc6688c15b3fa133abeb3626e8f0767c (Apr 2020),
PC-relative entries avoid dynamic relocations and can therefore make the
secti

[XRay] Make xray_fn_idx entries PC-relative

As mentioned by commit c5d38924dc6688c15b3fa133abeb3626e8f0767c (Apr 2020),
PC-relative entries avoid dynamic relocations and can therefore make the
section read-only.

This is similar to D78082 and D78590. We cannot commit to support
compiler/runtime built at different versions, so just don't play with versions.

For Mach-O support (incomplete yet), we use non-temporary `lxray_fn_idx[0-9]+`
symbols. Label differences are represented as a pair of UNSIGNED and SUBTRACTOR
relocations. The SUBTRACTOR external relocation requires r_extern==1 (needs to
reference a symbol table entry) which can be satisfied by `lxray_fn_idx[0-9]+`.
A `lxray_fn_idx[0-9]+` symbol also serves as the atom for this dead-strippable
section (follow-up to commit b9a134aa629de23a1dcf4be32e946e4e308fc64d).

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

show more ...

Reland "D144999 [MC][MachO]Only emits compact-unwind format for "canonical" personality symbols. For the rest, use DWARFs."

Reasons for rolling forward:
- the crash reported from Chromium was fi

Reland "D144999 [MC][MachO]Only emits compact-unwind format for "canonical" personality symbols. For the rest, use DWARFs."

Reasons for rolling forward:
- the crash reported from Chromium was fixed in D151824 (not related to this patch at all)
- since D152824 was committed, it should now be safe to roll this forward.

New change:
- add an additional _ in name check

This reverts commit 4980eead4d0b4666d53dad07afb091375b3a13a0.

show more ...

[Triple] Add triple for UEFI

Target triple to support "x86_64-unknown-uefi"

Reviewed By: phosek

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

[Coverity] Constant variable guards dead code.

Revert "[RFC][MC][MachO]Only emits compact-unwind format for "canonical" personality symbols. For the rest, use DWARFs."

This reverts commit 09aaf53a05e3786eea374f3ce57574225036412d.
Causes toolchai

Revert "[RFC][MC][MachO]Only emits compact-unwind format for "canonical" personality symbols. For the rest, use DWARFs."

This reverts commit 09aaf53a05e3786eea374f3ce57574225036412d.
Causes toolchain asserts building libc++ for x86_64,
see https://reviews.llvm.org/D144999#4356215

show more ...

[RFC][MC][MachO]Only emits compact-unwind format for "canonical" personality symbols. For the rest, use DWARFs.

Details: https://github.com/rust-lang/rust/issues/102754

The MachO format uses 2 bits

[RFC][MC][MachO]Only emits compact-unwind format for "canonical" personality symbols. For the rest, use DWARFs.

Details: https://github.com/rust-lang/rust/issues/102754

The MachO format uses 2 bits to encode these personality funtions, with 0 reserved for "no-personality".
This means we can only have up to 3 personality. There are already three popular personalities: __gxx_personality_v0, __gcc_personality_v0, and __objc_personality_v0.
As a result, any system that needs custom-personality will run into a problem.

This patch implemented jyknight's proposal to simply force DWARFs for all non-canonical personality functions.

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

show more ...

-fdebug-prefix-map=: make the last win when multiple prefixes match

For
`clang -c -g -fdebug-prefix-map=a/b=y -fdebug-prefix-map=a=x a/b/c.c`,
we apply the longest prefix substitution, but
GCC has a

-fdebug-prefix-map=: make the last win when multiple prefixes match

For
`clang -c -g -fdebug-prefix-map=a/b=y -fdebug-prefix-map=a=x a/b/c.c`,
we apply the longest prefix substitution, but
GCC has always been picking the last applicable option (`a=x`, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591).

I feel that GCC's behavior is reasonable given the convention that the last
value wins for the same option.

Before D49466, Clang appeared to apply the shortest prefix substitution,
which likely made the least sense.

Reviewed By: #debug-info, scott.linder

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

show more ...

[MCContext] Use `const Twine &` in symbol creation methods. NFC

All of these methods will invoke `getOrCreateSymbol(const Twine &Name)`, using `Twine` here makes these methods more flexible.

Differ

[MCContext] Use `const Twine &` in symbol creation methods. NFC

All of these methods will invoke `getOrCreateSymbol(const Twine &Name)`, using `Twine` here makes these methods more flexible.

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

show more ...

MC: Add .data. and .rodata. prefixes to MCContext section classification

Commit 463da422f019 ("MC: make section classification a bit more
thorough") changed MCContext::getELFSection section classifi

MC: Add .data. and .rodata. prefixes to MCContext section classification

Commit 463da422f019 ("MC: make section classification a bit more
thorough") changed MCContext::getELFSection section classification logic
to default to SectionKind::getText (previously default was
SectionKind::getReadOnly) and added some matching based on section name
to determine internal section classification.

The BPF runtime implements global variables using 'BPF map'
datastructures, specifically the arraymap BPF map type. Global variables
in a section are placed in a single arraymap value at predictable byte
offsets. Variables in different sections are placed in separate
arraymaps, so in this example:

#define SEC(name) __attribute__((section(name)))
SEC(".data.A") u32 one;
SEC(".data.A") u32 two;
SEC(".data.B") u32 three;
SEC(".data.B") u32 four;

variables one and two would correspond to some byte offsets (probably 0
and 4) in one arraymap, while three and four would be in a separate
arraymap. Variables of a bpf_spin_lock type are considered to protect
next-generation BPF datastructure types in the same arraymap value and
there can only be a single bpf_spin_lock variable per arraymap value -
and thus per section.

As a result it's necessary to keep bpf_spin_locks and the datastructures
they guard in separate data sections. Before the aforementioned commit,
a section whose name starts with ".data." - like ".data.A" - would be
classified as SectionKind::getReadOnly, whereas after it is
SectionKind::getText. If 4-byte padding is required in such a section due to
alignment of some symbol within it, classification of the section as
SectionKind::getText will result in compilation of those variables to
BPF backend failing with an error like "unable to write nop sequence of
4 bytes". This is due to nop instruction emitted in
BPFAsmBackend::writeNopData being 8 bytes, so the function fails since
it cannot emit a 4-byte nop instruction.

Let's follow the pattern of matching section names starting with ".bss."
and ".tbss." prefixes resulting in proper classification of the section
as data by adding similar matches for ".data." and ".rodata." prefixes.
This will bring padding behavior for these sections back to what it was
before that commit and fix the crash.

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

show more ...

std::optional::value => operator*/operator->

value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_E

std::optional::value => operator*/operator->

value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see
_LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS).

This commit fixes LLVMAnalysis and its dependencies.

show more ...

Remove unused #include "llvm/ADT/Optional.h"

[MC] llvm::Optional => std::optional

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

DebugInfoMetadata: convert Optional to std::optional

[llvm] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of ma

[llvm] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[XCOFF] set fragment for XMC_PR csects.

Summary: -xcoff-traceback-table is a default option on AIX regardless of optimization and debug levels. An error of relocation for paired relocatable term is

[XCOFF] set fragment for XMC_PR csects.

Summary: -xcoff-traceback-table is a default option on AIX regardless of optimization and debug levels. An error of relocation for paired relocatable term is not yet supported in XCOFFObjectWriter::recordRelocation occurred when both of the -xcoff-traceback-table and -function-sections are enabled.
The root cause is that we missed to calculate the symbols difference as absolute value before adding fixups when symbol_A without the fragment set is the csect itself and symbol_B is in it.
This patch only sets the fragment for XMC_PR csects because we don't have other cases that hit this problem yet.

Reviewed By: DiggerLin, hubert.reinterpretcast

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

show more ...

Move getenv for AS_SECURE_LOG_FILE to clang

Avoid calling getenv in the MC layer and let the clang driver do it so
that it is reflected in the command-line as an -mllvm option.

rdar://101558354

Di

Move getenv for AS_SECURE_LOG_FILE to clang

Avoid calling getenv in the MC layer and let the clang driver do it so
that it is reflected in the command-line as an -mllvm option.

rdar://101558354

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

show more ...

MC: make section classification a bit more thorough

This does *NOT* change the emitted section flags in any way. This only
impacts the internal classification of sections.

Extend the section class

MC: make section classification a bit more thorough

This does *NOT* change the emitted section flags in any way. This only
impacts the internal classification of sections.

Extend the section classification in LLVM for ELF targets. This has one
important change: we now classify sections as text by default rather
than readonly. This matches the behaviour for GAS better.

Ensure that any section that has a writable attribute set is not treated
as readonly. We also special case any section named `.debug_` which is
reserved for DWARF as metadata. In the case none of the attributes are
set (or because no attributes were provided), consult the section name
for classification. We match the well known names and classify the
section accordingly. Any remaining section is now classified as text.

This change allows us to classify sections in the MC layer more
precisely which is needed for subsequent changes for handling target
specific behaviour.

Re-apply the change that was reverted with additional changes to
classify section prefixes appropriately and differentiate the TLS
sections, addressing the FIXME and post-commit review comments by
@MaskRay.

Differential Revision: https://reviews.llvm.org/D133456
Reviewed By: @MaskRay

show more ...

Revert "MC: make section classification a bit more thorough"

This reverts commit 73a9dfcee24df959b59a46d75dcbdc0bcfb50fe6.

We started to hit assertions when compiling & assembling separately.
See c

Revert "MC: make section classification a bit more thorough"

This reverts commit 73a9dfcee24df959b59a46d75dcbdc0bcfb50fe6.

We started to hit assertions when compiling & assembling separately.
See comments in https://reviews.llvm.org/D131270

show more ...

MC: make section classification a bit more thorough

This does *NOT* change the emitted section flags in any way. This only
impacts the internal classification of sections.

Extend the section class

MC: make section classification a bit more thorough

This does *NOT* change the emitted section flags in any way. This only
impacts the internal classification of sections.

Extend the section classification in LLVM for ELF targets. This has one
important change: we now classify sections as text by default rather
than readonly. This matches the behaviour for GAS better.

Ensure that any section that has a writable attribute set is not treated
as readonly. We also special case any section named `.debug_` which is
reserved for DWARF as metadata. In the case none of the attributes are
set (or because no attributes were provided), consult the section name
for classification. We match the well known names and classify the
section accordingly. Any remaining section is now classified as text.

This change allows us to classify sections in the MC layer more
precisely which is needed for subsequent changes for handling target
specific behaviour.

Differential Revision: https://reviews.llvm.org/D131270
Reviewed By: @echristo

show more ...