On Thu, Jan 19, 2012 at 11:21 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Jan 19, 2012 at 8:01 AM, Jamie Lokier <jamie@xxxxxxxxxxxxx> wrote: >> Andrew Lutomirski wrote: >>> It's reasonable, obvious, and even more wrong than it appears. On >>> Xen, there's an extra 64-bit GDT entry, and it gets used by default. >>> (I got bitten by this in some iteration of the vsyscall emulation >>> patches -- see user_64bit_mode for the correct and >>> unusable-from-user-mode way to do this.) >> >> Here it is: >> >> static inline bool user_64bit_mode(struct pt_regs *regs) > > This is pointless, even if it worked, which it clearly doesn't on Xen > (or other random situations). > > Why would you care? > > The issue is *not* whether somebody is running in 32-bit mode or 64-bit mode. > > The problem is the system call itself, and that can be 32-bit or > 64-bit independently of the execution mode. So knowing the user-mode > mode is simply not relevant. Unless you're writing a debugger and you want to disassemble the code that's being executed (i.e. normal code, not a system call). I wonder how gdb guesses whether the cpu is in long mode. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
