Re: [CFT]: ClangBSD is selfhosting, we need testers now
On Fri, Apr 16, 2010 at 06:08:18PM +0200, Roman Divacky wrote: > Hi, > > ClangBSD is a branch of FreeBSD that aims at integrating clang > (clang.llvm.org) > into FreeBSD, replacing GCC as a system compiler. > > Recently, we've achieved the state when clang can compile all of FreeBSD world > on i386/amd64 platforms (including all the C++ apps we have and itself) > and a bootable kernel. Thus we feel that the time has come to ask the FreeBSD > community for wider testing on i386/amd64 (you sure can help with other > platforms too :)). > > How to setup ClangBSD: > > The default configuration of ClangBSD requires clang installed so you can > either install fresh llvm-devel port (portinstall devel/llvm-devel) or change > CC to "gcc" and CXX to "g++" in share/mk/sys.mk. I recommend the former. > > > svn co http://svn.freebsd.org/base/projects/clangbsd/ clangbsd > > cd clangbsd && make buildworld > > echo NO_WERROR= >> /etc/make.conf > echo WERROR=>> /etc/make.conf you have to do those echos before the buildworld of course... sorry, my mistake ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fix for compressed coredumps, please review
On Fri, 16 Apr 2010 18:16:14 -0700
Alfred Perlstein wrote:
> Can I get a review for this?
>
> summary:
> If doing compressed cores and there is an error, we leak
> resources unless this is fixed.
>
>
> Index: imgact_elf.c
> ===
> --- imgact_elf.c (revision 206498)
> +++ imgact_elf.c (working copy)
> @@ -29,7 +29,7 @@
> */
>
> #include
> -__FBSDID("$FreeBSD$");
> +__FBSDID("$FreeBSD: head/sys/kern/imgact_elf.c 205643 2010-03-25 14:31:26Z
> nwhitehorn $");
>
> #include "opt_compat.h"
> #include "opt_core.h"
> @@ -1088,8 +1088,10 @@
> hdrsize = 0;
> __elfN(puthdr)(td, (void *)NULL, &hdrsize, seginfo.count);
>
> - if (hdrsize + seginfo.size >= limit)
> - return (EFAULT);
> + if (hdrsize + seginfo.size >= limit) {
> + error = EFAULT;
> + goto done;
> + }
>
> /*
>* Allocate memory for building the header, fill it up,
> @@ -1097,7 +1099,8 @@
>*/
> hdr = malloc(hdrsize, M_TEMP, M_WAITOK);
> if (hdr == NULL) {
> - return (EINVAL);
> + error = EINVAL;
> + goto done;
> }
> error = __elfN(corehdr)(td, vp, cred, seginfo.count, hdr, hdrsize,
> gzfile);
> @@ -1125,8 +1128,8 @@
> curproc->p_comm, error);
> }
>
> +done:
> #ifdef COMPRESS_USER_CORES
> -done:
> if (core_buf)
> free(core_buf, M_TEMP);
> if (gzfile)
>
Looks good to me.
Actually, you don't need the "if (core_buf)" since free(9) DTRT with NULL.
--
Gary Jennejohn (gj@)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ISO9660 4GB directory structures boundary limit and growisofs
on 17/04/2010 02:07 Paul B Mahol said the following: > Hi, > > It is apparently not possible to make use of -use-the-force-luke=4gms > on FreeBSD when appending new session after 4GB. Mounted disk > afterwards show nothing. Is it expected that everyone knows what -use-the-force-luke=4gms is? > Should we allow it like linux does? What exactly is disallowed on FreeBSD? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ISO9660 4GB directory structures boundary limit and growisofs
On 4/17/10, Andriy Gapon wrote: > on 17/04/2010 02:07 Paul B Mahol said the following: >> Hi, >> >> It is apparently not possible to make use of -use-the-force-luke=4gms >> on FreeBSD when appending new session after 4GB. Mounted disk >> afterwards show nothing. > > Is it expected that everyone knows what -use-the-force-luke=4gms is? > >> Should we allow it like linux does? > > What exactly is disallowed on FreeBSD? http://fy.chalmers.se/~appro/linux/DVD+RW/ search for 4gms :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
On 16 Apr 2010, at 22:41, Ivan Voras wrote: > Roman Divacky wrote: > >> We kindly ask you to setup ClangBSD chroot and/or use clang compiled kernel >> and use it as you would normally use FreeBSD. Please report back > > I have a buildworld error here: > > clang -isystem /usr/obj/mt/clangbsd/tmp/usr/include/clang/1.5 -isystem > /usr/obj/mt/clangbsd/tmp/usr/include -B/usr/obj/mt/clangbsd/tmp/usr/lib/ > -L/usr/obj/mt/clangbsd/tmp/usr/lib/ -fpic -DPIC -O2 -pipe -mtune=generic > -I/mt/clangbsd/lib/libc/include -I/mt/clangbsd/lib/libc/../../include > -I/mt/clangbsd/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE > -I/mt/clangbsd/lib/libc/../../contrib/gdtoa -DINET6 > -I/usr/obj/mt/clangbsd/lib/libc -I/mt/clangbsd/lib/libc/resolv -D_ACL_PRIVATE > -DPOSIX_MISTAKE -I/mt/clangbsd/lib/libc/../../contrib/tzcode/stdtime > -I/mt/clangbsd/lib/libc/stdtime -I/mt/clangbsd/lib/libc/locale -DBROKEN_DES > -DPORTMAP -DDES_BUILTIN -I/mt/clangbsd/lib/libc/rpc -DYP -DNS_CACHING > -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror > -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c > /mt/clangbsd/lib/libc/sys/__error.c -o __error.So > /mt/clangbsd/lib/libc/sys/stack_protector.c:88:19: error: format string is > not a string literal (potentially insecure) [-Wformat-security] >syslog(LOG_CRIT, msg); > ^~~ > 1 diagnostic generated. > *** Error code 1 > /mt/clangbsd/lib/libc/sys/stack_protector.c:88:19: error: format string is > not a string literal (potentially insecure) [-Wformat-security] >syslog(LOG_CRIT, msg); > ^~~ > 1 diagnostic generated. > *** Error code 1 > 2 errors > *** Error code 2 > 1 error > > > The context is... I think a bit overprotective here :) At least this > particular warning knob should probably be turned off. Actually, I would rather fix the code that does this than disabling the warning. Even if this particular code is not vulnerable to format string problems, it's 2010 now and it doesn't hurt to add a "%s" there. Regards, -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HP, IBM and Supermicro Servers Compatibility.
We use Supermicro here extensively and have never had a single problem with them. We tend to combine them with Areca RAID cards which also work well with FreeBSD. Regards Steve - Original Message - From: "Juanito Cassemiro" To: Sent: Thursday, April 15, 2010 6:10 PM Subject: HP, IBM and Supermicro Servers Compatibility. Hi. I want to know if the IBM, HP or Supermicro Servers are compatible with FreeBSD OS. Could you send me a hardware compatibility list with compatible servers? Thank you. Juanito Caue Cassemiro Técnico em Informática INFO2001 - IARA CRISTINA DA SILVA MEIRELLES ARARAQUARA (16)3331-7727 0800-8912360 Skype: juanitocc_2001 MSN: juanitocc_2...@hotmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r206408 - in head: etc etc/defaults etc/rc.d share/man/man5
Doug Barton wrote in <4bc8ee88.6000...@freebsd.org>: do> > or if the do> > commit hadn't happed in the middle of a discussion that died with do> > this. do> do> I took from the discussion the few things that we had achieved some form do> of consensus on, and chose to drop the rest of the topics that I had do> severe disagreements about. I also followed up to the list regarding do> this, and my reasons for dropping out. No, you changed the meaning of $ipv6_prefer, which does not agree with one of the results of discussion. When ipv6_prefer=YES, ifdisabled flag must be cleared on all interfaces. The reason is to enable automatic link-local address assignment without manual configuration. I explained again and again, the ifdisabled flag is *not for* disabling IPv6 on an interface as opposed to the name. In rc.d scripts this is used for controlling link-local address assignment. Your change removed the logic in no $ifconfig_IF_ipv6 case, and it is not a consensus. I strongly disagree with this because some IPv6 applications depend on link-local address automatically added on cloned interfaces and at the same time IPv4 people do not like the link-local address. We need a knob to control that, and the default should be "no link-local when no ifconfig_IF_ipv6", and "all interfaces have a link-local address when $ipv6_prefer=YES". For all scenarios I can think of this is the least-worst. Also, source address selection has to be IPv4-preferred by default. Why did you change this? I disagree with this. I want "IPv6 enabled by default", but we are not ready for "IPv6 is preferred when the both are available" for various reasons. do> > So usually we seem to use the upper case pseudo arguments like DHCP, do> > SYNCDHCP, WPA, .. in combination with an actual command to start apart do> > from ifconfig. Now RTADV does not do that but it passes accept_rtadv or do> > -accept_rtadv to ifconfig. So if you need a command alias for that it do> > should probably be in ifconfig and discussed separately. do> do> I understand your argument, but I don't agree with it. The one thing do> that there was actually strong consensus on was that the IPv6 do> configuration should have feature-parity with IPv4. Given that we have do> easy to use knobs to enable things like DHCP and WPA that users are do> already familiar with it made sense to me to introduce the same types of do> knobs for RA. This is in anticipation of also adding support for DHCPV6 do> at some point in the future. From a user interface standpoint it does do> not make sense to have one form of IPv6 configuration to require an do> ifconfig statement, and another to have a knob. do> do> Furthermore: do> 1. I explicitly included support for the existence of [-]accept_rtadv in do> ifconfig_IF_ipv6 so if you or anyone else prefers that method of do> configuration it's available to you. do> 2. Just because RTADV doesn't start something "apart from ifconfig" now do> doesn't mean it won't or can't in the future. Specifically I'd like to do> see this knob turn on rtsold as well. (Even if I thought your argument do> above was valid, which I do not.) So please add that after you implement it and RTADV is not equivalent to accept_rtadv. I cannot understand why we need to add it now. At this moment, having two keywords makes nothing easy. Invoking rtsold (and/or dhclient) when receiving RAs are not so simple. Did you really try that? I personally lean to having a userland daemon to handle RA options including RDNSS and O-flag. If you want direction for extending rc.d scripts to handle them, please show the concrete implementation first as David Horn did. I think this is not a simple one like just adding a keyword and careful consideration is needed before implementing it. do> It did not. Previous to the introduction (and overloading) of the do> ipv6_prefer knob if you enabled IPv6 support with ipv6_enable it was do> preferred. With the code just prior to my change in order to configure do> IPv6 for an interface at all it was necessary to set ipv6_prefer to on, do> which meant that there was no way to have IPv6 configured but not have do> it be preferred. That behavior was intentional. Please keep it disabled by default. I disagree with decoupling seatbelt for link-local addr assignment from IPv6-preferred source address selection. The IPv6-preferred source address selection is troublesome for IPv4-only people, and for IPv6-people the seatbelt for link-local addr is troublesome. I designed $ipv6_prefer as a knob for this trade-off. -- Hiroki pgpW03Tnuoi30.pgp Description: PGP signature
Re: ISO9660 4GB directory structures boundary limit and growisofs
Paul B Mahol wrote: It is apparently not possible to make use of -use-the-force-luke=4gms on FreeBSD when appending new session after 4GB. Mounted disk afterwards show nothing. Should we allow it like linux does? Are you claiming there is a problem when FreeBSD reads such images or a problem with creating such images? What programs are you using? This sounds like a pretty unsurprising 32-bit truncation bug: the filesystem structures in ISO9660 are all sector numbers so 8TB should be the natural limit (4G sectors times 2k bytes/sector). Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
On 2010-04-16 18:08, Roman Divacky wrote: cd clangbsd&& make buildworld Buildworld all goes well, until this stage: -- stage 4.2: building libraries -- cd /home/dim/src/clangbsd; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/home/dim/src/clangbsd/tmp VERSION="FreeBSD 9.0-CURRENT i386 900010" INSTALL="sh /home/dim/src/clangbsd/tools/install.sh" PATH=/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/sbin:/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/bin:/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/games:/usr/obj/home/dim/src/clangbsd/tmp/usr/sbin:/usr/obj/home/dim/src/clangbsd/tmp/usr/bin:/usr/obj/home/dim/src/clangbsd/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin CC="clang -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include/clang/1.5 -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include -B/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/ -L/usr/o bj/home/dim/src/clangbsd/tmp/usr/lib/" CXX="clang++ -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include/clang/1.5 -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include -isystem /usr/obj/home/dim/src/clangbsd/tmp/include/c++/4.2 -isystem /usr/obj/home/dim/src/clangbsd/tmp/include/c++/4.2/backward -B/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/ -L/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/" NO_CTF=1 make -f Makefile.inc1 DESTDIR=/usr/obj/home/dim/src/clangbsd/tmp -DNO_FSCHG -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DWITHOUT_PROFILE libraries cd /home/dim/src/clangbsd; make -f Makefile.inc1 _prereq_libs; make -f Makefile.inc1 _startup_libs; make -f Makefile.inc1 _prebuild_libs; make -f Makefile.inc1 _generic_libs; ===> gnu/lib/libssp/libssp_nonshared (obj,depend,all,install) rm -f .depend CC='clang -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include/clang/1.5 -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include -B/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/ -L/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/' mkdep -f .depend -a -DHAVE_CONFIG_H -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/.. -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include -DPIC /home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c clang -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include/clang/1.5 -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include -B/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/ -L/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/ -O2 -pipe -DHAVE_CONFIG_H -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/.. -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include -fPIC -DPIC -fvisibility=hidden -std=gnu99 -fstack-protector -c /home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c '486' is not a recognized processor for this target (ignoring processor) building static ssp_nonshared library ranlib libssp_nonshared.a sh /home/dim/src/clangbsd/tools/install.sh -C -o root -g wheel -m 444 libssp_nonshared.a /usr/obj/home/dim/src/clangbsd/tmp/usr/lib ===> gnu/lib/libgcc (obj,depend,all,install) make -f /home/dim/src/clangbsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/home/dim/src/clangbsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc tm.h TARGET_CPU_DEFAULT="" HEADERS="options.h i386/i386.h i386/unix.h i386/att.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h i386/freebsd.h defaults.h" DEFINES="" /bin/sh /home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tm.h echo '#define EXTRA_MODES_FILE "i386/i386-modes.def"' >> tm.h make -f /home/dim/src/clangbsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/home/dim/src/clangbsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc tconfig.h TARGET_CPU_DEFAULT="" HEADERS="auto-host.h ansidecl.h" DEFINES="USED_FOR_TARGET" /bin/sh /home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tconfig.h make -f /home/dim/src/clangbsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/home/dim/src/clangbsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc options.h LC_ALL=C awk -f /home/dim/src/clangbsd/gnu/l
Re: [CFT]: ClangBSD is selfhosting, we need testers now
On 2010-04-17 11:58, Roman Divacky wrote: svn co http://svn.freebsd.org/base/projects/clangbsd/ clangbsd cd clangbsd&& make buildworld echo NO_WERROR=>> /etc/make.conf echo WERROR=>> /etc/make.conf you have to do those echos before the buildworld of course... sorry, my mistake Btw, http://wiki.freebsd.org/BuildingFreeBSDWithClang says to put these in src.conf, it does not mention make.conf. This is most likely the correct location, right? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ISO9660 4GB directory structures boundary limit and growisofs
On Sat, Apr 17, 2010 at 4:31 PM, Tim Kientzle wrote: > Paul B Mahol wrote: >> >> It is apparently not possible to make use of -use-the-force-luke=4gms >> on FreeBSD when appending new session after 4GB. Mounted disk >> afterwards show nothing. >> >> Should we allow it like linux does? > > Are you claiming there is a problem when FreeBSD reads such > images or a problem with creating such images? What > programs are you using? I burn flac files in multiple sessions, each session have separate directory, on DVD+R DL MKM/003 After I used 4gms switch mounted fs shows nothing. (but there is >5GB of data) According to growisofs source BD (bluray) dont need this switch at all ... > This sounds like a pretty unsurprising 32-bit truncation > bug: the filesystem structures in ISO9660 are all sector > numbers so 8TB should be the natural limit (4G sectors > times 2k bytes/sector). I did not tested this on FreeBSD amd64 yet. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
Roman Divacky wrote: > Recently, we've achieved the state when clang can compile all of FreeBSD world > on i386/amd64 platforms (including all the C++ apps we have and itself) > and a bootable kernel. bigback:/usr/clangbsd# make buildworld . . . clang++ -O2 -pipe -I/usr/clangbsd/usr.bin/clang/lib/libllvmsupport/../../../../contrib/llvm/include -I/usr/clangbsd/usr.bin/clang/lib/libllvmsupport/../../../../contrib/llvm/tools/clang/include -I/usr/clangbsd/usr.bin/clang/lib/libllvmsupport/../../../../contrib/llvm/lib/Support -I. -I/usr/clangbsd/usr.bin/clang/lib/libllvmsupport/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"amd64-undermydesk-freebsd9.0\" -g -I/usr/obj/usr/clangbsd/tmp/legacy/usr/include -c /usr/clangbsd/usr.bin/clang/lib/libllvmsupport/../../../../contrib/llvm/lib/Support/DeltaAlgorithm.cpp /tmp/cc-Jb5jkf.s: Assembler messages: /tmp/cc-Jb5jkf.s:4487: Error: can not do 8 byte pc-relative relocation /tmp/cc-Jb5jkf.s:4607: Error: can not do 8 byte pc-relative relocation /tmp/cc-Jb5jkf.s:4640: Error: can not do 8 byte pc-relative relocation /tmp/cc-Jb5jkf.s:4787: Error: can not do 8 byte pc-relative relocation /tmp/cc-Jb5jkf.s:4820: Error: can not do 8 byte pc-relative relocation /tmp/cc-Jb5jkf.s:4969: Error: can not do 8 byte pc-relative relocation clang: error: assembler command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop in /usr/clangbsd/usr.bin/clang/lib/libllvmsupport. *** Error code 1 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
what version of clang/llvm are you using? On Sat, Apr 17, 2010 at 11:48:02AM -0500, James R. Van Artsdalen wrote: > Roman Divacky wrote: > > Recently, we've achieved the state when clang can compile all of FreeBSD > > world > > on i386/amd64 platforms (including all the C++ apps we have and itself) > > and a bootable kernel. > > bigback:/usr/clangbsd# make buildworld > . > . > . > clang++ -O2 -pipe > -I/usr/clangbsd/usr.bin/clang/lib/libllvmsupport/../../../../contrib/llvm/include > -I/usr/clangbsd/usr.bin/clang/lib/libllvmsupport/../../../../contrib/llvm/tools/clang/include > -I/usr/clangbsd/usr.bin/clang/lib/libllvmsupport/../../../../contrib/llvm/lib/Support > -I. -I/usr/clangbsd/usr.bin/clang/lib/libllvmsupport/../../include > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS > -DLLVM_HOSTTRIPLE=\"amd64-undermydesk-freebsd9.0\" -g > -I/usr/obj/usr/clangbsd/tmp/legacy/usr/include -c > /usr/clangbsd/usr.bin/clang/lib/libllvmsupport/../../../../contrib/llvm/lib/Support/DeltaAlgorithm.cpp > /tmp/cc-Jb5jkf.s: Assembler messages: > /tmp/cc-Jb5jkf.s:4487: Error: can not do 8 byte pc-relative relocation > /tmp/cc-Jb5jkf.s:4607: Error: can not do 8 byte pc-relative relocation > /tmp/cc-Jb5jkf.s:4640: Error: can not do 8 byte pc-relative relocation > /tmp/cc-Jb5jkf.s:4787: Error: can not do 8 byte pc-relative relocation > /tmp/cc-Jb5jkf.s:4820: Error: can not do 8 byte pc-relative relocation > /tmp/cc-Jb5jkf.s:4969: Error: can not do 8 byte pc-relative relocation > clang: error: assembler command failed with exit code 1 (use -v to see > invocation) > *** Error code 1 > > Stop in /usr/clangbsd/usr.bin/clang/lib/libllvmsupport. > *** Error code 1 > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
what version of clang/llvm are you using? On Sat, Apr 17, 2010 at 07:03:14PM +0200, Dimitry Andric wrote: > On 2010-04-16 18:08, Roman Divacky wrote: > > cd clangbsd&& make buildworld > > Buildworld all goes well, until this stage: > > -- > >>>stage 4.2: building libraries > -- > cd /home/dim/src/clangbsd; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 > MACHINE=i386 CPUTYPE= > GROFF_BIN_PATH=/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/bin > GROFF_FONT_PATH=/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/share/tmac > _SHLIBDIRPREFIX=/usr/obj/home/dim/src/clangbsd/tmp VERSION="FreeBSD > 9.0-CURRENT i386 900010" INSTALL="sh > /home/dim/src/clangbsd/tools/install.sh" > PATH=/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/sbin:/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/bin:/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/games:/usr/obj/home/dim/src/clangbsd/tmp/usr/sbin:/usr/obj/home/dim/src/clangbsd/tmp/usr/bin:/usr/obj/home/dim/src/clangbsd/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin > CC="clang -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include/clang/1.5 > -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include > -B/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/ -L/usr/o > bj/home/dim/src/clangbsd/tmp/usr/lib/" CXX="clang++ -isystem > /usr/obj/home/dim/src/clangbsd/tmp/usr/include/clang/1.5 -isystem > /usr/obj/home/dim/src/clangbsd/tmp/usr/include -isystem > /usr/obj/home/dim/src/clangbsd/tmp/include/c++/4.2 -isystem > /usr/obj/home/dim/src/clangbsd/tmp/include/c++/4.2/backward > -B/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/ > -L/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/" NO_CTF=1 make -f > Makefile.inc1 DESTDIR=/usr/obj/home/dim/src/clangbsd/tmp -DNO_FSCHG > -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DWITHOUT_PROFILE > libraries > cd /home/dim/src/clangbsd; make -f Makefile.inc1 _prereq_libs; make -f > Makefile.inc1 _startup_libs; make -f Makefile.inc1 _prebuild_libs; make > -f Makefile.inc1 _generic_libs; > ===> gnu/lib/libssp/libssp_nonshared (obj,depend,all,install) > rm -f .depend > CC='clang -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include/clang/1.5 > -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include > -B/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/ > -L/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/' mkdep -f .depend -a > -DHAVE_CONFIG_H -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/.. > -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp > > -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include > -DPIC > /home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c > clang -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include/clang/1.5 > -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include > -B/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/ > -L/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/ -O2 -pipe -DHAVE_CONFIG_H > -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/.. > -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp > > -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include > -fPIC -DPIC -fvisibility=hidden -std=gnu99 -fstack-protector -c > /home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c > '486' is not a recognized processor for this target (ignoring processor) > building static ssp_nonshared library > ranlib libssp_nonshared.a > sh /home/dim/src/clangbsd/tools/install.sh -C -o root -g wheel -m 444 > libssp_nonshared.a /usr/obj/home/dim/src/clangbsd/tmp/usr/lib > ===> gnu/lib/libgcc (obj,depend,all,install) > make -f > /home/dim/src/clangbsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > MFILE=/home/dim/src/clangbsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > GCCDIR=/home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc tm.h > TARGET_CPU_DEFAULT="" HEADERS="options.h i386/i386.h i386/unix.h > i386/att.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h > freebsd.h i386/freebsd.h defaults.h" DEFINES="" /bin/sh > /home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tm.h > echo '#define EXTRA_MODES_FILE "i386/i386-modes.def"' >> tm.h > make -f > /home/dim/src/clangbsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > MFILE=/home/dim/src/clangbsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile > GCCDIR=/home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc tconfig.h > TARGET_CPU_DEFAULT="" HEADERS="auto-host.h ansidecl.h" > DEFINES="USED_FOR_TARGET" /bin/sh > /home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh > tconfig.h > make -f > /home/
Re: [CFT]: ClangBSD is selfhosting, we need testers now
On Sat, 17 Apr 2010 20:07:05 +0300, Dimitry Andric wrote: Btw, http://wiki.freebsd.org/BuildingFreeBSDWithClang says to put these in src.conf, it does not mention make.conf. This is most likely the correct location, right? Either way works, src.conf is probably more "correct" location, but it doesn't really make a difference for clangbsd. -- Andrius ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
On 04/17/10 10:24, Andrius Morkūnas wrote: > On Sat, 17 Apr 2010 20:07:05 +0300, Dimitry Andric > wrote: >> Btw, http://wiki.freebsd.org/BuildingFreeBSDWithClang says to put these >> in src.conf, it does not mention make.conf. This is most likely the >> correct location, right? > > Either way works, src.conf is probably more "correct" location, but it > doesn't really make a difference for clangbsd. It should be in src.conf unless it is desirable for those same flags to affect port builds. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
On 2010-04-17 19:33, Roman Divacky wrote: what version of clang/llvm are you using? As I mentioned at the end of my previous post: I'm using the llvm-devel-2.7.r100430 port. This is the current devel/llvm-devel port, AFAICS? The system itself runs -CURRENT as of r206706. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
On Sat, Apr 17, 2010 at 08:14:21PM +0200, Dimitry Andric wrote: > On 2010-04-17 19:33, Roman Divacky wrote: > >what version of clang/llvm are you using? > > As I mentioned at the end of my previous post: > > >>I'm using the llvm-devel-2.7.r100430 port. > > This is the current devel/llvm-devel port, AFAICS? The system itself > runs -CURRENT as of r206706. sorry.. havent noticed that you wrote that in your first mail yes, i386 has a problem. I am just distilling the testcase and I guess it will be fixed in upstream LLVM in a couple of hours. I'll let you know. thnx for the report! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN rev 206755 breakage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The revision labeled:
SVN rev 206755 on 2010-04-17 11:40:39Z by rpaulo
Add another ICH7M chipset that works.
.. is incorrect and will cause some laptops to not boot.
Of the following identifiers:
{0x27c48086, 0x00, "Intel ICH7M", 0},
.. is the ICH7M in legacy and/or combined mode, i.e. *not* AHCI
{0x27c58086, 0x00, "Intel ICH7M", 0},
.. is the *same* chipset in AHCI mode,
imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkvKKW4ACgkQQv9rrgRC1JIMUQCeKmCz2USYE2SSyb1X5f6tes7G
DtsAoKkjFHhlPdESsziKO92LCaxK6EI5
=JAg8
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
IPv6 configuration in rc.d (Was: Re: svn commit: r206408 ...)
To add a little history to the discussion: In June of last year you posted a patch to the -rc list to update our treatment of IPv6 configuration in rc.d and bring it on par with how we configure IPv4. At the time I did not give your patch adequate review, and subsequent to it being committed a number of problems were discovered, and some things about your changes that I did not agree with became apparent to me. Some of the problems were easily fixed, others were more fundamental and required a lot more time and attention. OTOH, the majority of the work you did was really great, long overdue, and as I've said in the past you should be commended for it. I would like to be clear that for the most part where you and I disagree is not in the "under the hood" aspects of the scripting but rather in the user interface design. For a variety of reasons I was unable to give the more in-depth issues the time and attention they deserved until recently. Frankly I did not place a high priority on this because for the most part the IPv6 configuration worked, and since the changes are not going to be MFC'ed I devoted my attention to other things. (FWIW my life for over a year now has been devoted to trying to find a job, and doing what little contract work I've been able to find, including the work on portmaster that has been supported by the FreeBSD community.) For the last several weeks I have tried to engage you, and other interested parties in discussion about how IPv6 configuration in rc.d should look. For better or worse you have a very clear, well-defined vision of what you think things should look like, and have (IMO) been quite intractable. Others in the community have spoken up and expressed their opinions on how they would like to see the configuration look as well. I continue to disagree rather strongly with some of your perspectives, most notably the demise of the ipv6_enable knob. However as I expressed in my post to -current after I committed my most recent changes I judged the opinions expressed by the community as roughly evenly divided, so I regarded the fact that I was the only one complaining about it as the tie-breaking vote and agreed to let it stay dead. On other aspects of the UI design I listened to what you and our users had to say and tried to come up with what I believe is a good compromise that is clean, easy to understand, and consistent. Regarding some of the other aspects of your concept of the UI I have tried to be diplomatic and express my opinions in the context of what I believe the good points are in the changes I made. However given your continued insistence on the issues you expressed below I think I need to be more direct. While a lot of what you did was great work, several aspects of the UI that you had/have in mind are quite simply bad ideas. While to some extent I understand the goals of what you seem to be trying to achieve the ideas you have are in many cases overly complex, and more importantly inconsistent with general rc.d UI concepts and more specifically inconsistent with how we configure IPv4. I will respond more particularly to the points you make below, however as I said previously I've already spent way too much time on what (IMO) should have been some simple changes to make things easier and more consistent for our users. If after reading this message you still don't agree with my perspective I would like to suggest that you use the available dispute resolution mechanism and then we can take it from there. On 04/17/10 07:39, Hiroki Sato wrote: > Doug Barton wrote > in <4bc8ee88.6000...@freebsd.org>: > > do> > or if the > do> > commit hadn't happed in the middle of a discussion that died with > do> > this. > do> > do> I took from the discussion the few things that we had achieved some form > do> of consensus on, and chose to drop the rest of the topics that I had > do> severe disagreements about. I also followed up to the list regarding > do> this, and my reasons for dropping out. > > No, you changed the meaning of $ipv6_prefer, which does not agree > with one of the results of discussion. When ipv6_prefer=YES, > ifdisabled flag must be cleared on all interfaces. The reason is to > enable automatic link-local address assignment without manual > configuration. I'm sorry, but what you're suggesting makes no sense at all. One area that you and I agreed on was that the previous ipv6_enable knob was overloaded in the sense of controlling 3 different things that should have had separate configuration options (overall IPv6 config, accepting RAs, and preferring IPv6). Your idea to split these functions into separate configuration elements is a major step forward. However, adding a new knob for ipv6_prefer and then also overloading it to control link-local addresses is a big step backwards. The ipv6_prefer knob should control one thing, and one thing only, whether or not IPv6 transport is preferred vs. IPv4 transport. This is what I mean by "clean and simple
Re: SVN rev 206755 breakage
It's generally also a good idea to cc the author of the change just in case they don't get to their -current mail in a timely manner. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN rev 206755 breakage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/17/10 18:05, Rui Paulo wrote: > On 17 Apr 2010, at 22:34, Michael Butler wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> The revision labeled: >> >> SVN rev 206755 on 2010-04-17 11:40:39Z by rpaulo >> >> Add another ICH7M chipset that works. >> >> .. is incorrect and will cause some laptops to not boot. > > So, in AHCI mode it doesn't find the disks? No - the driver fails to attach (ENXIO). I'm looking into which resource(s) it either couldn't allocate or gain control. The BIOS on my Toshiba does not initialize BAR(5) and, in the most general case, combined mode (MAP.SMS=0b, MAP.MV=10b) is required as the hard-drive is SATA but the DVD+RW is PATA :-( imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvKMloACgkQQv9rrgRC1JJ4FACdHxDzzfGIwBS4XEnfPWGCs2Qb wSsAoJAV6q/b16joC9MylPS8ZbT2JB/b =IeOp -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN rev 206755 breakage
On 17 Apr 2010, at 22:34, Michael Butler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> The revision labeled:
>
> SVN rev 206755 on 2010-04-17 11:40:39Z by rpaulo
>
> Add another ICH7M chipset that works.
>
> .. is incorrect and will cause some laptops to not boot.
So, in AHCI mode it doesn't find the disks?
>
> Of the following identifiers:
>
>{0x27c48086, 0x00, "Intel ICH7M", 0},
>
> .. is the ICH7M in legacy and/or combined mode, i.e. *not* AHCI
>
>{0x27c58086, 0x00, "Intel ICH7M", 0},
>
> .. is the *same* chipset in AHCI mode,
Unfortunately, this is not the case on my laptop and I would rather find a way
to correctly identify the chipset instead of backing out this change.
Regards,
--
Rui Paulo
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SPOOFED: Re: SVN rev 206755 breakage
On 17 Apr 2010, at 23:12, Michael Butler wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/17/10 18:05, Rui Paulo wrote: >> On 17 Apr 2010, at 22:34, Michael Butler wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> The revision labeled: >>> >>> SVN rev 206755 on 2010-04-17 11:40:39Z by rpaulo >>> >>> Add another ICH7M chipset that works. >>> >>> .. is incorrect and will cause some laptops to not boot. >> >> So, in AHCI mode it doesn't find the disks? > > No - the driver fails to attach (ENXIO). But since ahci failed to attach, won't atapci attach later? Can you show me the dmesg? Regards, -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
In the last episode (Apr 17), Rui Paulo said: > On 16 Apr 2010, at 22:41, Ivan Voras wrote: > > I have a buildworld error here: > > > > clang -isystem /usr/obj/mt/clangbsd/tmp/usr/include/clang/1.5 -isystem > > /usr/obj/mt/clangbsd/tmp/usr/include -B/usr/obj/mt/clangbsd/tmp/usr/lib/ > > -L/usr/obj/mt/clangbsd/tmp/usr/lib/ -fpic -DPIC -O2 -pipe -mtune=generic > > -I/mt/clangbsd/lib/libc/include -I/mt/clangbsd/lib/libc/../../include > > -I/mt/clangbsd/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE > > -I/mt/clangbsd/lib/libc/../../contrib/gdtoa -DINET6 > > -I/usr/obj/mt/clangbsd/lib/libc -I/mt/clangbsd/lib/libc/resolv > > -D_ACL_PRIVATE -DPOSIX_MISTAKE > > -I/mt/clangbsd/lib/libc/../../contrib/tzcode/stdtime > > -I/mt/clangbsd/lib/libc/stdtime -I/mt/clangbsd/lib/libc/locale -DBROKEN_DES > > -DPORTMAP -DDES_BUILTIN -I/mt/clangbsd/lib/libc/rpc -DYP -DNS_CACHING > > -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror > > -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c > > /mt/clangbsd/lib/libc/sys/__error.c -o __error.So > > /mt/clangbsd/lib/libc/sys/stack_protector.c:88:19: error: format string is > > not a string literal (potentially insecure) [-Wformat-security] > >syslog(LOG_CRIT, msg); > > ^~~ > > 1 diagnostic generated. > > *** Error code 1 > > 2 errors > > *** Error code 2 > > 1 error > > > > The context is... I think a bit overprotective here :) At least this > > particular warning knob should probably be turned off. > > Actually, I would rather fix the code that does this than disabling the > warning. Even if this particular code is not vulnerable to format string > problems, it's 2010 now and it doesn't hurt to add a "%s" there. Agree. Calling sprintf-like functions with unknown format strings is dangerous. Technically, though, the code as is stands is safe, since __fail is static and the only two callers do pass safe string literals. It looks like we found three buglets here :) 1) __fail should use syslog(LOG_CRIT, "%s", msg). 2) We should add -Wformat-nonliteral to the gcc CFLAGS list so it can make the same check across the entire build (though it's no smarter than clang and emits one for this file). 3) Both clang and gcc (when asked to) emit a warning when they have enough information to know it's safe. It's better to err on the side of caution, though, and the compiler would have to analyze the whole source file to know that all the callers use the function safely. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SPOOFED: Re: SVN rev 206755 breakage
Rui Paulo wrote: > On 17 Apr 2010, at 23:12, Michael Butler wrote: >> On 04/17/10 18:05, Rui Paulo wrote: >>> On 17 Apr 2010, at 22:34, Michael Butler wrote: The revision labeled: SVN rev 206755 on 2010-04-17 11:40:39Z by rpaulo Add another ICH7M chipset that works. .. is incorrect and will cause some laptops to not boot. >>> So, in AHCI mode it doesn't find the disks? >> No - the driver fails to attach (ENXIO). > > But since ahci failed to attach, won't atapci attach later? If probe succeeded - no. > Can you show me the dmesg? More important probably would be `pciconf -lvcb`. Intel controllers after ICH6 change both ID and set of resources, depending on AHCI enabled in BIOS. There is separate set of IDs for controllers with AHCI enabled. As I can see, Linux handles ID 0x27c4 as non-AHCI SATA. If for some reason this ID could be used for both modes (I have doubts), we may try to set AHCI_Q_NOFORCE flag to make driver check PCI class/subclass, if it is correct there. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
