In fc26, kernel config enables CONFIG_FORTIFY_SOURCE
in 4.13 kernel. This is not available in fc25.
This config is used to detect overflows of buffers in common string
and memory functions where the compiler can determine and
validate the buffer sizes.

When enabled, this option provides an implementation (body)
for certain string function. For example, in
/lib/modules/4.13.10-200.fc26.x86_64/build/include/linux/string.h,
you can find
...
extern void * memcpy(void *,const void *,__kernel_size_t);
...
__FORTIFY_INLINE void *memcpy(void *p, const void *q, __kernel_size_t size)
{
        size_t p_size = __builtin_object_size(p, 0);
        size_t q_size = __builtin_object_size(q, 0);
        if (__builtin_constant_p(size)) {
                if (p_size < size)
                        __write_overflow();
                if (q_size < size)
                        __read_overflow2();
        }
        if (p_size < size || q_size < size)
                fortify_panic(__func__);
        return __builtin_memcpy(p, q, size);
}

In current clang frontend, we treat an external function with function body
as a rewritable target. We also assume the declaration of this external function,
if body is present, must have named arguments. This is largely true
for functions in bpf program file/text itself as these external functions often
do not have declarations.

We should not try to rewrite string/memory functions exposed by
CONFIG_FORTIFY_SOURCE. This patch adds restriction for rewritable function
only if the corresponding file is the main file with bpf program itself.

I discovered that it is possible file name is empty for tracepoint
functions, e.g.,
  TRACEPOINT_PROBE(irq, softirq_entry)
The reason could be function name itself is derived from helpers.h while
function declaration/body is in the main file after macro expansion.
Note that function name is still correctly derived by the compiler.
Signed-off-by: Yonghong Song <yhs@fb.com>