[PATCH] kallsyms: ignore ARM mode switching veneers

[PATCH] kallsyms: ignore ARM mode switching veneers

[Ard Biesheuvel]

On ARM, the linker may emit veneers to deal with relative branch
instructions that appear too far away from their targets. Since the second
kallsyms pass results in an increase of the kernel size, it may result in
additional veneers to be emitted, potentially affecting the output of
kallsyms itself if these symbols are visible to it, and for that reason,
symbols whose names end in '_veneer' are ignored explicitly.

However, when building Thumb2 kernels, such veneers are named differently
if they also incur a mode switch, and since they are not filtered by
kallsyms, they may cause the build to fail. So filter symbols whose names
end in '_from_arm' or '_from_thumb' as well.

Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 scripts/kallsyms.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 8fa81e84e295..e2379de76563 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -215,6 +215,8 @@ static int symbol_valid(struct sym_entry *s)
 
 	static char *special_suffixes[] = {
 		"_veneer",		/* arm */
+		"_from_arm",		/* arm */
+		"_from_thumb",		/* arm */
 		NULL };
 
 	int i;
-- 
2.5.0

[PATCH] kallsyms: ignore ARM mode switching veneers

[Arnd Bergmann]

On Friday 26 February 2016 20:50:54 Ard Biesheuvel wrote:
> On ARM, the linker may emit veneers to deal with relative branch
> instructions that appear too far away from their targets. Since the second
> kallsyms pass results in an increase of the kernel size, it may result in
> additional veneers to be emitted, potentially affecting the output of
> kallsyms itself if these symbols are visible to it, and for that reason,
> symbols whose names end in '_veneer' are ignored explicitly.
> 
> However, when building Thumb2 kernels, such veneers are named differently
> if they also incur a mode switch, and since they are not filtered by
> kallsyms, they may cause the build to fail. So filter symbols whose names
> end in '_from_arm' or '_from_thumb' as well.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>


Thanks again for debugging this!

I have two (randconfig) configurations that ran into this problem, and they
are both with your patch

Tested-by: Arnd Bergmann <arnd@arndb.de>

>  scripts/kallsyms.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
> index 8fa81e84e295..e2379de76563 100644
> --- a/scripts/kallsyms.c
> +++ b/scripts/kallsyms.c
> @@ -215,6 +215,8 @@ static int symbol_valid(struct sym_entry *s)
>  
>  	static char *special_suffixes[] = {
>  		"_veneer",		/* arm */
> +		"_from_arm",		/* arm */
> +		"_from_thumb",		/* arm */
>  		NULL };
>  
>  	int i;
> 

[PATCH] kallsyms: ignore ARM mode switching veneers

[Ard Biesheuvel]

On 26 February 2016 at 21:21, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 26 February 2016 20:50:54 Ard Biesheuvel wrote:
>> On ARM, the linker may emit veneers to deal with relative branch
>> instructions that appear too far away from their targets. Since the second
>> kallsyms pass results in an increase of the kernel size, it may result in
>> additional veneers to be emitted, potentially affecting the output of
>> kallsyms itself if these symbols are visible to it, and for that reason,
>> symbols whose names end in '_veneer' are ignored explicitly.
>>
>> However, when building Thumb2 kernels, such veneers are named differently
>> if they also incur a mode switch, and since they are not filtered by
>> kallsyms, they may cause the build to fail. So filter symbols whose names
>> end in '_from_arm' or '_from_thumb' as well.
>>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
>
> Thanks again for debugging this!
>
> I have two (randconfig) configurations that ran into this problem, and they
> are both with your patch
>
> Tested-by: Arnd Bergmann <arnd@arndb.de>
>

Added to the patch tracker as #8555