let rewriter add code to define CONFIG_CC_STACKPROTECTOR

[yonghong-song]

Fix issue #1730

Linux kernel commit 2bc2f688fdf8 ("Makefile: move stack-protector
availability out of Kconfig") moved CONFIG_CC_STACKPROTECTOR
from Kconfig to Makefile. Commit 44c6dc940b19 ("Makefile: introduce
CONFIG_CC_STACKPROTECTOR_AUTO") introduced CONFIG_CC_STACKPROTECTOR_AUTO.

Whether CONFIG_CC_STACKPROTECTOR is defined depends on
CONFIG_CC_STACKPROTECTOR_{AUTO,REGULAR,STRONG}. Since the clang supports
stack-protector, CONFIG_CC_STACKPROTECTOR_AUTO will imply
CONFIG_CC_STACKPROTECTOR for gcc/clang based compilation.

Such changes are introduced in 4.16. For example, the following code
is defined in linux/include/linux/sched.h,

        pid_t                           pid;
        pid_t                           tgid;

        /* Canary value for the -fstack-protector GCC feature: */
        unsigned long                   stack_canary;
        /*
         * Pointers to the (original) parent process, youngest child, younger sibling,
         * older sibling, respectively.  (p->father can be replaced with
         * p->real_parent->pid)
         */

        /* Real parent process: */
        struct task_struct __rcu        *real_parent;

If kernel config has CONFIG_CC_STACKPROTECTOR_{STRONG,REGULAR,AUTO} defined,
CONFIG_CC_STACKPROTECTOR will be defined in compilation flags by kernel toplevel Makefile.
But since CONFIG_CC_STACKPROTECTOR is not defined in configuration file autoconf.h,
bcc will consider it is not defined. This will cause bcc to access wrong data
in task_struct for any fields after the above stack_canary.

Instead to fix any individual tool, in this patch the bcc rewriter added necessary
macro definition for CONFIG_CC_STACKPROTECTOR in the source code, depending on
CONFIG_CC_STACKPROTECTOR_{AUTO,REGULAR,STRONG}.

Signed-off-by: Yonghong Song [email protected]

[yonghong-song]

cc @luohao-brian could you try this patch whether it fixed your problem?