Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
On Aug 23, 2013, at 7:54 AM, David Chisnall wrote: On 23 Aug 2013, at 14:52, Warner Losh i...@bsdimp.com wrote: No. That breaks non x86 architecutres. gcc must remain in base for now, or there's no bootstrap ability. Nobody has done the lifting to cleanly integrate gcc as a port into buildworld, althogh Brooks' work gets us most of the way there. We've been using brooks' work to build the base system with an out-of-tree toolchain for some time now... I'll have to try the native build part of the cycle then... Early versions of the patch failed when you cross built the target, installed the target, but wound up with no compilers to bootstrap the external toolchains with to do native builds on the target. Warner ___ 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: patch to add AES intrinsics to gcc
On Aug 23, 2013, at 4:01 PM, Alfred Perlstein wrote: On 8/23/13 3:35 AM, David Chisnall wrote: On 23 Aug 2013, at 10:58, Bernhard Fröhlich de...@freebsd.org wrote: I don't know if you are aware that IF you really do that we will have serious problems to ship packages for 10. USE_GCC=any is the fallback in the portstree for all ports that are unable to build with clang which was introduced when HEAD switched to clang as default cc. Right now there are 150 ports in the tree that use this fallback and quite a few of them are high profile ports: the highlights: audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 security/clamav the full list: http://dpaste.com/1354075/ A possible hack could be to add a check for USE_GCC=any to behave like a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc from ports for a lot of people on HEAD I suppose. We certainly need to do that switch to remove the ancient gcc from base some time but with my portmgr hat on I can only say we don't plan to do that before 10.0 especially not if we are only talking about a few weeks time window. That is unfortunate. We have said for over a year that 10.0 should not ship with gcc. I can delay committing the patch to flip the switch until later in the code slush, if re approves, but ports that require gcc should be building with gcc from ports (which will also improve code quality, as gcc 4.6/7 produce significantly better code than 4.2.1). David ___ Why can't ports just then add the old-version of GCC? This tight coupling between src and ports is screwing us over for far too long. ports already has various gcc versions in ports, needed for dozens of ports that require newer gcc, and this could be adopted for the gcc from base issue. But that's not the issue. It is making the ports that need it use it, and from the quoted message it sounds like that would take work. Work takes time, and the window is closing. If src needs to move on, and it surely seems like it does, then ports needs to adapt. I'd dispute the 'and surely it seems like it does' part of this. Non x86 architectures will continue to use gcc because clang just isn't ready at this time for them. Some are very close (arm), some are close (powerpc64, mips*), some are no where near ready, or will never be ready (sparc64, ia64). There's no coherent, documented plan for these absent gcc at the moment. There are lots of pieces there, and those pieces will form the basis of the solution (+handbook updates) for the removal of gcc in 11, but we just aren't there yet. No offense to either team, but this is just common sense. The only ones that would really matter are ones in any bootstrap path we might need for external toolchains. Since qemu is the basis for cross building ports, it is disturbing to see that on the list. I know qemu has, in the past, been sensitive to compiler versions, as are many of the emulators in the tree. It might not be a simple matter to just use gcc 4.6 or 4.7 for some of the items on the list. When I've moved gcc versions and had problems with FOSS it is either due to new warnings/errors and language violations. Some of these are trivial to fix, others reveal fundamental flaws in the code and many changes are needed. Sometimes newer compilers also have optimizations bugs (as opposed to language violations now optimized differently) which break things at run-time, despite things appearing to compile. These aren't insurmountable problems, but do take time to implement and test. Warner ___ 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: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree
On May 7, 2013, at 11:41 PM, Simon J. Gerraty wrote:
On Tue, 7 May 2013 21:25:37 -0600, Warner Losh writes:
where does MAKEOBJDIRPREFIX come into play?
I don't normally use it, it is a handy but rather crude implement.
I normally use
MAKEOBJDIR='${.CURDIR:S,${SRCTOP},${OBJTOP},}'
which gives you a similar - but much neater result than
MAKEOBJDIRPREFIX.
Isn't that backwards. MAKEOBJDIRPREFIX in today's FreeBSD is much more like
OBJTOP than what you've quoted here. That's how I set the top of the tree
today, usually with a 'setenv MAKEOBJDIRPREFIX $HOME/obj' in my .cshrc so it is
always active. That way I can just buildworld or buildkernel without having to
worry where things will wind up, or having problems with /usr/obj being
unwritable... I know this trick doesn't work for netbsd's make (or didn't
years ago when I was building it on a regular basis), so I assume it is FreeBSD
make centric.
We do it both ways: on some architectures we have multiple =
MACHINE_ARCHes per MACHINE (like mips and arm) and on others we have one =
MACHINE_ARCH and mutliple machines (like i386 and pc98).
Yes, which is why I'm adjusting accordingly.
We currently use ${MACHINE}.${MACHINE_ARCH} for cross builds, which =
works out nicely. For historical reasons that turn out to be =
inconvenient, we don't do this for native builds.
Why is this gratuitously different than the current scheme?
Do you mean why not simply use ${MACHINE}.${MACHINE_ARCH} always?
Encoding both MACHINE and MACHINE_ARCH always is doable, but I avoid '.'
because it prevents being able to use modifiers like :R and :E
to separate the directory component from the target machine spec.
The project currently uses dots without issue. Not quite sure why you'd need to
generate things that way. Sure it sounds useful, but it seems rather a
backwards way to work out MACHINE and MACHINE_ARCH (or I'm misunderstanding
what you are saying).
The projects/bmake branch is about showing how freebsd can be built in
meta mode. The tree dependencies are represented as dir.target_spec
would I build a pc98 build with this? And why have it be different for =
it would just get pc98 since there's no ambiguity.
But as noted above, if you wanted to always be explicit that wouldn't be
a problem (assuming '.' is avoided).
___
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: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree
On May 7, 2013, at 9:42 PM, Garrett Cooper wrote:
On Tue, May 7, 2013 at 2:26 PM, Garrett Cooper yaneg...@gmail.com wrote:
On Tue, May 7, 2013 at 2:00 PM, Warner Losh i...@bsdimp.com wrote:
On May 7, 2013, at 2:46 PM, Garrett Cooper wrote:
On May 7, 2013, at 1:39 PM, Brooks Davis wrote:
On Tue, May 07, 2013 at 01:05:07PM -0700, Garrett Cooper wrote:
Hi,
A common pattern that I've seen at Isilon and something else that I've
wanted to have for a while is the ability to designate where the top of a
source tree was. This is important and helpful when dealing with source
files that build upon each other or depend on sources located in other
sections of the tree; contrib stuff needs to set .PATH appropriately to
point to sources at the top of the tree, sys stuff is riddled with S= in
order to point to where /sys, etc lives, we build upon FreeBSD within an
expected directory structure as well.
I haven't come up with a name, but was wondering if this was a good
idea, and if so does anyone have any outstanding patches for this that can
be pushed into FreeBSD?
I'd like to see this. There's a variable for this in NetBSD and I've
wanted to do this because it makes code easier to relocate within the
tree.
This is another good reason. It would make porting code to/from
NetBSD a LOT easier… especially because I plan on pulling a lot of
test/test infrastructure code from NetBSD and I really don't want to commit
too many local changes to the Makefiles. Less divergence - better
cross-pollination - less work for all - win for the BSDs.
Thanks for the reminder.. I'll base it off what NetBSD did :).
SRCDIR
EVARINUSE?
share/mk/bsd.doc.mk:# SRCDIRDirectory where source files live.
[${.CURDIR}]
share/mk/bsd.doc.mk:TRFLAGS+= -I${SRCDIR}
share/mk/bsd.doc.mk:.PATH: ${.CURDIR} ${SRCDIR}
share/mk/bsd.doc.mk:cd ${SRCDIR}; \
share/mk/bsd.doc.mk:SRCDIR?=${.CURDIR}
share/mk/bsd.doc.mk:cd ${SRCDIR}; ${UNROFF} ${MACROS} ${UNROFFFLAGS} \
share/mk/bsd.doc.mk:cd ${SRCDIR}; ${UNROFF} -ms ${UNROFFFLAGS} \
share/mk/bsd.info.mk:SRCDIR?= ${.CURDIR}
...
share/doc/llvm/Makefile:SRCDIR= ${.CURDIR}/../../../contrib/llvm
share/doc/llvm/Makefile:.PATH: ${SRCDIR} ${SRCDIR}/lib/Support
share/doc/llvm/clang/Makefile:SRCDIR=
${.CURDIR}/../../../../contrib/llvm/tools/clang
share/doc/llvm/clang/Makefile:.PATH: ${SRCDIR}
Once upon a time, this *HAD* to be set, and wasn't inferred from the current
top of the tree. Please, for the love of god, make sure that we don't lose
the infer from top of tree ability, or I will hurt you. Often. Through all
the minions that owe me minor favors.
I don't want to break that ever; it's a fantastic feature. If you could point
me to where that magic awesomeness lives (make?), I'll be more than happy to
address it in my branch where I'm going to do this.
I really don't like how NetBSD turned their top-level build command into a
shell script [in part because it needs to bootstrap a bunch of tools]. It
makes things painful when doing iterative builds..
So all in all, I completely and wholeheartedly agree with your concerns.
Oh sweet.. this is something to keep in mind too (from bsd.port.mk)...
# SRC_BASE - The root of the src tree. (Some ports require this to get
# kernel sources). Default: /usr/src
All else fails, ports has done it first -_-...
Not the first var I've seen this done with...
I thought ports specifically named things differently to avoid conflicts.
Warner
___
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: c89 broken on head?
On Mar 7, 2013, at 8:07 PM, Eitan Adler wrote: On 7 March 2013 18:03, Tijl Coosemans t...@coosemans.org wrote: On 2013-03-07 22:36, Warner Losh wrote: On Mar 7, 2013, at 2:28 PM, Dimitry Andric wrote: On 2013-03-07 21:22, Tijl Coosemans wrote: ... Because it's the practical thing to do? Old code/makefiles can't possibly be expected to know about compilers of the future, while new code can be expected to add -std=c11. I am not sure I buy that argument; if it were so, we should default to KR C instead, since old code (for some arbitrary definition of old) could never have been expected to know about gcc defaulting to gnu89. My argument was to be practical, i.e. don't change what doesn't have to change. -std=c11 is defintely too new, but maybe c89 is too old. I thought the c89 program actually was mandated by POSIX, no? Both were part of POSIX. c89 was a strict ISO c89 compiler, while cc was c89, but could additionally accept an unspecified dialect of the C language. http://pubs.opengroup.org/onlinepubs/007908799/xcu/cc.html So, if practicality isn't a good enough argument, maybe POSIX compliance is? cc is marked as LEGACY which is described as optional (need not be provided). However, I would not be surprised if a non-zero number of ports depend on cc existing. If we are to remove it or change it, I would like to see that preceded by an exp-run. Removing cc is an exceedingly stupid idea. I think it should be preceded by the heat death of the universe. It will cause nothing but gratuitous pain and suffering for our users and gain us absolutely nothing in return. Do not even think about removing 'cc,' let alone trying to do an exp-run. The idea is a non-starter and you'd be wasting your time. Warner ___ 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: c89 broken on head?
On Mar 7, 2013, at 2:28 PM, Dimitry Andric wrote: On 2013-03-07 21:22, Tijl Coosemans wrote: ... Because it's the practical thing to do? Old code/makefiles can't possibly be expected to know about compilers of the future, while new code can be expected to add -std=c11. I am not sure I buy that argument; if it were so, we should default to KR C instead, since old code (for some arbitrary definition of old) could never have been expected to know about gcc defaulting to gnu89. -std=c11 is defintely too new, but maybe c89 is too old. I thought the c89 program actually was mandated by POSIX, no? Warner ___ 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: Removing default build of gcc
On Jan 25, 2013, at 4:31 AM, Konstantin Belousov wrote: On Fri, Jan 25, 2013 at 08:41:11AM +, David Chisnall wrote: Hi All, In 10.0, the plan is not to ship any GPL'd code, so I'd like to start disconnecting things from the default build, starting with gcc. I've been running a gcc-free system for a while, and I think all of the ports that don't build with clang are now explicitly depending on gcc. Does anyone have strong opinions on when would be a good time for head on x86 and x86-64 to default to not building gcc? To clarify: there is no plans to not ship any GPLed code for 10.x. Instead, there are still plans to ship working 10.x. Please do not consider the personal opinion as the statement of the project policy. The goal is to try not to ship GPL'd code in 10. The goal is not to ship 10 without GPL'd code if that results in a broken system. The goal also as articulated at different forum, was for Tier 1 systems. Tier 2 and 3 systems may use GPL code as a fallback if the non-gpl'd code doesn't work on those platforms. That is to say, it is a goal, not an absolute requirement. Warner ___ 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: Removing default build of gcc
On Jan 25, 2013, at 3:18 PM, Andriy Gapon wrote: on 25/01/2013 21:35 Warner Losh said the following: This has been talked about in a vague way for years. Warner, just a nitpick, couldn't resist - sorry, so for years we talked about the magic 10.x release to become GPL-free? Or was it just a goal for 'some day'? In the talks that we've had at different venues, 10.x has been a short hand for someday. At first it was clear that it was too ambitious to be in 9.0, then later it was a nice goal to have for 10.x, but it isn't a show-stopper for shipping 10.0 if there's still GPL'd code in the tree. Remove as much as possible, as fast as possible, but with the big caveat of without removing features that mattered. clang is nice and all, but it isn't yet a complete replacement for the tier 2/3 platforms for gcc. It is unrealistic to expect that we'll have something that's functional on those platforms in the 10.0 time frame, unless that timeframe is very far in the future. Again, it is the difference between a goal (which we can fail to achieve fully) and a requirement (which gates the release) that's the important distinction here. Core has never set GPL-free as a requirement for 10.x. They haven't even stated, as far as I can recall, that it is a desired goal for the project. The goal has been driven by many stakeholders that can't use GPL today, as well as a recognition that GPL-free is a big selling point in some markets. The more we can do this, in general, the better. However, the drive must also be tempered by the need to keep current things working and not break them needlessly. Which, btw, is the whole reason full external toolchain support is necessary. With that, we can kill three birds with one stone. (1) we can allow users to use the vendor optimized versions of the gcc toolchain, if they want. (2) non-tier 1 platforms could use it to build with known good gcc/binutils versions that may live in ports. ia64 is often mentioned here. (3) We provide a fallback for people that want to use gcc on tier-1 platforms, but newer versions. We've only kinda sorted solved these problems in a kludgy, error-prone tedious manner today, and much work remains to bring the support up to the quality users expect and need from the project. Warner ___ 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: Using non-standard linker
On Dec 13, 2012, at 6:18 AM, Erik Cederstrand wrote: Den 13/12/2012 kl. 14.10 skrev David Chisnall thera...@freebsd.org: Hi Eric, The easiest way of doing this is to make /usr/bin/ld (in the host system and in the bootstrap) into a symbolic link that points to whatever the selected linker is. I had to do this when testing gold as well (we end up with ld-gold and ld-bfd and ld being a symlink to one of them). Yes, a symlink is of course an easy solution post-install. But 'ld' is built as part of 'make toolchain', I believe, so this approach wouldn't work if I wanted mclinker to be used as the linker in 'make buildworld'. The newly built 'ld' in /usr/obj/ would be used as the linker instead. Install ld as ld.gnu during the build and after. Make ld a small shell script that invokes ld.gnu by default, or something else if a variable is set. Much like the way we have different mail backends to a common mail front end. Then ld does what people want, and you have a hook to do different things. Warner ___ 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: BSD archive file formats
Hi Pete, the best way to find out if support for archives are needed is to release it for testing. People find the craziest things when testing in a wider arena. Alternatively, see if can survive /usr/ports being thrown at it :) even clang can't do that yet (although it isn't always clang's fault for reasons too numerous to enumerate here). Warner On Aug 3, 2012, at 6:39 AM, pete wrote: Hi David, Thanks for your information! Then I'll probably work on other features development first. And I also checked that MCLinker is able to link itself with archive libraries on i386 FreeBSD9. Thanks, Pete On Fri, Aug 3, 2012 at 7:43 PM, David Chisnall thera...@theravensnest.orgwrote: Hi Pete. The end of the man page says: This manual page documents the ar(1) archive formats used by the 4.4BSD and UNIX SVR4 operating system releases. I think it's probably safe to assume that the 4.4BSD format was dropped at some indeterminate point in the past, probably when we moved from a.out to ELF format binaries. If the tools currently shipped in the base system are not producing them, then support is probably not important - people can always install GNU binutils from ports if it is for some legacy software. David On 3 Aug 2012, at 12:36, pete wrote: Hi folks, I'm working on archive file format support in MCLinker project. GNU variant archive format is supported in MCLinker now. And from FreeBSD man pages, I can find there are some differences between BSD and GNU variants. However, when I try to check BSD variant on freebsd9 (i386), I can only find GNU variant archive files. And if using ar to make an archive file on freebsd9, I still get a GNU variant one. So, I would like to ask if BSD variant supported/existing in BSD system. Or I missed something in configuring or others? I'm new to BSD. Any information will be helpful! Thanks, Pete ___ 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 ___ 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 ___ 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: gcc46 header search path
On Jul 6, 2012, at 1:11 PM, David Chisnall wrote: On 6 Jul 2012, at 17:54, Andriy Gapon wrote: Yeah. Honestly speaking I myself was not aware of what is written in that link and I thought that our gcc ports (from ports) added /usr/local/include to the default search path by some mistake. And if somebody asked me what I thought about the idea of adding /usr/local/include to the default path, I'd say that it was a stupid idea. Why? The number one question I get from developers new FreeBSD is 'I wanted to use libfoo from ports, I stalled it, and now [gcc,clang] doesn't find the headers, why not?' No one has yet provided me with a sane reason why our system compiler would not look in the standard locations where we install headers and libraries. Because they aren't standard locations. Or at least didn't used to be standard locations. At this point, I'd say it is likely better to include the new path than not, since it has become standard since FreeBSD started tracking gcc. Running configure scripts on FreeBSD is a colossal pain because of this - you often need to explicitly say -with-foo-include=/usr/local/include -with-foo-lib=/usr/local/lib for an arbitrary number of values of foo, depending on the library. Please, please, please, can we put our standard library and header paths in the compiler standard header or library paths, or can someone give me a good reason other than 'it's a stupid idea' why we should force every single program that anyone compiles on FreeBSD to do CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib? The reasons are that /usr/local/include superceds anything in /usr/include. This is dangerous. Users should get just the system default libraries and headers when they compile unless they ask for more. That's what makes it stupid. However, regardless of my opinion, I think this may be a case where the avalanche has started, and it is too late for the snow flakes to vote. Warner ___ 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: setting CC/CXX/CPP unconditionally in src.conf
On Feb 26, 2012, at 2:37 PM, Alexander Best wrote: hi there, any chance support for setting CC/CXX/CPP unconditionally in src.conf could be added before the release of freebsd 10.0? the way it is done atm is really not intuitive. the rule should really be: - make.conf = applies globally - src.conf = applies only to /usr/src ( maybe a ports.conf or port.conf could be introduced at some point, too) ... the current situation, where only certain variables can be set in src.conf is not ideal. What doesn't work? Or rather, how does it work now? Warner ___ 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: [poc] buildkernel + clang + -Werror
On Nov 6, 2011, at 1:58 PM, Alexander Best wrote: On Sun Nov 6 11, Dimitry Andric wrote: On 2011-11-06 21:33, Alexander Best wrote: ... the problem is, something like uint x; if (x 0) ... clang will warn about this, yet it is 100% valid code so my vote would be to make such an error into a warning. Sorry, but checking something unsigned to be smaller than zero is bogus, or at the least superfluous, and it's perfectly sane to warn about this, especially since the compiler is not going to emit code for it at all. there was a discussion with the topic disable -Wtautological-compare for clang on freebsd-toolchain@ and most of the devs considered this code *not* to be bogus. ;) The code actually is bogus. It may be masking a real problem, because often times it is a sanity check to make sure that you aren't doing something naughty, like passing -1 for the length. However, if you then pass the unsigned through a signed value, it suddenly becomes negative, and you have a hard to spot bug. IIR the the tread, there weren't too many people offering an opinion... Warner___ 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: [poc] buildkernel + clang + -Werror
On Nov 6, 2011, at 2:13 PM, Rui Paulo wrote: The only argument against this tautological check that I agree with is when the code is explicitly trying to be safe. If the developer checks for i 0 when indexing an array he/she is trying to guard against possible pitfalls in the future when someone suddenly decides to change the variable type to become signed. One possible security vulnerability was avoided because that developer checked for negative values. I'm against turning this off by default, but it should not cause an error. Except when you pass args back and forth between signed and unsigned and back again. If you check 0 in the middle, that's one more security bug you thought you had fixed, but really you've done nothing with. Warner ___ 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: [poc] buildkernel + clang + -Werror
On Nov 6, 2011, at 5:47 PM, Rui Paulo wrote: On Nov 6, 2011, at 4:36 PM, Warner Losh wrote: On Nov 6, 2011, at 2:13 PM, Rui Paulo wrote: The only argument against this tautological check that I agree with is when the code is explicitly trying to be safe. If the developer checks for i 0 when indexing an array he/she is trying to guard against possible pitfalls in the future when someone suddenly decides to change the variable type to become signed. One possible security vulnerability was avoided because that developer checked for negative values. I'm against turning this off by default, but it should not cause an error. Except when you pass args back and forth between signed and unsigned and back again. If you check 0 in the middle, that's one more security bug you thought you had fixed, but really you've done nothing with. Of course, but in the context of the compiler checks this argument doesn't apply. It is also useful for code where the default differs from system to system. For example, char are signed on some architectures, and unsigned on others. This warning would expose cases where the 0 check was done for safety from those where it was done in error. Warner___ 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: [toolchain] disable -Wtautological-compare for clang
I'm all for leaving it on because things like char are signed on some architectures and unsigned on others. This leads to bugs that only appear on one architecture. This warning will, at least, flag those usages. On Oct 17, 2011, at 10:56 AM, Gerald Pfeifer wrote: On Mon, 17 Oct 2011, Alexander Best wrote: any chance we could disable -Wtautological-compare for clang? i don't think comparing an unsigned int against 0 is worth a warning. actually it's always nice to have such a seatbelt, in case somebody changes the type to int and forgets to introduce such a check. I am on the fence on this one, for when I used the equivalent warning in GCC this did found a number of real issues that I then addressed for Wine (as an example). Gerald ___ 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 ___ 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: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported
We really need a 'SYSTEM_COMPILER={gcc,clang,xxx}' sort of knob.
Warner
On Aug 18, 2011, at 2:04 PM, Kostik Belousov wrote:
On Thu, Aug 18, 2011 at 09:54:41PM +0200, Dimitry Andric wrote:
The problem is in your make.conf. Effectively, you are doing:
CC = clang
CXX = clang++
which will not work, at least not for the 32-bit compat stage on amd64.
Please use the following fragment instead, which is recommended on
http://wiki.freebsd.org/BuildingFreeBSDWithClang:
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == cpp
CPP=clang -E
.endif
May be, add the commented out lines into share/examples/etc/make.conf ?
___
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: [help] rebuild libc failed
You need to use buildworld or one of its sub-targets. Warner On Aug 4, 2011, at 2:38 AM, majia gm wrote: Hi, everyone. I'm building the libc code which derived from a current trunk mirror/freebsd/head under PCBSD 8.2 which contains FreeBSD 8.2 release. I'm trying to test the modified libc by using LD_LIBRARY_PATH. But failed to build it. I change the current direcotry into head/lib/libc and run make. I get the following error. Warning: Object directory not changed from original /usr/home/forandom/work/soc2011/xxp-head/lib/libc cc -O2 -pipe -I/usr/home/forandom/work/soc2011/xxp-head/lib/libc/include -I/usr/home/forandom/work/soc2011/xxp-head/lib/libc/../../include -I/usr/home/forandom/work/soc2011/xxp-head/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/home/forandom/work/soc2011/xxp-head/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/home/forandom/work/soc2011/xxp-head/lib/libc -I/usr/home/forandom/work/soc2011/xxp-head/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/home/forandom/work/soc2011/xxp-head/lib/libc/../../contrib/tzcode/stdtime -I/usr/home/forandom/work/soc2011/xxp-head/lib/libc/stdtime -I/usr/home/forandom/work/soc2011/xxp-head/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/home/forandom/work/soc2011/xxp-head/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 /usr/home/forandom/work/soc2011/xxp-head/lib/libc/gen/__getosreldate.c /usr/home/forandom/work/soc2011/xxp-head/lib/libc/gen/__getosreldate.c: In function '__getosreldate': /usr/home/forandom/work/soc2011/xxp-head/lib/libc/gen/__getosreldate.c:58: error: 'AT_OSRELDATE' undeclared (first use in this function) /usr/home/forandom/work/soc2011/xxp-head/lib/libc/gen/__getosreldate.c:58: error: (Each undeclared identifier is reported only once /usr/home/forandom/work/soc2011/xxp-head/lib/libc/gen/__getosreldate.c:58: error: for each function it appears in.) *** Error code 1 Stop in /usr/home/forandom/work/soc2011/xxp-head/lib/libc. It seems there's little difference between head and this release. AT_OSRELDATE is defined in head/sys/i386/include/elf.h. But in the release 8.2, elf.h doesn't have this definition. How can let it to use the include files in head rather than the system include files? Thanks. ___ 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 ___ 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: ARM issue with old binutils
On Jun 25, 2011, at 9:16 AM, Gerald Pfeifer wrote: On Wed, 22 Jun 2011, Damjan Marion wrote: I see 3 options to fix this: 1. Ask clang folks to patch llvm to use old mnemonics (mov r0, r0, rrx instead of rrx r0,r0) 2. Maintain same patch for freebsd only 3. patch binutils to support this new mnemonics 4. Finally upgrade to a modern version of binutils. Yes, I know that is GPLv3. Been there, done that, and it is not a problem at all, just FUD. IBM, SAP, Oracle, and all the others are not concerned about GPLv3 in the toolchain, nor should we. Except for FUD. Except there *ARE* FreeBSD users that have said that it is a real problem for them. It isn't FUD. The project has adopted the policy in reaction to large commercial FreeBSD users that have very restrictive company policies driven by their legal department's evaluation of GPLv3. Warner ___ 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: cross-compiling for arm with clang
On Jun 21, 2011, at 3:12 AM, Damjan Marion wrote: On Jun 17, 2011, at 9:16 PM, Warner Losh wrote: On Jun 17, 2011, at 12:38 PM, Damjan Marion wrote: Now, I'm back on my original problem, clang invokes /usr/bin/as which is i386 AS instead of ARM version in obj tree. That's a bogus assumption on the part of clang. At the very least, it should be adding the magic gas flags to use the correct triple for the platform. But if you did that, your next complaint would be that we only build as for the native architecture and not anything else. How this works on other platforms (i.e. cross-compiling for amd64)? How it normally works is that we build a compiler that invokes the right as, ld, etc for the architecture in question. Clang is clearly broken here in assuming that as can cope with anything other than native assembler :) We normally either build gcc that knows where to find these files. In the buildworld case, this is communicate with weird paths and shell variables. With the whole 'xdev' series of targets (which are instructive to look at), we build into a specific location /usr/freebsd-xdev-arm/bin, etc). It works by accident for i386 on amd64, I think. as treats the more or less as the same. I submitted a patch[1] to clang mailer which invokes xxx-yyy-zzz-as/ld based on -ccc-host-triple. Patch is copy of netbsd code which is already in clang. For me it works well, even when I use clang on Darwin host, it calls proper as/ld. # /opt/llvm/bin/clang -ccc-host-triple arm-unknown-freebsd -mfloat-abi=soft test.c -o test -v -c clang version 3.0 (http://llvm.org/git/clang.git 98138cdfdee05c0afbab2b209ce8cfe4a52474e1) Target: arm-unknown-freebsd Thread model: posix [snip] End of search list. /opt/llvm/bin/arm-unknown-freebsd-as -o test /var/folders/kb/kbDaYaFqFQaCg3mXbTLH5U+16gE/-Tmp-/cc-RMHOwf.s Is this what we need to support cross-compiling freebsd with clang? As we do it today? No. Today we build the binaries as 'as' which are part of the buildworld. These binaries aren't called arm-unknown-freebsd-as, but instead 'as'. Do we want to switch? Maybe. There's a make xdev target that installs both the /usr/arm-freebsd/usr/bin/as type files as well as symbolic links in /usr/local/bin/arm-freebsd-as. But that target isn't part of buildworld. It has been tested recently (it was broken for a while in 8, and I'm not sure I've merged the patches over yet). However, it doesn't include the extra bogus 'unknown' which if you were to have included it breaks many of the autoconf scripts that I ran into when I did this patch. Also, I install things as /usr/local/bin/arm-freebsd9-as as well, since that's what we needed for gcc compatibility. I suppose we could include a unknown thing. However, you'd need to install symlinks to make this work in a build-world setting. Is there any other comment to this patch[1]? [1] http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110620/043072.html Not enough of a llvm guy to know if this patch is good or bad. Warner ___ 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
