Re: What exactly do 32-bit x86 exceptions push on the stack in the CS slot?

[Linus Torvalds]

On Mon, Nov 21, 2016 at 10:26 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> On 11/21/16 10:00, Linus Torvalds wrote:
>>
>> I'd much rather we go back to just making the "cs" entry explicitly
>> 16-bit, and have a separate padding entry, the way we used to long
>> long ago.
>>
>
> I would agree 100% with this.

We _used_ to do it like this in some places (signal stack, other places):

    unsigned short  cs, __csh;

and

    int xcs;

in others (pt_regs, for example).

You still see that "xcs" thing in the x86 uapi/asm/ptrace.h file, but
that's what our native pt_regs used to look like). And we still have
that "cs+__cs" thing in at least 'struct user_regs_struct32'. But our
"struct pt_regs" gas lost it.

I wonder why we broke that. I suspect it happened when we merged the
64-bit and 32-bit files, but I was too lazy to try to pinpoint it.

And I do think the original i386 model was better - exactly because it
didn't access undefined state when you just accessed "cs". Either you
had to know about it and it wasn't called 'cs' ("xcs") or you had that
high/low separation.

Of course, what might be better yet is to use an anonymous union, so
that you can do both of the above for all the cases (ie access it both
as a trustworthy low 16 bits, _and_ as a single 32-bit piece of
information).

We use anonymous unions all over now, we used to not do it because of
compiler limitations.

With an anonymous union, we could do soemthing like

    union {
        unsigned int xcs;
        unsigned short cs;
    }

and so easily access either the reliable part (cs) or the full word
(xcs) without masking or having to play games.

[ In fact, I think we could try to make the "cs" member in that union
be marked "const", which should mean that we'd get warnings if
somebody were to try to assign just the half-word (so you'd always
have to *assign* to "xcs", but you'd be able to read "cs").

  I think that has made it from C++ to C. I'm not sure that's
somethign we can/should use, but it sounds potentially useful for
these kinds of cases ]

              Linus