Re: svn commit: r280636 - head/include
On Sat, 28 Mar 2015, Mark Millard wrote: With reference to Dimitry Andric's Thu Mar 26 14:41:43 UTC 2015 note ... [... gcc's "fixing" of headers] Indeed. See also this recent discussion on -current: https://lists.freebsd.org/pipermail/freebsd-current/2015-March/055111.html where a "fixed" stdio.h (from a gcc port) causes trouble. Preface: I do not want to be taken as indicating that GCC manipulation of headers to make alternates is a good thing: it is not. I expect that such creates lots of problems, as has been indicated. But I also maintain that the code sighted in https://lists.freebsd.org/pipermail/freebsd-current/2015-March/055111.html also has a problem relative to the C language standards (various vintages), independent of any gcc header manipulation of the C standard headers or FreeBSD headers. Setting up the context for the point: The code references the type name va_list from a #include'd header () that is not from a C standard in order to declare a function that is not from a C standard (__xvprintf). is nonstandard, so it can do anything it wants, including requiring users of it to do certain things although that is of low quality. It does do the latter. stdio.h is fairly careful about namespace pollution, but printf.h has mounds of namespace pollution. It is not documented in any man page, and I don't like it so I try not to look at it and don't remember what it is supposed to do. Outside of libraries, it is only used in a single place in /usr/src (hastd). So it appears to be an implementation detail that escaped. It might be clean enough for an implementation detail. It has 4 namespace errors and 1 or 4 style bugs in the line that declares __xvprintf(). Almost all the identifiers have 1 or 2 bugs: X int __xvprintf(FILE *fp, const char *fmt0, va_list ap); - "int" is correct - after "int", there is the style bug not indenting the function name. All the prototypes in this file have this bug. stdio uses the very strict KNF indentation of 1 tab, then 1 space to line after the function names after putting a "*" in front of some of them - "__xvprintf" is correct - "FILE" is correct. This file has stdio.h as a prerequisite (though it includes stdio.h itself, perhaps for its broken conversion to a public header) - "fp" is broken since it is in the application namespace - "fp" is a style bug in strict KNF. Strict KNF disallows names for parameters in prototypes to avoid the previous bug in a way that I don't like. The originators of this style didn't like names with the necessary number of underscores (1). - "fmt0" and "ap" have the same 2 bugs as "fp" - "va_list" is more fundamentally broken. It is not always declared in stdio.h, so it cannot be used here. In C99, stdio.h is not permitted to declared it. I forget if C99 always leaves it in the application namespace unless is included. POSIX broke this in some cases, and FreeBSD broke it in more cases (see below). Apparently, gcc causes further problems by "fixing" some cases. Indeed, gcc48 "fixes" the broken declaration of va_list to one of __not_va_list__, and fixes the non-broken use of __va_list to use of __gnu_va_list. gcc can hard-code __gnu_va_list like this, but FreeBSD cannot. FreeBSD's __va_list is a macro that expands to __gnu_va_list iff that is correct. __not_va_list__ seems to be completely broken. Sometimes it is correct for stdio.h to declare va_list, and the "fix" breaks these cases. printf.h should take the same care as stdio.h here. For va_list, this is just to use __va_list like stdio.h does in 9 places. Most of the other bugs can be fixed by removing the parameter names. stdio.h used to be careful with parameter names, but now has bugs like missing parentheses in almost all of the uses of the parameter names in the __cplusplus section at the end of the file (these are macro parameters, so their names don't need underscores). The only obvious bugs in parameters in old code is missing parentheses for fropen() and fwopen(). The brokenness of va_list in is: - POSIX.1-2001 is broken by specifying va_list to be declared in for the XSI case - some time after the 2004 version on the web, but before a 2007 draft version, POSIX completed this breakage by specifying va_list to be declared in unconditionally. It marks this as a C extension of course - C11 didn't break this, at least in the n1570.pdf draft. It still doesn't have it in stdio.h, and says to include both and before using each of the varargs functions in . Using these functions without including may even be an error if their va_list parameter is just passed to another function. FreeBSD's implementation using the __va_list spelling doesn't force an error in this case. - FreeBSD broke this for 2001 POSIX until before the version of POSIX that completed the breakage, by declaring va_list in stdio.h for all versions of POSIX >= 200112, instead of for all vers
Re: Fails to build sys/i386/boot2 with gcc 4.9
> On Mar 28, 2015, at 5:33 PM, Dimitry Andric wrote: > > On 29 Mar 2015, at 00:05, Craig Rodrigues wrote: >> >> To work around the problems build rescue, this time I used a build host >> running FreeBSD-CURRENT at svn revision r280353 >> >> I took this patch for libc++ and applied it to my tree: >> >> http://reviews.llvm.org/D8461 > > I've only got one minor remark left on that fix, which is that it > doesn't work for gcc 4.7. Once we either say that version of gcc is > just buggy and can't be helped, or have some other way of fixing the > original problem, I'll import it. > > > >> I used this script to build with gcc 4.9: >> >> https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh >> >> Buildling sys/i386/boot2 failed: > ... >> output: fmt=bin size=21ef text=200 data=1fef org=0 entry=0 >> -1007 bytes available >> *** Error code 1 > > Oof, this is going to be hard to fix. For some reason, boot2 is one of > those programs that keeps getting worse (i.e. larger) with *each* new > compiler version, be it gcc or clang! > > The last few times when we imported a new clang version, we had to jump > through several hoops, and attempted to shrink the code again with > various cleanups. Even then, we don't have a lot of headroom. > > If it is now also becoming a problem with gcc 4.9, we should really > start looking for a more permanent solution, e.g.: > * Getting rid of the 7680 byte limit (seems to be impossible?) > * Rewrite most of (or all of) boot2 in assembly The 7680 byte limit is a hard limit. Rewriting in assembler is possible, but just using the 4.2.1-compiled .s file might be a good place to start. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
svn commit: r280636 - head/include
With reference to Dimitry Andric's Thu Mar 26 14:41:43 UTC 2015 note ... > On 26 Mar 2015, at 14:20, Tijl Coosemans wrote: > > > > On Thu, 26 Mar 2015 17:37:53 +1100 (EST) Bruce Evans > optusnet.com.au> wrote: > >> On Wed, 25 Mar 2015, Pedro Giffuni wrote: > ... > >>> The reason why I had to revert the change is actually a systematic > >>> bug in gcc: during it's build process gcc generates a new cdefs.h > >>> from our headers. Attempting to use an older gcc from ports > >>> that was build with the broken mono-parameter __nonnull() ended > >>> up causing breakage in any code using signal.h or pthreads.h. > >> > >> I see. gcc's "fixed" headers cause lots of problems. > > > > I've complained about this multiple times in the past. The gcc ports > > should not install these "fixed" headers. > > Indeed. See also this recent discussion on -current: > > https://lists.freebsd.org/pipermail/freebsd-current/2015-March/055111.html > > where a "fixed" stdio.h (from a gcc port) causes trouble. > > -Dimitry > Preface: I do not want to be taken as indicating that GCC manipulation of headers to make alternates is a good thing: it is not. I expect that such creates lots of problems, as has been indicated. But I also maintain that the code sighted in https://lists.freebsd.org/pipermail/freebsd-current/2015-March/055111.html also has a problem relative to the C language standards (various vintages), independent of any gcc header manipulation of the C standard headers or FreeBSD headers. Setting up the context for the point: The code references the type name va_list from a #include'd header () that is not from a C standard in order to declare a function that is not from a C standard (__xvprintf). The point: That code does so before any #include happens in the #include sequence. Under the C standards one must include a standard header before one's own code can validly refer to anything that the standard header officially defines or declares. For the C standard headers themselves (various C standard vintages): is supposed to declare the likes of vfprintf, vprintf, and vsprintf but not the public name va_list, just using a private-named/anonymous synonym for the type to declare the functions. Also is not supposed to include . The standard headers have mutual independence (so include-order-independence) and idempotent status (include-repeatability) only relative to each other, not relative to one's own code that references the standard header content. is the only C standard header that is supposed to define the public name va_list (and so the one publicly available synonym for the type in question). Where I get this from: Much of my background information for this and the terminology that I use for the C library is from The Standard C Library by P. J. Plauger, Copyright 1992. But I've not noticed any later ANSI/ISO/IEC material indicating that the above material has changed status in more recent vintages of the standard. I could be wrong since I've not tried to be comprehensive about analyzing all the changes. I have a copy of BS ISO/IEC 9899:1999 (with Technical Corrigendum 1 incorporated and with the Revision 5.10 C Rationale) but not of the C11 vintage of the standard. I'll shut-up on this point after this note (unless I get a question/request) and I'll leave it to official FreeBSD folks for any further consideration of what to do about the code sighted in https://lists.freebsd.org/pipermail/freebsd-current/2015-March/055111.html . Attempting to present my claim a 3rd time seems enough, likely overkill already. I sent this note to freebsd-toolchain as it seemed more relevant than freebsd-current for the issue involved. === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Fails to build sys/i386/boot2 with gcc 4.9
On 29 Mar 2015, at 00:05, Craig Rodrigues wrote: > > To work around the problems build rescue, this time I used a build host > running FreeBSD-CURRENT at svn revision r280353 > > I took this patch for libc++ and applied it to my tree: > > http://reviews.llvm.org/D8461 I've only got one minor remark left on that fix, which is that it doesn't work for gcc 4.7. Once we either say that version of gcc is just buggy and can't be helped, or have some other way of fixing the original problem, I'll import it. > I used this script to build with gcc 4.9: > > https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh > > Buildling sys/i386/boot2 failed: ... > output: fmt=bin size=21ef text=200 data=1fef org=0 entry=0 > -1007 bytes available > *** Error code 1 Oof, this is going to be hard to fix. For some reason, boot2 is one of those programs that keeps getting worse (i.e. larger) with *each* new compiler version, be it gcc or clang! The last few times when we imported a new clang version, we had to jump through several hoops, and attempted to shrink the code again with various cleanups. Even then, we don't have a lot of headroom. If it is now also becoming a problem with gcc 4.9, we should really start looking for a more permanent solution, e.g.: * Getting rid of the 7680 byte limit (seems to be impossible?) * Rewrite most of (or all of) boot2 in assembly -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Fails to build sys/i386/boot2 with gcc 4.9
Hi,
To work around the problems build rescue, this time I used a build host
running FreeBSD-CURRENT at svn revision r280353
I took this patch for libc++ and applied it to my tree:
http://reviews.llvm.org/D8461
I used this script to build with gcc 4.9:
https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh
Buildling sys/i386/boot2 failed:
===> sys/boot/i386/boot2 (all)
objcopy -S -O binary boot1.out boot1
dd if=/dev/zero of=boot2.ldr bs=512 count=1
1+0 records in
1+0 records out
512 bytes transferred in 0.34 secs (14989607 bytes/sec)
/usr/local/bin/x86_64-portbld-freebsd11.0-gcc -isystem
/usr/obj/opt2/branches/head/tmp/usr/include
-L/usr/obj/opt2/branches/head/tmp/usr/lib
--sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/
-fomit-frame-pointer -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2
-DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600
-I/opt2/branches/head/sys/boot/i386/boot2/../../common
-I/opt2/branches/head/sys/boot/i386/boot2/../btx/lib -I. -Wall
-Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow
-Wstrict-prototypes -Wwrite-strings -Winline -march=i386 -ffreestanding
-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32
-std=gnu99-Os -fno-guess-branch-probability -fno-unit-at-a-time
--param max-inline-insns-single=100 -mpreferred-stack-boundary=2 -S -o
boot2.s.tmp /opt2/branches/head/sys/boot/i386/boot2/boot2.c
/opt2/branches/head/sys/boot/i386/boot2/boot2.c: In function 'parse':
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:484:6: warning: suggest
parentheses around assignment used as truth value [-Wparentheses]
if (k = ep - arg) {
^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c: In function 'load':
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:334:9: warning: called from
here [-Winline]
if (xfsread(ino, &hdr, sizeof(hdr)))
^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:341:6: warning: called from
here [-Winline]
if (xfsread(ino, p, hdr.ex.a_text))
^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:344:6: warning: called from
here [-Winline]
if (xfsread(ino, p, hdr.ex.a_data))
^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:349:10: warning: called
from here [-Winline]
if (xfsread(ino, ep + j, sizeof(ep[0])))
^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:357:10: warning: called
from here [-Winline]
if (xfsread(ino, p, ep[i].p_filesz))
^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:365:10: warning: called
from here [-Winline]
if (xfsread(ino, &es, sizeof(es)))
^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:371:7: warning: called from
here [-Winline]
if (xfsread(ino, p, es[i].sh_size))
^
sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s
rm -f boot2.s.tmp
/usr/local/bin/x86_64-portbld-freebsd11.0-gcc -isystem
/usr/obj/opt2/branches/head/tmp/usr/include
-L/usr/obj/opt2/branches/head/tmp/usr/lib
--sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/
-m32 -c boot2.s
/usr/local/bin/x86_64-portbld-freebsd11.0-gcc -isystem
/usr/obj/opt2/branches/head/tmp/usr/include
-L/usr/obj/opt2/branches/head/tmp/usr/lib
--sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/
-fomit-frame-pointer -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2
-DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600
-I/opt2/branches/head/sys/boot/i386/boot2/../../c
Re: Failed to build rescue with gcc 4.9
On Sat, Mar 28, 2015 at 2:34 PM, Craig Rodrigues wrote: > > > I double checked. cat.lo is not a truncated file. > # ls -l cat.lo ; file cat.lo > -rw-r--r-- 1 jenkins wheel 13112 Mar 28 21:17 cat.lo > cat.lo: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), stripped > > Hmm, so file reports that it is an ELF file, but readelf barfs on the file. I have the file here for anyone who wants to look at it: http://people.freebsd.org/~rodrigc/cat.lo # file cat.lo ; readelf -a cat.lo cat.lo: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), stripped readelf: Error: Unable to read in 0x40 bytes of section headers ELF Header: Magic: 7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI:UNIX - FreeBSD ABI Version: 0 Type: REL (Relocatable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 51092930964640 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 0 (bytes) Number of program headers: 0 Size of section headers: 64 (bytes) Number of section headers: 19 Section header string table index: 16 readelf: Error: Unable to read in 0x4c0 bytes of section headers readelf: Error: Section headers are not available! Abort trap (core dumped) -- Craig ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Failed to build rescue with gcc 4.9
Hi, The build host VM that I used was FreeBSD 10.1-RELEASE, amd64. I took this patch for libc++ and applied it to my tree: http://reviews.llvm.org/D8461 I used this script to build with gcc 4.9: https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh Building rescue failed. You can see the full build log here: https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/26/console The relevant section seems to be this: --- rescue --- /usr/local/bin/x86_64-portbld-freebsd10.0-gcc -isystem /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include -L/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/lib --sysroot=/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp -B/usr/local/x86_64-freebsd/bin/ -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo sleep.lo stty.lo sync.lo test.lo rcp.lo csh.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo bsdlabel.lo fdisk.lo dhclient.lo head.lo mt.lo nc.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo less.lo xz.lo tar.lo vi.lo id.lo zdb.lo chroot.lo chown.lo /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/exec.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/getusershell.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/login_class.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/popen.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/rcmdsh.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/sysctl.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/system.o -lcrypt -ledit -ljail -lkvm -ll -ltermcapw -lutil -lxo -lalias -lcam -lncursesw -ldevstat -lipsec -llzma -lavl -lzpool -lzfs_core -lzfs -lnvpair -lpthread -luutil -lumem -lgeom -lbsdxml -lkiconv -lmt -lsbuf -lufs -lz -lbz2 -larchive -lcrypto -lmd -lm cat.lo: file not recognized: File truncated collect2: error: ld returned 1 exit status *** [rescue] Error code 1 make[5]: stopped in /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue 1 error I double checked. cat.lo is not a truncated file. # ls -l cat.lo ; file cat.lo -rw-r--r-- 1 jenkins wheel 13112 Mar 28 21:17 cat.lo cat.lo: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), stripped Any ideas? -- Craig ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: lldb compilation problem with gcc 4.9
On Fri, Mar 27, 2015 at 10:03 PM, Craig Rodrigues wrote: > Hi, > > I had problems compiling lldb with gcc 4.9. > > See problem description plus patch which I submitted upstream: > > https://llvm.org/bugs/show_bug.cgi?id=23051 > > My patch was accepted upstream: http://llvm.org/viewvc/llvm-project?view=revision&revision=233478 -- Craig ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
