Date: Thu, 31 Aug 2006 13:56:39 +0200 From: Joerg Schilling <schilling@fokus.fraunhofer.de> To: schilling@fokus.fraunhofer.de, marius@alchemy.franken.de Cc: cvs-ports@freebsd.org Subject: Re: cvs commit: ports/sysutils/cdrdao/files Message-ID: <200608311156.k7VBuemx021777@burner.fokus.fraunhofer.de> In-Reply-To: <20060828153510.GJ28747@alchemy.franken.de> References: <200608280627.k7S6RBh1019446@burner.fokus.fraunhofer.de> <20060828153510.GJ28747@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Marius Strobl <marius@alchemy.franken.de> wrote:
> > I am not shure about the background of this patch, but it seems that you have a
> > major missconception of the Schily Makefile system.....
> >
> > 1)
> > The Schily Makefile system does not ignore the exist status except when
> > you are using a broken make program (e.g. smake-1.2a23 that calls
> > "sh -c command...." instead of "sh -ce command....") or a shell that
> > incorrectly handles the -e flag. It seems that there sre still peple who do not
> > understand the POSIX shell rules correctly.
>
> What I was refering to is the fact that the unaltered Schily
> Makefile system does ignore the exist status on at least both
> FreeBSD and Solaris when used with GNU make (at least with 3.80
> and 3.81, but AFAIR also with all previous versions I used).
> Regardless of whether that's a bug or not, it's the reason why
> a core dumping avoffset doesn't cause the build of Cdrtools to
> fail when using GNU make.
This is not true:
An unaltered Schily Makefile system does not ignore the exist status
in case you use SunPro make or my smake. So it is obviously a GNU make bug.
This is why GNU make is only the last resort in case that neither smake (the
preferred make) not SunPro make is available.
> > 2)
> > If avoffset dumps core, you found a serious problem that needs to be fixed.
> > The expected error situations for avoffset (when stack scanning is not possible
> > on a specific platform) is to receive a SIGBUS or a SIGDEV. There is a handler
> > that catches these signals and calls exit(0). If you see a SIGILL, then you
> > should check your compiler....or find another reason why an illegal instruction
> > gets executed while the code only follows a linked list.
> >
> > Using the Sun C-compiler, I receive a SIGBUS (with address allignement error)
> > on Sparc using 64 bits.
>
> The SIGILL is due to a data access exception. Maybe a FP_OFF of
> 0x10 isn't appropriate for GCC on FreeBSD/sparc64? With GCC 3.4.4
> and 3.4.6 changing FP_OFF from 0x10 to 0 changes the SIGILL into
> a SIGSEGV (I also get a SIGSEGV with FP_OFF = 0x10 when compiling
> w/o optimizations).
> Anyway, until getting to the bottom of the existing layers of
> workarounds and the real problems, adding another workaround in
> order to get cdrdao build again seemed reasonable...
The correct workaround for your problem would be to add a signal handler
for SIGILL.
I now use:
#ifdef SIGBUS
signal(SIGBUS, handler);
#endif
signal(SIGSEGV, handler);
#ifdef SIGILL
signal(SIGILL, handler); /* For gcc -m64/sparc on FreeBSD */
#endif
And it may be useful to add handlers for all other Core dump signals too.
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200608311156.k7VBuemx021777>