Modules and CONFIG_ALTIVEC

On ppc, the size of thread_struct depends on the CONFIG_ALTIVEC setting.
Thus, the offset of various task_struct fields are dependent upon this
config option.

This makes it difficult to distribute precompiled module binaries
(in a safe manner). It really shouldn't be necessary to bundle:

	module-2.4.X
	module-2.4.X-smp
	module-2.4.X-altivec
	module-2.4.X-altivec-smp

To avoid this problem, one could do something like:

        unsigned long   fpscr;          /* Floating point status */
-#ifdef CONFIG_ALTIVEC
-       vector128       vr[32];         /* Complete AltiVec set */
-       vector128       vscr;           /* AltiVec status */
-       unsigned long   vrsave;
-#endif /* CONFIG_ALTIVEC */
+	altivec_t	*vregs;

I'm not sure the affected task_struct fields are
ever referenced by a typical kernel module. But this is
difficult to check and besides, new fields might be added
to the end of the struct.

Thoughts?

/Samuel


----------------------------------------------------------
 E-mail [off-list ref]  WWW: <http://www.ibrium.se>
  Phone/fax: (home) +46 8 4418431, (work) +46 8 790nnnn
----------------------------------------------------------

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Sunday 05 August 2001 04:49, Samuel Rydh wrote:

On ppc, the size of thread_struct depends on the CONFIG_ALTIVEC setting.
Thus, the offset of various task_struct fields are dependent upon this
config option.

[snip]

        unsigned long   fpscr;          /* Floating point status */
-#ifdef CONFIG_ALTIVEC
-       vector128       vr[32];         /* Complete AltiVec set */
-       vector128       vscr;           /* AltiVec status */
-       unsigned long   vrsave;
-#endif /* CONFIG_ALTIVEC */
+	altivec_t	*vregs;

This also affects gdb. When gdb reads a core file, it gets upset if the size
of a regset isn't what it thinks it should be. Currently it's a bit too easy
to change that size...

-Hollis

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/