linux-kernel - Re: Problems compiling with KCFLAGS="-frecord-gcc-switches"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <28fcb028-68a7-707d-006c-dcbd58e3aba0@roeck-us.net>
Date:   Fri, 29 Sep 2017 16:08:10 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Problems compiling with KCFLAGS="-frecord-gcc-switches"

On 09/29/2017 01:58 PM, Josh Poimboeuf wrote:
> On Fri, Sep 29, 2017 at 01:38:43PM -0700, Guenter Roeck wrote:
>> On Fri, Sep 29, 2017 at 01:00:56PM -0700, Guenter Roeck wrote:
>>> Hi Josh,
>>>
>>> when trying to compile an image with KCFLAGS="-frecord-gcc-switches",
>>> I get the folllowing build warning/error.
>>>
>>> make allmodconfig
>>> KCFLAGS="-frecord-gcc-switches" make arch/x86/kvm/emulate.o
>>> ./tools/objtool/objtool check --no-unreachable "arch/x86/kvm/emulate.o"
>>>
>>> arch/x86/kvm/emulate.o: warning:
>>> 	objtool: .GCC.command.line+0x0: special: can't find new instruction
>>>
>>> Building a full image aborts with:
>>>
>>> WARNING: arch/x86/kvm/kvm.o(__ex_table+0x4c): Section mismatch in reference
>>> 	from the (unknown reference) (unknown)
>>> 	to the variable .GCC.command.line:kvm_fastop_exception
>>> FATAL: The relocation at __ex_table+0x4c references
>>> section ".GCC.command.line" which is not executable, IOW
>>> the kernel will fault if it ever tries to
>>> jump to it.  Something is seriously wrong
>>> and should be fixed.
>>> make[2]: *** [arch/x86/kvm/kvm.o] Error 1
>>>
>>> Any idea what might cause this problem ?
>>>
>>
>> Here is another interesting problem, seen when building arm64 allmodconfig
>> -CONFIG_CPU_BIG_ENDIAN +CONFIG_EFI.
>>
>> kallsyms failure:
>> 	relative symbol value 0xffffff9008073000 out of range in relative mode
>>
>> This is due to symbols such as
>>
>> 000000000000000e n __efistub_$d
>>
>> in the symbol table. Those are not filtered out by kallsyms, resulting in a
>> relative "base" address of 0x0e, and all other symbols are out of range.
>> Those symbols are only generated in efi/libstubs.
>>
>> Any idea what might be going on there, and how to fix it ?
>> An easy fix would be something like
>>
>> -       else if (stype == 'N')
>> +       else if (toupper(stype) == 'N')
>>
>> in kallsyms, but that doesn't seem like a clean solution to me.
> 
> Not sure... What does 'n' mean?  I don't see it in the man page for nm.
> 

Good question. As far as I can see, gcc uses it to mark symbols associated
with -frecord-gcc-switches, presumably in the .GCC.command.line section.

Guenter