[PATCH] D133376: Allow epilogue_begin to be emitted when generating DWARF
Ariel Burton via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Sep 6 15:31:47 PDT 2022
Ariel-Burton added a comment.
In D133376#3773083 <https://reviews.llvm.org/D133376#3773083>, @MatzeB wrote:
> What is this epilogue information going to be used for?
>
> Generally I find the notion of "epilogue" a bit sketchy, since you can easily imagine the scheduler mixing CSR restore instructions (and whatever else you consider epilogue) with normal computation so you'll have epilogue and non-epilogue code mixed together so a notion of "epilogue starts here" doesn't really mean much...
As per the DWARF standard, it is intended to identify a location at which am exit breakpoint may be placed before the return.
One use case is for "run-to-end-of-funciton" (which some (e.g., z/OS), but not all debuggers support), instead of the gdb "finish"-like semantics, which will run to just after the current function returns (i.e., it will return to the caller).
I hear that the notion of epilogue might be a bit sketchy with some architectures, or optimization settings. I don't think that matters. Supporting epilogue_begin isn't mandatory, and from what I see in the sources, FrameDestory is not used on all platforms. On those platforms epilogue_begin will not be emitted at all. This change will not affect existing tools which ignore epilogue_begin for the reasons you give, or indeed, any other reasons. But it is useful for tools which do care, and on platforms where the epilogue is identifiable.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D133376/new/
https://reviews.llvm.org/D133376
More information about the llvm-commits
mailing list