On Wed, Oct 12, 2005 at 08:58:30AM -0400, Jeff Squyres wrote:
> On Oct 12, 2005, at 12:54 AM, Brooks Davis wrote:
> 
> >> Can you elaborate on why you needed that?  If there's a problem with
> >> the stacktrace stuff on BSD, I'd like to make it either disable by
> >> default or fix whatever is required to work properly on BSD.
> >
> > There were a bunch of undefined symbols that I didn't track down.
> > Hopefully there's just a missing header file.  I need to dig into it
> > more.  I just disabled it because I was hoping that would be the only
> > issue.  It wasn't but, I had stop working before I could try again
> > with stack traces enabled.
> 
> Ok.  Right now, that section is only protected with #ifdef __GLIBC__, 
> so let us know what you find.  The sooner, the better.  :-)

After some investigation I've discovered there are two parts to this.

First, the failure to compile is due to FreeBSD not defining a large
portion of the si_code values in the decoding table.  Overall the state
of documentation of the FreeBSD si_code values is rather crappy so I've
added #ifdef's around the ones that fail, but not attempted to add more
values except SI_UNDEFINED.  I've attached this bit (with this the
system compiles with ./configure).

Second, is actually supporting backtraces.  It turns out there's a
library to provide the glibc backtrace* API on BSD systems.  I don't
know which ones it works on or how good it is, but it's probably worth a
short.  The big change will be switching from __GLIBC__ to probing for
libexecinfo, and the necessicary symbols.  I'm taking a look at this
now.

> > On FreeBSD, eval is using 32-bit signed numbers internally on i386 (it
> > looks like it uses longs in general, but I haven't tested on a 64-bit
> > machine yet).  This means that when you compute 2^31 you get INT_MAX + 
> > 1
> > which is negative.  Subtracting one gives INT_MAX so you get the right
> > value despite the sign weirdness.  Assuming I'm correct about longs
> > being used, we'll also be OK on 64-bit machines even if this code is
> > used to compute the maximum value of a 64-bit signed integer.  It won't
> > work for unsigned numbers on either system though.
> 
> Gotcha.  This makes me nervous, though (negative to positive magic); it 
> seems like it might not work on all platforms.
> 
> Another developer suggested just using a hex representation and avoid 
> this -- that seems to be simpler and much more portable (i.e., it 
> becomes string manipulation at this point, and doesn't depend on how 
> expr or the shell is implemented).

I'm pretty sure this will work OK, but I agree that string manipulation
gives a better feel.

> Thanks -- and keep the bug reports coming!

You're welcome.  I hope to see FreeBSD on at least the unofficaly
supported list by SC.

> Aside: rc3 is coming shortly.  We have some pending fixes that we want 
> to get in before cutting it, but there will likely also be an rc4 after 
> that because everything probably won't make the rc3 cutoff.

Sounds good.  Hopefully rc3 or rc4 will build out of the box.

-- Brooks


Index: stacktrace.c
===================================================================
--- stacktrace.c        (revision 7718)
+++ stacktrace.c        (working copy)
@@ -87,15 +87,21 @@
       case SIGILL:
         switch (info->si_code)
           {
+#ifdef ILL_ILLOPC
             case ILL_ILLOPC: str = "ILL_ILLOPC"; break;
+#endif
 #ifdef ILL_ILLOPN
             case ILL_ILLOPN: str = "ILL_ILLOPN"; break;
 #endif
 #ifdef ILL_ILLADR
             case ILL_ILLADR: str = "ILL_ILLADR"; break;
 #endif
+#ifdef ILL_ILLTRP
             case ILL_ILLTRP: str = "ILL_ILLTRP"; break;
+#endif
+#ifdef ILL_PRVOPC
             case ILL_PRVOPC: str = "ILL_PRVOPC"; break;
+#endif
 #ifdef ILL_PRVREG
             case ILL_PRVREG: str = "ILL_PRVREG"; break;
 #endif
@@ -129,14 +135,20 @@
       case SIGSEGV:
         switch (info->si_code)
           {
+#ifdef SEGV_MAPERR
             case SEGV_MAPERR: str = "SEGV_MAPERR"; break;
+#endif
+#ifdef SEGV_ACCERR
             case SEGV_ACCERR: str = "SEGV_ACCERR"; break;
+#endif
           }
         break;
       case SIGBUS:
         switch (info->si_code)
           {
+#ifdef BUS_ADRALN
             case BUS_ADRALN: str = "BUS_ADRALN"; break;
+#endif
 #ifdef BUSADRERR
             case BUS_ADRERR: str = "BUS_ADRERR"; break;
 #endif
@@ -159,12 +171,24 @@
       case SIGCHLD:
         switch (info->si_code)
           {
+#ifdef CLD_EXITED
             case CLD_EXITED: str = "CLD_EXITED"; break;
+#endif
+#ifdef CLD_KILLED
             case CLD_KILLED: str = "CLD_KILLED"; break;
+#endif
+#ifdef CLD_DUMPED
             case CLD_DUMPED: str = "CLD_DUMPED"; break;
+#endif
+#ifdef CLD_WTRAPPED
             case CLD_TRAPPED: str = "CLD_TRAPPED"; break;
+#endif
+#ifdef CLD_STOPPED
             case CLD_STOPPED: str = "CLD_STOPPED"; break;
+#endif
+#ifdef CLD_CONTINUED
             case CLD_CONTINUED: str = "CLD_CONTINUED"; break;
+#endif
           }
         break;
 #ifdef SIGPOLL
@@ -197,6 +221,9 @@
 #ifdef SI_KERNEL
             case SI_KERNEL: str = "SI_KERNEL"; break;
 #endif
+#ifdef SI_UNDEFINED
+            case SI_UNDEFINED: str = "SI_UNDEFINED"; break;
+#endif
           }
     }
 

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

Attachment: pgpADfPyeIXAp.pgp
Description: PGP signature

Reply via email to