IIUC, llvm/llvm-project@7b604cd affects which FDE is selected, but doesn't affect which range within the FDE is selected. Like, there are two separate mechanisms for decrementing pc in non-top/non-signal frames: (1) the --pc in setInfoBasedOnIPRegister(), which is used for finding an FDE, (2) the "off-by-one" codeOffset < pcoffset in parseFDEInstructions(), which is used for finding a range withing an FDE.

EDIT: Not quite: parseFDEInstructions() is called both from setInfoBasedOnIPRegister() (with adjusted pc) and from DwarfInstructions<A, R>::stepWithDwarf() (with unadjusted pc). I'm not sure what determines which one happens; when debugging on ARM, I saw the call from stepWithDwarf(). The call from setInfoBasedOnIPRegister() seems off-by-one independent of any of these fixes: it uses decremented pc, but parseFDEInstructions() seems to expect non-decremented pc, as comment in https://github.com/ClickHouse/libunwind/pull/30/files explains.

EDIT2: If I were to fix it, I'd do:

• Make parseFDEInstructions() take decremented pc (codeOffset <= pcoffset), matching DWARF Spec section 6.4.3 "Call Frame Instruction Usage".
• Do the pc adjustment in only one place, probably in setInfoBasedOnIPRegister(). Probably save the adjusted value in the cursor, next to _isSignalFrame (and maybe _isSignalFrame is not used for anything else and can be removed). Use the adjusted pc in stepWithDwarf().
• The difficult part: research aaalllll the other unwinding methods and platforms (compact, SEH, TBTAB, EHABI, whatever any of those words mean, PPC, MIPS, SPARK, RISKV, etc) to see which of them need this adjustment. Or gate all changes to only affect DWARF. Or something in the middle.