[PATCH 00/11] Reduce usage of timestamp macros

[Pali Rohár]

On Wednesday 01 September 2021 17:33:57 Tom Rini wrote:
> On Wed, Sep 01, 2021 at 11:28:54PM +0200, Pali Rohár wrote:
> > On Wednesday 01 September 2021 17:17:06 Tom Rini wrote:
> > > On Wed, Sep 01, 2021 at 11:05:45PM +0200, Pali Rohár wrote:
> > > > On Wednesday 01 September 2021 16:59:09 Tom Rini wrote:
> > > > > On Mon, Aug 02, 2021 at 03:18:27PM +0200, Pali Rohár wrote:
> > > > > 
> > > > > > Including timestamp.h (either directly or transitionally) cause build
> > > > > > system to recompile binaries at every 'make' run. This has disadvantage
> > > > > > in U-Boot development as for every small change 'make' recompiles lot of
> > > > > > other irrelevant files which were not touched / changed.
> > > > > > 
> > > > > > This patch series eliminate transitional / indirect usage of
> > > > > > timestamp.h by removing unneeded inclusion of header files, moving
> > > > > > timestamp values from macros to global variables, etc...
> > > > > > 
> > > > > > After these patches, U-Boot tools are not recompiled by every 'make' run,
> > > > > > which decrease time for incremental U-Boot recompilation.
> > > > > > 
> > > > > > Please test these patches, specially m68k and powerpc parts as I do not
> > > > > > have any of these boards.
> > > > > > 
> > > > > > Patch series depend on this patch (now marked as accepted):
> > > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210710111001.32325-1-pali@kernel.org/
> > > > > > 
> > > > > > Pali Rohár (11):
> > > > > >   Remove #include <timestamp.h> from files which do not need it
> > > > > >   Remove #include <version.h> from files which do not need it
> > > > > >   efi_loader: Use directly version_string variable
> > > > > >   version: Move version_string[] from version.h to version_string.h
> > > > > >   m68k: mcf: Remove overloading version_string
> > > > > >   version: Put version_string[] variable into section
> > > > > >     .text_version_string
> > > > > >   powerpc: mpc: Put U-Boot version string at correct place by linker
> > > > > >     script
> > > > > >   version: Do not make version_string[] variable as a weak
> > > > > >   x86: quark: MRC: Remove U_BOOT_DATE and U_BOOT_TIME from debug log
> > > > > >   version: Remove global macro U_BOOT_VERSION_STRING from version.h
> > > > > >   Remove including timestamp.h in version.h
> > > > > 
> > > > > So, looking at https://source.denx.de/u-boot/u-boot/-/pipelines/8948
> > > > > this fails to build for at least qemu-ppce500 and xtfpga.  Over in 
> > > > > doc/develop/ci_testing.rst we document how to run a world build.  Please
> > > > > fix these build errors and re-submit, thanks.
> > > > 
> > > > Already happened about month ago
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20210808112038.7942-1-pali@kernel.org/
> > > > 
> > > > As stated, following build command now passes:
> > > > make CROSS_COMPILE=powerpc-linux-gnu- MCR3000_defconfig u-boot.bin
> > > 
> > > OK, I'll make sure to grab that.  Note that xtfpga isn't PowerPC...
> > 
> > I saw only error https://source.denx.de/u-boot/u-boot/-/jobs/316601 and
> > this should be fixed above patch. At least I got similar error for
> > MCR3000_defconfig with new gcc before that.
> > 
> > But now after scrolling down I see that second xtfpga error
> > https://source.denx.de/u-boot/u-boot/-/jobs/316614
> > But seems that in this UI is error log truncated. I see only
> > 
> > +xtensa-dc233c-elf-ld.bfd: section .text_version_string LMA [00000000fe021584,00000000fe0215c7] overlaps section .u_boot_list LMA [00000000fe021584,00000000fe021e6b]
> > 
> > Is there a way how to show full build log? And which defconfig and
> > compiler is used? Because that error does not help me what is wrong
> > here...
> 
> That's the full error log, from the linker, I believe.  It's the xtfpga
> config for the xtensa architecture.  It's one of the few that buildman
> won't fetch a good toolchain for so you'll want to look at
> tools/docker/Dockerfile and see we get it from
> https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-dc233c-elf.tar.gz
> if you don't have the CI builder container itself handy already.

So this is the only other build which failed, right? I suspect that
there is some other bug in xtfpga linker script, that it missed
specifying wildcard sections and this change triggered it.

I will try to look at it.

It is pity that in above gitlab build log is missing full command which
produced that error as in its arguments could be something interesting,
like path to linker script or compile flags...