On November 21, 2016 1:21:35 PM PST, Linus Torvalds <torva...@linux-foundation.org> wrote: >On Mon, Nov 21, 2016 at 10:26 AM, H. Peter Anvin <h...@zytor.com> 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
Now, segment loads have always ignored the top 32 bits; it's an issue when examined by other kinds of code. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.