[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