create-diff-object: don't create __fentry__ dynrelas

This fixes the following issue for a patch which changes a module:

  kpatch_create_mcount_sections: 1968: bad first rela in .rela.text.e_show

The first rela is "bad" because the real first rela was converted to a
dynrela and then removed from the rela list.

This is a temporary fix.  The more permanent fix should be to allow
lookups in vmlinux for patched modules so we don't create any
unnecessary dynrelas.
kpatch-build: extract GCC version from .comment section

Extract the GCC version from the .comment section of vmlinux.  This
hopefully makes the version check more robust across various distros.

Fixes #297.
Merge pull request #300 from jpoimboe/gcc-version-readelf

kpatch-build: extract GCC version from .comment section
Merge pull request #298 from jpoimboe/no-fentry-dynrela

create-diff-object: don't create __fentry__ dynrelas
Merge pull request #299 from useidel/master

Rebase of SPEC file to current version
create-diff-object: fix for unincluded sec->secsym

When running kpatch-build with -d, I was getting a seg fault.  It was
faulting in kpatch_dump_kelf() when trying to print sec->secsym->name
for the .smp_locks section.  It turns out that the section was included
but its section symbol wasn't included, so sec->secsym pointed to freed
memory.
README.md: add debian support
README.md: add build-essential package
add KPATCH_WARN_*_LINE macros

WARN macros are problematic because they embed the line number in an
instruction.  As a result, when a function is changed higher in a file,
the line numbers for any WARN calls below that function in the file can
result in unnecessarily changed functions.

These macros allow a patch author to hard code the line numbers in WARN
macros to prevent functions from otherwise changing and getting pulled
into a patch module unnecessarily.
kmod/core: check force flag in replace case

When unpatching a function due to "kpatch replace", check the force flag
before doing the activeness safety check.
Merge pull request #304 from jpoimboe/force-fix

kmod/core: check force flag in replace case
Merge pull request #302 from goldyfruit/master

README.md: add debian support
prevent rmmod of forced modules

I found a bad bug:

- Module A is loaded, and registers function foo() with
  KPATCH_FORCE_UNSAFE.
- Module A is unloaded.  The new version of foo() is on the backtrace of
  a task, but the core module ignores it because of the force flag, so
  the unloading succeeds.
- The task returns to the new version of foo() which no longer exists.
- BOOM.

The only way I can think of to prevent this scenario is to prevent
forced modules from being unloaded (but still allow them to be
disabled).

An annoying side effect of this approach is that forced modules stay
loaded and in memory forever.  And that after "kpatch unload" of a
forced module, you can't ever load it again because the previous
instance of it is still loaded (but permanently disabled).

This is ugly but I can't really think of a better way to handle it.  If
necessary we could create a workqueue and periodically check to see if
we can safely call module_put() so that the module could be eventually
removed.
code review fix

Return 0 on rmmod error.
Merge pull request #305 from jpoimboe/force-prevent-rmmod

prevent rmmod of forced modules
kpatch: pass basename of argument to unload_module
readme: add links to more videos
Merge pull request #308 from jpoimboe/readme-videos

readme: add links to more videos
Merge pull request #301 from jpoimboe/debug-seg-fault

create-diff-object: fix for unincluded sec->secsym
Merge pull request #307 from flaming-toast/kpatch-unload

kpatch: pass basename of argument to unload_module