APIC, AMD-K6/2 -mcpu=586...

APIC, AMD-K6/2 -mcpu=586...

[Bill Pringlemeir]

Hello,

I have the 2.4.4 distribution from kernel.org. 

 "http://www.kernel.org/pub/linux/kernel/v2.4/"

I have a Mandrake system and selected the AMD processors and APIC
option.  The egcs-2.91.66 compiler with -mcpu=586.  It appears that
the structure alignment of the floating point registers was not
correct under this configuration.  This code was being compiled and
a linker error produced.

	if (offsetof(struct task_struct, thread.i387.fxsave) & 15) {
/*  printk("WJP: value is %x.\n", 
       offsetof(struct task_struct, thread.i387.fxsave) & 15); */
/*  	  while(1); */
		extern void __buggy_fxsr_alignment(void);
		__buggy_fxsr_alignment();
	}

The alignment was to 8 bytes instead of 16.  I added some padding to
the thread structure to produce an alignment of 16 and the code
compiled and seemed to work fine; I used it for a few days.

[in processor.h]
/* floating point info */
/*          unsigned char wjpDummy[8]; */
	union i387_union	i387;


I did not see any mention of this in the archives [but the volume of
mailings is large... which I may be contributing to].  I recompiled
without the padding and APIC support and everything seems to be fine,
but _VERY_ slow.  Is this change ok locally?  Has it been addressed 
in a patch?

regards,
Bill Pringlemeir.

Re: APIC, AMD-K6/2 -mcpu=586...

[Bill Pringlemeir]

>>>>> "WJP" == Bill Pringlemeir <bpringle@sympatico.ca> 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.

Re: APIC, AMD-K6/2 -mcpu=586...

[J . A . Magallon]

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:jamagallon@able.es
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

Re: APIC, AMD-K6/2 -mcpu=586...

[Bill Pringlemeir]

>>>> 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.

Re: APIC, AMD-K6/2 -mcpu=586...

[Bill Pringlemeir]

>>>>> "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.

 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_union	i387;

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.