[U-Boot] __FILE__ usage and and SPL limits for SRAM

[Masahiro Yamada]

Hi Denys,


2017-05-23 2:23 GMT+09:00 Denys Dmytriyenko <denis at denix.org>:
> On Sat, Apr 22, 2017 at 02:30:09PM +0900, Masahiro Yamada wrote:
>> >>> On Tuesday 28 March 2017 03:14 AM, Nishanth Menon wrote:
>> >>> > Hi,
>> >>> >
>> >>> > we've kind of run into an interesting situation recently, but might be
>> >>> > of interest for various folks trying to reduce the image sizes.
>> >>> >
>> >>> > our AM335x device has a limited amount of sram.. and the SPL tries to
>> >>> > fit into it (a bit tricky given the restricted space we have on it on
>> >>> > certain class of devices).
>> >>> >
>> >>> > arch/arm/mach-omap2/am33xx/u-boot-spl.lds is a bit custom tailored
>> >>> > around this.
>> >>> >
>> >>> > Key in this is:
>> >>> > . = ALIGN(4);
>> >>> > .rodata : { *(SORT_BY_ALIGNMENT(.rodata*)) } >.sram
>> >>> >
>> >>> > . = ALIGN(4);
>> >>> > .data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram
>> >>> >
>> >>> >
>> >>> > Now, our jenkins build system happens to use a varied build path and
>> >>> > uses O= path. to simplify the details:
>> >>> > mkdir
>> >>> > /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb/cccccccccccccccccccccccccccccccccccccccccccccccccc
>> >>> >
>> >>> > mkdir
>> >>> > /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb/cccccccccccccccccccccccccccccccccccccccccccccccccc/b
>> >>> >
>> >>> >
>> >>> > git clone u-boot
>> >>> > cd u-boot
>> >>> >
>> >>> > git clean -fdx
>> >>> > make CROSS_COMPILE=arm-linux-gnueabihf- O=../b am335x_evm_defconfig
>> >>> > make CROSS_COMPILE=arm-linux-gnueabihf- O=../b all
>> >>> >
>> >>> > depending on depth of the path, this would fail.. a little bit of
>> >>> > headscratching later..
>> >>> > when using O= build system uses absolute paths, which translates to
>> >>> > __FILE__ being absolute paths as well..
>> >>> >
>> >>> > in u-boot, any printf("%s", __FILE__) makes u-boot allocate this file
>> >>> > path in rodata.
>> >>> >
>> >>> > So, depending on how deep the path is rodata size varies and ends up
>> >>> > pushing .data out of sram max range.
>> >>> >
>> >>> > we dont really care to put a print of complete absolute path anyways,
>> >>> > and I am not really sure of a clean way to resolve this:
>> >>> > a) override __FILE__ with something.. -Wbuiltin-macro-redefined kicks in
>> >>> > b) replace usage of __FILE__ with something like __FILENAME__ as
>> >>> > recommended by [1]
>> >>> >
>> >>> >
>> >>> > What is the suggestion we do?
>> >>> >
>> >>> > [1] http://stackoverflow.com/questions/8487986/file-macro-shows-full-path
>
> <snip>
>
>> I can do this, but
>> I'd like to move forward synced with Linux.
>>
>>
>> Yesterday, I took some time to write patches
>> and sent them to Linux ML.
>>
>>
>> Plan A:
>> https://lkml.org/lkml/2017/4/21/623
>> https://patchwork.kernel.org/patch/9693559/
>> https://patchwork.kernel.org/patch/9693563/
>>
>>
>> Plan B:
>> https://patchwork.kernel.org/patch/9693623/
>
> FWIW:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
>
> --
> Denys


Thanks for you pointer!

If merged, it will reduce the image size, and also helpful for
reproducible build.

(We can not save users of old GCC versions, though...)




-- 
Best Regards
Masahiro Yamada