> So now the kernel is using incorrect opcodes to get the right output.
[...]
For the moment, Albert, there are a select few spots where I used
instructions that were known to create the right opcodes *ONLY* to avoid
craziness and panic that could possibly ensue if gas might have
misassembled it. It was a judgement call that I made when I saw the huge
amount of difference between the binutils versions on this box versus that
box versus that box. I didn't have the resources available to test every
single possible combination of binutils so I took the lowest common
denominator and ran with it. I chose to err on the side of caution by
having a bootable, usable kernel than pushing the line by trying to use
instructions that are known to cause problems on the older versions of
binutils that people are using (for some strange reason unbeknownst to
me).
When everyone (some day) gets off their collective asses (actually, all
that has to really happen is distro packagers have to update binutils)
then I'll change it to be syntactically perfect. Right now, as it stands,
its pretty darn close (for a first patch, at least). The important thing
is that it assembles properly and the only people that have to "worry"
about it (eg bootcode hackers) all recognize that there is *no tangible
difference* in the new stuff.
Have you even looked at the code yet? It's still the same damn code that's
been there for ages. It's simply been written in a different format.
That's it, that's all. It's not as if I had to write this on every line:
"XXX: 'mzpq %(foop)(al)p, $$4' should be 'movb $4, %al' but gas is dumb"
> When you change to using the correct opcodes, what happens?
> Do all the assemblers that tolerate the current code become junk?
Well, I certainly *feel* the time has come to upgrade our minimum
requirements of binutils, considering that the minimums listed in
Documentation/Changes are horribly out of date. Those versions of binutils
haven't been touched in over *A YEAR AND A HALF*. That's a bit old,
wouldn't you agree? As I see it, Linus does, and he's a proponent of
breaking with backwards compatibility if the rewards are great enough. I
feel that they are.
I don't have a sick hatred for as86, I just think its ridiculous to have
an outside requirement on a single, outdated tool to build the kernel when
we have that tool already available and packaged with binutils.
> Did you tell Linus that you were using the WRONG opcodes?
> I'm guessing you just snuck that by him. (well Linus?)
I'm using the same exact opcodes as the old bootcode. Now if you were
referring to the instructions used in the source to produce those
opcodes, let me say this: they could be written perfectly right now.
I just figured that it would be safer at this moment in time to leave them
be and let them work. Once things settle a bit and people are using
updated tools, it'll be updated.
Linus has already responded to the list regarding the fact that we use
"movl" where "movw" would be more appropriate in order to satisfy older
broken gas versions. He said that working around the bugs in gas was
alright, as long as they were eventually fixed (which they *already* are
in 2.9.5).
> Being forced to use gcc 2.7 and up is OK. The old ones are broken.
> Being forced to change gas because you don't LIKE as86 is awful.
Not a correct assumption to make, Albert. :)
I dig as86. I use it every once in a while.
I'm doing a lot of people some good with this:
(a) Removing a dependency on as86; yes, if you like it that's no big deal.
What about those who want those extra inodes taken up by it? What about
those that never use it, see it, or even know its there but *depend* on it
to build their kernels?
(b) Everyone *should* be using the latest binutils, not only because I'd
like to but also because it is full of bugfixes, optimizations, etc. Yes,
people are reluctant to do it, but afterwards its a good thing for
everyone. And those that it would bother the most (diy'ers), aren't too
put off by upgrading binutils; distro makers will include them with their
distros, etc.
The latest version I asked for was 2.9.1.0.7 which was listed as a
recommended minimum in *2.2* -- It's not unreasonable to ask for an update
to a significantly important set of tools for *2.4*.
How can you possibly use the argument about gcc and turn around and miss
the fact that the 'old ones are broken' when referring to binutils as
well! The 2.8's are borked, most early 2.9.1's are as well.
>
> > You bring up some valid points, but I feel the intent of the patch was
> > misjudged.
>
> The intent was...? (screw people not running the very latest?)
To remove a dependency on an outside program necessary to build the
kernel.
To slowly begin to migrate people to the new binutils.
To initiate world peace.
To piss you off. :)
> > Just a few points on the latest binutils (which now might be a requirement
> > of the next 2.3): The changes to the bootcode were intended to be
> > included with a kernel that had a minimum binutils of 2.9.1.0.7, because
> > I didn't feel it was worth a binutils upgrade to 2.9.5 to each and every
> > person in order to have "syntactic perfection" (due to the fact that only
> > the *latest* binutils produce the most correct code for most every case).
> > I just wanted joe user to be able to still compile, but without the
> > dependency on as86.
>
> So now joe user (who already has as86) must upgrade to 2.9.1.0.7
> or later, disturbing fairly important parts of the system. Had you
> simply changed to NASM (still pointless IMHO), I could at least
> upgrade without risk to gcc. (kernels are easy because of LILO)
>
> This all because you have some weird hatred of Genuine Intel syntax?
> I wish you were local so that I could scream obscenities at you.
2.9.1.0.7 was already the recommended binutils for 2.2, and most distro's
use a version much later than that. I wasn't out there to screw people
over, I was there to make their lives better(tm). It's a good move, a good
idea, and one that I'm glad was blessed by Linus.
Thanks for livening up the discussion a bit :)
Chris Noe
(stiker@northlink.com)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/