Re: Problems with commit 'kallsyms: add support for relative offsets in kallsyms address table' (in mmotm)

[Ard Biesheuvel]

> On 24 jan. 2016, at 03:35, Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
> 
>> On 01/23/2016 06:06 PM, Guenter Roeck wrote:
>> Hi,
>> 
>> I see runtime problems with the current mmotm branch. All qemu mips targets
>> (32 and 64 bit, big and little endian) are stuck in boot after this commit.
>> 
>> Bisect points to commit d13682e4d9d2 ("kallsyms: add support for relative offsets
>> in kallsyms address table". Disabling CONFIG_KALLSYMS_BASE_RELATIVE fixes the problem,
>> ie I can boot the image with qemu.
>> 
>> Bisect log is attached.
>> 
>> Playing with the problem, I found the following:
>> 
>> 1) The problem is only seen with a toolchain using binutils 2.22, but not
>>    with a toolchain using binutils 2.25. The compiler configuration may be
>>    different for both toolchains.
>> 2) Message "kallsyms failure: absolute symbol value 0xffffffff807afd14 out of range
>>    in relative mode" (twice) when using the toolchain with binutils 2.22.
>>    This does not cause the build to fail, though.
>> 3) kallsyms_sym_address() parameter variable type is "int". In the calling code,
>>    the variable type used is "unsigned long". That has no impact on the problem,
>>    though.
> 
> An additional data point: When using the older toolchain, many symbols in System.map
> are marked "A".
>    ffffffff80100000 A _text
> With the more recent toolchain, the same symbols are marked "T".
>    ffffffff80100000 T _text
> 

Thanks for the analysis. It is surprising that the build does not fail when this occurs, and the subsequent hangs themselves are probably caused by missing kallsyms data.

scripts/kallsyms.c ignores all A symbols except _text, which is actually a relative symbol by nature so we can simply assume it is relative (i.e., override it as T)

Re x86_64 !SMP, any build time errors there as well? Likewise for sparc32?


Thanks again, and sorry for the trouble,
Ard.

> 
>> Please let me know if there is anything I can do to help tracking down the problem.
>> 
>> Thanks,
>> Guenter
>> 
>> ---
>> # bad: [437b7ef6d6484bb36afb2c75897e14bf03113dbd] pci: test for unexpectedly disabled bridges
>> # good: [afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc] Linux 4.4
>> git bisect start 'HEAD' 'v4.4'
>> # bad: [10078c1820d81131bc338c7c919feb2638a912ad] ocfs2: o2hb: add NEGOTIATE_APPROVE message
>> git bisect bad 10078c1820d81131bc338c7c919feb2638a912ad
>> # bad: [1b06048b37e888edb609e1509070ec0c6580eedd] kallsyms-add-support-for-relative-offsets-in-kallsyms-address-table-fix
>> git bisect bad 1b06048b37e888edb609e1509070ec0c6580eedd
>> # good: [ed312d94332968c86f53295795a3d122fd32cea2] arch/alpha/kernel/systbls.S: remove debug check
>> git bisect good ed312d94332968c86f53295795a3d122fd32cea2
>> # good: [1cbe7000217b0126821ecd8fba0ba5f9315a0560] thp: limit number of object to scan on deferred_split_scan()
>> git bisect good 1cbe7000217b0126821ecd8fba0ba5f9315a0560
>> # good: [474324b13e8184aa088c722b771f0f31ab773476] vmstat: remove BUG_ON from vmstat_update
>> git bisect good 474324b13e8184aa088c722b771f0f31ab773476
>> # good: [d94a9840c248207040d62ca0f380943db9423418] proc: fix missing reference of mm
>> git bisect good d94a9840c248207040d62ca0f380943db9423418
>> # bad: [d13682e4d9d2ad8220354b5e1a2bd6623e1f2e38] kallsyms: add support for relative offsets in kallsyms address table
>> git bisect bad d13682e4d9d2ad8220354b5e1a2bd6623e1f2e38
>> # first bad commit: [d13682e4d9d2ad8220354b5e1a2bd6623e1f2e38] kallsyms: add support for relative offsets in kallsyms address table
>