From: Tom Rini <trini@kernel.crashing.org>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: post-halloween 0.2
Date: Wed, 30 Oct 2002 13:23:06 -0700 [thread overview]
Message-ID: <20021030202306.GB27472@opus.bloom.county> (raw)
In-Reply-To: <770420000.1036007878@flay>
On Wed, Oct 30, 2002 at 11:57:58AM -0800, Martin J. Bligh wrote:
> >> > Can you also mention not using gcc 3.0.x (stack pointer handling bug)
> >>
> >> Any chance of putting this sort of thing as #error detection
> >> in the compile so it auto-breaks? I seem to recall that's done
> >> for some versions of GCC already ...
> >
> > And what arch is that for? Adding a nice facility for per-arch (and
> > maybe global) compiler / binutils testing would be nice, if we're going
> > to go down that road..
>
> Alan, would you consider something like (TOTALLY untested):
[snip]
So it's a global thing then?
> If you like it, I'll get it tested.
>
> Probably some things are per-arch and some are global, at a guess.
> Currently we have:
[snip]
And then ppc32 does some binutils checks, not-in-C and before we let the
kernel get too far. What I was proposing is we add something outside of
the direct kernel src (something in scripts? Generic make magic?) to
verify that a compiler / binutils / whatever tool is a good version.
This is rather easy for binutils + obvious instruction problem (missing
/ incorrect operands), and for compiler versions, something to generate
a test-file and then see if it compiles.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
next prev parent reply other threads:[~2002-10-30 20:16 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-30 17:11 post-halloween 0.2 Dave Jones
2002-10-30 18:47 ` Ian Soboroff
2002-10-30 18:52 ` Greg KH
2002-10-30 19:02 ` Ian Soboroff
2002-10-30 19:08 ` Greg KH
2002-10-30 19:13 ` Patrick Mochel
2002-10-30 19:16 ` Ian Soboroff
2002-10-30 19:23 ` Patrick Mochel
2002-10-30 19:17 ` Ian Soboroff
2002-10-30 19:33 ` Alan Cox
2002-10-30 19:17 ` Martin J. Bligh
2002-10-30 19:50 ` Tom Rini
2002-10-30 19:57 ` Martin J. Bligh
2002-10-30 20:23 ` Tom Rini [this message]
2002-10-30 20:50 ` Arador
2002-10-30 21:03 ` Martin J. Bligh
2002-10-31 0:12 ` Alan Cox
2002-10-31 0:47 ` Dave Jones
2002-10-31 11:48 ` Alan Cox
2002-11-01 1:29 ` Bill Davidsen
2002-10-30 23:09 ` Pavel Machek
2002-10-31 0:35 ` Skip Ford
2002-10-31 6:27 ` Htree ate my hard drive, was: " Duncan Sands
2002-10-31 8:07 ` Andreas Dilger
2002-10-31 8:20 ` Duncan Sands
2002-11-04 22:42 ` [Ext2-devel] " Stephen C. Tweedie
2002-11-04 22:59 ` Duncan Sands
2002-11-04 23:22 ` Udo A. Steinberg
2002-10-31 23:05 ` Mike Civil
2002-11-03 20:42 ` Duncan Sands
2002-11-03 22:00 ` Mike Civil
2002-11-03 22:11 ` Martin Waitz
2002-11-07 15:36 ` Jan Kara
2002-11-07 15:44 ` Dave Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021030202306.GB27472@opus.bloom.county \
--to=trini@kernel.crashing.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox