Gang,

The prototype for rgs() in sys/i386/include/cpufunc.h claims that the result of the function is 32-bits (ie returns an u_int). As such, when inlining the function the compiler happy generates the following code:

11ed7: 8c 6d 80 movl %gs,0xffffff80(%ebp)

or

12175: 8c ad 14 fd ff ff movl %gs,0xfffffd14(%ebp)

where in this case the memory operand is 32-bit. The source location that corresponds with this is sys/i386/linux/linux_sysvec.c:331 and sys/i386/linux/linux_sysvec.c:451

If you actually look at the frame being created in the debugger, you'll see:

Breakpoint 4, linux_sendsig (catcher=0x28091468, sig=11, mask=0xc2827d78, code=30) at ../../../i386/linux/linux_sysvec.c:472 472 if (copyout(&frame, fp, sizeof(frame)) != 0) { Current language: auto; currently c (kgdb) p /x frame $21 = {sf_sig = 0xb, sf_sc = {sc_gs = 0xcdd3002f, sc_fs = 0xf, sc_es = 0x2f, sc_ds = 0x2f, sc_edi = 0x2809aca8, sc_esi = 0xbfbff0e0, [snip]

In words: the upper 32-bit of sf_sc.sc_gs are garbage. Different CPU implementations behave differently WRT to the upper 16-bits when the destination is known to be a 32-bit operand (ie register).

The point: should we not do (whitespace corrupted diff):

Index: cpufunc.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/cpufunc.h,v retrieving revision 1.130 diff -u -r1.130 cpufunc.h --- cpufunc.h 22 Sep 2002 04:45:21 -0000 1.130 +++ cpufunc.h 1 Nov 2002 01:08:45 -0000 @@ -449,10 +449,10 @@ return (sel); }

-static __inline u_int +static __inline u_int16_t rgs(void) { - u_int sel; + u_int16_t sel; __asm __volatile("movl %%gs,%0" : "=rm" (sel)); return (sel); }

So that the compiler generates:

5c2: 8c e8 mov %gs,%eax 5c4: 0f b7 c0 movzwl %ax,%eax 5c7: 89 45 80 mov %eax,0xffffff80(%ebp)

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message