Re: [PATCH 00/11] Reduce usage of timestamp macros

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 5422 bytes --]

On Wed, Sep 01, 2021 at 11:44:52PM +0200, Pali Rohár wrote:
> 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

I don't know.  The GitLab job is configured in three stages so if
something early fails we don't wait forever to fail.  The Azure job is
over at
https://dev.azure.com/u-boot/u-boot/_build/results?buildId=2792&view=results
and hasn't completed but doesn't look like it's showing anything you
haven't already fixed.

> 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...

I think what you're missing isn't about gitlab, but rather about
buildman.  If you've picked up any tips on how to debug these problems,
updating doc/develop/ci_testing.rst for the next time would be good.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]