This is an archive of the discontinued LLVM Phabricator instance.

[gcov] Set nounwind and respect module flags metadata "frame-pointer" & "uwtable" for synthesized functions
ClosedPublic

Authored by MaskRay on Apr 22 2021, 8:35 PM.

Details

Summary

This applies the D100251 mechanism to the gcov instrumentation pass.

With this patch, -fno-omit-frame-pointer in
clang -fprofile-arcs -O1 -fno-omit-frame-pointer will be respected for synthesized
__llvm_gcov_writeout,__llvm_gcov_reset,__llvm_gcov_init functions: the frame pointer
will be kept (note: on many targets -O1 eliminates the frame pointer by default).

clang -fno-exceptions -fno-asynchronous-unwind-tables -g -fprofile-arcs will
produce .debug_frame instead of .eh_frame.

Fix: https://github.com/ClangBuiltLinux/linux/issues/955

Diff Detail

Event Timeline

MaskRay created this revision.Apr 22 2021, 8:35 PM
MaskRay requested review of this revision.Apr 22 2021, 8:35 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 22 2021, 8:35 PM
MaskRay edited the summary of this revision. (Show Details)Apr 22 2021, 8:38 PM
MaskRay added inline comments.
llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp
1048

I think not all three functions need noinline, so I do not place noinline in the common function.

@void Do you know why noredzone is needed? Many other instrumentation passes don't set this attribute.

nickdesaulniers accepted this revision.Apr 23 2021, 10:32 AM

Thanks @MaskRay !

llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp
1048

With KCOV (not GCOV) and LTO, we can and sometimes do inline the coverage runtime helper functions, FWIW.

This revision is now accepted and ready to land.Apr 23 2021, 10:32 AM
void added inline comments.Apr 23 2021, 2:14 PM
llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp
1048

It's been 8 years... Here's the commit where I added it

commit 74f334e476a62d0ddcd4751d266560a503e00d55
Author: Bill Wendling <isanbard@gmail.com>
Date:   Mon Dec 10 19:46:49 2012 +0000

    Don't use a red zone for code coverage if the user specified `-mno-red-zone'.

    The `-mno-red-zone' flag wasn't being propagated to the functions that code
    coverage generates. This allowed some of them to use the red zone when that
    wasn't allowed.
    <rdar://problem/12843084>

    llvm-svn: 169754
MaskRay updated this revision to Diff 340375.Apr 25 2021, 11:34 AM

Move NoRedZone to the common function