objtool: Ignore bogus jump table entries when the table size is known

When the size of a jump table is unknown, heuristics are needed to
figure whether each subsequent address in .rodata is still part of the
jump table that is being parsed.

One of such stop conditions is a jump table reference to an address that
is outside of the function that the jump table belongs to. However,
there are cases where the compiler may emit such entries, e.g.,
(taken from drivers/net/dsa/vitesse-vsc73xx-core.c):

  |     88b:       41 83 e7 09             and    $0x9,%r15d
  |     ...
  |     8a9:       42 ff 24 fd 00 00 00    jmp    *0x0(,%r15,8)
  |     8b0:       00
  |                        8a9: R_X86_64_NONE      .rodata+0xd8
  |                        8ad: R_X86_64_32S       .rodata+0xd8
  |     8b1:       cc                      int3
  |
  |00000000000000d8 <$JTI0_1>:
  |     ...
  |      d8: R_X86_64_64 .text+0x8b2
  |      e0: R_X86_64_64 .text+0x928
  |      e8: R_X86_64_64 .text+0x980   <-- outside of the function
  |      f0: R_X86_64_64 .text+0x980
  |      f8: R_X86_64_64 .text+0x980
  |     100: R_X86_64_64 .text+0x980
  |     108: R_X86_64_64 .text+0x980
  |     110: R_X86_64_64 .text+0x980
  |     118: R_X86_64_64 .text+0x946
  |     120: R_X86_64_64 .text+0x917

In this case, the jump table index is masked with 0x9, making only
entries 0, 1, 8 and 9 reachable, and so the other values are never read.

Handle this case by ignoring the individual entries when the jump table
size is known a priori, rather than bailing out on the first occurrence.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>