This commit is still dirty because I'm jumbling cut & pasted
referring to dynup#1010 and dynup#1203.

symtab_read tries to skip '.dynsym' symbol table and only
read '.symtab' symbol table. Newer readelf from binutils 2.37
now adds section names (see the diff):

--- vmlinux.symtab      2022-02-18 02:10:06.691220932 +0100
+++ vmlinux.symtab.new  2022-02-18 01:16:06.161210458 +0100
Symbol table '.dynsym' contains 1541 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000100000     0 SECTION LOCAL  DEFAULT    1 .text
     2: 00000000017a3ac0     4 OBJECT  GLOBAL DEFAULT   19 sclp_console_pages
Symbol table '.symtab' contains 159980 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
-    41: 0000000001a93600     0 SECTION LOCAL  DEFAULT   41
-    42: 0000000001a9c678     0 SECTION LOCAL  DEFAULT   42
...
+    41: 0000000001a93600     0 SECTION LOCAL  DEFAULT   41 .dynsym
+    42: 0000000001a9c678     0 SECTION LOCAL  DEFAULT   42 .rela.dyn
...
     54: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS main.c

Simple matching of ".dynsym" in the line buffer is not enough anymore,
because it hits not just

Symbol table '.dynsym' contains 1541 entries:

line, but also

    41: 0000000001a93600     0 SECTION LOCAL  DEFAULT   41 .dynsym

skipping the rest of the file and leading to an error:

create-diff-object: ERROR: *.o: find_local_syms: 189: couldn't find matching
*.c local symbols in vmlinux symbol table

Limit matching only to lines containing "Symbol table" header.
This works with readelf from the binutils, as well as readelf from
elfutils (its output looks slightly different).

Symbol table [41] '.dynsym' contains 1541 entries:

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

1. -mno-pic-data-is-text-relative prevents relative addressing between
   code and data. This is needed to avoid relocation error when klp text
   and data are too far apart

2. Avoid generation of LANCHOR symbols through -fno-section-anchors.
   kpatch-build does not handle it well.

Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>

* Add s390 specific checks
* Identify patchable functions.
* Dont mark expolines as dynrelas. These expolines are always included
  in final kernel module. This ensures that expoline functions and the
  kernel itself are not too far apart and avoids out of range
  relocation. However, this isnt a problem for other functions, as these
  relocations are performed via R_390_PLT32DBL using gcc option
  -mno-pic-data-is-text-relative.
* s390 maintains expoline tables to locate the expoline thunks. If
  needed,  the module loader could later replace these expoline thunks
  with normal indirect branch. Each element in the expoline table is of 4
  bytes. If there is a changed function in rela.s390_return*, then mark
  that specific rela symbol as included. This is already performed in the
  processing of special sections. Hence include it.

Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>

Add object exclusion for s390

Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>

1. static const struct inet_sock fake_sk = {
	/* makes ip6_route_output set RT6_LOOKUP_F_IFACE: */
	.sk.sk_bound_dev_if = 1,
	.pinet6 = (struct ipv6_pinfo *) &fake_pinfo,
};

gcc can place fake_sk in .data.rel.ro.local:
ndx 38, data 0x3ffb3280a58, size 960, name .data.rel.ro.local.fake_sk.1
ndx 39, data 0x3ffb32be5e8, size 24, name .rela.data.rel.ro.local.fake_sk.1

2. static LIST_HEAD(patch_objects);

gcc can place patch_objects relocation in .data.rel.local:
sym 56, type 1, bind 0, ndx 34, name patch_objects -> .data.rel.local

Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>

Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>

Merge pull request dynup#1203 from sumanthkorikkar/s390x-kpatch-support