labath wrote:
So, it took some effort, but I managed to reproduce the problem and figure out
what's going on. You can find my analysis on
https://github.com/llvm/llvm-project/pull/92503
https://github.com/llvm/llvm-project/pull/91321
___
labath wrote:
> Ah, so the problem here is that we're missing the eh_frame instructions for
> _sigtramp on arm64 with macOS 14. `signal_generating_add` is a frameless
> function (a great stress test in this instance), and _sigtramp is called with
> enough of a faked-up stack that a stack walk
labath wrote:
> > > LLDB became unresponsive on windows when a `thread backtrace` command was
> > > issued after hitting the exception i have temporarily reverted the change
> > > to make buildbot green.
> >
> >
> > Could you please give me some more information about the problem? I don't
>
jasonmolenda wrote:
(and it turns out the reason we don't have eh_frame is because _sigtramp on
arm64 is written in C, and I'm not sure how I'm going to track which
callee-saved register the argument is copied into, so this is definitely not
something I can get fixed quickly.)
omjavaid wrote:
> > LLDB became unresponsive on windows when a `thread backtrace` command was
> > issued after hitting the exception i have temporarily reverted the change
> > to make buildbot green.
>
> Could you please give me some more information about the problem? I don't
> have access
jasonmolenda wrote:
Ah, so the problem here is that we're missing the eh_frame instructions for
_sigtramp on arm64 with macOS 14. `signal_generating_add` is a frameless
function (a great stress test in this instance), and _sigtramp is called with
enough of a faked-up stack that a stack walk
jasonmolenda wrote:
> It's not completely correct -- the frame for `signal_generating_add` is
> missing. That's what the error message is complaining about.
Ah, thanks, I missed that! Let me debug it and comment further
https://github.com/llvm/llvm-project/pull/91321
labath wrote:
> LLDB became unresponsive on windows when a `thread backtrace` command was
> issued after hitting the exception i have temporarily reverted the change to
> make buildbot green.
Could you please give me some more information about the problem? I don't have
access to a windows
omjavaid wrote:
LLDB became unresponsive on windows when a `thread backtrace` command was
issued after hitting the exception
i have temporarily reverted the change to make buildbot green.
https://github.com/llvm/llvm-project/pull/91321
___
labath wrote:
> Ah, I misunderstood what the nature of the failure was. I tried running the
> shell test, and it's failing for different reasons. I almost never touch
> shell tests, I find them really hard to debug so I'm not sure what the
> problem is. If I run it by hand,
>
> ```
> (lldb)
omjavaid wrote:
@labath this seems to have broken lldb-aarch64-windows bot with
TestInterruptBacktrace.py failing on
num_frames = thread.GetNumFrames()
https://github.com/llvm/llvm-project/pull/91321
___
lldb-commits mailing list
jasonmolenda wrote:
maybe the shell test is building without debug info, I am surprised to see
assembly there. If I build it like that and run it by hand,
```
(lldb) settings set platform.plugin.darwin.ignored-exceptions
EXC_BAD_INSTRUCTION
(lldb) b sigill_handler
Breakpoint 1: where =
jasonmolenda wrote:
Ah, I misunderstood what the nature of the failure was. I tried running the
shell test, and it's failing for different reasons. I almost never touch shell
tests, I find them really hard to debug so I'm not sure what the problem is.
If I run it by hand,
```
(lldb)
jasonmolenda wrote:
> I have fixed/worked around the mach exception issue in a [followup
> commit](https://github.com/llvm/llvm-project/commit/b903badd73a2467fdd4e363231f2bf9b0704b546)
> with a `settings set platform.plugin.darwin.ignored-exceptions
> EXC_BAD_INSTRUCTION`. Now the process
labath wrote:
I have fixed/worked around the mach exception issue in a [followup
commit](https://github.com/llvm/llvm-project/commit/b903badd73a2467fdd4e363231f2bf9b0704b546)
with a `settings set platform.plugin.darwin.ignored-exceptions
EXC_BAD_INSTRUCTION`. Now the process gets a SIGILL as
jasonmolenda wrote:
Ah, so the problem is,
```
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION
(code=1, subcode=0xdead)
* frame #0: 0x00013f2c b.out`signal_generating_add + 4 at
signal-in-leaf-function-aarch64.c:5
frame #1:
jasonmolenda wrote:
Will debug this today.
https://github.com/llvm/llvm-project/pull/91321
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
adrian-prantl wrote:
I think that would be a good start. Also tagging @jasonmolenda for advice.
https://github.com/llvm/llvm-project/pull/91321
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
labath wrote:
> This looks good to me, I know there are other codepaths that handle this
> correctly, where we can backtrace out of a frameless function that faults
> into a trap handler and we have the entire register state available in the
> trap handler.
>
> Looking at this, I'm a little
https://github.com/labath closed https://github.com/llvm/llvm-project/pull/91321
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg commented:
LGTM.
https://github.com/llvm/llvm-project/pull/91321
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda approved this pull request.
This looks good to me, I know there are other codepaths that handle this
correctly, where we can backtrace out of a frameless function that faults into
a trap handler and we have the entire register state available in the trap
@@ -1555,12 +1555,12 @@ RegisterContextUnwind::SavedLocationForRegister(
}
if (unwindplan_regloc.IsSame()) {
-if (!IsFrameZero() &&
+if (!m_all_registers_available &&
(regnum.GetAsKind(eRegisterKindGeneric) == LLDB_REGNUM_GENERIC_PC ||
@@ -467,7 +465,7 @@ size_t UnwindAssemblyInstEmulation::WriteMemory(
m_pushed_regs[reg_num] = addr;
const int32_t offset = addr - m_initial_sp;
m_curr_row->SetRegisterLocationToAtCFAPlusOffset(reg_num, offset,
-
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
A leaf function may not store the link register to stack, but we it can still
end up being a non-zero frame if it gets interrupted by a signal. Currently, we
were unable to unwind past this function because
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/91321
A leaf function may not store the link register to stack, but we it can still
end up being a non-zero frame if it gets interrupted by a signal. Currently, we
were unable to unwind past this function because we
26 matches
Mail list logo
