From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eduardo Pereira Habkost Subject: Re: ELKS memcpy_fromfs() failing. Wrong variable offsets Date: Wed, 2 Jun 2004 09:52:31 -0300 Sender: linux-8086-owner@vger.kernel.org Message-ID: <20040602125230.GX21172@duckman.distro.conectiva> References: <20040601222140.GV21172@duckman.distro.conectiva> <609c173af82cc283@mayday.cix.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EguBBKnZWdUQS9Kz" Return-path: Content-Disposition: inline In-Reply-To: <609c173af82cc283@mayday.cix.co.uk> List-Id: To: Robert de Bath Cc: Linux-8086 --EguBBKnZWdUQS9Kz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 02, 2004 at 09:47:25AM +0100, Robert de Bath wrote: >=20 > Oh my, confusion reigns. I guess so. 8) >=20 > Okay first the si and di variables are usually defined as callee saves > unless you're compiling with the '-Mc' option. >=20 > The "memcpy_fromfs.off" stuff is generated for optimising the push/pop > of the si and di variables. It's a reasonably recent addition so all > accesses of si and si can be eliminated if they are unused. However, > it's only turned on if you use '-O'. I've seen that this .off stuff was added between 0.16.0 and 0.16.15. That is why the (wrong) ELKS code used to work. >=20 > Ie: this is working as it should. >=20 > You have highlighted a bug though, the definition some of the 'set' > variables is actually wrong, they should have memcpy_fromfs.off added > when it might be non-zero. >=20 > BTW: You should really be using those variables to access C arguments > and locals, the '_memcpy_fromfs.ds' is for stack pointer relative the > '.memcpy_fromfs.ds' is for 'bp' relative. Hey, nice! I've never looked at that code before, and I didn't know what the author have assumed about the offsets of the variables, but these [._]. macros are what I was looking for fixing the code. Thanks. :) BTW: these [._].macros are available since old versions, right? I will change ELKS code to use them. >=20 > I can fix the bug in one of two ways; either actually add the > 'memcpy_fromfs.off' variable to the 'set' variables or simply > have the compiler assume that any '#asm' will use si and di. > (The asm("...") function will not however.) >=20 > Actually I think assuming that #asm uses si/di is best because as this > example has shown it is quite likely to be true, plus, it's the failsafe > option. >=20 > (PS: It's also very easy to do :-) see attached. ) >=20 > So do you want me to make it like it was before? :-) No, I just wanted to understand what happened. Now I understand the Right Way to access variables and parameters inside #asm. :) I think that forcing the user to save DI and SI if he wants to use the registers is ok, unless it would break some existing software. It's up to you. Adding a way to make #asm tell the compiler which registers it will use (and maybe assume by default that it will change all registers) would be interesting, too. >=20 > --=20 > Rob. (Robert de Bath ) > >=20 > diff -Nurd linux86.old/bcc/table.c linux86/bcc/table.c > --- linux86.old/bcc/table.c Sun Jul 28 08:43:13 2002 > +++ linux86/bcc/table.c Wed Jun 2 09:37:56 2004 > @@ -400,6 +400,11 @@ > register struct symstruct *symptr; > int i; > =20 > + if (framep && optimise && !callersaves) { > + regfuse |=3D callee1mask; > + outnstr("! Assuming #asm uses all callee saves registers"); > + } > + > for (i =3D 0; i < HASHTABSIZE; ++i) > for (symptr =3D hashtab[i]; symptr !=3D NULL; symptr =3D symptr->next) > if (symptr->storage =3D=3D LOCAL) --=20 Eduardo --EguBBKnZWdUQS9Kz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAvc2OcaRJ66w1lWgRAtOgAJ93CxwNOpc1BcH75lWR6+40yzYkewCgmYZA 9GjprGQUHOBU9OUAxhI6YlY= =uUv9 -----END PGP SIGNATURE----- --EguBBKnZWdUQS9Kz--