On Wed, Sep 16, 2020 at 1:46 AM Marco Elver <el...@google.com> wrote: > > On Wed, 16 Sep 2020 at 10:30, <pet...@infradead.org> wrote: > > On Tue, Sep 15, 2020 at 08:09:16PM +0200, Marco Elver wrote: > > > On Tue, 15 Sep 2020 at 19:40, Nick Desaulniers <ndesaulni...@google.com> > > > wrote: > > > > On Tue, Sep 15, 2020 at 10:21 AM Borislav Petkov <b...@alien8.de> wrote: > > > > > > > init/calibrate.o: warning: objtool: asan.module_ctor()+0xc: call > > > > > without frame pointer save/setup > > > > > init/calibrate.o: warning: objtool: asan.module_dtor()+0xc: call > > > > > without frame pointer save/setup > > > > > init/version.o: warning: objtool: asan.module_ctor()+0xc: call > > > > > without frame pointer save/setup > > > > > init/version.o: warning: objtool: asan.module_dtor()+0xc: call > > > > > without frame pointer save/setup > > > > > certs/system_keyring.o: warning: objtool: asan.module_ctor()+0xc: > > > > > call without frame pointer save/setup > > > > > certs/system_keyring.o: warning: objtool: asan.module_dtor()+0xc: > > > > > call without frame pointer save/setup > > > > > > This one also appears with Clang 11. This is new I think because we > > > started emitting ASAN ctors for globals redzone initialization. > > > > > > I think we really do not care about precise stack frames in these > > > compiler-generated functions. So, would it be reasonable to make > > > objtool ignore all *san.module_ctor and *san.module_dtor functions (we > > > have them for ASAN, TSAN, MSAN)? > > > > The thing is, if objtool cannot follow, it cannot generate ORC data and > > our unwinder cannot unwind through the instrumentation, and that is a > > fail. > > > > Or am I missing something here? > > They aren't about the actual instrumentation. The warnings are about > module_ctor/module_dtor functions which are compiler-generated, and > these are only called on initialization/destruction (dtors only for > modules I guess). > > E.g. for KASAN it's the calls to __asan_register_globals that are > called from asan.module_ctor. For KCSAN the tsan.module_ctor is > effectively a noop (because __tsan_init() is a noop), so it really > doesn't matter much. > > Is my assumption correct that the only effect would be if something > called by them fails, we just don't see the full stack trace? I think > we can live with that, there are only few central places that deal > with ctors/dtors (do_ctors(), ...?). > > The "real" fix would be to teach the compilers about "frame pointer > save/setup" for generated functions, but I don't think that's > realistic.
So this has come up before, specifically in the context of gcov: https://github.com/ClangBuiltLinux/linux/issues/955. I looked into this a bit, and IIRC, the issue was that compiler generated functions aren't very good about keeping track of whether they should or should not emit framepointer setup/teardown prolog/epilogs. In LLVM's IR, -fno-omit-frame-pointer gets attached to every function as a function level attribute. https://godbolt.org/z/fcn9c6 ("frame-pointer"="all"). There were some recent LLVM patches for BTI (arm64) that made some BTI related command line flags module level attributes, which I thought was interesting; I was wondering last night if -fno-omit-frame-pointer and maybe even the level of stack protector should be? I guess LTO would complicate things; not sure it would be good to merge modules with different attributes; I'm not sure how that's handled today in LLVM. Basically, when the compiler is synthesizing a new function definition, it should check whether a frame pointer should be emitted or not. We could do that today by maybe scanning all other function definitions for the presence of "frame-pointer"="all" fn attr, breaking early if we find one, and emitting the frame pointer setup in that case. Though I guess it's "frame-pointer"="none" otherwise, so maybe checking any other fn def would be fine; I don't see any C fn attr's that allow you to keep frame pointers or not. What's tricky is that the front end flag was resolved much earlier than where this code gets generated, so it would need to look for traces that the flag ever existed, which sounds brittle on paper to me. -- Thanks, ~Nick Desaulniers
