Date: Sat, 30 Jan 2016 03:00:26 -0800 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: Re: clang 3.8.0 based powerpc (32 bit) buildworld runs on a PowerMac! [problems found] Message-ID: <55814789-0489-48B5-867C-F678AE4EA5FF@dsl-only.net> In-Reply-To: <DEF41968-FFC4-417D-A31A-E392CB888C35@dsl-only.net> References: <DEF41968-FFC4-417D-A31A-E392CB888C35@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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=20
> #include <stdio.h>
> #include <signal.h>
>=20
> volatile sig_atomic_t sat =3D 0;
>=20
> void
> handler(int sig)
> {
> char uidbuf[32];
> (void) snprintf(uidbuf, sizeof uidbuf, "%d", 10);
> sat =3D uidbuf[0];
> }
>=20
> int
> main(void)
> {
> if (signal(SIGINT, handler) !=3D 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=3D0xffffd734, src0=3D<optimized out>, =
length=3D<optimized out>) at /usr/src/lib/libc/string/bcopy.c:124
> 124 TLOOP1(*--dst =3D *--src);
> (gdb) bt
> #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D<optimized out>, =
length=3D<optimized out>) at /usr/src/lib/libc/string/bcopy.c:124
> #1 0x419a3984 in __sfvwrite (fp=3D<optimized out>, uio=3D<optimized =
out>) at /usr/src/lib/libc/stdio/fvwrite.c:128
> #2 0x41934468 in __sprint (fp=3D<optimized out>, uio=3D<optimized =
out>, locale=3D<optimized out>) at =
/usr/src/lib/libc/stdio/vfprintf.c:164
> #3 io_flush (iop=3D<optimized out>, locale=3D<optimized out>) at =
/usr/src/lib/libc/stdio/printfcommon.h:155
> #4 __vfprintf (fp=3D<optimized out>, locale=3D<optimized out>, =
fmt0=3D<optimized out>, ap=3D<optimized out>) at =
/usr/src/lib/libc/stdio/vfprintf.c:1020
> #5 0x4199c644 in snprintf (str=3D0xffffd734 "", n=3D<optimized out>, =
fmt=3D0x1800850 "%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.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
On 2016-Jan-19, at 2:35 AM, Mark Millard <markmi@dsl-only.net> 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=3Dpowerpc . WITH_LIBCPLUSPLUS=3D and clang related =
material built,
gcc 4.2.1 related material not built. WITH_BOOT=3D as well. I choose
WITHOUT_DEBUG=3D and WITHOUT_DEBUG_FILES=3D . (I've not tried enabling =
them yet.)
binutils is not from ports.
F) Use DESTDIR=3D 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.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55814789-0489-48B5-867C-F678AE4EA5FF>