Re: [PATCH] [RFC] ARM: move __bug_table into .data for XIP_KERNEL

[Ard Biesheuvel]

> On 28 Jul 2017, at 16:27, Nicolas Pitre <nicolas.pitre@xxxxxxxxxx> wrote:
> 
>> On Fri, 28 Jul 2017, Arnd Bergmann wrote:
>> 
>> Matt Hart reports that vf610m4_defconfig kernels grew to 2GB
>> xipImage size after the __bug_table change.
>> 
>> I tried out a few things and found that moving the bug table
>> into the .data section avoids this problem. However, the
>> linker script magic is beyond my capabilities here, so this
>> is almost certainly not correct.
> 
> Well, before your patch the BUG_TABLE location as well as its runtime 
> functionality were completely wrong and broken.
> 
>> I've added a few people to Cc that understand this better
>> than I do, hopefully someone can turn my bogus patch into
>> a proper one.
> 
> Your patch isn't as bad as you make it, but maybe the following will 
> avoid open recoding BUG_TABLE locally:
> 
> diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
> index 8265b11621..21b4b29c2f 100644
> --- a/arch/arm/kernel/vmlinux-xip.lds.S
> +++ b/arch/arm/kernel/vmlinux-xip.lds.S
> @@ -237,13 +237,13 @@ SECTIONS
>         */
>        DATA_DATA
>        CONSTRUCTORS
> -
> -        _edata = .;
>    }
> -    _edata_loc = __data_loc + SIZEOF(.data);
> 
>    BUG_TABLE
> 

The .data section is deliberately emitted with LMA != VMA so that the code refers to the correct offset in RAM while the initial contents are in ROM and are copied into RAM by the startup code.

This applies to the bug table as well (now that it needs to be writable) so the only correct way to do this is to move it into .data like Arnd's patch does.

I guess we could split the macro so we can emit bug table into an existing section, but in itself, the code is correct, and i don't see a better way of doing it.

> +    _edata = .;
> +    _edata_loc = __data_loc + SIZEOF(.data);
> +
> #ifdef CONFIG_HAVE_TCM
>         /*
>     * We align everything to a page boundary so we can
> 
> 
> Nicolas