Continuing kallsyms failures - large kernels, XIP kernels, and large XIP kernels

[Stefan Agner]

On 2015-02-04 10:44, Russell King - ARM Linux wrote:
> On Tue, Feb 03, 2015 at 08:59:15PM -0500, Nicolas Pitre wrote:
>> On Wed, 4 Feb 2015, Russell King - ARM Linux wrote:
>>
>> > It looks like we have cases where this falsely triggers.  Consider EFM32:
>> >
>> > CONFIG_DRAM_BASE=0x88000000
>> > CONFIG_DRAM_SIZE=0x00400000
>> > CONFIG_FLASH_MEM_BASE=0x8c000000
>> > CONFIG_FLASH_SIZE=0x01000000
>> >
>> > This means that we quite legally end up with the .data section below the
>> > .text section, which makes:
>> >
>> > ASSERT((_data >= __data_loc), "Text section oversize")
>> >
>> > falsely trigger.
>> >
>> > The linker has the capacity to specify regions of ROM and RAM in the
>> > linker file, I wonder if we should be using those for XIP.  Merely
>> > adding the MEMORY table to the linker file is not good enough - we
>> > also need to explicitly tell the linker which memory regions to place
>> > the output sections, otherwise the linker ends up making assumptions.
>> >
>> > What that means is... asm-generic/vmlinux.lds.h breaks for us.
>> >
>> > Any ideas?  I think using the MEMORY table would be the best approach,
>> > because that should allow us to properly verify that the resulting
>> > binary should fit in the memory regions.
>>
>> Maybe simply having an assert() on the size of the .text section could
>> be all that is needed.  We already know the maximum size in advance.
> 
> That doesn't work, it's not just the .text section but also .rodata,
> __bug_table, __ksymtab, __ksymtab_gpl, __kcrctab, __kcrctab_gpl,
> __ksymtab_strings, __param, __modver, __ex_table, .notes, .vectors,
> .stubs, .init.text, maybe .exit.text, .init.arch.info, .init.tagtable,
> .init.smpalt, .init.pv_table, and apparently .init.data (which is
> surely wrong?)  The following is from Arnd's failing configuration:
> 
>  18 .init.tagtable 00000040  80073a9c  80073a9c  0100ba9c  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>  19 .init.data    000010e8  80073adc  80073adc  0100badc  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>  20 .data         003552c4  80008000  80074bc4  01010000  2**8
>                   CONTENTS, ALLOC, LOAD, DATA
> 
> Hmm, if .init.data is contained in the flash section (which it seemingly
> is), it seems that XIP support is currently broken - that section is
> definitely a read/write section.  No one has seemingly noticed that it's
> broken and it's been broken for a long time, so maybe the simple answer
> then is just to rip XIP support out?

Hi Russell,

I noticed that kallsyms resolution fails with XIP kernel in my patchset
to support Vybrids Cortex-M4, see
http://article.gmane.org/gmane.linux.drivers.devicetree/101196

Fwiw, although that platform has enough memory to use a normal kernel
too, the Cortex-M4 architecture has a dedicated code bus. I used the XIP
kernel to make use of the code bus for the kernel code at least.
However, there might be better ways to archive this.

--
Stefan