>>>> On 05.18 Bill Pringlemeir wrote:
>> Why don't the build scripts run a dummy file to determine where
>> the floating point registers should be placed?
>>
>> ... const int value = offsetof(struct task_struct,
>> thread.i387.fxsave) & 15; ...
>>>>> "JAM" == J A Magallon <[EMAIL PROTECTED]> writes:
JAM> That is not the problem. The problem is that the registers have
JAM> to lay in a defined way, transcribed to a C struct, and that
JAM> pgcc lays badly that struct.
Yes, I understand that. I was showing a way to find the value of padding
needed to align the register store in the structure. Perhaps I should have
shown a mod to asm/processor.h,
...
/* floating point info */
#if PAD_SIZE /* not needed if gcc accepts zero size arrays? */
unsigned char fpAlign[PAD_SIZE];
#endif
union i387_union i387;
...
Before compiling the `real source', the dummy file would be compiled
with PAD_SIZE set to zero. Then objdump (or some other tool) can find
out what the value is. Then when the task_struct is compiled in the
kernel, PAD_SIZE is set to the appropriate value to align the
structure.
I was describing a way to make things independent of the compiler layout
of the structs. However, this complicates the build process, and people
might not like the padding due to cache alignment details.
I am pretty sure what I am saying works... It might not be right though.
regards,
Bill Pringlemeir.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
