When code is compiled with: -fpatchable-function-entry=${PADDING_BYTES},${PADDING_BYTES} functions will have PADDING_BYTES of NOP in front of them. Unwinders and other things that symbolize code locations will typically attribute these bytes to the preceding function. Given that these bytes nominally belong to the following symbol this mis-attribution is confusing. Inspired by the fact that CFI_CLANG emits __cfi_##name symbols to claim these bytes, use objtool to emit __pfx_##name symbols to do the same when CFI_CLANG is not used. This then shows the callthunk for symbol 'name' as: __pfx_##name+0x6/0x10
Unified · Split
| @@ -2471,6 +2471,10 @@ config CALL_THUNKS · 2470 unmodified lines | |||
| 2471 | def_bool n | 2471 | def_bool n |
| 2472 | select FUNCTION_ALIGNMENT_16B | 2472 | select FUNCTION_ALIGNMENT_16B |
| 2473 | 2473 | ||
| 2474 | config PREFIX_SYMBOLS | ||
| 2475 | def_bool y | ||
| 2476 | depends on CALL_THUNKS && !CFI_CLANG | ||
| 2477 | |||
| 2474 | menuconfig SPECULATION_MITIGATIONS | 2478 | menuconfig SPECULATION_MITIGATIONS |
| 2475 | bool "Mitigations for speculative execution vulnerabilities" | 2479 | bool "Mitigations for speculative execution vulnerabilities" |
| 2476 | default y | 2480 | default y |
| @@ -265,6 +265,7 @@ objtool-args-$(CONFIG_STACK_VALIDATION) += --stackval · 264 unmodified lines | |||
| 265 | objtool-args-$(CONFIG_HAVE_STATIC_CALL_INLINE) += --static-call | 265 | objtool-args-$(CONFIG_HAVE_STATIC_CALL_INLINE) += --static-call |
| 266 | objtool-args-$(CONFIG_HAVE_UACCESS_VALIDATION) += --uaccess | 266 | objtool-args-$(CONFIG_HAVE_UACCESS_VALIDATION) += --uaccess |
| 267 | objtool-args-$(CONFIG_GCOV_KERNEL) += --no-unreachable | 267 | objtool-args-$(CONFIG_GCOV_KERNEL) += --no-unreachable |
| 268 | objtool-args-$(CONFIG_PREFIX_SYMBOLS) += --prefix=$(CONFIG_FUNCTION_PADDING_BYTES) | ||
| 268 | 269 | ||
| 269 | objtool-args = $(objtool-args-y) \ | 270 | objtool-args = $(objtool-args-y) \ |
| 270 | $(if $(delay-objtool), --link) \ | 271 | $(if $(delay-objtool), --link) \ |