diff options
| author | Josh Poimboeuf <jpoimboe@redhat.com> | 2016-04-15 10:17:10 -0400 |
|---|---|---|
| committer | Ingo Molnar <mingo@kernel.org> | 2016-04-16 05:14:17 -0400 |
| commit | b1547d3101e74e809b9790174b27f1080747b009 (patch) | |
| tree | f5eeb80c700d7dcaf512338063a07751d79d281d /tools/objtool/Documentation | |
| parent | 7e578441a4a3bba2a79426ca0f709c801210d08e (diff) | |
objtool: Detect falling through to the next function
There are several cases in compiled C code where a function may not
return at the end, and may instead fall through to the next function.
That may indicate a bug in the code, or a gcc bug, or even an objtool
bug. But in each case, objtool reports an unhelpful warning, something
like:
drivers/scsi/qla2xxx/qla_attr.o: warning: objtool: qla2x00_get_fc_host_stats()+0x0: duplicate frame pointer save
drivers/scsi/qla2xxx/qla_attr.o: warning: objtool: qla2x00_get_fc_host_stats()+0x0: frame pointer state mismatch
Detect this situation and print a more useful error message:
drivers/scsi/qla2xxx/qla_attr.o: warning: objtool: qla2x00_get_host_fabric_name() falls through to next function qla2x00_get_starget_node_name()
Also add some information about this warning and its potential causes to
the documentation.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/caa4ec6c687931db805e692d4e4bf06cd87d33e6.1460729697.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'tools/objtool/Documentation')
| -rw-r--r-- | tools/objtool/Documentation/stack-validation.txt | 38 |
1 files changed, 29 insertions, 9 deletions
diff --git a/tools/objtool/Documentation/stack-validation.txt b/tools/objtool/Documentation/stack-validation.txt index 5a95896105bc..55a60d331f47 100644 --- a/tools/objtool/Documentation/stack-validation.txt +++ b/tools/objtool/Documentation/stack-validation.txt | |||
| @@ -299,18 +299,38 @@ they mean, and suggestions for how to fix them. | |||
| 299 | Errors in .c files | 299 | Errors in .c files |
| 300 | ------------------ | 300 | ------------------ |
| 301 | 301 | ||
| 302 | If you're getting an objtool error in a compiled .c file, chances are | 302 | 1. c_file.o: warning: objtool: funcA() falls through to next function funcB() |
| 303 | the file uses an asm() statement which has a "call" instruction. An | ||
| 304 | asm() statement with a call instruction must declare the use of the | ||
| 305 | stack pointer in its output operand. For example, on x86_64: | ||
| 306 | 303 | ||
| 307 | register void *__sp asm("rsp"); | 304 | This means that funcA() doesn't end with a return instruction or an |
| 308 | asm volatile("call func" : "+r" (__sp)); | 305 | unconditional jump, and that objtool has determined that the function |
| 306 | can fall through into the next function. There could be different | ||
| 307 | reasons for this: | ||
| 309 | 308 | ||
| 310 | Otherwise the stack frame may not get created before the call. | 309 | 1) funcA()'s last instruction is a call to a "noreturn" function like |
| 310 | panic(). In this case the noreturn function needs to be added to | ||
| 311 | objtool's hard-coded global_noreturns array. Feel free to bug the | ||
| 312 | objtool maintainer, or you can submit a patch. | ||
| 311 | 313 | ||
| 312 | Another possible cause for errors in C code is if the Makefile removes | 314 | 2) funcA() uses the unreachable() annotation in a section of code |
| 313 | -fno-omit-frame-pointer or adds -fomit-frame-pointer to the gcc options. | 315 | that is actually reachable. |
| 316 | |||
| 317 | 3) If funcA() calls an inline function, the object code for funcA() | ||
| 318 | might be corrupt due to a gcc bug. For more details, see: | ||
| 319 | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 | ||
| 320 | |||
| 321 | 2. If you're getting any other objtool error in a compiled .c file, it | ||
| 322 | may be because the file uses an asm() statement which has a "call" | ||
| 323 | instruction. An asm() statement with a call instruction must declare | ||
| 324 | the use of the stack pointer in its output operand. For example, on | ||
| 325 | x86_64: | ||
| 326 | |||
| 327 | register void *__sp asm("rsp"); | ||
| 328 | asm volatile("call func" : "+r" (__sp)); | ||
| 329 | |||
| 330 | Otherwise the stack frame may not get created before the call. | ||
| 331 | |||
| 332 | 3. Another possible cause for errors in C code is if the Makefile removes | ||
| 333 | -fno-omit-frame-pointer or adds -fomit-frame-pointer to the gcc options. | ||
| 314 | 334 | ||
| 315 | Also see the above section for .S file errors for more information what | 335 | Also see the above section for .S file errors for more information what |
| 316 | the individual error messages mean. | 336 | the individual error messages mean. |
