headers
Ignatios Souvatzis | 8 Feb 2010 09:29
Picon

Re: host endianness

On Mon, Feb 08, 2010 at 08:19:34AM +0000, David Holland wrote:
> On Mon, Feb 08, 2010 at 09:44:35AM +0200, Alan Barrett wrote:
>  > > echo -n 'C!' | od -h | sed 's/[^1234]*//;s/2143/4321/p;d'
>  > 
>  > Host shells might not support "echo -n", so please use printf "%s" "C!"
>  > instead.
> 
> Why not just printf "C!"? However,
> 
>    echo 'C!' | od -N 2 -h | sed 's/[^1234]*//;s/2143/4321/p;d'
> 
> is somewhat tidier.

If this's s'ppossed to be host os and machine independent:

No 'od -h' on Solaris 8, neither on 10.

	-is
Permalink | Reply |
headers
David Holland | 9 Feb 2010 07:10
Picon

Re: host endianness

On Mon, Feb 08, 2010 at 09:29:59AM +0100, Ignatios Souvatzis wrote:
 > > Why not just printf "C!"? However,
 > > 
 > >    echo 'C!' | od -N 2 -h | sed 's/[^1234]*//;s/2143/4321/p;d'
 > > 
 > > is somewhat tidier.
 > 
 > If this's s'ppossed to be host os and machine independent:
 > 
 > No 'od -h' on Solaris 8, neither on 10.

Spoilsport :-)

--

-- 
David A. Holland
dholland <at> netbsd.org
Permalink | Reply |
headers
Ignatios Souvatzis | 9 Feb 2010 10:09
Picon

Re: host endianness

On Tue, Feb 09, 2010 at 06:10:07AM +0000, David Holland wrote:
> On Mon, Feb 08, 2010 at 09:29:59AM +0100, Ignatios Souvatzis wrote:
>  > > Why not just printf "C!"? However,
>  > > 
>  > >    echo 'C!' | od -N 2 -h | sed 's/[^1234]*//;s/2143/4321/p;d'
>  > > 
>  > > is somewhat tidier.
>  > 
>  > If this's s'ppossed to be host os and machine independent:
>  > 
>  > No 'od -h' on Solaris 8, neither on 10.
> 
> Spoilsport :-)

Works fine with 'od -x' instead. What do our standards lawyers say?

	-is
Permalink | Reply |
headers
Alan Barrett | 9 Feb 2010 12:16
Gravatar

Re: host endianness

On Tue, 09 Feb 2010, Ignatios Souvatzis wrote:
> >  > >    echo 'C!' | od -N 2 -h | sed 's/[^1234]*//;s/2143/4321/p;d'
> >  > No 'od -h' on Solaris 8, neither on 10.
> Works fine with 'od -x' instead. What do our standards lawyers say?

TOG says "od -t x2" is standard, and "od -x" is an XSI option.

src/tools/compat already has a configure script that sets BYTE_ORDER,
and I'd prefer it if we could use that definition, or add another mini C
program to the configure script, rather than relying on yet another host
tool.

--apb (Alan Barrett)
Permalink | Reply |
headers
Iain Hibbert | 10 Feb 2010 10:20

Re: host endianness


Well, in summary, you guys are pretty clever.

On Mon, 8 Feb 2010, Izumi Tsutsui wrote:
> With nbtool_config.h like src/sbin/disklabel/bswap.h?
>
> ---
> #include <sys/types.h>
>
> #if HAVE_NBTOOL_CONFIG_H
> #ifndef BYTE_ORDER
> #ifdef WORDS_BIGENDIAN
> #define BYTE_ORDER            BIG_ENDIAN
> #else
> #define BYTE_ORDER            LITTLE_ENDIAN
> #endif
> #endif
> #endif
>
> #define HOST_BYTE_ORDER               BYTE_ORDER

This however, requires modifying the pcc dist for a NetBSD-ism, which I'm
reluctant to do (the native pcc build just uses GNU configure to provide
this definition for each use case)

On Mon, 8 Feb 2010, Christos Zoulas wrote:
> compile and run:
>
> #include <stdio.h>
> union {
(Continue reading)

Permalink | Reply |
headers
Izumi Tsutsui | 10 Feb 2010 11:31
Picon
Gravatar

Re: host endianness

 :
> > #define HOST_BYTE_ORDER               BYTE_ORDER
> 
> This however, requires modifying the pcc dist for a NetBSD-ism, which I'm
> reluctant to do (the native pcc build just uses GNU configure to provide
> this definition for each use case)

What do you actually want to do?

You wrote in the original post:
>> In the native build of pcc(1), we use a pre-generated config.h which
>> contains HOST_(BIG|LITTLE)_ENDIAN and TARGET_(BIG|LITTLE)_ENDIAN
>> definitions which should really be provided at build time.

What is the "native build"?
Should it assume cross build or not?

If you can assume target == host,
(building src/usr.bin/pcc using /usr/bin/pcc)
you can simply use TARGET_ENDIANNESS for the host,
or hardcode it in target config files like
src/gnu/usr.bingcc4/arch/*/auto-host.h.

If you need generic cross-build structures,
you can't assume the host is NetBSD
(i.e. we can't predict what uname(1) returns),
and you might need a generic run-time test as
configure does.
---
Izumi Tsutsui
(Continue reading)

Permalink | Reply |
headers
Iain Hibbert | 11 Feb 2010 11:28

Re: host endianness

On Wed, 10 Feb 2010, Izumi Tsutsui wrote:

> If you can assume target == host,
> (building src/usr.bin/pcc using /usr/bin/pcc)
> you can simply use TARGET_ENDIANNESS for the host,

(apologies, I accidentally replied off list yesterday)

I had another thought - probably my desire to fix this is misplaced!

As pcc is a compiler, its definition of "target" and "host" is not the
same as the Makefile definition (doh). The build "target" will be the pcc
"host", and we never "build.sh distribution" where the pcc "host" and
"target" will differ..

When different host and target is wanted, we would make a cross-compiler
for the current host system using "build.sh -m target tools" (which uses a
configure script to determine host endianness).

I will add a comment to explain that, and use the same endian for target
and host..

thanks,
iain
Permalink | Reply |
headers
Izumi Tsutsui | 11 Feb 2010 16:09
Picon
Gravatar

Re: host endianness

> I had another thought - probably my desire to fix this is misplaced!
> 
> As pcc is a compiler, its definition of "target" and "host" is not the
> same as the Makefile definition (doh). The build "target" will be the pcc
> "host", and we never "build.sh distribution" where the pcc "host" and
> "target" will differ..

There are three types used in gnu toolchains:

target:	architecture which runs binary to be compiled by built tools compiler
host:	architecture which runs built tools compiler
build:	architecture which builds tools complier for target and build hosts

Even gcc had had confusion the latter two on some architecture.
(like PR toolchain/34549)
---
Izumi Tsutsui
Permalink | Reply |
headers
matthew green | 12 Feb 2010 01:31
Picon
Favicon

re: host endianness


   > I had another thought - probably my desire to fix this is misplaced!
   > 
   > As pcc is a compiler, its definition of "target" and "host" is not the
   > same as the Makefile definition (doh). The build "target" will be the pcc
   > "host", and we never "build.sh distribution" where the pcc "host" and
   > "target" will differ..

   There are three types used in gnu toolchains:

   target:	architecture which runs binary to be compiled by built tools compiler
   host:	architecture which runs built tools compiler
   build:	architecture which builds tools complier for target and build hosts

in netbsd, src/tools/gcc has host == build, target = build.sh -m value.
for /usr/bin/gcc, host == target, and build = anything.

i like the commited change.

iain, the GCC build for /usr/bin/gcc runs a ./configure script as it
needs to build host progarms to run, so, when it comes time to doing
pcc properly cross, that's entirely acceptable as a solution.

.mrg.
Permalink | Reply |
headers
Iain Hibbert | 12 Feb 2010 23:44

re: host endianness

On Fri, 12 Feb 2010, matthew green wrote:

> in netbsd, src/tools/gcc has host == build, target = build.sh -m value.
> for /usr/bin/gcc, host == target, and build = anything.

I think pcc is at the same place now, it can be built as a cross compiler
(tools/pcc with HAVE_PCC=yes) or cross built (/usr/bin/pcc with MKPCC=yes
MKPCCCMDS=yes). Though, it still has trouble in the NetBSD header files,
so not ready for mainline quite yet..

iain
Permalink | Reply |

Gmane