On 8 November 2012 19:52, Vineet Gupta <vineet.gup...@synopsys.com> wrote: > On 7 November 2012 10:47, Vineet Gupta <vineet.gup...@synopsys.com> wrote: >> I'd recommend not exporting the pt_regs structure to userspace. This >> struct is used heavily within the kernel and it's nice to have the >> leeway to be able to modify it as things evolve. GDB doesn't need to >> know about this struct anymore as it should be using regset's for any >> recent architectures anyway, so it's the regset layout that should be >> ABI stable instead of pt_regs. >> >> You can check the openrisc architecture as an example of how to do this. > > Hi Jonas, > > thanks for your review comment. I completely agree that pt_regs should not be > exported and very recently a change in pt_regs forced a gdbserver change too > (ABI incompatibility) which goes along what you are recommending. Infact the > ptrace patch for kernel (which will follow in series #2) provides a stable > regset ABI - extracting information from pt_regs. > > However our current gdb/gdbserver is 6.8 based and making it switch to regset > interface might not be possible for this release of tools. Since customers > are already using our stuff, we can not have a broken ABI. We do have ABI > versioning, so in next release we can fix gdb and remove this.
For generic syscalls it was generally decided that the upstream kernel would drop support for legacy syscalls, _even though_ userspace bits like uClibc required them. For _new_ architectures, userspace would need to adapt to the _mainline_ kernel; and as a stop-gap for existing software, external patches could be carried in an external git repository where _non-mainline_ kernel patches could be carried to provide a working kernel until userspace could catch up. I'd say the same applies here: GDB 6.8 may continue work with a mainline kernel plus a patch that restores the export of pt_regs, but GDB 7.2 (or whatever version you move on to) would be the one that fully supports an unpatched mainline. > > Please note that an additional reason for exporting pt_regs is due to the > fact that it is part of sigcontext. Keeping it exactly same as pt_regs helps > us do batch save/restore of user context in signal handling (please look at > my signal handling patch) but the flip side is that userspace SA_SIGINFO > needs to be able to have access to sigcontext and hence we explicitly need > pt_regs. We could arguably opencode pt_regs there - but that won't be clean > IMHO. It's not really pt_regs you need here, but the userspace equivalent thereof. On OpenRISC, for example, we have user_regs_struct which is an ABI stable version of pt_regs. These may even be identical to begin with, but at least the distinction can be made now between the kernel-internal struct and the ABI stable one. /Jonas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
