let rewriter add code to define CONFIG_CC_STACKPROTECTOR

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 <yhs@fb.com>

src/cc/frontends/clang/b_frontend_action.cc

@@ -1057,7 +1057,28 @@ bool BFrontendAction::is_rewritable_ext_func(FunctionDecl *D) {
           (file_name.empty() || file_name == main_path_));
 }
 
+void BFrontendAction::DoMiscWorkAround() {
+  // In 4.16 and later, CONFIG_CC_STACKPROTECTOR is moved out of Kconfig and into
+  // Makefile. It will be set depending on CONFIG_CC_STACKPROTECTOR_{AUTO|REGULAR|STRONG}.
+  // CONFIG_CC_STACKPROTECTOR is still used in various places, e.g., struct task_struct,
+  // to guard certain fields. The workaround here intends to define
+  // CONFIG_CC_STACKPROTECTOR properly based on other configs, so it relieved any bpf
+  // program (using task_struct, etc.) of patching the below code.
+  rewriter_->getEditBuffer(rewriter_->getSourceMgr().getMainFileID()).InsertText(0,
+    "#if !defined(CONFIG_CC_STACKPROTECTOR)\n"
+    "#if defined(CONFIG_CC_STACKPROTECTOR_AUTO) \\\n"
+    "    || defined(CONFIG_CC_STACKPROTECTOR_REGULAR) \\\n"
+    "    || defined(CONFIG_CC_STACKPROTECTOR_STRONG)\n"
+    "#define CONFIG_CC_STACKPROTECTOR\n"
+    "#endif\n"
+    "#endif\n",
+    false);
+}
+
 void BFrontendAction::EndSourceFileAction() {
+  // Additional misc rewrites
+  DoMiscWorkAround();
+
   if (flags_ & DEBUG_PREPROCESSOR)
     rewriter_->getEditBuffer(rewriter_->getSourceMgr().getMainFileID()).write(llvm::errs());
   if (flags_ & DEBUG_SOURCE) {

src/cc/frontends/clang/b_frontend_action.h

@@ -150,6 +150,7 @@ class BFrontendAction : public clang::ASTFrontendAction {
   TableStorage &table_storage() const { return ts_; }
   std::string id() const { return id_; }
   bool is_rewritable_ext_func(clang::FunctionDecl *D);
+  void DoMiscWorkAround();
 
  private:
   llvm::raw_ostream &os_;