On 7 November 2012 10:47, Vineet Gupta <vineet.gup...@synopsys.com> wrote:
>> diff --git a/arch/arc/include/asm/ptrace.h b/arch/arc/include/asm/ptrace.h
>> new file mode 100644
>> index 0000000..c178357
>> --- /dev/null
>> +++ b/arch/arc/include/asm/ptrace.h
>> @@ -0,0 +1,120 @@
>> +/* THE pt_regs: Defines how regs are saved during entry into kernel */
>> +
>> +struct pt_regs {> 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. 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. What do you think ! -Vineet-- 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/
