yurydelendik requested peterhuene for a review on PR #2357.
yurydelendik opened PR #2357 from pub-unwindcode
to main
:
Prepares code for #2313
- Make cranelift_codegen::isa::unwind::input public
- Move
UnwindCode
's commonoffset
field out of the structure- Make
MachCompileResult::unwind_info
more generic
yurydelendik updated PR #2357 from pub-unwindcode
to main
:
Prepares code for #2313
- Make cranelift_codegen::isa::unwind::input public
- Move
UnwindCode
's commonoffset
field out of the structure- Make
MachCompileResult::unwind_info
more generic
yurydelendik updated PR #2357 from pub-unwindcode
to main
:
Prepares code for #2313
- Make cranelift_codegen::isa::unwind::input public
- Move
UnwindCode
's commonoffset
field out of the structure- Make
MachCompileResult::unwind_info
more generic
yurydelendik updated PR #2357 from pub-unwindcode
to main
:
Prepares code for #2313
- Make cranelift_codegen::isa::unwind::input public
- Move
UnwindCode
's commonoffset
field out of the structure- Make
MachCompileResult::unwind_info
more generic
yurydelendik updated PR #2357 from pub-unwindcode
to main
:
Prepares code for #2313
- Make cranelift_codegen::isa::unwind::input public
- Move
UnwindCode
's commonoffset
field out of the structure- Make
MachCompileResult::unwind_info
more generic
yurydelendik edited PR #2357 from pub-unwindcode
to main
:
Prepares code for #2313
- Make cranelift_codegen::isa::unwind::input public
- Move
UnwindCode
's commonoffset
field out of the structure- Make
MachCompileResult::unwind_info
more generic- Record initial stack pointer offset (as in CIE)
The changes allows furthe introduction of fastcall logic and support of ARM-like architectures.
yurydelendik updated PR #2357 from pub-unwindcode
to main
:
Prepares code for #2313
- Make cranelift_codegen::isa::unwind::input public
- Move
UnwindCode
's commonoffset
field out of the structure- Make
MachCompileResult::unwind_info
more generic- Record initial stack pointer offset (as in CIE)
The changes allows furthe introduction of fastcall logic and support of ARM-like architectures.
cfallin submitted PR Review.
cfallin submitted PR Review.
cfallin created PR Review Comment:
s/intermidate/intermediate/
cfallin created PR Review Comment:
s/speficied/specified/ (and below)
cfallin created PR Review Comment:
Outdated comment (not just one word-size but configurable)?
cfallin created PR Review Comment:
This is pretty counter-intuitive to me without more context: maybe a comment describing the scheme would help. I think what is going on is: if the call-frame address is already defined in terms of a frame register, then this call overrides that definition (
Cfa
sets both reg and offset); but if no frame register is defined, then this call defines the given register to be the frame register. Is that right?I'm not sure I understand the semantics fully either. "Frame register" implies to me a register that does not move, and elsewhere in this impl, we conditionally adjust offsets based on whether or not we're using a frame register. It seems that whether or not we're using a frame register is determined by how many times we call
set_cfa_reg
(whether odd or even count, I think?), which is confusing to me.
cfallin created PR Review Comment:
Hmm -- long-term, I think it might make more sense to generate the necessary
UnwindCode
sequence directly in prologue/epilogue generation, rather than reverse-engineering the VCode sequence; this feels somewhat fragile (we have to keep in mind this translation if we change the ABI code). Out of scope for this PR, but I wonder if you have any thoughts on that...
bjorn3 submitted PR Review.
bjorn3 created PR Review Comment:
"Reliable and Fast DWARF-Based Stack Unwinding" (https://hal.inria.fr/hal-02297690/document), actually states the how hard it is to keep the unwind info in sync while performing optimizations as one of it's reasons to generate unwind info from the actual assembly.
peterhuene created PR Review Comment:
This is really strange to me as this
rsp
isn't really a frame pointer and if this is only necessary to incur a call toset_cfa_reg
for poppingrbp
in SystemV unwind information generation then I'd prefer it done a different way.
peterhuene created PR Review Comment:
nit: should we keep this a constant?
peterhuene submitted PR Review.
peterhuene created PR Review Comment:
Perhaps a
filter_map
here instead of returning an emptyVec
for the last epilogue?Also, if there's always two elements in the
Vec
, I wonder ifUnwindInfo<Reg>::epilogues_unwind_codes
should beVec<[(CodeOffset, UnwindCode<Reg>); 2]>
to reduce these small allocations?
peterhuene created PR Review Comment:
I'm also having a hard time understanding why this is necessary from what it was previously implemented, namely recording a CFA change for the restore of
rbp
(i.e. inrestore_reg
) rather than having a strange, to me at least, "set frame pointer torsp
" unwind operation with these changes that causes the call toset_cfa_reg
.Yury, is there a semantic difference to the resulting baseline changes?
specifically:
DW_CFA_def_cfa(rsp, 8) DW_CFA_same_value(rbp)
and
DW_CFA_same_value (rbp) DW_CFA_def_cfa(rsp, 8)
peterhuene submitted PR Review.
peterhuene edited PR Review Comment.
peterhuene created PR Review Comment:
The more I think about this, the more I wonder if
UnwindInfo<Reg>::epilogues_unwind_codes
is even necessary rather than letting the unwind format consume the epilogue ranges fromUnwindInfoContext
and handle the remember state / restore state logic (which is DWARF-specific anyway).
peterhuene submitted PR Review.
peterhuene created PR Review Comment:
On an aside: do we have any test cases for
DW_CFA_remember_state
/DW_CFA_restore_state
? A quick grep doesn't show any results.
peterhuene submitted PR Review.
yurydelendik submitted PR Review.
yurydelendik created PR Review Comment:
DW_CFA_def_cfa(rsp, 8)
andDW_CFA_same_value(rbp)
affect different states, so in this case order is not relevant.I'll add
ResetFramePointer
to restore CFA to its default value, as specified as the CIE.
peterhuene submitted PR Review.
peterhuene created PR Review Comment:
A different unwind operation (e.g.
RestoreFramePointer
) I think makes sense to me :+1:
yurydelendik updated PR #2357 from pub-unwindcode
to main
:
Prepares code for #2313
- Make cranelift_codegen::isa::unwind::input public
- Move
UnwindCode
's commonoffset
field out of the structure- Make
MachCompileResult::unwind_info
more generic- Record initial stack pointer offset (as in CIE)
The changes allows furthe introduction of fastcall logic and support of ARM-like architectures.
peterhuene created PR Review Comment:
Per the discussion in the other comment thread, I think this will be resolved with a new
RestoreFramePointer
unwind code.
peterhuene submitted PR Review.
yurydelendik submitted PR Review.
yurydelendik created PR Review Comment:
It is a TODO -- added a comment about that. The test is
test_multi_return_func
at unwind/system.rs
peterhuene edited PR Review Comment.
peterhuene submitted PR Review.
peterhuene created PR Review Comment:
Ah, missed that as I was looking for a file test.
yurydelendik updated PR #2357 from pub-unwindcode
to main
:
Prepares code for #2313
- Make cranelift_codegen::isa::unwind::input public
- Move
UnwindCode
's commonoffset
field out of the structure- Make
MachCompileResult::unwind_info
more generic- Record initial stack pointer offset (as in CIE)
The changes allows furthe introduction of fastcall logic and support of ARM-like architectures.
cfallin submitted PR Review.
cfallin created PR Review Comment:
Interesting; one thing to note is that the prologue generation in our case happens right before code emission, after any optimizations, but point taken that there is a potential for mismatch. I suppose as long as we are careful with any changes to the prologue code that the translation still works (though the tests look quite good here so that gives me confidence).
peterhuene submitted PR Review.
yurydelendik merged PR #2357.
Last updated: Dec 23 2024 at 12:05 UTC