On Wed, Apr 18, 2012 at 11:21 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > On 04/18/2012 11:15 AM, H.J. Lu wrote: >> >> In x32 glibc, I have >> >> # if compile for X32 >> /* si_utime and si_stime must be 4 byte aligned for x32 to match the >> kernel. We align siginfo_t to 8 bytes so that si_utime and si_stime >> are actually aligned to 8 bytes since their offsets are multiple of >> 8 bytes. */ >> typedef __clock_t __attribute__ ((__aligned__ (4))) __sigchld_clock_t; >> # define __SI_ALIGNMENT __attribute__ ((__aligned__ (8))) >> # else >> typedef __clock_t __sigchld_clock_t; >> # define __SI_ALIGNMENT >> # endif >> >> typedef struct siginfo >> { >> ... >> /* SIGCHLD. */ >> struct >> { >> __pid_t si_pid; /* Which child. */ >> __uid_t si_uid; /* Real user ID of sending process. */ >> int si_status; /* Exit value or signal. */ >> __sigchld_clock_t si_utime; >> __sigchld_clock_t si_stime; >> } _sigchld; >> ... >> } siginfo_t __SI_ALIGNMENT; >> > > So in other words, a separate type just for this. However, the question Yes. > still holds: could we simply change __kernel_clock_t for x32 and be done > with it? It would affect the alignment of struct tms, I guess; it > wouldn't really affect the kernel directly since the kernel gets a > pointer straight from userspace for times(2), but it would kind of mess > up a userspace which uses __kernel_clock_t directly. That is true. > Urk, okay... > This is the best approach I can think of. -- H.J. -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html