[U-Boot-Users] [PATCH] tools/envcrc.c: use the target sizeof rather than build

[Mike Frysinger]

On Sunday 30 March 2008, Wolfgang Denk wrote:
> In message <1206908872-2141-1-git-send-email-vapier at gentoo.org> you wrote:
> > The envcrc.c does sizeof(unsigned long) when calculating the crc, but
> > this is done with the build toolchain instead of the target toolchain, so
> > if the build is a 64bit system but the target is 32bits, the size will
> > obviously be wrong.  This introduces a sizeof.sh script to calculate the
> > required sizeof() value of any type with any compiler.
>
> It seems this script requires up to 64 runs  of  the  C  compiler.  I
> consider this pretty expensive. Isn't there a cheaper way to do that?

if the type you're testing for is 64bytes, then yes it'll run that many times, 
as it should.  i guess it should be even larger though considering there are 
types out there that are 128bytes or bigger.

but 64 is the upper limit before the script gives up.  it starts at 0 and 
counts up.  so on a normal run, it'll execute either 4 or 8 times before it 
gets success.

> Consider the simple logic used to decide between 32 versus 64 bit
> pointer types - shouldn't this be sufficient here, too?

the script can be used to calculate any type.  i imagine i could make it 
increment by 4 and then count down to find the limit, but i dont really think 
the savings is worth while.

> > --- /dev/null
> > +++ b/tools/sizeof.sh
> > @@ -0,0 +1,35 @@
> > +#!/bin/sh
> > +# Get the sizeof(type) for a compiler
> > +
> > +type="$*"
> > +CC=${CC:-gcc}
> > +
> > +if [ -z "$type" ] ; then
> > +	echo "Usage: sizeof.sh <type>" 1>&2
> > +	exit 1
> > +fi
> > +
> > +test_size() {
> > +	cat <<-EOF > sizeof.c
> > +	typedef $type ac__type_sizeof_;
> > +	int main() {
> > +		static int test_array [1 - 2 * !(((long int) (sizeof
> > (ac__type_sizeof_))) <= $size)]; +		test_array [0] = 0;
> > +		return 0;
> > +	}
> > +	EOF
> > +	${CC} -c sizeof.c >/dev/null 2>&1
> > +	ret=$?
> > +	rm -f sizeof.[co]
> > +	return $ret
> > +}
>
> Are there no Copyrights / License conditions attached to  this  code?
> Where exactly is it coming from?

i wrote it.  the one magic line (the test_array) is based on code from 
autoconf, so i guess it'll be GPL-2.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080330/b11bd4d5/attachment.pgp