lkml.org 
[lkml]   [2001]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: APIC, AMD-K6/2 -mcpu=586...
From
Date

>>>> 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 <jamagallon@able.es> 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:53    [W:0.036 / U:2.412 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site