Re: kernel-2.2.1-undefined references.

[craig at jcb-sc dot com]

>> Be aware that __builtin_return_address probably will stop working
>> someday in gcc.  Read my latest tirade to get an idea of why that is.
>
>Craig, gcc is the GNU project's compiler.  That means that one of its
>important roles is to be able to compile kernels (Linux or the Hurd).
>Since you're the Fortran guy, you are somewhat insulated from these
>issues (Fortran just doesn't make provisions for writing "close to the
>machine" code).

Actually, I'm not talking as the "Fortran guy".  I'm talking as someone
who understands operating systems development and computer-architecture
issues better than he understands Fortran compiler development.

And, note, C doesn't really make provisions for writing "close to the
machine" code any better than Fortran.  It provides a *model* that
more closely parallels many of today's most popular architectures,
making it more "obvious" to today's programmers that a straightforward
translation is possible, but *nothing* in the C standard, aside
from stuff like `volatile' (assuming that's even in the standard),
says anything about the mapping to the underlying machine.  But the
"as if" rule means you can't just *assume* the machine will behave
a certain way when running C code.

(I've worked on operating systems written in Fortran, assembler, and
PL/1, but no C, by the way.)

I've written on this range of topics, especially involving C, C++,
Fortran, and operators, on USENET many times in the past, so I don't
think it behooves anyone to go into more details.  I'll just disagree
with the assertion and leave it at that, noting that the way Fortran
offers similar *effects* as almost all of C's facilities does, usually,
require somewhat more typing.  :)

>The result is that gcc is going to have to continue to support certain
>extensions for the indefinite future (though kernel developers should
>not assume that "it worked in version x.y.z" is a commitment for the
>future, we will need to supply some mechanisms in some cases.

Oh, I agree.  I'm not saying that feature *will* stop working, just
that, at some point in the future, when gcc is *expected* to support
high-performance platforms like massively parallel machines, it will
either have to stop returning anything other than 0 from that
function in many cases, or the mere use of that function will
mandate a substantial drop in performance of the compiled code,
if my guesses about future directions of computing are correct (and
they're hardly controversial).

If that substantial drop happens, the users who notice it will
complain saying "it stopped working", is my prediction.

>It may actually be easier to support features like this if they are
>specified at a higher level of abstraction.  That is, understand why Linus
>is using some trick to do something, and then recommend alternative ways
>to do them that are actually supportable.  e.g. if the real job is to get
>a stack trace, maybe there could be some facility to provide for that
>directly, possibly borrowing some code from gdb.

Exactly.  Doing that is pretty hard, but I think it's better to try
and do it up front, offer the most SWYM-like ways for people like
Linus to express themselves, and support *that* as well as possible.

(After all, what the heck *is* a "stack trace", precisely defined,
and exactly how does "getting" it help Linux developers?  As soon
as you start answering by talking about frame and stack pointers,
you've headed off the SWYM reservation and are assuming a particular
machine model for gcc to permanently cater to, at the expense of
more powerful machines that don't fit that model.)

Instead, for the time being, practical concerns dictate (or have
dictated) offering fairly straightforward hooks of the DWIS variety,
which tend to mandate some kind of common machine model which,
though ill-defined, matches most or all of today's targets, but
which won't necessarily match some of tomorrow's.

If and when that happens, the old DWIS constructs must, for the
new, different models, either be dropped (rendered innocuous,
whatever), or implemented such that their mere presence shuts
down lots of important optimizations.

>Despite Linus's tendency to be insulting, he is one our most important
>"customers" (or, more accurately, the people who depend on the Linux
>kernel working are).  We need to have sufficient facilities so that C plus
>inline assembly can do the whole job.

That's a highly worthy goal.  Do you think gcc's important customers
also include all those people who just write straightforward,
standard-conforming code and want it to go as fast as possible on
the most powerful machines available at the time?  I do, and these
customers basically rely on the SWYM aspects of code generation for
gcc's family of languages.

Do you think gcc can evolve to handle both those kinds of customers
and the Linux kind, which expects all the existing DWIS-like hooks
(which assume a certain static machine model) to continue working
forever, without becoming unmaintainable?  I don't.

In any case, do you think it'll be *easier* or *harder* to maintain
gcc if products like Linux are encouraged to slowly dispense with
dependencies on gcc's current DWIS-like extensions, so both Linux
and gcc are less dependent on assuming a certain static machine
model that has informed the development and use of so many of gcc's
extensions?

I think it'd be *easier*, and the sooner it's done, the better.

Finally, I'll ask a different version of the same question I posed
earlier:

Will it ever be acceptable for any version of gcc to generate substantially
different code for an application due to the addition of a single
reference to a function like `__builtin_return_address', making for
possibly *large* differences in performance between the two versions,
and perhaps in the reproducibility of bugs in the code, due to
all sorts of code and data being moved around?

        tq vm, (burley)

P.S. It's unclear to me whether C will survive long enough to make
any of the issues I raise above matter.  That is, if we can predict
its "death", meaning the point at which improving it further becomes
a non-issue for the industry, then perhaps we can also predict the
final sorts of uses to which it'll be put.  There's reasons to believe
those uses will be much more DWIS-like than SWYM-like, and others
reasons to believe the other way.  I lean towards the former, which
is why I don't get excited about the SWYM features C9X or whoever
are adding to the language: I think they'll hasten, not delay, the
death of C, because they'll just keep making a hard language harder
to use, which is death for SWYM purposes.

Anyway, once the industry decides C will finally become a DWIS-like
language for sure (let's say), then its "body of development" will
become like a corpse -- anyone who wants to pick at it, by adding
the DWIS features they need at the moment, will feel comfortable
doing so.  They'll know they aren't coding for the distant future.
gcc can then support whatever DWIS extensions it wants at that point.

But the same issues persist for other gcc languages, though I think
C++ will die before C does, because they include Fortran, Java,
Ada, and so on.

So the gcc *back end* will have to support *all* of these combinations
of SWYM and DWIS extensions, and still meet all the expectations placed
on it to generate great code for every machine imaginable.

I think that might become extremely hard to manage someday, and the
symptoms will probably be a serious development split when it comes
to supporting some new, weird, high-performance machine, for which
many of the DWIS extensions make little or no sense.

But I could be wrong, and wouldn't mind being proven so: if gcc could
literally become the world's catch-all code generator, beautifully
optimizing clean code targeting every machine, including the bizarre
ones, while also accommodating the needs of people who want to micro-
manage its code generation, that'd be *great*.