Can you file a bug in llvm bugzilla?
On Sat, Jan 30, 2016 at 03:00:26AM -0800, Mark Millard wrote:
> I got around to trying some more use of the 3.8.0 clang based world on
> powerpc (32 bit) (now -r294962 based) and ran into:
>
> A) Segmentation faults during signal handlers in syslogd, nfsd, mountd, and
> (for SIGNFO) make.
>
> B) ls sometimes segmentation faulting
>
> C) make -j 6 buildworld segmentation faulting in make eventually but make
> buildworld works.
>
> I have reduced (A) to a simple program that demonstrates the behavior:
>
> > # more sig_snprintf_use_test.c
> > #include <stdio.h>
> > #include <signal.h>
> >
> > volatile sig_atomic_t sat = 0;
> >
> > void
> > handler(int sig)
> > {
> > char uidbuf[32];
> > (void) snprintf(uidbuf, sizeof uidbuf, "%d", 10);
> > sat = uidbuf[0];
> > }
> >
> > int
> > main(void)
> > {
> > if (signal(SIGINT, handler) != SIG_ERR) raise(SIGINT);
> > return sat;
> > }
>
> > # ./a.out
> > Segmentation fault (core dumped)
> > # /usr/local/bin/gdb a.out /var/crash/a.out.1510.core
> > GNU gdb (GDB) 7.10 [GDB v7.10 for FreeBSD]
> . . .
> > warning: Unexpected size of section `.reg2/100167' in core file.
> > #0 0x419a89c8 in memcpy (dst0=0xffffd734, src0=<optimized out>,
> > length=<optimized out>) at /usr/src/lib/libc/string/bcopy.c:124
> > 124 TLOOP1(*--dst = *--src);
> > (gdb) bt
> > #0 0x419a89c8 in memcpy (dst0=0xffffd734, src0=<optimized out>,
> > length=<optimized out>) at /usr/src/lib/libc/string/bcopy.c:124
> > #1 0x419a3984 in __sfvwrite (fp=<optimized out>, uio=<optimized out>) at
> > /usr/src/lib/libc/stdio/fvwrite.c:128
> > #2 0x41934468 in __sprint (fp=<optimized out>, uio=<optimized out>,
> > locale=<optimized out>) at /usr/src/lib/libc/stdio/vfprintf.c:164
> > #3 io_flush (iop=<optimized out>, locale=<optimized out>) at
> > /usr/src/lib/libc/stdio/printfcommon.h:155
> > #4 __vfprintf (fp=<optimized out>, locale=<optimized out>, fmt0=<optimized
> > out>, ap=<optimized out>) at /usr/src/lib/libc/stdio/vfprintf.c:1020
> > #5 0x4199c644 in snprintf (str=0xffffd734 "", n=<optimized out>,
> > fmt=0x1800850 "%d") at /usr/src/lib/libc/stdio/snprintf.c:72
> > #6 0x01800708 in handler ()
> > Backtrace stopped: Cannot access memory at address 0xffffd760
>
> (The "Unexpected size . . ." is a known problem in powerpc land at this
> point, not tied to clang 3.8.0 .)
>
> The syslogd, nfsd, mountd, and SIGINFO-related make backtraces are similar. I
> got the program above from simplifying the mountd failure context.
>
> A direct call, handler(0), does not get the segmentation fault.
>
> I'll note that in C the handler calling snprintf or other such is a no-no for
> the general case: only abort(), _Exit(), or signal() as of C99 as I
> understand. But the restriction is not true of use of raise so the small
> program is still valid C99 code. Of course it appears FreeBSD allows more
> than C99 does in this area.
>
> I've not yet investigated what the original signals are in syslogd, nfsd, or
> mountd. They may well indicate another problem.
>
>
> I've not gotten as far classifying (B) or (C) as well.
>
> (B) is a xo_emit context each time so far (so C elipsis use again, like (A))
> but no signal handler seems to be active. It stops in
> xo_format_string_direct. My attempts at simpler code have not produced the
> problem so far.
>
> (C) is such that GDB 7.10 reports "previous frame to this frame (corrupt
> stack?)" or otherwise gives up. It shows Var_Value called by Make_Update
> before reporting that. gdb 6.1.1 shows more after that: JobFinish,
> JobReapChild, Job_CatchChildern, Job_CatchOutput, Make_Run, main). SIGCHLD or
> other such use may well be involved here.
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> On 2016-Jan-19, at 2:35 AM, Mark Millard <[email protected]> wrote:
>
> I now have an SSD that contains:
>
> 0) installkernel material from a gcc 4.2.1 based buildkernel
>
> 1) installworld material from a clang 3.8.0 based buildworld
> (clang 3.8.0, libc++, etc.)
>
> It boots and seems to be operating fine after booting --in both a G5 and a G4
> PowerMac.
>
> Apparently the clang code generation has been updated to not require an
> explicit -mlongcall. I had to remove those since clang rejects them on
> command lines. It linked without complaint (and later seems to be running
> fine). (I've seen llvm review notes mentioning the "medium model" or some
> phrase like that for powerpc.)
>
> (I've not been able to buildkernel yet for powerpc (non-64) from my amd64
> environment: rejected command lines for other issues. Thus the current
> limitation to buildworld.)
>
>
>
> To get to (1) I did the following sort of sequence:
> (The first few steps deal with other issues in order to have sufficient
> context.)
>
>
> A) Started by installing the latest powerpc (non-64) snapshot.
> (
> http://ftp1.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/FreeBSD-11.0-CURRENT-powerpc-20160113-r293801-disc1.iso
> )
>
> (I had to use a PowerMac with video hardware that vt would handle.)
> (Basic display, no X-windows involvement here.)
>
>
> B) Rebuild, including using my usual kernel configuration that has
> both vt and sc. I did this based on projects/clang380-import
> -r294201 /usr/src but still using gcc 4.2.1 (native on the
> PowerMac). The configuration turns off kernel debugging extras too.
>
>
> C) installkernel, installworld, etc., set to use sc instead of vt, and
> rebooted.
>
> (As of this I could use the SSD in more PowerMacs by using sc instead of vt
> via a /boot/loader.conf assignment.)
>
>
> D) dump/restore the file systems to another SSD (after partitioning it).
> Adjust the host name and the like on the copy.
>
> (This copy later ends up having new installworld materials overlaid.)
>
>
> E) In a projects/clang380-import -r294201 amd64 environment, buildworld for
> TARGET_ARCH=powerpc . WITH_LIBCPLUSPLUS= and clang related material built,
> gcc 4.2.1 related material not built. WITH_BOOT= as well. I choose
> WITHOUT_DEBUG= and WITHOUT_DEBUG_FILES= . (I've not tried enabling them
> yet.)
> binutils is not from ports.
>
>
> F) Use DESTDIR= with installworld to an initially empty directory tree. tar
> the tree.
>
>
> G) Transfer the tar file to the PowerMac. Mount the to-be-updated SSD to
> /mnt and /mnt/var. After chflags -R noschg on /mnt and /mnt/var use
> tar xpf to replace things from the buildworld on /mnt and /mnt/var.
>
> (This does leave older gcc 4.2.1 related materials in place.)
>
> H) Dismounts, shutdown, and then boot from the updated SSD.
>
>
>
> Note: I've never manage to get powerpc64-xtoolchain-gcc/powerpc64-gcc to
> produce working 32-bit code. So I've never gotten this far via that path.
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
>
> _______________________________________________
> [email protected] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "[email protected]"
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[email protected]"
