Re: APIC, AMD-K6/2 -mcpu=586...
> "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. WJP> Yes, I understand that. I was showing a way to find the value WJP> of padding needed to align the register store in the structure. WJP> Perhaps I should have shown a mod to asm/processor.h, [snip] WJP> I was describing a way to make things independent of the WJP> compiler layout of the structs. However, this complicates the WJP> build process, and people might not like the padding due to WJP> cache alignment details. Sorry, they would obviously declare it as such if the kernel developers wanted to. /* floating point info */ unsigned char fpAlign[0] __attribute__ ((aligned (16))); union i387_unioni387; This is a much simpler way of achieving what I was trying to explain previously. I think that this syntax has been in the GCC extensions for some time. 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/
Re: APIC, AMD-K6/2 -mcpu=586...
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_unioni387; ... 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/
Re: APIC, AMD-K6/2 -mcpu=586...
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; > ... > That is not the problem. The problem is that the registers have to lay in a defined way, transcribed to a C struct, and that pgcc lays badly that struct. -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.4-ac11 #2 SMP Fri May 18 12:27:06 CEST 2001 i686 - 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/
Re: APIC, AMD-K6/2 -mcpu=586...
> "WJP" == Bill Pringlemeir <[EMAIL PROTECTED]> writes:
[snip]
WJP> I have the 2.4.4 distribution from kernel.org.
WJP> "http://www.kernel.org/pub/linux/kernel/v2.4/";
WJP> I have a Mandrake system and selected the AMD processors and
WJP> APIC option. The egcs-2.91.66 compiler with -mcpu=586. It
WJP> appears that the structure alignment of the floating point
Sorry,
I compiled from a user account and `/usr/bin' was before
`/usr/local/bin' on my path. I had actually installed the tools as
per Documentation/Changes, honest! I was compiling with the
pgcc-2.91.66 and not egcs-2.91.66. The root account was set up to use
egcs-2.91.66.
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;
...
VAL = objdump --all-headers foo.o | grep value | cut -c 48-57
PAD_SIZE = objdump --start-address=$VAL --disassemble-all foo.o | cut...
Or perhaps some better method for determining the offset on the host,
Compiling and execute won't work in cross development mode...
int main(){return offsetof(struct task_struct, thread.i387.fxsave) & 15;}
Perhaps this is a bit much to demand, instead of having a specific
compiler.
fwiw,
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/
