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.
These specify that the value of the given register in the previous frame
is the CFA plus some offset. This isn't very common but can be necessary
if the original value is normally reconstructed from the stack/frame
pointer instead of being saved on the stack and reloaded from there.
#98060 introduced a warning for unterminated string constants, however
it was only checking for `\n` which means that it produced strange
results on Windows (always blaming column 1) including having the
[associated test
fail](https://buildkite.com/llvm-project/github-pull-requests/builds/111277#0192a122-c5c9-4e4e-bc5b-7532fec99ae4)
if Git happened to use Windows newlines when creating the file.
This fix for this is to detect both `\r` and `\n`, but don't double-warn
for Windows newlines.
It is almost always simpler to use {} instead of std::nullopt to
initialize an empty ArrayRef. This patch changes all occurrences I could
find in LLVM itself. In future the ArrayRef(std::nullopt_t) constructor
could be deprecated or removed.
The quotes should be stripped.
Improve the test to check all of Identifier, Integer, and String.
GNU assembler also supports `.irpc c,"" a` but there is no real world
use case. So don't implement it.
As reported in https://llvm.org/PR30955, `.balign` with a fill-value of 0 did
not actually align using zeroes, on non-x86 targets.
This is because the check of whether to use the code alignment routines
or whether to just use the fill value was checking whether the fill
value was equal to `TextAlignFillValue`, which has not been changed from
its default of 0 on most targets (it has been changed for x86). However,
most targets do not set the fill value because it doesn't entirely make
sense -- i.e. on AArch64 there's no reasonable byte value to use for
alignment, as instructions are word-sized and have to be well-aligned.
I think the check at the end `AsmParser::parseDirectiveAlign` is
suspicious even on x86 - if you use `.balign <align>, 0x90` in a code
section, you don't end up with a block of `0x90` repeated, you end up
with a block of NOPs of various widths. This functionality is never
tested.
The fix here is to modify the check to ignore the default text align
fill value when choosing to do code alignment or not.
Fixes#30303
In the .altmacro mode, an argument can be expanded even if not preceded
by \. This behavior is not enabled for Darwin, which uses $
(`isIdentifierChar('$')` is true) for macro expansion.
This is f8b1ca4992a22b4b65282c09dd6f07a1a2839070 with a fix.
This reverts commit f8b1ca4992a22b4b65282c09dd6f07a1a2839070.
It incorrectly replaces `t` in `blt` to `h`.
```
.altmacro
.macro gen t
blt 2f
2:
.endm
gen h
```
Fix#98558
GNU assembler 2.26 introduced the .cfi_label directive. It does not
expand to any CFI instructions, but defines a label in
.eh_frame/.debug_frame, which can be used by runtime patching code to
locate the FDE. .cfi_label is not allowed for CIE's initial
instructions, and can therefore be used to force the next instruction to
be placed in a FDE instead of a CIE.
In glibc since 2018, sysdeps/riscv/start.S utilizes .cfi_label to force
DW_CFA_undefined to be placed in a FDE. arc/csky/loongarch ports have
copied this use.
```
.cfi_startproc
// DW_CFA_undefined is allowed for CIE's initial instructions.
// Without .cfi_label, gas would place DW_CFA_undefined in a CIE.
.cfi_label .Ldummy
.cfi_undefined ra
.cfi_endproc
```
No CFI instruction is associated with .cfi_label, so the `case
MCCFIInstruction::OpLabel:` code in BOLT is unreachable and onlt to make
-Wswitch happy.
Close#97222
Pull Request: https://github.com/llvm/llvm-project/pull/97922
Since `raw_string_ostream` doesn't own the string buffer, it is
desirable (in terms of memory safety) for users to directly reference
the string buffer rather than use `raw_string_ostream::str()`.
Work towards TODO comment to remove `raw_string_ostream::str()`.
Previously, a symbol insertion requires (at least) three hash table
operations:
- Lookup/create entry in Symbols (main symbol table)
- Lookup NextUniqueID to deduplicate identical temporary labels
- Add entry to UsedNames, which is also used to serve as storage for the
symbol name in the MCSymbol.
All three lookups are done with the same name, so combining these into a
single table reduces the number of lookups to one. Thus, a pointer to a
symbol table entry can be passed to createSymbol to avoid a duplicate
lookup of the same name.
The new symbol table entry value is placed in a separate header to avoid
including MCContext in MCSymbol or vice versa.
Amend 7c956293d856224dd6a1b633820ef53009f7ef1c ("MCAsmParser: Support
\+") to increase Macro.Count per iteration to match the new gas feature
(milestone: 2.43).
```
.irp foo,1
nop
.endr
nop
```
expands to an excess EOL between two nop lines. Other loop directives
and .macro have the same issue.
`Lex()` at "Jump to the macro instantiation and prime the lexer"
requires that there is one single \n token in CurTok. Therefore, we
cannot consume the trailing \n when parsing the macro(-like) body.
(commit c6e787f771d1f9d6a846b2d9b8db6adcd87e8dba (reverted by
1e5f29af81a5f6fda308074f6345b9fba4faa71c))
Instead, skip the potential \n after jumpToLoc at handleMacroExit.
This reverts commit c6e787f771d1f9d6a846b2d9b8db6adcd87e8dba.
parseEOL() would remove \n # after .endr, not recognizing the line marker.
```
// reduced from Linux kernel arch/x86/crypto/sha1_avx2_x86_64_asm.S
.rept 1
nop
.endr
# 512 "a.s"
```
In .macro, \+ expands to the per-macro invocation count.
https://sourceware.org/pipermail/binutils/2024-May/134009.html
\+ counts from 0 for .irp/.irpc/.rept .
Note: We currently prints \q for `.print "\q"` while gas doesn't. This
patch does not change this behavior.
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator==/!= outnumber StringRef::equals by a factor of
70 under llvm/ in terms of their usage.
- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.
- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".
A symbol with an `N_ALT_ENTRY` attribute may be defined in the middle of
a subsection, so it is reasonable to opt them out of the
`.cfi_{start,end}proc` nesting check.
Fixes: https://github.com/llvm/llvm-project/issues/82261
Linux kernel fs/binfmt_elf_fdpic.c supports FDPIC for MMU-less systems.
GCC/binutils/qemu support FDPIC ABI for ARM
(https://github.com/mickael-guene/fdpic_doc).
_ARM FDPIC Toolchain and ABI_ provides a summary.
This patch implements FDPIC relocations to the integrated assembler.
There are 6 static relocations and 2 dynamic relocations, with
R_ARM_FUNCDESC as both static and dynamic.
gas requires `--fdpic` to assemble data relocations like `.word f(FUNCDESC)`.
This patch adds `MCTargetOptions::FDPIC` and reports an error if FDPIC
is not set.
Pull Request: https://github.com/llvm/llvm-project/pull/82187
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.
This showed up when simplifying some large testcase, where the cfi directives
became out of sync with the proc's they enclose.
Now restricted to platforms that support .subsections_via_symbols.
This reverts commit 797b68c0ba699994e1038ac33d3083541482bf19.
Fixes: #72802
Differential revision: https://reviews.llvm.org/D153167
rdar://111459507
This reverts commit 4323da926f12672daec7f59384bd153a7cf28674.
This broke building libffi for ARM on Windows (and probably Darwin),
where one extern function intentionally falls through to another
one, while sharing one CFI region.
As long as one isn't using .subsections_via_symbols on MachO,
this probably shouldn't be a hard error.
Secondly, the tested pattern only produces an error on MachO and
COFF targets, but not for ELF, making the error case even more
inconsistent.
Reverting this commit for now, to figure out the best way forward.
This showed up when simplifying some large testcase, where the cfi directives
became out of sync with the proc's they enclose.
rdar://111459507
Differential revision: https://reviews.llvm.org/D155245
This reverts commit 4172fcc1ebbe0a7b699bfcbdaae9d5f688b62b09.
This showed up when simplifying some large testcase, where the cfi directives
became out of sync with the proc's they enclose.
rdar://111459507
Differential revision: https://reviews.llvm.org/D155245
This reverts commit 4172fcc1ebbe0a7b699bfcbdaae9d5f688b62b09.
This showed up when simplifying some large testcase, where the cfi directives
became out of sync with the proc's they enclose.
rdar://111459507
Differential revision: https://reviews.llvm.org/D155245
This patch warns when an align directive with a non-zero fill value is
used in a virtual section. The fill value is also set to zero,
preventing an assertion in `MCAssembler::writeSectionData` for the case
of `MCFragment::FT_Align` from tripping.
