Repository navigation
Conversation
…tion. This is a sketch only. I'm posting it in case any Windows devs want to play around with the idea. This code has never been compiled on Windows, let alone run. I assume it will not work as-is.
Tested by (with assertions enabled): test/ExecutionEngine/Orc/trivial-return-zero.ll
…AT .pdata$* sections
|
|
Member
|
jank follows upstream LLVM, without its own changes. We need to get this upstreamed or jank will not be able to use it. |
jeaye
pushed a commit
that referenced
this pull request
Sep 1, 2026
`target.process.memory-cache-line-size` is an unbounded `UInt64`, so
`settings set` accepts 0, and `MemoryCache` keeps the value in a
`uint32_t`, so it also accepts any multiple of 2^32, which truncates to
0. Every consumer then takes a remainder by 0.
`Process::ReadCStringFromMemory` divides on the first iteration of its
loop, before it touches inferior memory, so any address reproduces it.
On an x86_64 host that is a `SIGFPE` and lldb dies; on AArch64 `udiv` by
zero yields 0, so `addr % 0` evaluates to `addr` and the subtraction
underflows to a huge chunk size, and the bug hides.
```
$ lldb -b \
-o 'settings set target.process.memory-cache-line-size 0' \
-o 'target create --core linux-x86_64.core'
Floating point exception: 8
```
Under UBSan on any host, with
`lldb/test/API/tools/lldb-dap/coreFile/linux-x86_64.core`:
```
lldb/source/Target/Process.cpp:2388:40: runtime error: division by zero
#0 lldb_private::Process::ReadCStringFromMemory
#2 ProcessElfCore::GetMainExecutableModuleSpec
#3 ProcessElfCore::DoLoadCore
#4 lldb_private::Process::LoadCore
```
The truncating case crashes the same way while `settings show` reports a
value that is not 0, so nothing in the UI hints at the cause:
```
(lldb) settings set target.process.memory-cache-line-size 4294967296
(lldb) settings show target.process.memory-cache-line-size
target.process.memory-cache-line-size (unsigned) = 4294967296
```
The cache uses 0. 4294967297 truncates to 1, so the cache uses a
one-byte line.
Bound the property once instead of at each use, from 1 to `UINT32_MAX`,
the way `Debugger` bounds `term-width` and `term-height`. Rejecting
beats clamping, because `settings show` reads the stored value back and
would otherwise report a number the cache does not use:
```
(lldb) settings set target.process.memory-cache-line-size 4294967296
error: 4294967296 is out of range, valid values must be between 1 and 4294967295.
```
`OptionValueProperties::CreateLocalCopy` deep-copies the option values,
so the bounds also apply to each process's own collection, not just the
global one.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of the LLVM SEH support changes from lhames#5 to the Jank LLVM 22 branch.
Original description follows.
This PR promotes the
WindowsEasyEHPluginto a library level plugin and fixes the prerequisite JITLink COFF bugs needed to make C++ exceptions work end to end through LLJIT on msys2/mingw.The fixes were developed iteratively using jank as the test driver. Each iteration: run jank's test suite, hit a crash or link error, write a minimal lit test that reproduces the failure, diagnose the root cause, implement the fix, confirm the lit test passes, then move on to the next failure.
Tests were written with AI assistance and verified with the fail before/pass after principle. Mentioning for transparency, they could benefit from an expert eye. Feedback welcome. I leave it to you whether you'd like to keep them.
The implementation code includes comments at the API level and inside functions where the reasoning isn't obvious from the code alone.
Changes:
Enable JITLink for COFF x86_64 (
2019be527937) - Previously LLJIT explicitly excluded COFF (UseJITLink = !TT.isOSBinFormatCOFF()), falling back to RTDyld. Test:coff-imagebase-resolution.ll(basic JITLink linking).Resolve
__ImageBasebefore ADDR32NB lowering (8fcef754b66c) -__ImageBasewas left at address 0, so.pdata/.xdataimage-relative offsets were computed as absolute addresses overflowing 32 bits and crashing the unwinder. Test:coff-imagebase-resolution.ll.Add GOT/PLT stubs for external calls (
5bb976340d29) - External DLL calls use 32bit PC relative branches that can't reach targets beyond 2GB. Without stubs, calls to DLL functions (e.g.puts) crash with out of range relocations. Test:coff-plt-stubs.ll.Add ADDR32NB stubs for image relative external references (
f9f8a22050de) -.xdatareferences the personality function via a 32bit image relative offset, but externals in DLLs are too far away. An executable stub near JIT'd code bridges the gap. Test:coff-addr32nb-stubs.ll.Fix COMDAT section-definition symbol registration (
59c2bca9d561) - The first symbol in a COMDAT pair wasn't registered in the graph symbol table, so.pdatarelocations referencing it by index failed with "Could not find symbol at given index." Test:coff-comdat-relocation.ll.Set OverrideObjectFlags for JITLink on COFF (
f226c46abf37) - COFF has no hidden visibility, all externals becomeExported. Without the override, hidden visibility IR symbols (e.g.__lljit_run_atexits) trigger a "Resolving symbol with incorrect flags" assertion. Test:trivial-return-zero.ll(existing test now passes).Add SEHFrameRegistrationPlugin (
8327fd89a8a3) — PromotesWindowsEasyEHPlugininto a library level plugin, wired intosetUpGenericLLVMIRPlatformso all LLJIT users get SEH registration automatically. Test:coff-seh-registration.ll.Add filtered DLLImportDefinitionGenerator (
905aef3d2517) - Only forwards__imp_prefixed symbols. Without the filter, the generator intercepts personality function lookups and creates conflicting null stubs, crashing the unwinder. Test:coff-dllimport-filter.ll.Extend SEHFrameKeepAlivePass for COMDAT
.pdata$*(4198c1650b54) - The pass only matched the exact name.pdata, so COMDAT sections like.pdata$comdat_fnwere dead-stripped and their unwind info lost. Test:coff-comdat-pdata-keepalive.ll.Remove dead
findDefinedSymbolByNamefrom GetImageBaseSymbol (1b574b035c62) -__ImageBaseis always external or absolute, never defined. The scan over all defined symbols was unnecessary dead code. Test:coff-imagebase-lookup-perf.ll.Add end-to-end integration tests (
13c2f438225e) - C++ throw/catch through multiple JIT'd frames (with and without frame pointers), exercising the full SEH pipeline. Tests:throw-catch-mingw-seh.ll,throw-catch-mingw-seh-no-fp.ll.Happy to answer any follow up questions regarding any of the fixes.
Thanks