Documentation: x86: exception-tables: document CONFIG_BUILDTIME_TABLE_SORT

Provide more information about __ex_table sorting post link.

The exception tables and fixup tables use a commonly recurring pattern
in the kernel of storing the address of labels as date in custom ELF
sections, then finding these sections, iterating elements within them,
and possibly revisiting them or modifying the data at these addresses.

Sorting readonly arrays to minimize runtime penalties is quite clever.

Suggested-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Link: https://lore.kernel.org/r/20200327000951.84071-1-ndesaulniers@google.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Nick Desaulniers 2020-03-26 17:09:51 -07:00 committed by Jonathan Corbet
parent 19e91e543c
commit abcb1e021a

View File

@ -257,6 +257,9 @@ the fault, in our case the actual value is c0199ff5:
the original assembly code: > 3: movl $-14,%eax
and linked in vmlinux : > c0199ff5 <.fixup+10b5> movl $0xfffffff2,%eax
If the fixup was able to handle the exception, control flow may be returned
to the instruction after the one that triggered the fault, ie. local label 2b.
The assembly code::
> .section __ex_table,"a"
@ -344,3 +347,14 @@ pointer which points to one of:
it as special.
More functions can easily be added.
CONFIG_BUILDTIME_TABLE_SORT allows the __ex_table section to be sorted post
link of the kernel image, via a host utility scripts/sorttable. It will set the
symbol main_extable_sort_needed to 0, avoiding sorting the __ex_table section
at boot time. With the exception table sorted, at runtime when an exception
occurs we can quickly lookup the __ex_table entry via binary search.
This is not just a boot time optimization, some architectures require this
table to be sorted in order to handle exceptions relatively early in the boot
process. For example, i386 makes use of this form of exception handling before
paging support is even enabled!