Build regressions/improvements in v4.9-rc1

Build regressions/improvements in v4.9-rc1

[Geert Uytterhoeven]

On Mon, Oct 17, 2016 at 9:21 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Below is the list of build error/warning regressions/improvements in
> v4.9-rc1[1] compared to v4.8[2].

> [1] http://kisskb.ellerman.id.au/kisskb/head/11053/ (all 262 configs)
> [2] http://kisskb.ellerman.id.au/kisskb/head/10989/ (all 262 configs)

> 48 error regressions:
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r4]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r5]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r6]':  => 475, 476
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r8]':  => 476, 475, 515
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r11]':  => 476
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r13]':  => 493, 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r14]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r18]':  => 493
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r21]':  => 493
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r6]':  => 476, 475, 515
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r7]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r6,[r12]':  => 493
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r6,[r3]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r6,[r8]':  => 493
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r6,[r9]':  => 493
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r0,[r6]':  => 516
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r10,[r12]':  => 496
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r14,[r9]':  => 496
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r16,[r8]':  => 496
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r0]':  => 479
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r13]':  => 496, 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r18]':  => 496
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r21]':  => 496
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r4]':  => 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r5]':  => 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r6]':  => 478, 516, 479
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r8]':  => 479, 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r11]':  => 479
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r13]':  => 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r14]':  => 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r6]':  => 479, 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r7]':  => 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478

arcv2/axs103_smp_defconfig

>   + /home/kisskb/slave/src/arch/powerpc/kvm/book3s_hv_rm_xics.c: error: implicit declaration of function 'get_hard_smp_processor_id' [-Werror=implicit-function-declaration]:  => 758:2

powerpc/ppc64_defconfig+UP

>   + /home/kisskb/slave/src/drivers/dma/omap-dma.c: error: unrecognizable insn::  => 350:1

cris-allyesconfig
cris-allmodconfig

>   + error: ".irq_set_parent" [drivers/mfd/tps65217.ko] undefined!:  => N/A
>   + error: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!:  => N/A

ppc64le/allmodconfig+ppc64le
powerpc/powerpc-allmodconfig

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

Build regressions/improvements in v4.9-rc1

[Vineet Gupta]

+CC Arnd, Michal

Hi Geert, Arnd

Need some guidance here.

On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
>> 48 error regressions:
>> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
>> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  => 475

[snip...]

>> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
>> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478
> arcv2/axs103_smp_defconfig


I'm thinking how to address this correctly.

This is due to the older version of compiler.  The fix itself is trivial - add an
"call as-instr" construct in Makefile to get -DARC_TOOLS_SUPPORT_LLOCKD

However the atomic64 API variant (CONFIG_GENERIC_ATOMIC64 or arch native) which
gets included in build comes from Kconfig (ISA supports them or not). How do we
tie the Makefile info into the Kconfig.

We could trigger a build failure for invalid combinations of GENERIC_ATOMIC64 and
ARC_TOOLS_SUPPORT_LLOCKD but that would be less than ideal out of box experience.

Or the simpler solution is that kisskb upgrades the ARC GNU compiler ;-)

-Vineet

Build regressions/improvements in v4.9-rc1

[Arnd Bergmann]

On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
> +CC Arnd, Michal
> 
> Hi Geert, Arnd
> 
> Need some guidance here.
> 
> On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
> >> 48 error regressions:
> >> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
> >> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  => 475
> 
> [snip...]
> 
> >> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
> >> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478
> > arcv2/axs103_smp_defconfig
> 
> 
> I'm thinking how to address this correctly.
> 
> This is due to the older version of compiler.  The fix itself is trivial - add an
> "call as-instr" construct in Makefile to get -DARC_TOOLS_SUPPORT_LLOCKD
> 
> However the atomic64 API variant (CONFIG_GENERIC_ATOMIC64 or arch native) which
> gets included in build comes from Kconfig (ISA supports them or not). How do we
> tie the Makefile info into the Kconfig.
> 
> We could trigger a build failure for invalid combinations of GENERIC_ATOMIC64 and
> ARC_TOOLS_SUPPORT_LLOCKD but that would be less than ideal out of box experience.
> 
> Or the simpler solution is that kisskb upgrades the ARC GNU compiler 

Some ideas, none of which are perfect:

- add an #ifndef ARC_TOOLS_SUPPORT_LLOCKD clause in asm/atomic.h that uses
  .long with hardcoded opcodes in place of the mnemonics.

- instead of setting CONFIG_GENERIC_ATOMIC64 from Kconfig, add a file
  in arch/arc/kernel/ that includes lib/atomic64.c if ARC_TOOLS_SUPPORT_LLOCKD
  is not set.

- add "-DCONFIG_GENERIC_ATOMIC64" to cflags-y from arch/arc/Makefile if
  old binutils are found.

I think someone was suggesting in the past that Kconfig could be extended
to make decisions based on the gcc version, and the same thing could
be done for binutils. Don't remember who that was though. I think a number
of awkward hacks in the kernel could be simplified if we had this.

	And

Build regressions/improvements in v4.9-rc1

[Vineet Gupta]

On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
> On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
>> +CC Arnd, Michal
>>
>> Hi Geert, Arnd
>>
>> Need some guidance here.
>>
>> On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
>>>> 48 error regressions:
>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  => 475
>>
>> [snip...]
>>
>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478
>>> arcv2/axs103_smp_defconfig
>>
>>
>> I'm thinking how to address this correctly.
>>
>> This is due to the older version of compiler.  The fix itself is trivial - add an
>> "call as-instr" construct in Makefile to get -DARC_TOOLS_SUPPORT_LLOCKD
>>
>> However the atomic64 API variant (CONFIG_GENERIC_ATOMIC64 or arch native) which
>> gets included in build comes from Kconfig (ISA supports them or not). How do we
>> tie the Makefile info into the Kconfig.
>>
>> We could trigger a build failure for invalid combinations of GENERIC_ATOMIC64 and
>> ARC_TOOLS_SUPPORT_LLOCKD but that would be less than ideal out of box experience.
>>
>> Or the simpler solution is that kisskb upgrades the ARC GNU compiler 
> 
> Some ideas, none of which are perfect:
> 
> - add an #ifndef ARC_TOOLS_SUPPORT_LLOCKD clause in asm/atomic.h that uses
>   .long with hardcoded opcodes in place of the mnemonics.
> 
> - instead of setting CONFIG_GENERIC_ATOMIC64 from Kconfig, add a file
>   in arch/arc/kernel/ that includes lib/atomic64.c if ARC_TOOLS_SUPPORT_LLOCKD
>   is not set.
> 
> - add "-DCONFIG_GENERIC_ATOMIC64" to cflags-y from arch/arc/Makefile if
>   old binutils are found.

I'm tending towards this one - seems cleanest, however...

@Michael can I bother you to upgrade the tools or is this absolutely must for you.

> 
> I think someone was suggesting in the past that Kconfig could be extended
> to make decisions based on the gcc version, and the same thing could
> be done for binutils. Don't remember who that was though. I think a number
> of awkward hacks in the kernel could be simplified if we had this.
> 
> 	And
> 

Build regressions/improvements in v4.9-rc1

[Michael Ellerman]

Vineet Gupta <Vineet.Gupta1 at synopsys.com> writes:
> On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
>> On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
>>> On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
>>>>> 48 error regressions:
>>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
>>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  => 475
>>>
>>> [snip...]
>>>
>>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
>>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478
>>>> arcv2/axs103_smp_defconfig
>
> @Michael can I bother you to upgrade the tools or is this absolutely must for you.

Happy to, just short on time.

I tried building a new toolchain with buildroot, using the instructions
from last time, but the resulting toolchain doesn't relocate, ie. it has
hard-coded paths in it. Any ideas?

cheers

Build regressions/improvements in v4.9-rc1

[Alexey Brodkin]

Hi Michael,

On Wed, 2016-10-19@22:50 +1100, Michael Ellerman wrote:
> Vineet Gupta <Vineet.Gupta1 at synopsys.com> writes:
> > 
> > On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
> > > 
> > > On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
> > > > 
> > > > On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
> > > > > 
> > > > > > 
> > > > > > 48 error regressions:
> > > > > > > 
> > > > > > > ? + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':??=> 476
> > > > > > > ? + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':??=>
> > > > > > > 475
> > > > 
> > > > [snip...]
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > ? + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':??=> 516
> > > > > > > ? + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':??=> 478
> > > > > arcv2/axs103_smp_defconfig
> > 
> > @Michael can I bother you to upgrade the tools or is this absolutely must for you.
> 
> Happy to, just short on time.
> 
> I tried building a new toolchain with buildroot, using the instructions
> from last time, but the resulting toolchain doesn't relocate, ie. it has
> hard-coded paths in it. Any ideas?

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

If I'm not mistaken Thomas runs some post-processing script to make these toolchains
relocatable.

Maybe Thomas may comment on that and even maybe will share his post-processing technique
so you'll be able to build your customized toolchain.

Regards,
Alexey

Build regressions/improvements in v4.9-rc1

[Thomas Petazzoni]

Hello,

On Wed, 19 Oct 2016 12:23:12 +0000, Alexey Brodkin wrote:

> > I tried building a new toolchain with buildroot, using the instructions
> > from last time, but the resulting toolchain doesn't relocate, ie. it has
> > hard-coded paths in it. Any ideas?  
> 
> 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
> 
> If I'm not mistaken Thomas runs some post-processing script to make these toolchains
> relocatable.
> 
> Maybe Thomas may comment on that and even maybe will share his post-processing technique
> so you'll be able to build your customized toolchain.

I simply have two patches on top of Buildroot to build the toolchains
available at http://autobuild.buildroot.org/toolchains/tarballs/ :

 - One patch that builds mpc, gmp and mpfr statically. This is needed
   since the host tools are built with an absolute rpath, so once the
   toolchain is moved, it can't find the host shared libraries that
   have been built for it. Using static linking is a temporary
   work-around, our idea is to fix the rpath to use relative path using
   $ORIGIN. There are some patches from Samuel Martin doing this, we
   have discussed them during the Buildroot Developers Meeting last
   week-end, and we proposed to Samuel to investigate a slightly
   different approach (namely add more features to the upstream
   patchelf utility).

 - One patch that fixes the toolchain wrapper logic so that it works
   fine when the toolchain is moved out of the usr/ sub-directory. We
   started discussing it during the meeting, but I got drowned into
   other discussions, so we haven't had the time to get to the bottom
   of it.

If people are interested, I can prepare a tutorial on how to build
re-usable and relocatable toolchains with Buildroot.

Best regards,

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

Build regressions/improvements in v4.9-rc1

[Michael Ellerman]

Alexey Brodkin <Alexey.Brodkin at synopsys.com> writes:
> On Wed, 2016-10-19@22:50 +1100, Michael Ellerman wrote:
>> Vineet Gupta <Vineet.Gupta1 at synopsys.com> writes:
>> > On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
>> > > On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
>> > > > On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
>> > > > > > 48 error regressions:
>> > > > > > > 
>> > > > > > > ? + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':??=> 476
>> > > > > > > ? + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':??=>
>> > > > > > > 475
>> > > > 
>> > > > [snip...]
>> > > > > > > 
>> > > > > > > ? + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':??=> 516
>> > > > > > > ? + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':??=> 478
>> > > > > arcv2/axs103_smp_defconfig
>> > 
>> > @Michael can I bother you to upgrade the tools or is this absolutely must for you.
>> 
>> Happy to, just short on time.
>> 
>> I tried building a new toolchain with buildroot, using the instructions
>> from last time, but the resulting toolchain doesn't relocate, ie. it has
>> hard-coded paths in it. Any ideas?
>
> 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.


So those are still failing:

  http://kisskb.ellerman.id.au/kisskb/buildresult/12841194/


cheers

Build regressions/improvements in v4.9-rc1

[Thomas Petazzoni]

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

Build regressions/improvements in v4.9-rc1

[Alexey Brodkin]

Hi Thomas, Michael,

On Thu, 2016-10-27@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

Build regressions/improvements in v4.9-rc1

[Thomas Petazzoni]

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

Build regressions/improvements in v4.9-rc1

[Geert Uytterhoeven]

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

Build regressions/improvements in v4.9-rc1

[Alexey Brodkin]

Hi Thomas,

On Thu, 2016-10-27@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

Build regressions/improvements in v4.9-rc1

[Vineet Gupta]

+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

Build regressions/improvements in v4.9-rc1

[Arnd Bergmann]

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

Build regressions/improvements in v4.9-rc1

[Arnd Bergmann]

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

Build regressions/improvements in v4.9-rc1

[Thomas Petazzoni]

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