linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* Modules and CONFIG_ALTIVEC
@ 2001-08-05 21:49 Samuel Rydh
  2001-08-05 23:08 ` Hollis
  0 siblings, 1 reply; 4+ messages in thread
From: Samuel Rydh @ 2001-08-05 21:49 UTC (permalink / raw)
  To: linuxppc-dev


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 <samuel@ibrium.se>  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/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Modules and CONFIG_ALTIVEC
  2001-08-05 21:49 Modules and CONFIG_ALTIVEC Samuel Rydh
@ 2001-08-05 23:08 ` Hollis
  2001-08-06  6:38   ` Daniel Jacobowitz
  0 siblings, 1 reply; 4+ messages in thread
From: Hollis @ 2001-08-05 23:08 UTC (permalink / raw)
  To: Samuel Rydh; +Cc: linuxppc-dev


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/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Modules and CONFIG_ALTIVEC
  2001-08-05 23:08 ` Hollis
@ 2001-08-06  6:38   ` Daniel Jacobowitz
  2001-08-06  8:09     ` Franz Sirl
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Jacobowitz @ 2001-08-06  6:38 UTC (permalink / raw)
  To: linuxppc-dev


On Sun, Aug 05, 2001 at 06:08:21PM -0500, Hollis wrote:
>
> 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...

Yup.  Expect GDB patches to deal with that (and with altivec) from me
in the next month, if no one beats me to it.  It's approaching the top
of my TODO list.

--
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Modules and CONFIG_ALTIVEC
  2001-08-06  6:38   ` Daniel Jacobowitz
@ 2001-08-06  8:09     ` Franz Sirl
  0 siblings, 0 replies; 4+ messages in thread
From: Franz Sirl @ 2001-08-06  8:09 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: linuxppc-dev


At 08:38 06.08.2001, Daniel Jacobowitz wrote:

>On Sun, Aug 05, 2001 at 06:08:21PM -0500, Hollis wrote:
> >
> > 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...
>
>Yup.  Expect GDB patches to deal with that (and with altivec) from me
>in the next month, if no one beats me to it.  It's approaching the top
>of my TODO list.

Uhm, I sent a patch to Daniel Berlin a while ago for commenting, but
haven't heard back yet. I can send it to you if you want to take a look.

Franz.


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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2001-08-06  8:09 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-08-05 21:49 Modules and CONFIG_ALTIVEC Samuel Rydh
2001-08-05 23:08 ` Hollis
2001-08-06  6:38   ` Daniel Jacobowitz
2001-08-06  8:09     ` Franz Sirl

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).