Re: EGCS breaks what(1)
Alternately, we could jimmy around with the current hack, and prefix it with 4 NULs, and see what happened. Sorry, I haven't tested this idea, as I've not yet made the EGCS jump. egcs aligns long (= about 28 bytes) strings to 32-byte boundaries. This adds up to 27 NULs to sccsid[] depending on the alignment of sccsidp[]. Aligning long strings to 32-byte boundaries is a pessimisation in kernels (because it makes poor locality poorer), especially on 486's where the cache line size is 16. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS breaks what(1)
'what' is broken. C does not impose any sort of address ordering restriction on globals or autos that are declared next to each other. Right, except that 'what' isn't broken. It is vers.c (and conf/newvers.sh) that is broken, believing that the two variables will be allocating in contiguous memory. Changing newvers.sh to generate char sccs[] = @( #) FreeBSD ...; char version = FreeBSD ...; will make what on the kernel work again, at the expense of about 100 duplicated bytes. The real question is whether the extreme alignment and padding used by EGCS can be turned off, especially for 486s. John To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS breaks what(1)
The real question is whether the extreme alignment and padding used by EGCS can be turned off, especially for 486s. Considering it... probably based on -m486. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS breaks what(1)
On Tue, 6 Apr 1999, Bruce Evans wrote: Alternately, we could jimmy around with the current hack, and prefix it with 4 NULs, and see what happened. Sorry, I haven't tested this idea, as I've not yet made the EGCS jump. egcs aligns long (= about 28 bytes) strings to 32-byte boundaries. This adds up to 27 NULs to sccsid[] depending on the alignment of sccsidp[]. Aligning long strings to 32-byte boundaries is a pessimisation in kernels (because it makes poor locality poorer), especially on 486's where the cache line size is 16. Bruce not aligning data is extremely expensive on PII's rob To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS breaks what(1)
'what' is broken. C does not impose any sort of address ordering restriction on globals or autos that are declared next to each other. Right, except that 'what' isn't broken. It is vers.c (and conf/newvers.sh) that is broken, believing that the two variables will be allocating in contiguous memory. Changing newvers.sh to generate char sccs[] = @( #) FreeBSD ...; char version = FreeBSD ...; I will assume you meant char *version here. will make what on the kernel work again, at the expense of about 100 duplicated bytes. Check me if I'm wrong, but could we not do the same thing without the duplication: char sccs[] = @( #) FreeBSD ...; char *version = sccs + 4; Happy hacking, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS breaks what(1)
: Okay, let me be a little clearer ;) What(1) on the kernel no longer works
:because previously, the
:char sccs[] = { '@', '(', '#', ')' };
:char version[] = blahhhfoo;
:Was contiguous. However, nowadays, nice EGCS pads 4 bytes (WHY?!?!) between
:those. So it appears @(#)\0\0\0\0FreeBSD. in the binary. Of course,
:strings are null-terminated... :P I don't know why EGCS does this!
:
: Brian Feldman_ __ ___ ___ ___ ___
: gr...@unixhelp.org_ __ ___ | _ ) __| \
: FreeBSD: The Power to Serve! _ __ | _ \__ \ |) |
: http://www.freebsd.org _ |___/___/___/
'what' is broken. C does not impose any sort of address ordering
restriction on globals or autos that are declared next to each other.
While it is true that programmers regularly make assumptions in regards
to the placement and alignment of fields in structures and the
placement and alignment of arguments to procedures, it does not follow
that programmers can make assumptions in regards to the placement and
alignment of globals.
EGCS is trying to optimize access to the array by aligning it, in order
to reduce cache line burst-from-meory inefficiencies. It happens
to break bad assumptions made in 'what'.
-Matt
Matthew Dillon
dil...@backplane.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: EGCS breaks what(1)
On Monday, 5th April 1999, Matthew Dillon wrote:
:char sccs[] = { '@', '(', '#', ')' };
:char version[] = blahhhfoo;
:Was contiguous.
'what' is broken. C does not impose any sort of address ordering
restriction on globals or autos that are declared next to each other.
Well, it's really an abuse of 'what', and not anything wrong with 'what'
ifself. It will continue to work fine doing the job it was designed to do.
The NetBSD folks faced this problem some time ago, and I believe their
solution was to duplicate the version information. So, version[] is the
same as it used to be, and sccs[] is 4 bytes longer than version[] to hold
a complete copy, and the @(#) prefix. This is then completely portable.
Alternately, we could jimmy around with the current hack, and prefix it
with 4 NULs, and see what happened. Sorry, I haven't tested this idea, as
I've not yet made the EGCS jump.
Stephen.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
