Re: [RFC 0/7] cgcc: use gcc -dumpmachine

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 17/02/2019 15:31, Luc Van Oostenryck wrote:
> This experimental series contains:
> * some cleanup patches in preparation of:
> * Uwe's patch for gcc -dumpmachine but:
>   - with more code sharing
>   - using a pattern for the platform (and so
>     is much more generic)
>   - added support for x86-x32
> * tentative cleanup of cgcc's add_specs(), splitting
>   it into an 'OS' part and an 'arch' part.
> 
> All this is not really tested, higly experimental, ...
> 
> Note: the patches should be applied over the previous series
>       adding support for '-mfloat-abi'.
> 
> The series is also available at:
> 	git://github.com/lucvoo/sparse-dev.git cgcc-dumpmachine

I have tested this branch on Linux Mint 18.3 32-bit x86, Linux
Mint 19.1 64-bit x86_64 and cygwin 64-bit x86_64. (I have not
had time to try Ubuntu and fedora, but I expect to see the
identical behaviour).

No regressions noted. This is with 'make check; make selfcheck;
make install' along with a git build.

This does not help with platforms I don't have available, of
course (particularly mips/arm), but it is something. ;-)

I have some minor comments on the patches, but I will have to
wait until tomorrow now (I have to get some sleep).

However, there was one thing I wanted to mention tonight. These
patches change the interface of cgcc in a non-backward compatible
way. In particular, the -target=<spec> parameter, which can and
pretty much _had_ to be specified multiple times (well OK twice
in practice), to specify _both_ the 'OS' and 'arch' specs.

Before these patches, the <spec>s available to the -target
parameter was:

sunos
linux
gnu/kfreebsd
openbsd
freebsd
netbsd
darwin
gnu
unix
cygwin
i386
sparc
sparc64
x86_64
ppc
ppc64
s390x
arm
aarch64
host_os_specs
host_arch_specs

After these patches, the <spec>s available are now only:

i386
sparc
sparc64
x86_64
ppc
ppc64
ppc64+be
ppc64+le
s390x
arm
arm+hf
aarch64

Note that the tokens 'host_os_specs' and 'host_arch_specs'
were useful (even though they _could have_ been replaced
on the command-line by "$(uname -s)" and "$(uname -m)"
respectively).

This is a bad loss of functionality.

I have to go now.

ATB,
Ramsay Jones




[Index of Archives]     [Newbies FAQ]     [LKML]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Trinity Fuzzer Tool]

  Powered by Linux