On Tue, Mar 10, 2015 at 2:17 PM, Chung-Lin Tang <cltang@xxxxxxxxxxxxxxxx> wrote: > On 2015/3/10 10:54 AM, Ley Foon Tan wrote: >> On Tue, Mar 10, 2015 at 1:05 AM, Ezequiel Garcia >> <ezequiel@xxxxxxxxxxxxxxxxxxxx> wrote: >>> >>> >>> On 03/09/2015 02:02 PM, Chung-Lin Tang wrote: >>>> On 2015/3/10 12:54 AM, Chung-Lin Tang wrote: >>>>> It appears that some of the ways nios2 has organized the >>>>> ucontext/pt_regs/etc. are remnants of the pre-generic code, some >>>>> basically because the port was based off m68k. >>>>> >>>>> I've re-organized the headers a bit: nios2/include/asm/ucontext.h is >>>>> deleted, and re-definition of struct sigcontext now allows use of >>>>> uapi/asm-generic/ucontext.h directly. Note that the reorg, despite >>>>> effectively renaming some fields, is still binary compatible. I'll >>>>> probably update the corresponding glibc definitions later. >>>>> >>>>> struct pt_regs is now not exported, and all exported register sets are >>>>> now supposed to follow the 49 register set defined as in GDB now. >>>>> >>>>> Tobias, Ley Foon, how do you think this looks? >>>> >>>> Sorry, accidentally attached unrelated GCC patch instead, this one's the >>>> correct one. >>>> >>> >>> Looks good. I'm wondering if... >>> >>> +/* User structures for general purpose registers. */ >>> +struct user_pt_regs { >>> + __u32 regs[49]; >>> }; >>> >>> Can we expose the registers explicitly here? Like this: >>> >>> struct user_pt_regs { >>> __u32 r0; >>> __u32 r1; >>> ... >>> __u32 sp; >>> __u32 gp; >>> __u32 estatus; >>> }; >>> >>> It looks self-documenting and thus easier to use. >> >> Hi Chung-Lin, >> >> Your patch look good to me. >> Do you have any problem to change the struct user_pt_regs based on >> Ezequiel's suggestion? > > Well, exposing the register names like that sort of defeats the purpose of > the PTR_* defines. > > Judging from the overall trend of style in arch/*/include/uapi/asm/ptrace.h > across ports, I would prefer to stay with the array field. > Okay, I will include your patch. Regards Ley Foon -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html