summaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface
diff options
context:
space:
mode:
authorSam Elliott <quic_aelliott@quicinc.com>2024-07-24 18:24:39 +0100
committerGitHub <noreply@github.com>2024-07-24 18:24:39 +0100
commitea222be0d9266d9d5c100496f8c9606f213454ee (patch)
tree8bc805cbc40f37115b40642b4ec01b813566590d /lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface
parentbb0300cf7ce54bfbb1607348c89cb0525e12076b (diff)
[MC] Honour alignment directive fill value for non-intel (#100136)
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
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface')
0 files changed, 0 insertions, 0 deletions