crash in config.guess on Power Mac G5 under Mac OS X 10.4.6

Vincent Lefevre vincent at vinc17.org
Sat May 20 00:50:06 CEST 2006


On 2006-05-19 23:16:14 +0200, Torbjorn Granlund wrote:
> Vincent Lefevre <vincent at vinc17.org> writes:
>   
>   But at least, this would fix the problem on a number of systems
>   (and in particular, probably Mac OS X, well... I hope so). On the
>   other systems, if a bad instruction doesn't send a signal, then
>   there wouldn't be any change compared to the current behavior.
>   But then, the only way to fix the problem for all possible systems
>   would be not to run the code that has a bad instruction.
>   
> We cannot disable it for systems where it doesn't work, since we
> don't know which systems that would be in the future.

I mean that if you want to be sure that on any system, the code won't
fail badly, then the only way is to disable it for any system.

> The current configure systems tries to rely on feature tests as much
> as possible, and as little as possible on hardwired "X is true for
> system Y" kind of things.

You don't necessarily need such a thing. For instance, you can trap
the standard signal SIGILL on any system. So, on some of them, this
would improve the situation, and on other systems, this would not
change anything. If you fear that the code won't compile (there could
be freestanding C implementations after all), then you can detect
that too and try on a code without signals (e.g. the current one)
as a fallback.

>   BTW, the current behavior is bad on Linux too, since a core dump may
>   be generated and fill the disk space. And asking the users to disable
>   core dumps is a bad idea, as they are useful for debugging and for
>   bug reports.
>   
> What is bad on Linux and why?
> 
> I think you're exaggerating somewhat if you think config.guess' tiny
> programs will fill any disks.

OK, that's true that there are tiny, but I've already seen large core
files for small programs... For instance,

#include <stdlib.h>
int main(void)
{
  abort();
  return 0;
}

generates a 160-KB core file on my machine here. That's OK here,
but I'd prefer to avoid it. One never knows what can occur in
every situation.

>  I don't know the size of your disks,

It depends on the machine. The Zaurus has very limited disk space in
standard (64 MB internal flash for mine).

> of course, but I doubt a 20 line program that doesn't allocate any
> memory will result in core dumps more than a few Kibytes, even on
> the weirdest of systems.

Well, you can see above a 6-line program that generates a core dump
taking more than a few KB. :)

-- 
Vincent Lefèvre <vincent at vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA


More information about the gmp-bugs mailing list