Re: Unify the various copies of libgcc into lib

[Palmer Dabbelt]

On Wed, 24 May 2017 02:21:22 PDT (-0700), ge...@linux-m68k.org wrote:
> Hi Palmer,
>
> On Wed, May 24, 2017 at 12:05 AM, Palmer Dabbelt  wrote:
>> I'm in the process of submitting the RISC-V Linux port, and someone noticed
>> that we were adding copies of some libgcc emulation routines that were the 
>> same
>> as some of the other ports.  This prompted me to go through and check all the
>> ports for libgcc.h and to merge the versions that were functionally 
>> identical.
>>
>> The only difference in libgcc.h was that there was a #define for little vs 
>> big
>> endian.  The differences in the emulation routines were all just whitespace.
>>
>> This patch set comes in two parts:
>>
>>  * Patch 1 adds new copies of all the C files copied from libgcc, as well as
>>moving libgcc.h to include/lib (that's a new folder, which probably means
>>it's the wrong place to put it, but I couldn't find anything better).  
>> There
>>are Kconfig entries for each of these library functions so architectures 
>> can
>>select them one at a time.
>
> I would call the Kconfig symbols GENERIC_* instead of LIB_*, for consistency
> with other generic implementations.

OK.  I'll include that in my v2 patch set.

>>  * The rest of the patches convert each architecture over to the new system.
>
> Thanks! For all but "[PATCH 4/7] mips: ...":
>
> Reviewed-by: Geert Uytterhoeven 

Thanks!

>> Unless I screwed something up, this patch set shouldn't actually change any
>> functionality.  Unfortunately I don't actually have all these cross compilers
>> setup so I can't actually test any of this, but I did convert the RISC-V port
>> over to using this system and it appears to be OK there so at least this 
>> isn't
>> completely broken.
>
> https://www.kernel.org/pub/tools/crosstool/

Cool.  I'll build everything before I submit a v2.

Re: Unify the various copies of libgcc into lib

[Palmer Dabbelt]

On Wed, 24 May 2017 02:21:22 PDT (-0700), ge...@linux-m68k.org wrote:
> Hi Palmer,
>
> On Wed, May 24, 2017 at 12:05 AM, Palmer Dabbelt  wrote:
>> I'm in the process of submitting the RISC-V Linux port, and someone noticed
>> that we were adding copies of some libgcc emulation routines that were the 
>> same
>> as some of the other ports.  This prompted me to go through and check all the
>> ports for libgcc.h and to merge the versions that were functionally 
>> identical.
>>
>> The only difference in libgcc.h was that there was a #define for little vs 
>> big
>> endian.  The differences in the emulation routines were all just whitespace.
>>
>> This patch set comes in two parts:
>>
>>  * Patch 1 adds new copies of all the C files copied from libgcc, as well as
>>moving libgcc.h to include/lib (that's a new folder, which probably means
>>it's the wrong place to put it, but I couldn't find anything better).  
>> There
>>are Kconfig entries for each of these library functions so architectures 
>> can
>>select them one at a time.
>
> I would call the Kconfig symbols GENERIC_* instead of LIB_*, for consistency
> with other generic implementations.

OK.  I'll include that in my v2 patch set.

>>  * The rest of the patches convert each architecture over to the new system.
>
> Thanks! For all but "[PATCH 4/7] mips: ...":
>
> Reviewed-by: Geert Uytterhoeven 

Thanks!

>> Unless I screwed something up, this patch set shouldn't actually change any
>> functionality.  Unfortunately I don't actually have all these cross compilers
>> setup so I can't actually test any of this, but I did convert the RISC-V port
>> over to using this system and it appears to be OK there so at least this 
>> isn't
>> completely broken.
>
> https://www.kernel.org/pub/tools/crosstool/

Cool.  I'll build everything before I submit a v2.

Re: Unify the various copies of libgcc into lib

[John Paul Adrian Glaubitz]

On Wed, May 24, 2017 at 02:49:24PM +0100, David Howells wrote:
> Palmer Dabbelt  wrote:
> 
> > ... Unfortunately I don't actually have all these cross compilers setup...
> 
> If you have Fedora, you have the following available as standard
> RPMs:

And if you need more than just the cross-compilers (e.g. libraries for
the target architecture), I recommend a Debian Stretch or newer.

Debian's Multi-Arch allows one to install libraries for the target
system onto your build system. I have used that extensively in the
past, for example to bootstrap GHC for various architectures [1].

Adrian

> [1] https://wiki.debian.org/PortsDocs/BootstrappingGHC

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Unify the various copies of libgcc into lib

[John Paul Adrian Glaubitz]

On Wed, May 24, 2017 at 02:49:24PM +0100, David Howells wrote:
> Palmer Dabbelt  wrote:
> 
> > ... Unfortunately I don't actually have all these cross compilers setup...
> 
> If you have Fedora, you have the following available as standard
> RPMs:

And if you need more than just the cross-compilers (e.g. libraries for
the target architecture), I recommend a Debian Stretch or newer.

Debian's Multi-Arch allows one to install libraries for the target
system onto your build system. I have used that extensively in the
past, for example to bootstrap GHC for various architectures [1].

Adrian

> [1] https://wiki.debian.org/PortsDocs/BootstrappingGHC

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Unify the various copies of libgcc into lib

[David Howells]

Palmer Dabbelt  wrote:

> ... Unfortunately I don't actually have all these cross compilers setup...

If you have Fedora, you have the following available as standard RPMs:

gcc-aarch64-linux-gnu
gcc-alpha-linux-gnu
gcc-arm-linux-gnu
gcc-avr32-linux-gnu
gcc-bfin-linux-gnu
gcc-c6x-linux-gnu
gcc-cris-linux-gnu
gcc-frv-linux-gnu
gcc-h8300-linux-gnu
gcc-hppa-linux-gnu
gcc-hppa64-linux-gnu
gcc-ia64-linux-gnu
gcc-m32r-linux-gnu
gcc-m68k-linux-gnu
gcc-microblaze-linux-gnu
gcc-mips64-linux-gnu
gcc-mn10300-linux-gnu
gcc-nios2-linux-gnu
gcc-powerpc64-linux-gnu
gcc-ppc64-linux-gnu
gcc-s390x-linux-gnu
gcc-sh-linux-gnu
gcc-sparc64-linux-gnu
gcc-tile-linux-gnu
gcc-xtensa-linux-gnu

They're built from the same sources as the gcc rpm (and the matching binutils
cross rpms are built from the same sources as the binutils rpm) - it's only
the spec file that's different, and they lag a bit behind the core
gcc/binutils as they only get updated after those change.

So in Fedora 25 these are all gcc-6 and in Fedora 26 they're all gcc-7.

David

Re: Unify the various copies of libgcc into lib

[David Howells]

Palmer Dabbelt  wrote:

> ... Unfortunately I don't actually have all these cross compilers setup...

If you have Fedora, you have the following available as standard RPMs:

gcc-aarch64-linux-gnu
gcc-alpha-linux-gnu
gcc-arm-linux-gnu
gcc-avr32-linux-gnu
gcc-bfin-linux-gnu
gcc-c6x-linux-gnu
gcc-cris-linux-gnu
gcc-frv-linux-gnu
gcc-h8300-linux-gnu
gcc-hppa-linux-gnu
gcc-hppa64-linux-gnu
gcc-ia64-linux-gnu
gcc-m32r-linux-gnu
gcc-m68k-linux-gnu
gcc-microblaze-linux-gnu
gcc-mips64-linux-gnu
gcc-mn10300-linux-gnu
gcc-nios2-linux-gnu
gcc-powerpc64-linux-gnu
gcc-ppc64-linux-gnu
gcc-s390x-linux-gnu
gcc-sh-linux-gnu
gcc-sparc64-linux-gnu
gcc-tile-linux-gnu
gcc-xtensa-linux-gnu

They're built from the same sources as the gcc rpm (and the matching binutils
cross rpms are built from the same sources as the binutils rpm) - it's only
the spec file that's different, and they lag a bit behind the core
gcc/binutils as they only get updated after those change.

So in Fedora 25 these are all gcc-6 and in Fedora 26 they're all gcc-7.

David

Re: Unify the various copies of libgcc into lib

[Geert Uytterhoeven]

Hi Palmer,

On Wed, May 24, 2017 at 12:05 AM, Palmer Dabbelt  wrote:
> I'm in the process of submitting the RISC-V Linux port, and someone noticed
> that we were adding copies of some libgcc emulation routines that were the 
> same
> as some of the other ports.  This prompted me to go through and check all the
> ports for libgcc.h and to merge the versions that were functionally identical.
>
> The only difference in libgcc.h was that there was a #define for little vs big
> endian.  The differences in the emulation routines were all just whitespace.
>
> This patch set comes in two parts:
>
>  * Patch 1 adds new copies of all the C files copied from libgcc, as well as
>moving libgcc.h to include/lib (that's a new folder, which probably means
>it's the wrong place to put it, but I couldn't find anything better).  
> There
>are Kconfig entries for each of these library functions so architectures 
> can
>select them one at a time.

I would call the Kconfig symbols GENERIC_* instead of LIB_*, for consistency
with other generic implementations.

>  * The rest of the patches convert each architecture over to the new system.

Thanks! For all but "[PATCH 4/7] mips: ...":

Reviewed-by: Geert Uytterhoeven 

> Unless I screwed something up, this patch set shouldn't actually change any
> functionality.  Unfortunately I don't actually have all these cross compilers
> setup so I can't actually test any of this, but I did convert the RISC-V port
> over to using this system and it appears to be OK there so at least this isn't
> completely broken.

https://www.kernel.org/pub/tools/crosstool/

BTW, blackfin, h8300, m68k, and parisc have their own implementations, too.
They look different, but I believe their functionality is identical.
They can be converted later, though.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

Re: Unify the various copies of libgcc into lib

[Geert Uytterhoeven]

Hi Palmer,

On Wed, May 24, 2017 at 12:05 AM, Palmer Dabbelt  wrote:
> I'm in the process of submitting the RISC-V Linux port, and someone noticed
> that we were adding copies of some libgcc emulation routines that were the 
> same
> as some of the other ports.  This prompted me to go through and check all the
> ports for libgcc.h and to merge the versions that were functionally identical.
>
> The only difference in libgcc.h was that there was a #define for little vs big
> endian.  The differences in the emulation routines were all just whitespace.
>
> This patch set comes in two parts:
>
>  * Patch 1 adds new copies of all the C files copied from libgcc, as well as
>moving libgcc.h to include/lib (that's a new folder, which probably means
>it's the wrong place to put it, but I couldn't find anything better).  
> There
>are Kconfig entries for each of these library functions so architectures 
> can
>select them one at a time.

I would call the Kconfig symbols GENERIC_* instead of LIB_*, for consistency
with other generic implementations.

>  * The rest of the patches convert each architecture over to the new system.

Thanks! For all but "[PATCH 4/7] mips: ...":

Reviewed-by: Geert Uytterhoeven 

> Unless I screwed something up, this patch set shouldn't actually change any
> functionality.  Unfortunately I don't actually have all these cross compilers
> setup so I can't actually test any of this, but I did convert the RISC-V port
> over to using this system and it appears to be OK there so at least this isn't
> completely broken.

https://www.kernel.org/pub/tools/crosstool/

BTW, blackfin, h8300, m68k, and parisc have their own implementations, too.
They look different, but I believe their functionality is identical.
They can be converted later, though.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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