home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / unix / bsd / 11799 < prev    next >
Encoding:
Text File  |  1993-01-25  |  8.7 KB  |  257 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!europa.asd.contel.com!emory!swrinde!cs.utexas.edu!news.uta.edu!utacfd.uta.edu!rwsys!sneaky!gordon
  3. From: gordon@sneaky.lonestar.org (Gordon Burditt)
  4. Subject: [386bsd] gdb and 386bsd vs. floating point problems (+gdb patches)
  5. Message-ID: <C1EH04.45M@sneaky.lonestar.org>
  6. Organization: Gordon Burditt
  7. Date: Mon, 25 Jan 1993 08:02:23 GMT
  8. Lines: 247
  9.  
  10. Is anyone else having terrible floating point problems on 386bsd?
  11. I'm running on a 486DX/33, so the coprocessor is built in.
  12. I seem to be getting npx stack-underflow faults, in contexts where it
  13. makes absolutely no sense to be getting them ( e.g. fldl 16(%ebp);
  14. faddl 44(%ebp); fstpl 24(%ebp), and I get a stack-empty fault on the
  15. fstpl instruction.  Breaking npxprobe() to make it not recognize
  16. the coprocessor and using the math emulator instead makes the program 
  17. run VERY slowly but it works.  The math emulator doesn't seem to 
  18. do stack underflow faults.
  19.  
  20. A certain program I'm trying to port keeps dying on SIGFPEs.  It's a
  21. client of a server program run on the same machine, and so far only the
  22. client gets the SIGFPEs, although both use floating-point, and there's
  23. a lot of context-switching going on also.  So I get out gdb, and the 
  24. first thing I discover is that gdb doesn't do anything useful when you 
  25. ask for a stack trace, and complains about "Operation not permitted".  
  26. I discover that the user virtual address for the stack end is not a 
  27. constant, so I fix gdb to properly access the stack in core dumps:
  28.  
  29. Index: /usr/src/usr.bin/gdb/config/i386bsd-dep.c
  30. ***************
  31. *** 942,947 ****
  32. --- 942,957 ----
  33.            */
  34.           reg_offset = (int) u.u_ar0 - KERNEL_U_ADDR;
  35.   #else
  36. +         /*
  37. +          * 386bsd does not put the stack end in a fixed virtual
  38. +          * location, so we get the beginning and depend on the
  39. +          * MAXSSIZ constant for the full length of the stack to
  40. +          * find the end.
  41. +          * (See code & comments in kern_execve.c, search for USRSTACK)
  42. +          */
  43. +         stack_end = (CORE_ADDR) u.u_kproc.kp_eproc.e_vm.vm_maxsaddr 
  44. +             + MAXSSIZ;
  45. + 
  46.           data_end = data_start +
  47.               NBPG * u.u_kproc.kp_eproc.e_vm.vm_dsize;
  48.           stack_start = stack_end -
  49.  
  50. Ok, now I can get a stack trace.  The SIGFPEs seem to be coming at random
  51. places all over the code.  Further, getting an assembly file for the problem
  52. code, adding "fwait" instructions before and after every floating-point
  53. instruction, assembling it, and testing the new code doesn't change anything.
  54.  
  55. "info float" in gdb doesn't do anything.  The code is conditionalled out.
  56. So I fixed it.  Well, this is a bit kludgey, and I'd love to have someone 
  57. point out a mistake so that the problem really isn't as wierd as it seems,
  58. but it seems to work.  I couldn't figure out where to get an exception
  59. status value in addition to the stored one.  There are some fundamental
  60. disagreements between the original code and my reading of Intel manuals 
  61. regarding the order of floating-point registers saved by fsave/fnsave.
  62. Nothing but code in gdb seems to care, though.
  63.  
  64. Index: /usr/src/usr.bin/gdb/config/i386bsd-dep.c
  65. ***************
  66. *** 1758,1771 ****
  67.     
  68.     top = (ep->status >> 11) & 7;
  69.     
  70. !   printf ("regno  tag  msb              lsb  value\n");
  71. !   for (fpreg = 7; fpreg >= 0; fpreg--) 
  72.       {
  73.         double val;
  74.         
  75. !       printf ("%s %d: ", fpreg == top ? "=>" : "  ", fpreg);
  76.         
  77. !       switch ((ep->tag >> (fpreg * 2)) & 3) 
  78.       {
  79.       case 0: printf ("valid "); break;
  80.       case 1: printf ("zero  "); break;
  81. --- 1758,1773 ----
  82.     
  83.     top = (ep->status >> 11) & 7;
  84.     
  85. !   printf ("regno    tag  msb              lsb  value\n");
  86. !   for (fpreg = 0; fpreg <= 7; fpreg++) 
  87.       {
  88.         double val;
  89.         
  90. !       printf ("%s ST%d: ", ((fpreg+top)&7) == 7 ? "=>" : "  ", fpreg);
  91.         
  92. !       /* according to Intel 486 documentation, the registers are stored */
  93. !       /* in LOGICAL order but the tag bits correspond to PHYSICAL registers */
  94. !       switch ((ep->tag >> (((top + fpreg)&7) * 2)) & 3) 
  95.       {
  96.       case 0: printf ("valid "); break;
  97.       case 1: printf ("zero  "); break;
  98. ***************
  99. *** 1787,1792 ****
  100. --- 1789,1804 ----
  101.     if (ep->r3)
  102.       printf ("warning: reserved3 is 0x%x\n", ep->r3);
  103.   }
  104. + #ifdef __386BSD__
  105. + /* 
  106. +  * 386BSD name for saved fpu state. This had better have the same
  107. +  * layout as the env387 struct.  Note that the size of struct fpacc87
  108. +  * in <machine/npx.h> is actually wrong, due to struct padding, but
  109. +  * the data layout seems to be correct anyway.
  110. +  */
  111. + #define U_FPSTATE(u) u.u_pcb.pcb_savefpu
  112. + #define fpstate save87
  113. + #endif
  114.   
  115.   #ifndef U_FPSTATE
  116.   #define U_FPSTATE(u) u.u_fpstate
  117. ***************
  118. *** 1798,1823 ****
  119. --- 1810,1851 ----
  120.     int i;
  121.   #ifndef __386BSD__
  122.     /* fpstate defined in <sys/user.h> */
  123. + #else
  124. +   /* save87 defined in <machine/npx.h> */
  125. + #endif
  126.     struct fpstate *fpstatep;
  127.     char buf[sizeof (struct fpstate) + 2 * sizeof (int)];
  128.     unsigned int uaddr;
  129. + #ifndef __386BSD__
  130.     char fpvalid;
  131. + #else
  132. +   int fpvalid;
  133. + #endif
  134.     unsigned int rounded_addr;
  135.     unsigned int rounded_size;
  136.     extern int corechan;
  137.     int skip;
  138.     
  139. + #ifndef __386BSD__
  140.     uaddr = (char *)&u.u_fpvalid - (char *)&u;
  141. + #else
  142. +   uaddr = (char *)&u.u_pcb.pcb_flags - (char *)&u;
  143. + #endif
  144.     if (have_inferior_p()) 
  145.       {
  146.         unsigned int data;
  147.         unsigned int mask;
  148.         
  149. + #ifndef __386BSD__
  150.         rounded_addr = uaddr & -sizeof (int);
  151.         data = ptrace (3, inferior_pid, rounded_addr, 0);
  152.         mask = 0xff << ((uaddr - rounded_addr) * 8);
  153.         
  154.         fpvalid = ((data & mask) != 0);
  155. + #else
  156. +       data = ptrace(3, inferior_pid, (caddr_t)uaddr, 0);
  157. +       fpvalid = (data & FP_WASUSED) != 0;
  158. + #endif
  159.       } 
  160.     else 
  161.       {
  162. ***************
  163. *** 1825,1831 ****
  164.       perror ("seek on core file");
  165.         if (myread (corechan, &fpvalid, 1) < 0) 
  166.       perror ("read on core file");
  167. !       
  168.       }
  169.     
  170.     if (fpvalid == 0) 
  171. --- 1853,1861 ----
  172.       perror ("seek on core file");
  173.         if (myread (corechan, &fpvalid, 1) < 0) 
  174.       perror ("read on core file");
  175. ! #ifdef __386BSD__
  176. !     fpvalid = (fpvalid & FP_WASUSED) != 0;      
  177. ! #endif
  178.       }
  179.     
  180.     if (fpvalid == 0) 
  181. ***************
  182. *** 1847,1853 ****
  183.         ip = (int *)buf;
  184.         for (i = 0; i < rounded_size; i++) 
  185.       {
  186. !       *ip++ = ptrace (3, inferior_pid, rounded_addr, 0);
  187.         rounded_addr += sizeof (int);
  188.       }
  189.       } 
  190. --- 1877,1883 ----
  191.         ip = (int *)buf;
  192.         for (i = 0; i < rounded_size; i++) 
  193.       {
  194. !       *ip++ = ptrace (3, inferior_pid, (caddr_t)rounded_addr, 0);
  195.         rounded_addr += sizeof (int);
  196.       }
  197.       } 
  198. ***************
  199. *** 1861,1866 ****
  200. --- 1891,1900 ----
  201.       }
  202.     
  203.     fpstatep = (struct fpstate *)(buf + skip);
  204. + # ifdef __386BSD__
  205. +   /* not sure where to get exception status */
  206. +   print_387_status (0, (struct env387 *)fpstatep);
  207. + #else
  208.     print_387_status (fpstatep->status, (struct env387 *)fpstatep->state);
  209.   #endif
  210.   }
  211.  
  212. Ok, now I can see what happens when I get a SIGFPE.  Invariably the
  213. exceptions shown are INVALID, LOS, and FSTACK, and the stack is shown
  214. as empty.  The address of the last npx exception is often 0, but sometimes
  215. it shows the address of an instruction that's actually in my code.
  216.  
  217. Ok, so why am I getting these exceptions?  I can think of several
  218. reasons:
  219.  
  220. - Flakey hardware.  It's fairly new hardware, but there might be problems
  221.   with it.  It's a 486DX, though, so there's less a motherboard manufacturer
  222.   can goof up than if they were wiring a 386 and 387 together.
  223. - Flakey code generation by gcc.  Well, when I see code like:
  224.  
  225.     fldl 16(%ebp)
  226.     faddl 44(%ebp)
  227.     fstpl 24(%ebp)
  228.     fwait
  229.     ...
  230.  
  231. if I'm going to get an exception from the fstp (why? - the stack should
  232. have something on it), shouldn't I get the exception at the fwait
  233. or before (486 eip, not npx exception address), NOT dozens to hundreds 
  234. of instructions later?  And what's wrong with this code, anyway?  There 
  235. should be something on the stack.
  236.  
  237. - Flakey library code.  I suspected for a while that library code was
  238.   doing "fninit" instructions when it shouldn't, but I think I have
  239.   isolated the problem to exclude library code.
  240.  
  241. - Flakey OS floating point save/restore code.  I suspect this the most,
  242.   but I haven't been able to prove it.  I've tried putting fwait 
  243.   instructions around just about every floating-point instruction
  244.   in the kernel, and nothing makes much difference.  (If you do an
  245.   frstor, which starts saving the context, and yank the address space
  246.   out from under the npx by re-loading control register 3 or doing
  247.   a task switch, don't you NEED an fwait first?  There isn't one.  But 
  248.   fixing it doesn't change the problem.)  I tried setting the 486 NE 
  249.   bit in control register 0.  No change.  I'm still wondering what 
  250.   those outb calls for ports 0xb1 and 0xf0 do.
  251.  
  252. - Flakey debugger.  If my fixes to "info float" don't do what I think
  253.  they do, the problem might be something entirely different.
  254.  
  255.                         Gordon L. Burditt
  256.                         sneaky.lonestar.org!gordon
  257.