Re: get_current is __pure__, maybe __const__ even

[Albert Cahalan <albert@users.sf.net>]

On Wed, 2004-09-15 at 22:36, William Lee Irwin III wrote:
> On Wed, Sep 15, 2004 at 07:15:18PM -0400, Jakub Jelinek wrote:
> >>> current will certainly change in schedule (),
> 
> On Wed, Sep 15, 2004 at 10:10:20PM -0400, Albert Cahalan wrote:
> > Not really!
> 
> Yes it does. The interior of schedule() is C and must be compiled also.

Sure. It doesn't matter. The part that matters is
all arch-specific assembly.

Hey, the arm port already uses __const__.
Unless the arm port is broken, there's proof.

> At some point in the past, I wrote:
> >> Why would barrier() not suffice?
> 
> On Wed, Sep 15, 2004 at 10:10:20PM -0400, Albert Cahalan wrote:
> > I don't think even barrier() is needed.
> > Suppose gcc were to cache the value of
> > current over a schedule. Who cares? It'll
> > be the same after schedule() as it was
> > before.
> 
> Not over a call to schedule(). In the midst of schedule().

OK, let's look.

First, there's fork/vfork/clone. At no point does
"current" change. A process comes into existance
with a ready-made current.

Second, there's sched.c with context_switch().
That does everything via switch_to, like so:

/* Here we just switch the register state and the stack. */
switch_to(prev, next, prev);

No problem. Now I only need to show that switch_to()
is safe. Unfortunately, it's arch-specific code.
I'll look at a few examples...

x86_64:   assembly, and thus OK
i386:     assembly, and thus OK
ppc:      assembly, and thus OK
arm:      already uses __const__ :-)

To find a problem, you need to find an arch which
runs C code with current being inconsistent with
the stack or registers. That would be wild and evil.
In any case, adding __attribute__((__const__)) is
an arch-specific change. A truly evil arch running
C code with an inconsistent current can just leave
off the attribute or, better yet, stop being evil.