The isUnset state lacks significance and should be treated as equivalent
to an undefined symbol.
Equated and common symbols seem to have subtle semantic distinctions in
GAS, justifying the use of distinct `SymContents*` values.
TODO: Ensure common symbols have a fragment, so that `isDefined()`
returns true, rejecting `.comm c, 4, 4; .set c, 4`
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
This reverts commit ad36e4284d66c3609ef8675ef02ff1844bc1951d, fixing a
single uninitialized bit (which cannot be detected with Address
Sanitizer).
This PR adds support for the llvm-mc command-line flag "--gsframe" and
adds ".sframe" to the legal values passed ".cfi_section". It plumbs the
option through the cfi handling code a fair amount. Code to support
actual section generation follows in a future PR.
These options match the gnu-assembler's support syntax for sframes, on
both the command line and in assembly files.
First in a series of changes that will allow llvm-mc to produce sframe
.cfi sections. For more information about sframes, see
https://sourceware.org/binutils/docs-2.44/sframe-spec.html
and the llvm-RFC here:
https://discourse.llvm.org/t/rfc-adding-sframe-support-to-llvm/86900
This PR adds support for the llvm-mc command-line flag "--gsframe" and
adds ".sframe" to the legal values passed ".cfi_section". It plumbs the
option through the cfi handling code a fair amount. Code to support
actual section generation follows in a future PR.
These options match the gnu-assembler's support syntax for sframes, on
both the command line and in assembly files.
First in a series of changes that will allow llvm-mc to produce sframe
.cfi sections. For more information about sframes, see
https://sourceware.org/binutils/docs-2.44/sframe-spec.html
and the llvm-RFC here:
https://discourse.llvm.org/t/rfc-adding-sframe-support-to-llvm/86900
* Handle non-zero fill values for `.fill` and `.org` directives.
* Restore the fragment type check
(5ee34ff1e5cc952116f0da943ddaeb1a71db2940 removed a reachable
`llvm_unreachable`) to detect unintended API usage.
Remove virtual functions `getVirtualSectionKind` (added in
https://reviews.llvm.org/D78138) as they are unnecessary in diagnostics.
The a.out object file format has the BSS concept, which has been
inherited by COFF, XCOFF, Mach-O, and ELF object file formats.
Pull Request: https://github.com/llvm/llvm-project/pull/149721
The term BSS (Block Started by Symbol) is a standard, widely recognized
term, available in the a.out object file format and adopted by formats
like COFF, XCOFF, Mach-O (called S_ZEROFILL while `__bss` is also used),
and ELF. To avoid introducing unfamiliar terms, we should use
isBSSSection instead of isVirtualSection.
* Fix `.reloc constant` to mean section_symbol+constant instead of
.+constant . The initial .reloc support from MIPS incorrectly
interpreted the offset.
* Delay the evaluation of the offset expression after
MCAssembler::layout, deleting a lot of code working with MCFragment.
* Delete many FIXME from https://reviews.llvm.org/D79625
* Some lld/ELF/Arch/LoongArch.cpp relaxation tests rely on .reloc .,
R_LARCH_ALIGN generating ALIGN relocations at specific location.
Sort the relocations.
The being-removed PNaCl has a Software Fault Isolation mechanism, which
requires that certain instructions and groups of instructions do not
cross a bundle boundary. When `.bundle_align_mode` is in effect, each
instruction is placed in its own fragment, allowing flexible NOP
padding.
This feature has significantly complicated our refactoring of MCStreamer
and MCFragment, leading to considerable effort spent untangling
it (including flushPendingLabels (75006466296ed4b0f845cbbec4bf77c21de43b40),
MCAssembler iteration improvement, and recent MCFragment refactoring).
* Make MCObjectStreamer::emitInstToData non-virtual and delete
MCELFStreamer::emitInstTodata
* Delete MCELFStreamer::emitValueImpl and emitValueToAlignment
Minor instructions:u decrease for both -O0 -g and -O3 builds
https://llvm-compile-time-tracker.com/compare.php?from=c06d3a7b728293cbc53ff91239d6cd87c0982ffb&to=9b078c7f228bc5b6cdbfe839f751c9407f8aec3e&stat=instructions:u
Pull Request: https://github.com/llvm/llvm-project/pull/148781
* Rename the vague `Value` to `Fill`.
* FillLen is at most 8. Making the field smaller to facilitate encoding
MCAlignFragment as a MCFragment union member.
* Replace an unreachable report_fatal_error with assert.
so that subclasses can provide the appropriate MCAsmInfo to print
MCExpr objects.
At present, llvm/utils/TableGen/AsmMatcherEmitter.cpp constucts a
generic MCAsmInfo.
Many targets define MCTargetExpr subclasses just to encode an expression
with a relocation specifier. Create a generic MCSpecifierExpr to be
inherited instead. Migrate M68k and SPARC as examples.
GNU Assembler supports symbol reassignment via .set, .equ, or =.
However, LLVM's integrated assembler only allows reassignment for
MCConstantExpr cases, as it struggles with scenarios like:
```
.data
.set x, 0
.long x // reference the first instance
x = .-.data
.long x // reference the second instance
.set x,.-.data
.long x // reference the third instance
```
Between two assignments binds, we cannot ensure that a reference binds
to the earlier assignment. We use MCSymbol::IsUsed and other conditions
to reject potentially unsafe reassignments, but certain MCConstantExpr
uses could be unsafe as well.
This patch enables reassignment by cloning the symbol upon reassignment
and updating the symbol table. Existing references to the original
symbol remain unchanged, and the original symbol is excluded from the
emitted symbol table.
The conditions in parseAssignmentExpression are conservative. We should
also report an error when a non-redefiniable variable (e.g. .equiv
followed by .set; .weakref followed by .set).
Make MCAsmStreamer::emitLabel call setOffset to make the behavior
similar to MCObjectStreamer. `isUndefined()` can now be replaced with
`isUnset()`.
Additionally, fix an AMDGPU API user (tested by a few tests including
MC/AMDGPU/hsa-v4.s)
We report cyclic dependency errors for variable symbols and rely on
isSymbolUsedInExpression in parseAssignmentExpression at parse time,
which does not catch all setVariableValue cases (e.g. cyclic .weakref).
Instead, add a bit to MCSymbol and check it when walking the variable
value MCExpr. When a cycle is detected when we have a final layout,
report an error and set the variable to a constant to avoid duplicate
errors.
isSymbolUsedInExpression is considered deprecated, but it is still used
by AMDGPU (#112251).
Commit 8a0453e23abf27433b7539b2da2060d2df9fb39c (2015) added LCurly and
RCurly cases for Hexagon instruction bundles. While gas x86 also adopted
`{` in 2017 for pseudo prefixes (see `tc_symbol_chars`), `{` remains
uncommon among targets. Move `{` and `}` parsing into the newly
introduced `tokenIsStartOfStatement` hook (#137997).
Pull Request: https://github.com/llvm/llvm-project/pull/140101
Currently `MCTargetAsmParser::starIsStartOfStatement` checks for `*` at
the start of the statement. There are other (currently) downstream
back-ends that need the same treatment for other tokens. Instead of
introducing bespoke APIs for each such token, we generalize (and rename)
starIsStartOfStatement as tokenIsStartOfStatement which takes the token
of interest as an argument.
Update the BPF AsmParser (the only upstream consumer today) to use the
new version.
Due to the known limitations of .set reassignment (see
https://sourceware.org/PR288), we use diagnostics to reject patterns
that could lead to errors (ae7ac010594f693fdf7b3ab879e196428d961e75 2009-06)).
This code gets refined multiple times, see:
* 9b4a824217f1fe23f83045afe7521acb791bc2d0 (2010-05) `IsUsedInExpr`
* 46c79ef1132607aead144dfda0f26aa8b065214f (2010-11) renamed `IsUsedInExpr` to `IsUsed`
The related `SetUsed` bit seems unnecessary nowadays.
Following PR #132569 (RISC-V), which added `parseDataExpr` for parsing
expressions in data directives (e.g., `.word`), this PR migrates AArch64
`@plt`, `@gotpcrel`, and `@AUTH` from the `parsePrimaryExpr` workaround
to `parseDataExpr`. The goal is to align with the GNU assembler model,
where relocation specifiers apply to the entire operand rather than
individual terms, reducing complexity-especially evident in `@AUTH`
parsing.
Note: AArch64 ELF lacks an official syntax for data directives
(#132570). A prefix notation might be a preferable future direction.
I recommend `%specifier(expr)`.
AsmParser's `@specifier` parsing is suboptimal, necessitating lexer
workarounds. `@` might appear multiple times in an operand.
We should not use `@` beyond the existing AArch64 Mach-O instruction
operands.
In the test elf-reloc-ptrauth.s, many errors are now reported at parse
time.
Pull Request: https://github.com/llvm/llvm-project/pull/134202
https://reviews.llvm.org/D24047 added `IsAtStartOfStatement` to
MCAsmLexer, while its subclass AsmLexer had a variable of the same name.
The assignment in `UnLex` is unnecessary, which is now removed.
60b403e75cd25a0c76aaaf4e6b176923acf49443 (2019) named the result
`parseStatement` `Parsed`. `HasError` is a clearer name.
Some ELF targets don't use @ for relocation specifiers.
We should not report `error: invalid variant` when @ is used.
Attempt to make expr@specifier parsing less hacky.
clang -fexperimental-relative-c++-abi-vtables might generate `@plt` and
`@gotpcrel` specifiers in data directives. The syntax is not used in
humand-written assembly code, and is not supported by GNU assembler.
Note: the `@plt` in `.word foo@plt` is different from
the legacy `call func@plt` (where `@plt` is simply ignored).
The `@plt` syntax was selected was simply due to a quirk of AsmParser:
the syntax was supported by all targets until I updated it
to be an opt-in feature in a0671758eb6e52a758bd1b096a9b421eec60204c
RISC-V favors the `%specifier(expr)` syntax following MIPS and Sparc,
and we should follow this convention.
This PR adds support for `.word %pltpcrel(foo+offset)` and
`.word %gotpcrel(foo)`, and drops `@plt` and `@gotpcrel`.
* MCValue::SymA can no longer have a SymbolVariant. Add an assert
similar to that of AArch64ELFObjectWriter.cpp before
https://reviews.llvm.org/D81446 (see my analysis at
https://maskray.me/blog/2025-03-16-relocation-generation-in-assemblers
if intrigued)
* `jump foo@plt, x31` now has a different diagnostic.
Pull Request: https://github.com/llvm/llvm-project/pull/132569
The parser function used for the .ifeqs and .ifnes directives was
missing the check for whether we are currently in an ignored block of an
outer conditional directive, causing the block to be evaluated when it
should not, for example:
.if 0
.ifeqs "a", "a"
// Should not be evaluated, but is
nop
.endif
.endif
Follow-up to 14951a5a3120e50084b3c5fb217e2d47992a24d1
* Unify getVariantKindName and getVariantKindForName
* Allow each target to specify the preferred case (albeit ignored in MCParser)
Note: targets that use variant kinds should call MCExpr::print with a
non-null MAI to print variant kinds. operator<< passes a nullptr to
`MCExpr::print`, which should be avoided (e.g. Hexagon; fixed in
commit cf00ac81ac049cddb80aec1d6d88b8fab4f209e8).
A relocation expression might be used in an immediate operand or a
memory offset. https://reviews.llvm.org/D23110 , which intended to
generalize chained relocation operators (%hi(%neg(%gp_rel(x)))),
inappropriated introduced intrusive changes to the generic code. This
patch drops the intrusive changes and significantly simplifies the code.
The new style is similar to pre-D23110 but much cleaner.
Some weird expressions allowed by gas are not supported for simplicity,
e.g. "%lo foo", "(%lo(foo))", "%lo(foo)+1".
"(%lo(foo))", while previously parsed, is not used in practice.
"%lo(foo)+1" and "%lo(2*4)+foo" were previously parsed but would lead to
an error anyway as the expression is not relocatable
(`evaluateSymbolicAdd` does not fold the Add when RefKind are
different).
Add a default argument, which is more readable than existing call sites
and encourages new call sites to omit the argument.
Omit " in ... directive" since this the error message includes the line.
Update root file in DWARF file/line table as soon as we see the first
"#line" directive.
This was moved from "enabledGenDwarfForAssembly", which is called right
before we emit DWARF information. But if the file is empty or contains
expressions that doesn't need DWARF, it is never called, leaving an
original root file and not the file in the "#line" directive.
Add a test checking for this case.
This is reapply of #119229 with the following fix:
"MCContext::setMCLineTableRootFile" has the effect of adding
".debug_line" section to the output, even if DWARF generation is
disabled. Add a check and a test for this case.
Fixes: #119020Fixes: #119229
Update root file in DWARF file/line table as soon as we see the first
"#line" directive.
This was moved from "enabledGenDwarfForAssembly", which is called right
before we emit DWARF information. But if the file is empty or contains
expressions that doesn't need DWARF, it is never called, leaving an
original root file and not the file in the "#line" directive.
Add a test checking for this case.
Fixes: #119020
I was wrong last patch. I viewed the `Visited` set purely as a possible
recursion deterrent where functions calling a callee multiple times are
handled elsewhere. This doesn't consider cases where a function is
called multiple times by different callers still part of the same call
graph. New test shows the aforementioned case.
Reapplies #111004, fixes#115562.
