From: Alexander Turenko <alexander.turenko@tarantool.org> To: Timur Safin <tsafin@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [V2] luajit: pass properly compile options to LuaJIT for RelWithDebInfo Date: Tue, 28 Jul 2020 17:03:51 +0300 [thread overview] Message-ID: <20200728140351.gsnacxegpt22c2wq@tkn_work_nb> (raw) In-Reply-To: <c45c92732da64a6ef4bd84206f6e89aa7e3d31df.1595597785.git.tsafin@tarantool.org> > - set (luajit_cflags ${CMAKE_C_FLAGS}) > + string (TOUPPER ${CMAKE_BUILD_TYPE} upper_build_type) > + set (c_flags_init "CMAKE_C_FLAGS_${upper_build_type}") > + set (luajit_cflags ${${c_flags_init}}) Debug: -- CMAKE_C_FLAGS: -fexceptions -funwind-tables -fno-omit-frame-pointer -fno-stack-protector -fno-common -fopenmp -msse2 -- CMAKE_C_FLAGS_DEBUG: -g -ggdb -O0 RelWithDebInfo: -- CMAKE_C_FLAGS: -fexceptions -funwind-tables -fno-omit-frame-pointer -fno-stack-protector -fno-common -fopenmp -msse2 -- CMAKE_C_FLAGS_RELWITHDEBINFO: -O2 -g -DNDEBUG -ggdb -O2 So all those -fno-omit-frame-pointer was applied to luajit and we should proceed with each such option very carefully. For example, cite from cmake/compiler.cmake: | # | # Set flags for all include files: those maintained by us and | # coming from third parties. | # Since we began using luajit, which uses gcc stack unwind | # internally, we also need to make sure all code is compiled | # with unwind info. | # | | add_compile_flags("C;CXX" "-fexceptions" "-funwind-tables") | | # We must set -fno-omit-frame-pointer here, since we rely | # on frame pointer when getting a backtrace, and it must | # be used consistently across all object files. | # The same reasoning applies to -fno-stack-protector switch. | | if (ENABLE_BACKTRACE) | add_compile_flags("C;CXX" | "-fno-omit-frame-pointer" | "-fno-stack-protector") | endif() I would be okay to just enable '-g -ggdb' without changing base flags from CMAKE_C_FLAGS to CMAKE_C_FLAGS_{DEBUG,RELWITHDEBINFO}, but see below. > set (luajit_ldflags ${CMAKE_EXE_LINKER_FLAGS}) > separate_arguments(luajit_cflags) > separate_arguments(luajit_ldflags) > @@ -168,19 +170,12 @@ macro(luajit_build) > "-pagezero_size 10000 -image_base 100000000") > endif() > > - # We are consciously ommiting debug info in RelWithDebInfo mode So there was a reason. I don't know it, but we should know if we want to change it. Can it be related to performance? I would ask Nick Zavaritsky if you really want to know. I searched over commits and discussions that may be relevant, but didn't found anything. I asked about this in [1]. [1]: https://github.com/tarantool/tarantool/issues/4827#issuecomment-665059210 WBR, Alexander Turenko.
next prev parent reply other threads:[~2020-07-28 14:04 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-24 13:37 Timur Safin 2020-07-28 14:03 ` Alexander Turenko [this message] 2020-08-06 14:41 ` Igor Munkin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200728140351.gsnacxegpt22c2wq@tkn_work_nb \ --to=alexander.turenko@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --cc=tsafin@tarantool.org \ --subject='Re: [Tarantool-patches] [V2] luajit: pass properly compile options to LuaJIT for RelWithDebInfo' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox