Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1510100 > unrolled thread

Re: Build regressions/improvements in v4.9-rc1

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Build regressions/improvements in v4.9-rc1 Thomas Petazzoni <thomas.petazzoni@free-electrons.com> - 2016-10-27 09:10 +0200
    Re: Build regressions/improvements in v4.9-rc1 Alexey Brodkin <Alexey.Brodkin@synopsys.com> - 2016-10-27 16:00 +0200
      Re: Build regressions/improvements in v4.9-rc1 Alexey Brodkin <Alexey.Brodkin@synopsys.com> - 2016-10-27 16:00 +0200
        Re: Build regressions/improvements in v4.9-rc1 Vineet Gupta <vgupta@synopsys.com> - 2016-10-27 19:30 +0200
          Re: Build regressions/improvements in v4.9-rc1 Arnd Bergmann <arnd@arndb.de> - 2016-10-28 12:50 +0200
      Re: Build regressions/improvements in v4.9-rc1 Arnd Bergmann <arnd@arndb.de> - 2016-10-27 16:20 +0200
        Re: Build regressions/improvements in v4.9-rc1 Thomas Petazzoni <thomas.petazzoni@free-electrons.com> - 2016-10-27 17:00 +0200
      Re: Build regressions/improvements in v4.9-rc1 Thomas Petazzoni <thomas.petazzoni@free-electrons.com> - 2016-10-27 16:40 +0200
        Re: Build regressions/improvements in v4.9-rc1 Geert Uytterhoeven <geert@linux-m68k.org> - 2016-10-27 17:30 +0200

#1510100 — Re: Build regressions/improvements in v4.9-rc1

Hello,

On Thu, 27 Oct 2016 10:56:02 +1100, Michael Ellerman wrote:

> > Hm... that's strange - it used to work but doesn't work with newer Buildroot...
> >
> > Anyways if something very simple (i.e. with no extra libraries) works for you just go
> > ahead and grab pre-built image that Thomas Petazzoni builds.
> >
> > That's the most recent one:
> > http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2  
> 
> Thanks, I grabbed that and it works for axs103_smp_defconfig:
> 
>   http://kisskb.ellerman.id.au/kisskb/buildresult/12840656/
> 
> 
> It doesn't work for axs101_defconfig, saying:
> 
>   arch/arc/Makefile:29: *** Toolchain not configured for ARCompact builds.  Stop.

axs101 is using a 770 core, while the toolchain is built for the HS38
core. I'm somewhat surprised that a single ARC toolchain cannot produce
code for both 770 and HS38, but it seems to be the case.

So you need a separate toolchain for ARC770.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [next] | [standalone]

#1510157

Hi Thomas, Michael,

On Thu, 2016-10-27 at 09:07 +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 27 Oct 2016 10:56:02 +1100, Michael Ellerman wrote:
> 
> > 
> > > 
> > > Hm... that's strange - it used to work but doesn't work with newer Buildroot...
> > > 
> > > Anyways if something very simple (i.e. with no extra libraries) works for you just go
> > > ahead and grab pre-built image that Thomas Petazzoni builds.
> > > 
> > > That's the most recent one:
> > > http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2  
> > 
> > Thanks, I grabbed that and it works for axs103_smp_defconfig:
> > 
> >   http://kisskb.ellerman.id.au/kisskb/buildresult/12840656/
> > 
> > 
> > It doesn't work for axs101_defconfig, saying:
> > 
> >   arch/arc/Makefile:29: *** Toolchain not configured for ARCompact builds.  Stop.
> 
> axs101 is using a 770 core, while the toolchain is built for the HS38
> core. I'm somewhat surprised that a single ARC toolchain cannot produce
> code for both 770 and HS38, but it seems to be the case.
> 
> So you need a separate toolchain for ARC770.

Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while
axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core
which has ARCv2 ISA (binary incompatible with ARCompact).

Essentially both gcc and binutils will happily build for both architectures given
proper options were passed on the command line. But Linux kernel gets linked with
pre-built libgcc (it is a part of toolchain). And so it all boils down to a requirement
to have multilibbed uClibc toolchain. Which we don't have.

I think we discussed it a couple of times already and probably at some point will have it
but for now we have to use 2 different toolchains for ARCompact and ARCv2 cores.

I hope explanation above makes some sense.

-Alexey

[toc] | [prev] | [next] | [standalone]

#1510174

Hi Thomas,

On Thu, 2016-10-27 at 11:24 +0200, Geert Uytterhoeven wrote:
> On Thu, Oct 27, 2016 at 11:11 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > 
> > On Thu, 27 Oct 2016 09:07:55 +0000, Alexey Brodkin wrote:
> > 
> > > 
> > > > 
> > > > axs101 is using a 770 core, while the toolchain is built for the HS38
> > > > core. I'm somewhat surprised that a single ARC toolchain cannot produce
> > > > code for both 770 and HS38, but it seems to be the case.
> > > > 
> > > > So you need a separate toolchain for ARC770.
> > > 
> > > Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while
> > > axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core
> > > which has ARCv2 ISA (binary incompatible with ARCompact).
> > > 
> > > Essentially both gcc and binutils will happily build for both architectures given
> > > proper options were passed on the command line. But Linux kernel gets linked with
> > > pre-built libgcc (it is a part of toolchain). And so it all boils down to a requirement
> > > to have multilibbed uClibc toolchain. Which we don't have.
> > 
> > Interesting. Why is libgcc linked with the kernel on ARC? I don't think
> > that's the case on other architectures: the kernel is freestanding and
> > provides everything that it needs without relying on the compiler
> > runtime.
> 
> ARC is not the only one:
> 
> $ git grep print-libgcc-file-name
> arch/arc/Makefile:LIBGCC := $(shell $(CC) $(cflags-y) --print-libgcc-file-name)
> arch/h8300/boot/compressed/Makefile:LIBGCC := $(shell
> $(CROSS-COMPILE)$(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/hexagon/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
> -print-libgcc-file-name)
> arch/m32r/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
> -print-libgcc-file-name)
> arch/nios2/Makefile:LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS)
> $(KCFLAGS) -print-libgcc-file-name)
> arch/openrisc/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
> -print-libgcc-file-name)
> arch/parisc/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS)
> -print-libgcc-file-name)
> arch/tile/Makefile:  $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS)
> -print-libgcc-file-name)
> arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
> -print-libgcc-file-name)
> arch/xtensa/boot/boot-redboot/Makefile:LIBGCC := $(shell $(CC)
> $(KBUILD_CFLAGS) -print-libgcc-file-name)

Right.

I'm not 100% sure about all the details in case of Linux kernel on ARC
but I actually implemented decoupling from libgcc in U-Boot for ARC.
And from that experience I know what was required out of libgcc, see
http://git.denx.de/?p=u-boot.git;a=patch;h=a67ef280f46803e319639f5380ff8da6c6b7fbe7

And these are functions required by U-Boot (most probably the same is applied to kernel):
1) so-called millicode, stuff like __ld_rX_to_rY, __st_rX_to_rX
2) shifts: __ashldi3, __ashrdi3, __lshrdi3, 
3) divisions: udivmodsi4, __divsi3, __modsi3, __udivsi3, __umodsi3

Indeed it is possible to have so-called private libgcc in kernel as well but
benefit will be only for people building kernels but not user-space because
in absence of multilibbed toolchain 2 separate toolchains will be required anyways.

Still we'll have to pay an additional maintenance price to keep kernel's libgcc in
sync with the one from gcc.

-Alexey

[toc] | [prev] | [next] | [standalone]

#1510510

+CC Claudiu

On 10/27/2016 02:39 AM, Alexey Brodkin wrote:
>
> And these are functions required by U-Boot (most probably the same is applied to kernel):
> 1) so-called millicode, stuff like __ld_rX_to_rY, __st_rX_to_rX

This kicks in only at -Os and even there can be inhibited with a toggle.
I don't like it anyways, seems like a costly contraption in terms of microarch
cost of 2 extra long branches for both prologue and epilogue.

> 2) shifts: __ashldi3, __ashrdi3, __lshrdi3, 
> 3) divisions: udivmodsi4, __divsi3, __modsi3, __udivsi3, __umodsi3

Note that this list is not constant. I recently had to export another libgcc
symbol for modules, when a customer switched to ARC gnu 2016.03 for supposedly
building the same kernel code.

> Indeed it is possible to have so-called private libgcc in kernel as well but
> benefit will be only for people building kernels but not user-space because
> in absence of multilibbed toolchain 2 separate toolchains will be required anyways.

True, but a lot of people only care about builds (and not actually run), so for
them having to carry only one toolchain is an improvement.

> Still we'll have to pay an additional maintenance price to keep kernel's libgcc in
> sync with the one from gcc.

True, but libgcc math emulation is likely one off thing. GNU folks will write them
once and we use a snapshot - syncing back changes - if any around major gnu releases.

So I'm tending to include the libgcc code in kernel. @Arnd, @Claudiu do you know
of any potential licensing issues ?

-Vineet

[toc] | [prev] | [next] | [standalone]

#1511061

On Thursday, October 27, 2016 10:21:16 AM CEST Vineet Gupta wrote:
> 
> On 10/27/2016 02:39 AM, Alexey Brodkin wrote:
> >
> > And these are functions required by U-Boot (most probably the same is applied to kernel):
> > 1) so-called millicode, stuff like __ld_rX_to_rY, __st_rX_to_rX
> 
> This kicks in only at -Os and even there can be inhibited with a toggle.
> I don't like it anyways, seems like a costly contraption in terms of microarch
> cost of 2 extra long branches for both prologue and epilogue.
> 
> > 2) shifts: __ashldi3, __ashrdi3, __lshrdi3, 
> > 3) divisions: udivmodsi4, __divsi3, __modsi3, __udivsi3, __umodsi3
> 
> Note that this list is not constant. I recently had to export another libgcc
> symbol for modules, when a customer switched to ARC gnu 2016.03 for supposedly
> building the same kernel code.
> 
> > Indeed it is possible to have so-called private libgcc in kernel as well but
> > benefit will be only for people building kernels but not user-space because
> > in absence of multilibbed toolchain 2 separate toolchains will be required anyways.
> 
> True, but a lot of people only care about builds (and not actually run), so for
> them having to carry only one toolchain is an improvement.
> 
> > Still we'll have to pay an additional maintenance price to keep kernel's libgcc in
> > sync with the one from gcc.
> 
> True, but libgcc math emulation is likely one off thing. GNU folks will write them
> once and we use a snapshot - syncing back changes - if any around major gnu releases.
> 
> So I'm tending to include the libgcc code in kernel. @Arnd, @Claudiu do you know
> of any potential licensing issues ?
> 

I'd be surprised if there were any licensing issues, as libgcc is intentionally
meant to be included in everything built by gcc, and the architectures that don't
link against it tend to have a direct copy.

The main advantage of copying libgcc sources into the kernel instead of linking
directly to it is probably that you have better control over which functions
are actually used, as not everything in libgcc makes sense in kernel space.

The most common example is probably the 64-bit division, which is a libgcc
function on most architectures, and in the kernel we intentionally don't
implement that function in order to catch drivers trying to do that (and
change them to either explicit div_u64() or not do a 64-bit division).

Another example of a libgcc function you don't want is anything calling
abort(), which makes no sense in the kernel.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1510236

On Thursday, October 27, 2016 11:11:18 AM CEST Thomas Petazzoni wrote:
> On Thu, 27 Oct 2016 09:07:55 +0000, Alexey Brodkin wrote:
> 
> > > axs101 is using a 770 core, while the toolchain is built for the HS38
> > > core. I'm somewhat surprised that a single ARC toolchain cannot produce
> > > code for both 770 and HS38, but it seems to be the case.
> > > 
> > > So you need a separate toolchain for ARC770.  
> > 
> > Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while
> > axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core
> > which has ARCv2 ISA (binary incompatible with ARCompact).
> > 
> > Essentially both gcc and binutils will happily build for both architectures given
> > proper options were passed on the command line. But Linux kernel gets linked with
> > pre-built libgcc (it is a part of toolchain). And so it all boils down to a requirement
> > to have multilibbed uClibc toolchain. Which we don't have.
> 
> Interesting. Why is libgcc linked with the kernel on ARC? I don't think
> that's the case on other architectures: the kernel is freestanding and
> provides everything that it needs without relying on the compiler
> runtime.

A couple of other architectures do this as well:

$ git grep -w LIBGCC arch/*/Makefile
arch/arc/Makefile:LIBGCC        := $(shell $(CC) $(cflags-y) --print-libgcc-file-name)
arch/arc/Makefile:libs-y                += arch/arc/lib/ $(LIBGCC)
arch/cris/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS) -print-file-name=libgcc.a)
arch/cris/Makefile:libs-y               += arch/cris/$(SARCH)/lib/ $(LIBGCC)
arch/hexagon/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/hexagon/Makefile:libs-y += $(LIBGCC)
arch/m32r/Makefile:LIBGCC       := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/m32r/Makefile:libs-y       += arch/m32r/lib/ $(LIBGCC)
arch/nios2/Makefile:LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-name)
arch/nios2/Makefile:libs-y              += arch/nios2/lib/ $(LIBGCC)
arch/openrisc/Makefile:LIBGCC           := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/openrisc/Makefile:libs-y           += $(LIBGCC)
arch/parisc/Makefile:LIBGCC             = $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/parisc/Makefile:libs-y     += arch/parisc/lib/ $(LIBGCC)
arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/xtensa/Makefile:libs-y             += arch/xtensa/lib/ $(LIBGCC)

It's also not always freestanding on the architectures that don't
include libgcc:

$ git grep ffreestanding arch/
arch/mips/Makefile:cflags-y += -ffreestanding
arch/s390/boot/compressed/Makefile:KBUILD_CFLAGS += $(call cc-option,-ffreestanding)
arch/score/Makefile:    -D__linux__ -ffunction-sections -ffreestanding
arch/sh/Makefile:cflags-y       += $(isaflags-y) -ffreestanding
arch/x86/Makefile:        KBUILD_CFLAGS += -ffreestanding # temporary until string.h is fixed
arch/xtensa/Makefile:KBUILD_CFLAGS += -ffreestanding -D__linux__

(xtensa being the only one that apparently uses libgcc *and* passes
 -ffreestanding, for whatever reasons).

The other architectures tend to implement the parts of libgcc that they
need in the kernel.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1510362

Hello,

On Thu, 27 Oct 2016 11:32:11 +0200, Arnd Bergmann wrote:

> A couple of other architectures do this as well:
> 
> $ git grep -w LIBGCC arch/*/Makefile
> arch/arc/Makefile:LIBGCC        := $(shell $(CC) $(cflags-y) --print-libgcc-file-name)
> arch/arc/Makefile:libs-y                += arch/arc/lib/ $(LIBGCC)
> arch/cris/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS) -print-file-name=libgcc.a)
> arch/cris/Makefile:libs-y               += arch/cris/$(SARCH)/lib/ $(LIBGCC)
> arch/hexagon/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/hexagon/Makefile:libs-y += $(LIBGCC)
> arch/m32r/Makefile:LIBGCC       := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/m32r/Makefile:libs-y       += arch/m32r/lib/ $(LIBGCC)
> arch/nios2/Makefile:LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-name)
> arch/nios2/Makefile:libs-y              += arch/nios2/lib/ $(LIBGCC)
> arch/openrisc/Makefile:LIBGCC           := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/openrisc/Makefile:libs-y           += $(LIBGCC)
> arch/parisc/Makefile:LIBGCC             = $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/parisc/Makefile:libs-y     += arch/parisc/lib/ $(LIBGCC)
> arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/xtensa/Makefile:libs-y             += arch/xtensa/lib/ $(LIBGCC)
> 
> It's also not always freestanding on the architectures that don't
> include libgcc:
> 
> $ git grep ffreestanding arch/
> arch/mips/Makefile:cflags-y += -ffreestanding
> arch/s390/boot/compressed/Makefile:KBUILD_CFLAGS += $(call cc-option,-ffreestanding)
> arch/score/Makefile:    -D__linux__ -ffunction-sections -ffreestanding
> arch/sh/Makefile:cflags-y       += $(isaflags-y) -ffreestanding
> arch/x86/Makefile:        KBUILD_CFLAGS += -ffreestanding # temporary until string.h is fixed
> arch/xtensa/Makefile:KBUILD_CFLAGS += -ffreestanding -D__linux__
> 
> (xtensa being the only one that apparently uses libgcc *and* passes
>  -ffreestanding, for whatever reasons).
> 
> The other architectures tend to implement the parts of libgcc that they
> need in the kernel.

Thanks for the details, good to know!

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1510299

Hello,

On Thu, 27 Oct 2016 09:07:55 +0000, Alexey Brodkin wrote:

> > axs101 is using a 770 core, while the toolchain is built for the HS38
> > core. I'm somewhat surprised that a single ARC toolchain cannot produce
> > code for both 770 and HS38, but it seems to be the case.
> > 
> > So you need a separate toolchain for ARC770.  
> 
> Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while
> axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core
> which has ARCv2 ISA (binary incompatible with ARCompact).
> 
> Essentially both gcc and binutils will happily build for both architectures given
> proper options were passed on the command line. But Linux kernel gets linked with
> pre-built libgcc (it is a part of toolchain). And so it all boils down to a requirement
> to have multilibbed uClibc toolchain. Which we don't have.

Interesting. Why is libgcc linked with the kernel on ARC? I don't think
that's the case on other architectures: the kernel is freestanding and
provides everything that it needs without relying on the compiler
runtime.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1510393

On Thu, Oct 27, 2016 at 11:11 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Thu, 27 Oct 2016 09:07:55 +0000, Alexey Brodkin wrote:
>
>> > axs101 is using a 770 core, while the toolchain is built for the HS38
>> > core. I'm somewhat surprised that a single ARC toolchain cannot produce
>> > code for both 770 and HS38, but it seems to be the case.
>> >
>> > So you need a separate toolchain for ARC770.
>>
>> Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while
>> axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core
>> which has ARCv2 ISA (binary incompatible with ARCompact).
>>
>> Essentially both gcc and binutils will happily build for both architectures given
>> proper options were passed on the command line. But Linux kernel gets linked with
>> pre-built libgcc (it is a part of toolchain). And so it all boils down to a requirement
>> to have multilibbed uClibc toolchain. Which we don't have.
>
> Interesting. Why is libgcc linked with the kernel on ARC? I don't think
> that's the case on other architectures: the kernel is freestanding and
> provides everything that it needs without relying on the compiler
> runtime.

ARC is not the only one:

$ git grep print-libgcc-file-name
arch/arc/Makefile:LIBGCC := $(shell $(CC) $(cflags-y) --print-libgcc-file-name)
arch/h8300/boot/compressed/Makefile:LIBGCC := $(shell
$(CROSS-COMPILE)$(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/hexagon/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
-print-libgcc-file-name)
arch/m32r/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
-print-libgcc-file-name)
arch/nios2/Makefile:LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS)
$(KCFLAGS) -print-libgcc-file-name)
arch/openrisc/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
-print-libgcc-file-name)
arch/parisc/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS)
-print-libgcc-file-name)
arch/tile/Makefile:  $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS)
-print-libgcc-file-name)
arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
-print-libgcc-file-name)
arch/xtensa/boot/boot-redboot/Makefile:LIBGCC := $(shell $(CC)
$(KBUILD_CFLAGS) -print-libgcc-file-name)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web