Re: X32 psABI status
> The actual idea is to use the i386 compat ABI for memory layout, but > with a 64-bit register convention. That means that system calls that > don't make references to memory structures can simply use the 64-bit > system calls, otherwise we're planning to reuse the i386 compat system > calls, but invoke them via the syscall instruction (which requires a new > system call table) and to pass 64-bit arguments in single registers. Who actually needs this new extra API - whats the justification for everyone having more crud dumping their kernels, more syscall paths (which are one of the most security critical areas) and the like. What are the benchmark numbers to justify this versus just using the existing kernel interfaces ? Alan
Re: X32 psABI status
> a. the int $0x80 instruction is much slower than syscall. An actual >i386 process can use the syscall instruction which is disambiguated >by the CPU based on mode, but an x32 process is in the same CPU mode >as a normal 64-bit process. So set a flag, whoopee > b. 64-bit arguments have to be split between two registers for the >i386 entry points, requiring user-space stubs. Diddums. Given you've yet to explain why everyone desperately needs this extra interface why do we care ? > All in all, the cost of an extra system call table is quite modest. And the cost of not doing it is a gloriously wonderful zero. Yo've still not explained the justification or what large number of apps are going to use it. It's a simple question - why do we care, why do we want the overhead and the hassle, what do users get in return ? Alan
Re: Memory corruption due to word sharing
> So here's basically what the kernel needs: > > - if we don't touch a field, the compiler doesn't touch it. > >This is the rule that gcc now violates with bitfields. > >This is a gcc bug. End of story. The "volatile" example proves it - > anybody who argues otherwise is simply wrong, and is just trying to > make excuses. C historically didn't make this guarantee because a lot of processors couldn't make it because they didn't have things like byte accessors (In fact I suspect early ARM cannot make it for example). Not meeting it for types where you can do is a bit rude however and really ought to be an option (speed v sanity). > See above: it's not the "state" that is accessed concurrently. It's > the code. If you ever try to mark state, you've already lost. The same > "state" can be atomic or not depending on context. It's not about the > state or the data structures, and it never will be. There are optimisation cases - where you can prove access properties are safe (eg local variables some times) but they should be exactly that - optimisations. Alan
