jasonmolenda wrote:
> The way I see it, this check (at least the part about the RA register(*)) is
> heuristic that's impossible to get always right. Like, I could construct a
> test case using functions with non-standard ABIs where a non-leaf function
> legitimately has a `lr=` rule. Such
labath wrote:
I'm not quite sure what you have in mind, but I can tell you what's been going
through my mind in the context of the `m_all_registers_available` check in
`lldb/source/Target/RegisterContextUnwind.cpp` . The way I see it, this check
(at least the part about the RA register(*)) is
jasonmolenda wrote:
as cool as this idea is, I do worry that it will make the code less readable,
where instead of saying "BehavesLikeFrameZero / HasAllRegisters", we now need
to ask "can the frame below supply register x", I don't know. it's just
something I have running around my head
jasonmolenda wrote:
(with the caveat that a register location of IsSame for a volatile aka
non-callee-spilled register would be treated as "did not have a location")
https://github.com/llvm/llvm-project/pull/92503
___
lldb-commits mailing list
jasonmolenda wrote:
We should be able to work correctly with a trap handler that has full eh_frame
without knowing the function name. And we shouldn't treat a sigtramp missing
eh_frame as having all registers.
https://github.com/llvm/llvm-project/pull/92503
jasonmolenda wrote:
btw @labath I was thinking about "sigtramp routines" and fault / trap /
interrupt handlers in general, and how lldb has this list of function names
that it treats as fault handlers (`target.trap-handler-names`). And in the
unwinder we have the same idea of "the frame
https://github.com/labath closed https://github.com/llvm/llvm-project/pull/92503
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/92503
>From 47858edddfbccf989213d61f3761fcdb04814839 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Fri, 17 May 2024 06:34:08 +
Subject: [PATCH 1/2] Reapply "[lldb/aarch64] Fix unwinding when signal
interrupts
labath wrote:
> Yes, originally lldb's unwinder was recursive for any register propagation
> and it was easy to hit the problem of lldb blowing out its own stack on a
> recursive inferior that had crashed. I changed most of the propagation to a
> loop to solve this (years and years ago) but
https://github.com/jasonmolenda approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/92503
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jasonmolenda wrote:
Yes, originally lldb's unwinder was recursive for any register propagation and
it was easy to hit the problem of lldb blowing out its own stack on a recursive
inferior that had crashed. I changed most of the propagation to a loop to
solve this (years and years ago) but it
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
…unction (#91321)"
This reapplies fd1bd53ba5a06f344698a55578f6a5d79c457e30, which was reverted due
to a test failure on aarch64/windows. The failure was caused by a combination
of several factors:
- clang
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/92503
…unction (#91321)"
This reapplies fd1bd53ba5a06f344698a55578f6a5d79c457e30, which was reverted due
to a test failure on aarch64/windows. The failure was caused by a combination
of several factors:
- clang
13 matches
Mail list logo
