Linux kernel CONFIG_DEBUG_SECTION_MISMATCH make errors
This is just a warning. The kernel build systems did a sanity check and found out something that might be an error. The warning message says somewhere in kernel code there is code that might do inappropriate cross section access. Note that your kernel did build!
To understand what the warning means, consider the following example:
Some kernel code in the kernel text section might be trying to call a function marked with the __init
data macro, which the linker puts in the kernel init section that gets de-allocated after boot or module loading.
This might be a run time error since if the code in the text section calls the code in the init section after the initialization code has finished, it is basically calling a stale pointer.
Having said that, that call may be perfectly fine - it is possible that the calls in the kernel text section has some good reason to know that it only calls the function in the init section when it is guaranteed to be there.
This, of course, is just an example. Similar other scenarios also exists.
The solution is to compile with CONFIG_DEBUG_SECTION_MISMATCH=y
which will give you output of what function is trying to access which data or function and which section they belong to. You can then try to figure out if the build time warning is warranted and if so hopefully fix.
The init.h macros __ref
and __refdata
can be used to allow such init references without warnings. For example,
char * __init_refok bar(void)
{
static int flag = 0;
static char* rval = NULL;
if(!flag) {
flag = 1;
rval = init_fn(); /* a function discarded after init */
}
return rval;
}
__init_refok
, etc can fix "valid" instances, so the fact they exist may not inspire confidence.
How to fix linux kernel section mismatches?
The solution was inside mpm.c
and mpm-of.c
.
I changed static int msm_mpm_debug_mask = 1
with static int msm_mpm_debug_mask __initdata = 1
inside both file.
More info on the issue here
What is kernel section mismatch?
It means that a function that is in a section with a given lifetime references something that is in a section with a different lifetime.
When the kernel binary is linked, different parts of the code and data are split up into different sections. Some of these sections are kept loaded all the time, but some others are removed once they are no longer needed (things that are only required during boot for example can be freed once boot is done - this saves memory).
If a function that is in a long-lasting section refers to data in one of the discardable sections, there is a problem - it might try to access that data when it has already been released, leading to all kinds of runtime issues.
This is not a warning you'll fix yourself, unless you wrote that code or are very familiar with it. It gets fixed by correctly annotating the function (or the data it refers to) so that it goes into the right section. The right fix can only be determined with detailed knowledge of that part of the kernel.
For a list of these sections and annotations, refer to the include/linux/init.h
header in your kernel source tree:
/* These macros are used to mark some functions or
* initialized data (doesn't apply to uninitialized data)
* as `initialization' functions. The kernel can take this
* as hint that the function is used only during the initialization
* phase and free up used memory resources after
*
* Usage:
* For functions:
*
* You should add __init immediately before the function name, like:
*
* static void __init initme(int x, int y)
* {
* extern int z; z = x * y;
* }
*
* If the function has a prototype somewhere, you can also add
* __init between closing brace of the prototype and semicolon:
*
* extern int initialize_foobar_device(int, int, int) __init;
*
* For initialized data:
* You should insert __initdata between the variable name and equal
* sign followed by value, e.g.:
*
* static int init_variable __initdata = 0;
* static const char linux_logo[] __initconst = { 0x32, 0x36, ... };
*
* Don't forget to initialize data not at file scope, i.e. within a function,
* as gcc otherwise puts the data into the bss section and not into the init
* section.
*
* Also note, that this data cannot be "const".
*/
/* These are for everybody (although not all archs will actually
discard it in modules) */
#define __init __section(.init.text) __cold notrace
#define __initdata __section(.init.data)
#define __initconst __section(.init.rodata)
#define __exitdata __section(.exit.data)
#define __exit_call __used __section(.exitcall.exit)
Others follow, with more comments and explanations.
See also the help text for the CONFIG_DEBUG_SECTION_MISMATCH
Kconfig symbol:
The section mismatch analysis checks if there are illegal
references from one section to another section.
Linux will during link or during runtime drop some sections
and any use of code/data previously in these sections will
most likely result in an oops.
In the code functions and variables are annotated with
__init, __devinit etc. (see full list in include/linux/init.h)
which results in the code/data being placed in specific sections.
The section mismatch analysis is always done after a full
kernel build but enabling this option will in addition
do the following:
- Add the option -fno-inline-functions-called-once to gcc
When inlining a function annotated __init in a non-init
function we would lose the section information and thus
the analysis would not catch the illegal reference.
This option tells gcc to inline less but will also
result in a larger kernel.- Run the section mismatch analysis for each module/built-in.o
When we run the section mismatch analysis on vmlinux.o we
lose valueble information about where the mismatch was
introduced.
Running the analysis for each module/built-in.o file
will tell where the mismatch happens much closer to the
source. The drawback is that we will report the same
mismatch at least twice.- Enable verbose reporting from modpost to help solving
the section mismatches reported.
error after building Linux source code for android
You can try running:
ARCH=arm CROSS_COMPILE=/path/to/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- make CONFIG_DEBUG_SECTION_MISMATCH=y
So that make runs using the ARM settings
Also, which kernel version are you compiling? Where did you get this kernel? Why can't you use a kernel from the Android project directly?
Related Topics
Match a String That Contains a Newline Using Sed
Aws Lambda Permission Denied When Trying to Use Ffmpeg
Bpf Verifier Rejects Code: "Invalid Bpf_Context Access"
Memory Access Error Sys_Rt_Sigaction (Signal Handler)
Bash Pass Variable as Argument with Quotes
What Is Partition Checker in Arm Secure Mode
How to Find Words from One File in Another File
Is There an Acceptable Linux Targeted Gui Client for Git-Svn
How to Get All Parent Processes and All Subprocesses with 'Pstree'
How to Test If Your Linux Support Sse2
Sharing One Port Among Multiple Node.Js Http Processes
Linux Mint - Adding Environment Variables Permanently