Re: Deorbiting i386
On 26 May 2018, at 00:41, Maxim Sobolev wrote: > > If you've seen any of the atom bay trail systems in action you may understand > what I mean. You get full blown x64 system with four cores and it takes only > 2W of power. Which is pretty much my point - if you want a low-power x86 system for embedded use, it’s going to be x86-64, not x86-32 (though hopefully you’re using a 32-bit ABI with it). David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: Deorbiting i386
On 25 May 2018, at 05:27, Maxim Sobolev wrote: > > The idea looks very inmature and short-sighted to me. i386 is here to stay > not as a server/desktop platform but as an embedded/low power/low cost > platform for at least 5-10 years to come. There are plenty of applications in > the world that don't need > 3gb of memory space and have no use for extra > bits (and extra silicon) to function. This argument seems very odd to me. If you are targeting the embedded space, it is far easier to build a low-power chip that targets the x86-64 ISA than the x86-32 ISA. You can move all of the 80-bit floating point stuff into microcode. You can put anything using pair-of-32-bit-register 64-bit operations into slow microcode. You can skimp on store forwarding for stack addresses. You actually need fewer rename registers (one of the biggest consumers of power), because x86-64 code needs to do less register juggling to fit in the architectural register space. All of these things are big consumers of power and area and are far less necessary when running code compiled for x86-64. You can also do tricks like the one that Intel did on the early Atoms, where the SSE ALUs are actually only 64 bits wide and the 128-bit ops are cracked into pairs of 64-bit micro-ops. As to ‘not needing more than 3GB of memory space’, that’s what the x32 ABI is for. This lets you get all of the advantages of the x86-64 ISA (of which there are very many, in comparison to x86-32), without needing 64-bit pointers. You get the instruction density of x86-64 combined with the data density of x86-32. This is what Intel and Centaur have been pushing in the embedded space for several years. You do pay a slight hardware cost from supporting a 48-bit virtual address space, though with superpages that’s negligible and the hardware targeted at these applications often doesn’t support more than a 32-bit virtual address space. And this completely ignores the fact that Intel has almost no presence in the low-end embedded space. AArch32 is vastly more important there and if we dropped x86-32 and shifted that effort to AArch32 then I think we’d see a lot more adoption. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r328159 - head/sys/modules
On 19 Jan 2018, at 05:07, Conrad Meyer wrote: > > The spec says the behavior is undefined; not that the compiler has to > produce a warning or error message. The compiler *does* get to > arbitrarily decide what it wants to do when it encounters UB. It is > wholly free to implement this particular UB with the logical result > and no warning/error. First, you are not correct that the only logical outcome of a shift of greater than the width of a type is 0. In C, a right-shift of a signed type propagates the sign bit. Right shifting a negative 32-bit int by 16 and then again by 16 is not undefined behaviour (though doing the shift as a single operation is) and will give you a value of -1. The spec says that it is undefined, because on some architectures there is a right-shift instructions that produces non-zero values when instructed to shift right more than the width of the value. A shift of greater than the width of the size requires special handling in the compiler for some architectures and is always a logic error. This gives two cases: Either the compiler can statically prove that the value is too large, or it is not. Because the C spec says that it is undefined, if the compiler cannot prove that the value is too large, then it is free to assume that it isn’t. This means that the back end can always emit instructions that produce unspecified values for larger ranges. The compiler is free to do anything it wants in the case of UB, including make monkeys fly out of your nose. Telling you that you have done something obviously stupid is generally considered better than just generating wrong code. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326758 - in head/sys/i386: conf include
On 16 Dec 2017, at 18:05, John Baldwin wrote: > > When I build a FreeBSD/mips64 kernel with clang, > _any_ simple NFS op triggers a kernel stack overflow. Kernels compiled > with GCC do not. That is not my experience. I haven’t tried a MIPS64 kernel built with clang, but with in-tree gcc I get kernel panics as soon as I try to use NFS, unless I use Stacey’s patches that increase the kernel stack size. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r323329 - head/sys/sys
On 8 Sep 2017, at 21:09, Mateusz Guzik wrote:
>
> Author: mjg
> Date: Fri Sep 8 20:09:14 2017
> New Revision: 323329
> URL: https://svnweb.freebsd.org/changeset/base/323329
>
> Log:
> Allow __builtin_memset instead of bzero for small buffers of known size
This change seems redundant, because modern compilers already do this
optimisation. For example:
#include
char buf[42];
void bz(void)
{
bzero(buf, 42);
}
With clang 4.0 on x86 compiles to:
pushq %rbp
movq%rsp, %rbp
xorps %xmm0, %xmm0
movups %xmm0, buf+26(%rip)
movaps %xmm0, buf+16(%rip)
movaps %xmm0, buf(%rip)
popq%rbp
retq
On AArch64, it compiles to:
adrpx8, buf
add x8, x8, :lo12:buf
strhwzr, [x8, #40]
stp xzr, xzr, [x8, #24]
stp xzr, xzr, [x8, #8]
str xzr, [x8]
ret
Neither contains a call, both have inlined the zeroing. This change is
strictly worse, because the compiler has some carefully tuned heuristics that
are set per target for when to inline the memset / bzero and when to call the
function. These are based on both the size and the alignment, including
whether the target supports misaligned accesses and whether misaligned accesses
are cheap. None of this is captured by this change.
In the kernel, this optimisation is disabled by -ffreestanding, however
__builtin_memset will be turned into a memset call if the size is not constant
or if the memset call would be more efficient (as determined by the
aforementioned heuristics). Simply using __builtin_memset in all cases should
give better code, and is more likely to be forward compatible with future ISAs
where the arbitrary constant picked in this patch may or may not be optimal.
David
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r323277 - head/lib/libc/locale
Author: theraven
Date: Thu Sep 7 17:51:35 2017
New Revision: 323277
URL: https://svnweb.freebsd.org/changeset/base/323277
Log:
Document some invariants for the XLC_ enum.
These can't be reordered without breaking other code. Document that and add
some static asserts to ensure that anyone who tries gets build failures.
Modified:
head/lib/libc/locale/xlocale_private.h
Modified: head/lib/libc/locale/xlocale_private.h
==
--- head/lib/libc/locale/xlocale_private.h Thu Sep 7 17:20:47 2017
(r323276)
+++ head/lib/libc/locale/xlocale_private.h Thu Sep 7 17:51:35 2017
(r323277)
@@ -40,6 +40,14 @@
#include
#include "setlocale.h"
+/**
+ * The XLC_ values are indexes into the components array. They are defined in
+ * the same order as the LC_ values in locale.h, but without the LC_ALL zero
+ * value. Translating from LC_X to XLC_X is done by subtracting one.
+ *
+ * Any reordering of this enum should ensure that these invariants are not
+ * violated.
+ */
enum {
XLC_COLLATE = 0,
XLC_CTYPE,
@@ -50,6 +58,19 @@ enum {
XLC_LAST
};
+_Static_assert(XLC_LAST - XLC_COLLATE == 6, "XLC values should be contiguous");
+_Static_assert(XLC_COLLATE == LC_COLLATE - 1,
+ "XLC_COLLATE doesn't match the LC_COLLATE value.");
+_Static_assert(XLC_CTYPE == LC_CTYPE - 1,
+ "XLC_CTYPE doesn't match the LC_CTYPE value.");
+_Static_assert(XLC_MONETARY == LC_MONETARY - 1,
+ "XLC_MONETARY doesn't match the LC_MONETARY value.");
+_Static_assert(XLC_NUMERIC == LC_NUMERIC - 1,
+ "XLC_NUMERIC doesn't match the LC_NUMERIC value.");
+_Static_assert(XLC_TIME == LC_TIME - 1,
+ "XLC_TIME doesn't match the LC_TIME value.");
+_Static_assert(XLC_MESSAGES == LC_MESSAGES - 1,
+ "XLC_MESSAGES doesn't match the LC_MESSAGES value.");
/**
* Header used for objects that are reference counted. Objects may optionally
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r322875 - head/sys/dev/nvme
On 25 Aug 2017, at 07:32, Mark Millard wrote: > > As I remember _Static_assert is from C11, not > the older C99. In pre-C11 dialects of C, _Static_assert is an identifier reserved for the implementation. sys/cdefs.h defines it to generate a zero-length array if the condition is true or a negative-length array if it is false, emulating the behaviour (though giving less helpful error messages) > > As I understand head/sys/dev/nvme/nvme.h use by > C++ code could now reject attempts to use > _Static_assert . In C++, _Static_assert is an identifier reserved for the implementation, but in C++11 or newer static_assert is a keyword. sys/cdefs.h defines _Static_assert to static_assert for newer versions of C++ and defines it to the C-before-11-compatible version for C++-before-11. TL;DR: We have gone to a lot of effort to ensure that these keywords work in all C/C++ dialects, please use them, please report bugs if you find a case where they don’t work. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r313040 - head/sys/mips/include
On 1 Feb 2017, at 08:13, Konstantin Belousov wrote: > > On Wed, Feb 01, 2017 at 10:38:42AM -0500, Alexander Kabaev wrote: >> On Wed, 1 Feb 2017 16:17:21 +0200 >> Konstantin Belousov wrote: >> >>> Please do not retry on sc failure, return the error to upper layer. >>> See also r313007 and preceeding discussion after r312973. >> >> There was not much a discussion there, do you mind expanding a bit on >> why one behavior is more desired than other? I am not against the >> change, but I need to understand the reasoning behind it better. Since >> atomic_cmpset retries too, it will have to be adjusted as well. > > atomic_cmpset() cannot avoid retry on the ll/sc architectures, because > sc might fail even if the old and the new values are same. One of the > points of the fcmpset API design is to avoid nested loops: this is a > microoptimization to put less pressure on the CPUs frontend. The caller > of (f)cmpset must check for failure anyway, so not doing this inside the > function reduces number of branches. Less branches makes code shorter, > and reduces utilization of some CPU resources, like branch predictor > state. C[++]11 addresses this by having a weak and a strong variant of compare and exchange. The strong version may only fail if the comparison fails, we weak version is permitted to fail spuriously. Given that most uses of compare and exchange use a loop, and most ll/sc architectures guarantee forward process after a few attempts, you almost always want to use the weak version. The weak version also has the advantage that the compiler is free to fold the initial load into the load linked, as long as the target architecture would permit it, so you end up with more idiomatic ll, op, sc, branch sequences, rather than l, op, ll, branch, sc, branch sequences. David smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r310138 - head/lib/libc/stdio
On 22 Dec 2016, at 23:02, Baptiste Daroussin wrote: > > I think it is pretty clear that there are too many people requesting the > revert > for the revert not to be done. Even if this feature is desired, the implementation in the patch is broken and should be reverted until a correct implementation (one that doesn’t break the first time user code calls register_printf_*) is done. David smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r310138 - head/lib/libc/stdio
On 16 Dec 2016, at 19:31, Baptiste Daroussin wrote: > > Other than that, it makes more difficult to use vanilla gcc with out userland. > and it is adding more complexity to be able to build freebsd from a non > freebsd > system which some people are working on. Why? You’ll get some spurious warnings about printf, but that’s all. Our printf (like the glibc one) already supports user-defined extensions via register_printf_function (for which, I note, we don’t have a man page), so third-party code also has some of these warnings if they’ve registered other printf handlers. I’d actually consider that to be the biggest argument against adding %b support: we support users adding their own interpretation of %b via register_printf_function and this will break anyone third-party code where people do this. This commit is doubly bad, because not only does it change our ABI, it doesn’t document the fact. The code in this commit is also simply broken. It does not add a corresponding handler in xprintf.c, so as soon as someone calls register_printf_function with *any* argument, printf’s ability to handle %b will be broken in a difficult-to-debug way. David smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r302252 - head/sys/kern
On 4 Jul 2016, at 21:09, Adrian Chadd wrote: > > Right, so if we're not careful, we could leak bits of kernel memory, > and it can also screw up key cache comparisons. > > (I asked this question because I've been screwed by it recentlyish, > and it looks like the latest C standard didn't fix it..) It was discussed at the WG14 meeting in London in April, but I don’t think that there was a clear consensus. It gets particularly tricky for _Atomic types, and I think that there’s now a clarification (or will be in C2x, if not) that any padding in _Atomic types is zeroed. Generally, compilers will turn this into a bzero and then a set of the remaining fields, so you’re likely to end up with the right thing, but it’s not guaranteed by the standard. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r295768 - head/usr.sbin/iostat
On 22 Feb 2016, at 10:15, Kubilay Kocak wrote: > > For the lay persons among us (I'm genuinely interested), what are the > the downsides to requiring initialization of all fields? Explicit initialisation, or initialisation in general? Being able to initialise the entire structure with code that will always initialise everything with zero makes the code less fragile because you can add a field to the structure and not have to find all of the places where it’s initialised. The clang warning makes it easy to find the places you need to change, but now you have code churn for no good reason. Implicit initialisation is often useful for generating more efficient code. If you’re intialising with a bunch of common fields, the compiler will end up creating a static variable and doing a memcpy (which the back end may optimise), which is very cheap. A load of code in libc ends up like this. > And in addition, the upsides, if any, of 'deferred' field initialization? The same as the upsides for deferred variable initialization. Modern compilers are good at tracking intraprocedural data flow. If you don’t initialise a field, then the compiler can typically tell that you’ve read from a field but not written to it. It’s generally good defensive programming for zero to have a well-defined meaning (C codifies this for pointers, Go codifies it for all structure types), but if you haven’t done this then the zero may be a valid but incorrect value and no amount of static analysis can tell you that the programmer did something that is valid but wrong. Some languages with richer type systems explicitly encode the invalidity of the variable in its type and transform it to the valid version once it is initialised (some also provide maybe types as a programmer-level constructs. You can implement them fairly trivially in C++, see for example LLVM’s ErrorOr<> template). Sane coding style for C (not style(9)) typically includes the principle of minimum scope, where variables must be declared as close to possible their initialisation. This helps minimise these problems, because you either declare the variable where it is initialised, or (if initialisation is conditional) right next to it where you can clearly see that it has been initialised on all code paths. Unfortunately, as you can see from the PVS results, style(9) could have been carefully designed to maximise the introduction of accidental bugs. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r295768 - head/usr.sbin/iostat
On 19 Feb 2016, at 23:23, Dimitry Andric wrote:
>
> This warning is only produced when you use -Wall -W, and then initialize
> structs partially, i.e. you initialize some fields but not others. I
> think this is a quite reasonable warning for a high warning level.
The warning is annoying in many ways. You ought to be able to zero initialise
any struct with {0}, but clang objects if you do this and requires every field
to be filled in. This warning really shouldn’t be enabled with -Wall, because
it has too hight a false positive rate.
With regard to Bruce’s comment about padding, this is a known issue in C11.
There is an open DR about it and it’s scheduled for discussion at the WG14
meeting in London in April.
David
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r292809 - head/lib/libc/stdio
On 30 Dec 2015, at 00:48, Bruce Evans wrote: > > - C++ apparently spells this as both _Alignof() and alignof() after 2011/03 This is not correct. C++ spells it alignof. C spells it _Alignof, unless you include , in which case C spells it alignof and defines _ _alignof_is_defined. On FreeBSD, we define _Alignof in C++ mode, because it’s in the reserved identifier space and gives us something that works in C and C++. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r292876 - head/usr.bin/dtc
Author: theraven
Date: Tue Dec 29 16:29:42 2015
New Revision: 292876
URL: https://svnweb.freebsd.org/changeset/base/292876
Log:
Improvements to BSD-licensed DTC.
- Added an expression parser so that expressions from headers are now working
- Fixed missing null terminators on cross references
- Disabled exceptions / RTTI in the build for smaller binaries
- Changed phandle order generation to be identical to GPL'd dtc
Modified:
head/usr.bin/dtc/Makefile
head/usr.bin/dtc/checking.cc
head/usr.bin/dtc/checking.hh
head/usr.bin/dtc/dtb.hh
head/usr.bin/dtc/fdt.cc
head/usr.bin/dtc/fdt.hh
head/usr.bin/dtc/input_buffer.cc
head/usr.bin/dtc/input_buffer.hh
Modified: head/usr.bin/dtc/Makefile
==
--- head/usr.bin/dtc/Makefile Tue Dec 29 16:11:43 2015(r292875)
+++ head/usr.bin/dtc/Makefile Tue Dec 29 16:29:42 2015(r292876)
@@ -6,7 +6,7 @@ MAN=dtc.1
WARNS?=3
-CXXFLAGS+= -std=c++11
+CXXFLAGS+= -std=c++11 -fno-rtti -fno-exceptions
NO_SHARED?=NO
Modified: head/usr.bin/dtc/checking.cc
==
--- head/usr.bin/dtc/checking.ccTue Dec 29 16:11:43 2015
(r292875)
+++ head/usr.bin/dtc/checking.ccTue Dec 29 16:29:42 2015
(r292876)
@@ -51,7 +51,7 @@ namespace
struct address_cells_checker : public checker
{
address_cells_checker(const char *name) : checker(name) {}
- virtual bool check_node(device_tree *tree, const node_ptr &n)
+ virtual bool check_node(device_tree *, const node_ptr &n)
{
// If this has no children, it trivially meets the
// conditions.
@@ -151,7 +151,7 @@ property_checker::check_property(device_
}
bool
-property_size_checker::check(device_tree *tree, const node_ptr &n,
property_ptr p)
+property_size_checker::check(device_tree *, const node_ptr &, property_ptr p)
{
uint32_t psize = 0;
for (property::value_iterator i=p->begin(),e=p->end() ; i!=e ; ++i)
Modified: head/usr.bin/dtc/checking.hh
==
--- head/usr.bin/dtc/checking.hhTue Dec 29 16:11:43 2015
(r292875)
+++ head/usr.bin/dtc/checking.hhTue Dec 29 16:29:42 2015
(r292876)
@@ -86,7 +86,7 @@ class checker
* Method for checking that a node is valid. The root class version
* does nothing, subclasses should override this.
*/
- virtual bool check_node(device_tree *tree, const node_ptr &n)
+ virtual bool check_node(device_tree *, const node_ptr &)
{
return true;
}
@@ -94,7 +94,7 @@ class checker
* Method for checking that a property is valid. The root class
* version does nothing, subclasses should override this.
*/
- virtual bool check_property(device_tree *tree, const node_ptr &n,
property_ptr p)
+ virtual bool check_property(device_tree *, const node_ptr &,
property_ptr )
{
return true;
}
@@ -160,7 +160,7 @@ struct property_type_checker begin() == p->end();
}
@@ -175,7 +175,7 @@ struct property_type_checker begin() + 1 == p->end()) && p->begin()->is_string();
}
@@ -190,7 +190,7 @@ struct property_type_checker begin(),e=p->end() ; i!=e ;
++i)
@@ -213,7 +213,7 @@ struct property_type_checker begin() + 1 == p->end()) &&
(tree->referenced_node(*p->begin()) != 0);
Modified: head/usr.bin/dtc/dtb.hh
==
--- head/usr.bin/dtc/dtb.hh Tue Dec 29 16:11:43 2015(r292875)
+++ head/usr.bin/dtc/dtb.hh Tue Dec 29 16:29:42 2015(r292876)
@@ -186,11 +186,11 @@ class binary_writer : public output_writ
* The binary format does not support labels, so this method
* does nothing.
*/
- virtual void write_label(string name) {}
+ virtual void write_label(string) {}
/**
* Comments are ignored by the binary writer.
*/
- virtual void write_comment(string name) {}
+ virtual void write_comment(string) {}
virtual void write_string(string name);
virtual void write_data(uint8_t v);
virtual void write_data(uint32_t v);
Modified: head/usr.bin/dtc/fdt.cc
==
--- head/usr.bin/dtc/fdt.cc Tue Dec 29 16:11:43 2015(r292875)
+++ head/usr.bin/dtc/fdt.cc Tue Dec 29 16:29:42 2015(r292876)
@@ -264,24 +264,6 @@ property::parse_string(input_buffer &inp
void
property::parse_cells(input_buffer &input, int cell_size)
{
- unsigned long long cell_max;
- switch (cell_size)
- {
- case 8:
Re: svn commit: r290711 - head/sys/ofed/drivers/infiniband/core
On 13 Nov 2015, at 08:35, Konstantin Belousov wrote: > > On Fri, Nov 13, 2015 at 09:18:54AM +0100, Hans Petter Selasky wrote: >> Hi, >> >> On 11/12/15 18:17, Conrad Meyer wrote: >>> These should cast through (u)intptr_t rather than unsigned long. >>> >> >> This is Linux code, and they use "unsigned long" for pointer casts >> everywhere, trying to not break their style. >> >> BTW: I added to linux_compat.c: >> >> CTASSERT(sizeof(unsigned long) == sizeof(uintptr_t)); >> >> And it survived my "tinderbox" build and I was surprised! > > FreeBSD (at least currently) runs on two kinds of ABIs: ILP32 and LP64. > ILP32 means that sizeof(int) == sizeof(long) == sizeof(void *) == 4. > For LP64, sizeof(long) == sizeof(void *) == 8, while sizeof(int) == 4. > We do not support anything else. Note that this is not true of all downstreams. We currently have 128 and 256-bit void*s with 64-bit longs on CHERI, and I believe that bde’s version has 32-bit longs on all platforms. This kind of code *is* broken for us and we’d greatly appreciate people not writing new code that intentionally relies on undefined behaviour (round tripping a pointer via any integer type other than intptr_t is undefined in C), when a well-defined mechanism exists, just because Linux decides to do the wrong thing. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r289996 - head/usr.bin/dtc
Author: theraven Date: Mon Oct 26 11:02:57 2015 New Revision: 289996 URL: https://svnweb.freebsd.org/changeset/base/289996 Log: Update some obsolete information in the HACKING document. Reported by: bapt Modified: head/usr.bin/dtc/HACKING Modified: head/usr.bin/dtc/HACKING == --- head/usr.bin/dtc/HACKINGMon Oct 26 10:37:17 2015(r289995) +++ head/usr.bin/dtc/HACKINGMon Oct 26 11:02:57 2015(r289996) @@ -21,19 +21,17 @@ welcome. C++11 - -This project currently aims to compile with g++ 4.2.1 and so doesn't make any -use of C++11 features. It would be a good idea to relax this restriction once -clang is the default compiler for ARM, MIPS and PowerPC. - -This code makes use of a lot of iterator loops, which would be cleaner using -the new syntax in C++11. It also explicitly deletes a lot of objects held in -collections in destructors that have these collections as their members. This -could be simplified by using `shared_ptr`. - -The code does make use of `static_assert()`, but uses a macro in utility.hh to -remove these if they are not supported. The FreeBSD standard headers also -define a compatibility macro the implements static asserts in terms of an array -with 1 element on success and -1 elements on failure. +This project uses C++11, as the goal for FreeBSD 11 is to require C/C++11 as a +minimum, either from clang or an external toolchain. In particular, it uses +`std::unique_ptr` extensively for memory management within the tree. Unique +pointers are also used in several other places to track ownership. + +Most iterator loops use the new loop syntax and the `auto` type for type +deduction. Range-based `for` loops generally improve the readability of the +code, though `auto` should only be used in places where the type can be deduced +as easily by the reader as by the compiler. + +The code also makes use of `static_assert()` to track compile-time invariants. Adding New Checks - ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r289995 - head/usr.bin/dtc
On 26 Oct 2015, at 10:48, Baptiste Daroussin wrote: > > Just jumping on that one, you should probably revisit de HACKING files :) Ah, good point. I’ll update them. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r289995 - head/usr.bin/dtc
Author: theraven Date: Mon Oct 26 10:37:17 2015 New Revision: 289995 URL: https://svnweb.freebsd.org/changeset/base/289995 Log: Ensure that dtc is built in C++11 mode. Reported by: George Abdelmalik Modified: head/usr.bin/dtc/Makefile Modified: head/usr.bin/dtc/Makefile == --- head/usr.bin/dtc/Makefile Mon Oct 26 10:09:08 2015(r289994) +++ head/usr.bin/dtc/Makefile Mon Oct 26 10:37:17 2015(r289995) @@ -6,6 +6,8 @@ MAN=dtc.1 WARNS?=3 +CXXFLAGS+= -std=c++11 + NO_SHARED?=NO .include ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r289935 - in head/usr.bin: . dtc
Author: theraven
Date: Sun Oct 25 14:52:16 2015
New Revision: 289935
URL: https://svnweb.freebsd.org/changeset/base/289935
Log:
Lots of improvements to the BSD-licensed dtc
- Various fixes to includes (including recursive includes)
- Lots of testing that the output exactly matches GPL'd dtc
- Lots of bug fixes to merging
- Fix incorrect mmap usage
- Ad-hoc memory management replaced with C++11 unique_ptr and similar
Patrick Wildt has successfully run many (all?) of the GPL dtc test suite.
Modified:
head/usr.bin/Makefile
head/usr.bin/dtc/checking.cc
head/usr.bin/dtc/checking.hh
head/usr.bin/dtc/dtb.cc
head/usr.bin/dtc/dtc.cc
head/usr.bin/dtc/fdt.cc
head/usr.bin/dtc/fdt.hh
head/usr.bin/dtc/input_buffer.cc
head/usr.bin/dtc/input_buffer.hh
head/usr.bin/dtc/string.hh
Modified: head/usr.bin/Makefile
==
--- head/usr.bin/Makefile Sun Oct 25 14:42:56 2015(r289934)
+++ head/usr.bin/Makefile Sun Oct 25 14:52:16 2015(r289935)
@@ -210,8 +210,10 @@ SUBDIR.${MK_GAMES}+= pom
SUBDIR.${MK_GAMES}+= primes
SUBDIR.${MK_GAMES}+= random
.if ${MK_GPL_DTC} != "yes"
+.if ${COMPILER_FEATURES:Mc++11}
SUBDIR+= dtc
.endif
+.endif
SUBDIR.${MK_GROFF}+= vgrind
SUBDIR.${MK_HESIOD}+= hesinfo
SUBDIR.${MK_ICONV}+= iconv
Modified: head/usr.bin/dtc/checking.cc
==
--- head/usr.bin/dtc/checking.ccSun Oct 25 14:42:56 2015
(r289934)
+++ head/usr.bin/dtc/checking.ccSun Oct 25 14:52:16 2015
(r289935)
@@ -51,7 +51,7 @@ namespace
struct address_cells_checker : public checker
{
address_cells_checker(const char *name) : checker(name) {}
- virtual bool check_node(device_tree *tree, node *n)
+ virtual bool check_node(device_tree *tree, const node_ptr &n)
{
// If this has no children, it trivially meets the
// conditions.
@@ -61,8 +61,7 @@ namespace
}
bool found_address = false;
bool found_size = false;
- for (node::property_iterator i=n->property_begin(),
-e=n->property_end() ; i!=e ; ++i)
+ for (auto i=n->property_begin(), e=n->property_end() ;
i!=e ; ++i)
{
if (!found_address)
{
@@ -91,7 +90,7 @@ namespace
} // anonymous namespace
bool
-checker::visit_node(device_tree *tree, node *n)
+checker::visit_node(device_tree *tree, const node_ptr &n)
{
path.push_back(std::make_pair(n->name, n->unit_address));
// Check this node
@@ -100,8 +99,7 @@ checker::visit_node(device_tree *tree, n
return false;
}
// Now check its properties
- for (node::property_iterator i=n->property_begin(), e=n->property_end()
-; i!=e ; ++i)
+ for (auto i=n->property_begin(), e=n->property_end() ; i!=e ; ++i)
{
if (!check_property(tree, n, *i))
{
@@ -125,22 +123,21 @@ void
checker::report_error(const char *errmsg)
{
fprintf(stderr, "Error: %s, while checking node: ", errmsg);
- for (device_tree::node_path::iterator p=path.begin()+1, pe=path.end() ;
-p!=pe ; ++p)
+ for (auto &p : path)
{
putc('/', stderr);
- p->first.dump();
- if (!(p->second.empty()))
+ p.first.dump();
+ if (!(p.second.empty()))
{
putc('@', stderr);
- p->second.dump();
+ p.second.dump();
}
}
fprintf(stderr, " [-W%s]\n", checker_name);
}
bool
-property_checker::check_property(device_tree *tree, node *n, property *p)
+property_checker::check_property(device_tree *tree, const node_ptr &n,
property_ptr p)
{
if (p->get_key() == key)
{
@@ -154,7 +151,7 @@ property_checker::check_property(device_
}
bool
-property_size_checker::check(device_tree *tree, node *n, property *p)
+property_size_checker::check(device_tree *tree, const node_ptr &n,
property_ptr p)
{
uint32_t psize = 0;
for (property::value_iterator i=p->begin(),e=p->end() ; i!=e ; ++i)
@@ -216,10 +213,9 @@ bool
check_manager::run_checks(device_tree *tree, bool keep_going)
{
bool success = true;
- for (std::map::iterator i=checkers.begin(),
-e=checkers.end() ; i!=e ; ++i)
+ for (auto &i : checkers)
{
- success &= i->second->check_tree(tree);
+ success &= i.second->check_tree(tree);
if (!(success || keep_going))
{
break;
@@ -231,7 +227
Re: svn commit: r289027 - head/contrib/tzcode/stdtime
On 8 Oct 2015, at 13:51, Andriy Gapon wrote: > > What if one day github disappears but FreeBSD is still going? > The full commit message would be lost. That’s not the only thing that is bad about this commit message. Why ‘Assume C89?’ We compile libc as C99 + GNU extensions and are likely to default to C11 + GNU extensions soon. Reading the actual commit, it looks as if it’s changing K&R declarations to ISO C declarations. It’s also introducing an ATTRIBUTE_PURE macro in private.h, which does exactly the same as __pure declared in sys/cdefs.h (which is included by *every single FreeBSD header*. Why this extra spelling? No idea. Is this contrib code (it looks like it)? If so, it should come in via the vendor area (not be directly committed to head), if not then it should have been code reviewed and not include redundant and confusing macro declarations. When merging stuff from GitHub, Alfred has written some good documentation about how to handle them in such a way that we preserve the prior commit history (effectively, checkout the pr branch, rebase it on head, git svn dcommit the result). Please follow this procedure. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r287780 - in head: share/man/man9 sys/kern sys/sys
On 17 Sep 2015, at 08:20, Hans Petter Selasky wrote: > > On 09/17/15 00:05, Gleb Smirnoff wrote: >> Weren't you explicitly asked not to touch this system without a proper >> review and discussion? > > Adding a new function is not touching code. Adding a new interface to an existing core subsystem is most definitely touching the system. I would expect *anyone* making a change like this to have both the design and code reviewed for sanity checking. For someone who has already been required to have explicit review of any changes to the subsystem to skip this step shows a flagrant disregard for the project’s policies and best practices. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286715 - head/lib/libc/string
On 13 Aug 2015, at 08:56, Marcelo Araujo wrote: > > So it means, this commit here was right already: > https://svnweb.freebsd.org/base?view=revision&revision=286651 > > Although I made a mistake with the date. More or less. I partly agree with Bruce that suggesting memcpy is misleading. I’d prefer something like: This function is deprecated (marked as LEGACY in POSIX.1-2001): use .Xr memmove 3 in new programs. If you can guarantee that the input and output buffers do not overlap, then .Xr memcpy 3 may be more efficient. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286715 - head/lib/libc/string
On 13 Aug 2015, at 08:11, Marcelo Araujo wrote: > > The bcopy() was removed in IEEE Std 1003.1-2008 and it is marked as LEGACY in > IEEE Std 1003.1-2004. However, BSD has its implementation before IEEE Std > 1003.1-2001. > > In my understood it is obsolete on POSIX, but not truly obsolete for FreeBSD. > So I believe, this patch now address it in the correct way. Its use should be strongly discouraged in FreeBSD (or, ideally, replaced with the macro from the POSIX man page). LLVM does a load of optimisations for memmove and memcpy - using bcopy is a really good way of bypassing all of these. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286168 - head/sys/net
On 2 Aug 2015, at 17:34, Ian Lepore wrote: > > It generates a compiler error, so the output is going to contain > file-and-line like any other compiler error, as well as the message from > the source code. It will, of course, vary between compilers, but this is what clang generates: $ cat static.c _Static_assert(0, "example assert failed"); $ cc static.c static.c:1:1: error: static_assert failed "example assert failed" _Static_assert(0, "example assert failed"); ^ ~ 1 error generated. GCC 4.8 and later produce very similar output: $ gcc-4.8 static.c static.c:1:1: error: static assertion failed: "example assert failed" _Static_assert(0, "example assert failed"); ^ gcc 4.7 only provides the first line: $ gcc-4.7 static.c static.c:1:1: error: static assertion failed: "example assert failed" David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r285552 - head/usr.bin/xargs
On 15 Jul 2015, at 01:02, Xin Li wrote: > > My only concern with strtonum() is that it's English only. Given that strtonum() wraps strtoll, it ought to support whatever the current locale is (assuming that the program calls setlocale() before calling strtonum(), otherwise it will use the C locale[1]). Or do you mean that the error messages are not localised? David [1] I would strongly advise against calling strtonum() or strtoll(), rather than strtoll_l() from a library, as it is impossible to specify in a potentially multi-threaded context whether you’re currently using a human-friendly or a machine-friendly number representation. In a single-threaded application, it’s probably fine as long as *all* of your number parsing is either from a user or from a machine-parsable file (and all of your output is similar, or you’re explicitly setting the locale before each call). Given that strtonum() is non-standard anyway, we should probably add a strtonum_l() that takes a locale_t and a number base. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r285404 - head/sys/compat/cloudabi
On 11 Jul 2015, at 21:56, Konstantin Belousov wrote: > >> Bucket 2: The system call could also just fail and return an error >> (MSG_NOSIGPIPE). > SIGPIPE exists to ensure that naive programs do something reasonable > when their stdout suddenly goes away. Or, transposing the PoV, it allows > to write useful and well-behaving programs while ignoring complications. > If all programs must be aware of the special error code from write which > indicates that nobody listens to the output anymore, it would cause > unneeded code copy/pasted all over the src. Presumably this could be handled in userspace in the system call wrappers if someone wanted to do it that way - the syscall wrapper would check for the error condition and call the system call handler (though if you wanted the mcontext to be meaningful for the syscall return or support separate signal stacks then this would be fairly complex). David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r285284 - head/lib/liblzma
On 9 Jul 2015, at 10:19, NGie Cooper wrote: > > Yes, but this case will fail for gcc 4.3 ~ 4.4 through 5.x if you use > my recommended method... I think that’s probably fine. We basically have four cases that we care about: - People who are using clang because it’s the system compiler [works] - People who are using new clang from ports / svn because it’s new and shiny [works] - People who are using gcc from base because it’s the system compiler [works] - People who are using new gcc from ports / svn because it’s new and shiny [works] The only people it doesn’t work for are the ones building FreeBSD using an out-of-tree old GCC. There probably aren’t too many of those… David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r285284 - head/lib/liblzma
On 9 Jul 2015, at 03:53, NGie Cooper wrote: > > $ cat ~/has_immintrin.c > #include > > #if __has_include() > #error "I have immintrin.h" > #else > #error "I don't have immintrin.h" > #endif > $ clang -c ~/has_immintrin.c > /home/ngie/has_immintrin.c:4:2: error: "I have immintrin.h" > #error "I have immintrin.h" > ^ > 1 error generated. > $ gcc -c ~/has_immintrin.c > /home/ngie/has_immintrin.c:6:2: error: #error "I don't have immintrin.h" > > Sadly this macro wasn't added until gcc 5.x: > https://gcc.gnu.org/gcc-5/changes.html cdefs.h defines __has_include(x) to 0 if the compiler does not provide __has_include(), so this will also work with gcc in base (always claiming not to have immintrin.h). David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268137 - head/sys/sys
On 19 Jun 2015, at 15:32, Marcelo Araujo wrote: > > Maybe would be a good idea run an 'exp run' with this patch? Just to double > check if any port will break, although after you rename, I don't believe it > will conflict anymore, however an 'exp run' would show you it. It’s probably worth doing, though unfortunately the failure mode for the previous breakage was to silently generate the wrong code in some cases and so may not have shown up in an exp run. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268137 - head/sys/sys
On 19 Jun 2015, at 14:41, Hans Petter Selasky wrote: > > On 06/19/15 14:54, David Chisnall wrote: >> I definitely know of people building out-of-ports programs on FreeBSD whose >> code you have just broken (including myself, > > though I do Objective-C stuff on 10, so haven’t yet encountered the > > breakage). > > Hi David, > > r268137 has been in 11-current for a long time (11 months) and was MFC'ed to > 10-stable not long ago. We have not yet done a release from 10 with this breakage, so I’ve not yet seen it in the wild. Most people doing Objective-C development do not develop on FreeBSD -HEAD. The majority develop on OS X and port to FreeBSD releases. I am anxious to get this fixed before the next 10.x release is out so that we are not shipping something that is going to force people wanting to ship Objective-C code to have to have FreeBSD-specific work-arounds for the next few years. > I understand that including "sys/cdefs.h" breaks objective C-code in the > kernel, but we don't have any such code, do we? You fundamentally misunderstand what cdefs.h is. It is not a kernel header, it is the header that provides all of the definitions required for all system headers. All libc headers expect cdefs.h to be included (either directly or indirectly) before anything else in the file. > Multiple systems are defining __weak for C and C++ : > > Linux: >> include/linux/compiler-gcc.h: > #define __weak__attribute__((weak)) > > NetBSD: > > sys/cdefs_elf.h > #define __weak __attribute__((__weak__)) > > FreeBSD: > > sys/cdefs.h > #define __weak __attribute__((__weak__)) NetBSD is the only system that I’m aware of that has actually shipped this, and it broke a lot of things. Spot the odd one out: $ cat tmp.m #include __weak id x; # FreeBSD 10.1: $ cc -E tmp.m -fobjc-arc | tail -1 __attribute__((objc_ownership(weak))) id x; # Linux $ clang -E tmp.m -fobjc-runtime=gnustep-1.7 -fobjc-arc | tail -1 __attribute__((objc_ownership(weak))) id x; # FreeBSD Head: $ cc -E tmp.m -fobjc-arc | tail -1 __attribute__((__weak__)) id x; The worst thing about this is that you have broken it so that it silently does the wrong thing, rather than raising a warning with the default warnings enabled. >> Portable code should not rely on anything in cdefs.h. > > Right - can you explain why it is ending up in your ObjC code? Because it’s in cdefs.h, which is included by *every single userspace C header*. cdefs.h must work with all C-family languages. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268137 - head/sys/sys
On 19 Jun 2015, at 12:57, Hans Petter Selasky wrote: > > Hi, > >> Then they will get a compile error no matter what GNUstep’s Foundation.h >> does. It can’t prevent cdefs.h from redefining __weak to be something >> different. >> > > Except "#undef __weak” Please read the example that I wrote. This will *not* be fixed by #undef __weak. In particular, the __weak keyword is implemented in Clang as a pre-defined macro, so after *any* inclusion of any C standard library header, every program that uses zeroing weak references needs to redefine __weak to whatever (implementation-defined and subject to change thing) that the compiler defines it to. >> I’ve just looked at the GNUstep base changelog since that NetBSD commit and >> there are no relevant changes, so I’ve no idea what the NetBSD people are >> thinking there. >> > > I think we should have a common cross-BSD solution for the proper definition > of __weak, so that user-space applications which use it follow along. Portable code should not rely on anything in cdefs.h. > Is there a procedure for that? Possibly we should do an exp-run after > changing this to ensure that we don't break more than we fix. I’m not sure what we have any code in ports yet that uses ARC or GC in Objective-C, but I definitely know of people building out-of-ports programs on FreeBSD whose code you have just broken (including myself, though I do Objective-C stuff on 10, so haven’t yet encountered the breakage). > I'll ask some GNUstep people I know about this. Taking off my FreeBSD Core Team hat and putting on my GNUstep libobjc maintainer hat: Please fix this and do not define C-family language keywords or compiler reserved words to be incompatible things in cdefs.h. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268137 - head/sys/sys
On 19 Jun 2015, at 11:45, Hans Petter Selasky wrote:
>
> Appearently this will be fixed in GNUSTEP base:
>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/cdefs_elf.h?only_with_tag=MAIN
>
> Is this still an issue?
It is impossible to fix it in GNUstep Base, because we can’t guarantee that
user code doesn’t include system headers after including GNUstep headers (not
to mention the fact that GNUstep is not the only Objective-C standard library
implementation out there). If the user does, for example:
#import
#include
void example()
{
__weak id foo = bar();
baz(foo);
}
Then they will get a compile error no matter what GNUstep’s Foundation.h does.
It can’t prevent cdefs.h from redefining __weak to be something different.
I’ve just looked at the GNUstep base changelog since that NetBSD commit and
there are no relevant changes, so I’ve no idea what the NetBSD people are
thinking there.
David
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268137 - head/sys/sys
I only just caught this (having seen the fallout from NetBSD doing the same thing in a shipping release and the pain that it’s caused): __weak is a reserved keyword in Objective-C, please pick another name for this. This in cdefs.h makes it impossible to include any FreeBSD standard headers in Objective-C programs (of which we have a couple of hundred in ports) if they use any of the modern Objective-C language modes. David > On 2 Jul 2014, at 09:45, Hans Petter Selasky wrote: > > Author: hselasky > Date: Wed Jul 2 08:45:26 2014 > New Revision: 268137 > URL: http://svnweb.freebsd.org/changeset/base/268137 > > Log: > Define a "__weak" macro for declaring symbols "weak". > > Modified: > head/sys/sys/cdefs.h > > Modified: head/sys/sys/cdefs.h > == > --- head/sys/sys/cdefs.h Wed Jul 2 05:45:40 2014(r268136) > +++ head/sys/sys/cdefs.h Wed Jul 2 08:45:26 2014(r268137) > @@ -210,7 +210,9 @@ > #define __packed > #define __aligned(x) > #define __section(x) > +#define __weak > #else > +#define __weak __attribute__((__weak__)) > #if !__GNUC_PREREQ__(2, 5) && !defined(__INTEL_COMPILER) > #define __dead2 > #define __pure2 > ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r284198 - head/bin/ls
On 13 Jun 2015, at 11:17, Ian Lepore wrote: > > If you would have told me a year ago that you had a simple scheme that > could make 30 years of experience maintaining code for unix-like systems > completely worthless I would have been skeptical, but it seems we're > well on our way. There is a lot of heckling and unhelpful hyperbole in this thread. Reading the xo_emit format strings takes a little bit of getting used to, but the same is true of printf - it’s just that we’re already used to printf. The structured parts (xo_open_container, xo_close_container and friends) are clear and descriptive. The changes are fairly invasive, but the benefits are also very large for anyone who is wanting to automate administration of FreeBSD systems. If you have suggestions for how the libxo APIs could be improved, then please let us know - Phil is very reception to suggestions but objections along the lines of ‘it’s not what I’m used to and changes sometimes break things so we should never have changes’ are not helpful. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r281927 - head/lib/libc/locale
Author: theraven
Date: Fri Apr 24 10:21:20 2015
New Revision: 281927
URL: https://svnweb.freebsd.org/changeset/base/281927
Log:
__xlocale_C_ctype should not be const. It contains a reference count that is
modified by newlocale / duplocale / freelocale.
MFC after:1 week
Modified:
head/lib/libc/locale/none.c
Modified: head/lib/libc/locale/none.c
==
--- head/lib/libc/locale/none.c Fri Apr 24 10:18:41 2015(r281926)
+++ head/lib/libc/locale/none.c Fri Apr 24 10:21:20 2015(r281927)
@@ -209,7 +209,7 @@ struct xlocale_ctype __xlocale_global_ct
256 /* __mb_sb_limit */
};
-const struct xlocale_ctype __xlocale_C_ctype = {
+struct xlocale_ctype __xlocale_C_ctype = {
{{0}, "C"},
(_RuneLocale*)&_DefaultRuneLocale,
_none_mbrtowc,
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r281925 - head/lib/libc/locale
Author: theraven Date: Fri Apr 24 10:17:55 2015 New Revision: 281925 URL: https://svnweb.freebsd.org/changeset/base/281925 Log: Small changes to locale-related man pages. Fix a missing .h and change the recommended include for the POSIX2008 functions from xlocale.h to locale.h. Including xlocale.h is for legacy / Darwin compatibility so should not be encouraged. Modified: head/lib/libc/locale/duplocale.3 head/lib/libc/locale/freelocale.3 head/lib/libc/locale/newlocale.3 head/lib/libc/locale/querylocale.3 head/lib/libc/locale/uselocale.3 Modified: head/lib/libc/locale/duplocale.3 == --- head/lib/libc/locale/duplocale.3Fri Apr 24 09:52:41 2015 (r281924) +++ head/lib/libc/locale/duplocale.3Fri Apr 24 10:17:55 2015 (r281925) @@ -36,7 +36,7 @@ .Sh LIBRARY .Lb libc .Sh SYNOPSIS -.In xlocale.h +.In locale.h .Ft locale_t .Fn duplocale "locale_t locale" .Sh DESCRIPTION Modified: head/lib/libc/locale/freelocale.3 == --- head/lib/libc/locale/freelocale.3 Fri Apr 24 09:52:41 2015 (r281924) +++ head/lib/libc/locale/freelocale.3 Fri Apr 24 10:17:55 2015 (r281925) @@ -38,7 +38,7 @@ or .Sh LIBRARY .Lb libc .Sh SYNOPSIS -.In xlocale.h +.In locale.h .Ft int .Fn freelocale "locale_t locale" .Sh DESCRIPTION Modified: head/lib/libc/locale/newlocale.3 == --- head/lib/libc/locale/newlocale.3Fri Apr 24 09:52:41 2015 (r281924) +++ head/lib/libc/locale/newlocale.3Fri Apr 24 10:17:55 2015 (r281925) @@ -35,7 +35,7 @@ .Sh LIBRARY .Lb libc .Sh SYNOPSIS -.In xlocale +.In locale.h .Ft locale_t .Fn newlocale "int mask" "const char * locale" "locale_t base" .Sh DESCRIPTION Modified: head/lib/libc/locale/querylocale.3 == --- head/lib/libc/locale/querylocale.3 Fri Apr 24 09:52:41 2015 (r281924) +++ head/lib/libc/locale/querylocale.3 Fri Apr 24 10:17:55 2015 (r281925) @@ -36,7 +36,7 @@ .Sh LIBRARY .Lb libc .Sh SYNOPSIS -.In xlocale.h +.In locale.h .Ft const char * .Fn querylocale "int mask" "locale_t locale" .Sh DESCRIPTION Modified: head/lib/libc/locale/uselocale.3 == --- head/lib/libc/locale/uselocale.3Fri Apr 24 09:52:41 2015 (r281924) +++ head/lib/libc/locale/uselocale.3Fri Apr 24 10:17:55 2015 (r281925) @@ -36,7 +36,7 @@ .Sh LIBRARY .Lb libc .Sh SYNOPSIS -.In xlocale.h +.In locale.h .Ft locale_t .Fn uselocale "locale_t locale" .Sh DESCRIPTION ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r281721 - head/sys/sys
On 20 Apr 2015, at 17:19, Bruce Evans wrote: > > Enums should never be used in ABIs, since their size can be anything > large enough. The rules for the size of enums also differ between C and C++, though clang (and, I think, gcc) support an attribute for specifying the enum type. > They also cause namespace problems. The whole enum declaration must > be exposed in any header that uses an enum type. Both C and C++ permit forward declarations of enums for use in function prototypes and so on, e.g.: enum foo; void bar(enum foo); David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r280955 - in head/sys: modules/notrandom dev/notrandom
On 2 Apr 2015, at 11:22, Mateusz Guzik wrote: > > Now one has to wonder how obnoxious one has to get so that people think > "this can't be real". > > I tried really hard. :) Not sure about your locale, but here (where the tradition originated) if you fool someone in the morning then they are an April Fool, if you attempt to fool them in the afternoon then you are the April Fool. Your mail was timestamped 12:36 (ah, the perils of time zones...), though looking back at it I do rather like the commit time: Date: Wed Apr 1 13:37:00 2015 David (Blaming illness for not spotting the joke) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r280955 - in head/sys: modules/notrandom dev/notrandom
On 1 Apr 2015, at 18:41, Mateusz Guzik wrote: > > I guess you were right, this was bad. > > I moved the implementation to null.c, I hope this makes everyone happy. > > https://lists.freebsd.org/pipermail/svn-src-all/2015-April/101876.html This almost certainly does not make people happy: - * Copyright (c) 2000 Mark R. V. Murray & Jeroen C. van Gelderen - * Copyright (c) 2001-2004 Mark R. V. Murray - * Copyright (c) 2014 Eitan Adler + * Copyright (c) 2015 Mateusz Guzik * All rights reserved. * + * Some dudes which previously held the copyright: + * Marc V. R. Murray, Jeroen C. van Gelderen, Eytan Adrel + * Please try not to violate copyright in commits to the FreeBSD project. We get cranky when we have to talk to lawyers. This file already had a good example of how you amend existing copyright notices when you make a sufficiently significant change to warrant claiming copyright. Your copyright on your portions does not supersede the copyright held by the other contributors. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279764 - head/sys/vm
On 10 Mar 2015, at 10:18, Konstantin Belousov wrote: > > Because you cannot grep for the panic string when __func__ is used. The userspace assert uses __func__, __FILE__ and __LINE__, which means that you never need to grep the source code to find out where the assert came from: the assertion message tells you precisely where to go. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh
On 5 Mar 2015, at 14:13, Slawa Olhovchenkov wrote: > > Not better, no. Does telnet support creating server sockets? No. Does telnet support IPsec? No. Does telnet let you specify the tcp window size? No. Does telnet come with a massive selection of options for insecure login / authentication? Yes. Telnet is a tool for insecure remote access. nc is a tool for creating and debugging socket connections. > telnet more verbose (and by default and more). 'nc -v' is less to type than 'telnet' and provides *more* debugging support via -D. > And what about 'tools, not policy'? What about it? We provide a tool that *is designed for creating and debugging sockets*. You instead want a tool for insecure remote login that happens to sort-of work for creating and debugging sockets and your justification for wanting it is that you can use it for debugging sockets. >From your previous posts, you've clearly not read the nc man page and have >absolutely no idea what it is capable of. Why not spent five minutes learning >about the tool that we provide that is *designed specifically for your >requirements* and then suggest places where it could be improved for your >needs, rather than insisting that we provide you with a hammer so that you can >keep bashing screws into walls? David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh
On 5 Mar 2015, at 14:04, Dmitry Sivachenko wrote: > It is so nice to have most useful stuff out of the box. The question is whether a tool for logging into remote machines without encryption is 'the most useful stuff'. The tool is also [ab]used for network testing, but we already provide a better tool for that in the form of nc(1). David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh
On 5 Mar 2015, at 13:14, Slawa Olhovchenkov wrote: > > In previos message -- silently return when telnet speak about used IP > address and diagnostic messages. One simple command do many diagnostic > information. Okay, so check the return code. Or pass -v if you want more verbose information: $ nc -v foo.example.com 80 nc: getaddrinfo: nodename nor servname provided, or not known $ nc -v localhost 80 nc: connectx to localhost port 80 (tcp) failed: Connection refused nc: connectx to localhost port 80 (tcp) failed: Connection refused nc: connectx to localhost port 80 (tcp) failed: Connection refused Or even alias nc -v to telnet if you like typing more... Or add -D, if you want more debugging information. > I am know only about telnet can connect to unix socket. So can cat... Actually, so can nc if you read the man page (which, of course, you did before deciding that it couldn't do what you needed). With -U, it will connect to a UNIX domain socket. Oh, and it can also create UNIX sockets for listening to: $ nc -l -U tmp $ # in another terminal: $ nc -U tmp And now you have two nc instances talking to each other via a UNIX socket. > Why not? And why before this is will be ok? Telnet is in the base system because, back in the 4BSD days, telnet was the recommended way that you logged into remote computers. Now it isn't. For most network diagnostic and simple socket operations, nc is a far more useful tool. Including things that want to talk to UNIX sockets. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh
> On 5 Mar 2015, at 12:42, Slawa Olhovchenkov wrote: > >> netcat - nc(1) - which can also work in the other direction and is designed >> specifically for this purpose. > > nc(1) don't correctly work. It works for me for everything that I used to use telnet for (connection testing, checking plain-text protocols, although increasingly I have to use openssl s_client because few things speak TCP without SSL), what cases does it not work for you? > nc don't work with unix socket. Okay, now you're changing your requirements - you first spoke of remote equipment and network testing. However, UNIX domain sockets appear as files in the filesystem, and we have a host of utilities that are capable of interacting with files (unless they're message-oriented, but then telnet doesn't help either). >>> How to connect to mpd control socket?! >> >> mpdcon from the command line, MPDroid from my mobile, or nc if you're a >> masochist. > > MPDroid?! wut? Or you just don't know about mpd? The one that I'm familiar with is the music player daemon. The other common use of the initalism is multiple personality disorder. If you mean something else, then you should probably say what it is, rather than rely on other people understanding some obscure term (hint: you're not doing yourself any favours in justifying that this is a widespread requirement if people reading your post can't even tell what the requirement is). If you meant the mpd5 package then... well, if you're installing one thing from packages then installing another is not really likely to be an issue. Anyway, from your follow up to Gleb, it seems that your requirement is a network testing tool for computers that are not connected to a network? That seems like a sufficiently niche use that you don't need to have things in the base system. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh
On 5 Mar 2015, at 12:21, Slawa Olhovchenkov wrote: > >> I guess when they are going to be not precious enough to be removed? :) >> >> In modern world of ssh and https, does any OS require them in base? > > yes. > Some telecom equipment require rlogin. 'Some relatively obscure use case needs them' is not usually the requirement for keeping something in the base system. Presumably people who interact with telecoms equipment are capable of installing packages... David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh
On 5 Mar 2015, at 12:33, Slawa Olhovchenkov wrote: > > And how to test open/listing ports/sockets?! netcat - nc(1) - which can also work in the other direction and is designed specifically for this purpose. > How to connect to mpd control socket?! mpdcon from the command line, MPDroid from my mobile, or nc if you're a masochist. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh
On 5 Mar 2015, at 12:30, Slawa Olhovchenkov wrote: > > Yes, if ships before (don't break if working). > Some Linux distro remove telnet from default install. > Do you like to remove telnet also? Absolutely, now that netcat is part of the default install. For anything that a sane user might consider telnet for in 2015, netcat is a better option. For insane users, there's always pkg add. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r278479 - in head: etc sys/kern
On 10 Feb 2015, at 18:30, Rui Paulo wrote: > > Another thing I had in mind (which is more work) was to abstract the devctl > kernel code in an API which could make it easy to fan out the notifications > to multiple /dev devices. However, that may be overkill. This kind of notification is something that kdbus is increasingly being used for on Linux. The primitive allows events to originate either in the kernel or in userspace and to be sent either point-to-point or to a bloom filter set of recipients (so you occasionally get some messages you're not expecting, but hopefully don't get too many spurious wakeups). David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r274489 - in head/sys/amd64: amd64 include
On 21 Nov 2014, at 23:26, Scott Long wrote: > That’s a good question to look further into. I didn’t see any measurable > differences with this change. I think that the cost of the function call > itself masks the cost of a few extra instructions, but I didn’t test with > switching it on/off for the entire kernel [ Note: The following is not specific to the kernel ] The overhead for preserving / omitting the frame pointer is decidedly nonlinear. On a modern superscalar processor, it will usually be effectively zero, right up until the point that it pushes something out of the instruction cache on a hot path, at which point it jumps to 20-50%, depending on the workload. The performance difference was more pronounced on i386, where having an extra GPR for the register allocator to use could make a 10-20% performance difference on some fairly common code (the two big performance wins for x86-64 over IA32 were the increase in number of GPRs and an FPU ISA that wasn't batshit insane). For ISAs with more GPRs, that's less of an issue, although after inlining being able to use %rbp as a GPR can sometimes make a noticeable difference in performance. In particular, as %rpb is callee-save, it's very useful to be able to use it in non-leaf functions. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r274340 - in head/sys: crypto/rijndael dev/random geom/bde
On 11 Nov 2014, at 16:31, Brooks Davis wrote: > In general, we need to fix the C/C++ standard to us express the > things we actually mean when we use const (for example see strchr()'s > use of const). I believe the last issue now being tracked on Google's > internal list of deficiencies in the C++ standard. One of the reviewers for a paper involving this pointed me at Jeffrey Foster's work on qualifier polymorphism for C, which would address these issues. Unfortunately, this work is quite old and didn't make it into the standard. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r273382 - head/contrib/libcxxrt
On 6 Nov 2014, at 01:04, Rui Paulo wrote: > I don't think the non-temporary fix was ever committed. What's the problem? > Is something else defining these methods? Yes, they're defined by libc++ too. The problem is that gcc 4.9 wants to be able to throw bad_array_new_length exceptions when you do new foo[x] and sizeof(foo) * x overflows. It does this by calling a support function defined in the C++ runtime, but that means that the C++ runtime must have the bad_array_new_length class defined there too. Having the methods on those classes defined in libcxxrt and libc++ breaks things. The correct fix was to move a #endif in libc++ so that it didn't compile those functions. There was some discussion about whether we needed to support the case that old libc++ and new libcxxrt were used, but it's probably not required. Bapt was going to check whether there were any symbol versioning issues with code compiled against old libc++/libcxxrt and dynamically linked against the new one. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r274086 - head/sbin/route
On 4 Nov 2014, at 10:28, Stefan Farfeleder wrote: > Shouldn't Coverity understand that err doesn't return? err() is marked as __dead2, which expands to __attribute__((__noreturn__)). If Coverity doesn't know that __attribute__((__noreturn__)) functions don't return, then that's a Coverity bug and they should fix it (if we're not expanding __dead3 to __attribute__((__noreturn__)) for Coverity, then that's a sys/cdefs.h bug and should be fixed there). Putting a break after a noreturn function makes the code less readable and will cause errors in non-buggy static analysers (dead code warning - why do you have a break on an unreachable line?). David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r273274 - head/sys/netpfil/ipfw
On 19 Oct 2014, at 13:02, Andriy Gapon wrote: > I think that on platforms where an optimized version of fls() is available > that > would work faster than this cool piece of bit magic. If you're lucky, the compiler's idiom recogniser will spot this. You're generally better off using the builtins though, because then the compiler will expand them to something sensible (hopefully - old versions of gcc did horribly inefficient things for bswap and clz on platforms without native support). David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r273135 - in head/sys: contrib/rdma/krping dev/cxgbe/iw_cxgbe ofed/drivers/infiniband/core ofed/drivers/infiniband/hw/mlx4 ofed/drivers/infiniband/hw/mthca ofed/drivers/infiniband/ulp/
On 16 Oct 2014, at 14:41, Mateusz Guzik wrote: > Well, atomic_set can be as simple as v->counter = i; (which btw will > make it look identical to linux version). This should not give any > measureable effect unless atomic_set on given var is abused quite a lot. v->counter = i does not establish a happens-before relationship and so there is no guarantee that the write will be visible to other threads until something else does establish such a relationship. The compiler and CPU are both free to reorder the store at will, and to elide it. There is a reason that C11 provides atomic_store and atomic_load operations. It sounds like Linux wants the relaxed consistency model here, which *is* equivalent to v->counter = i on x86, but *will not be the same* on any weakly-ordered architecture (e.g. ARM). Given that we have a stdatomic.h in the base system, which works with all of our supported compilers, please consider using the functionality provided by the C standard to solve your exact problem. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268491 - head/usr.bin/users
On 10 Jul 2014, at 16:29, Ed Schouten wrote: > With the patch above, the binary shrinks to 15640 bytes, so my > concerns are somewhat addressed. :-) I wasn't seeing that saving, but I've now committed a tweak to the Makefile that turns off exceptions and RTTI. This shrinks the binary to 15569 bytes. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r268566 - head/usr.bin/users
Author: theraven Date: Sat Jul 12 07:47:50 2014 New Revision: 268566 URL: http://svnweb.freebsd.org/changeset/base/268566 Log: Turn off exceptions and rtti when building the c++ version of users. Neither is used in the program and this saves us 10KB (around 40%) in binary size. Modified: head/usr.bin/users/Makefile Modified: head/usr.bin/users/Makefile == --- head/usr.bin/users/Makefile Sat Jul 12 07:46:18 2014(r268565) +++ head/usr.bin/users/Makefile Sat Jul 12 07:47:50 2014(r268566) @@ -3,5 +3,6 @@ WARNS= 3 PROG_CXX= users +CXXFLAGS+= -fno-rtti -fno-exceptions .include ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268491 - head/usr.bin/users
On 11 Jul 2014, at 22:26, John Baldwin wrote: >> For things that live in the base system, there's not much danger of boost >> conflicts. 'using namespace std' is mostly a problem when it's in headers >> (especially > library headers), because it can break large amounts of code. In a tiny > utility, it's probably the right thing to do. > > The original question was about a general style rule for C++ code in FreeBSD. > I suppose it would be fine to permit it in small utilities and only in .cc > files but not otherwise? I would say that it's completely fine as long as: - It's in an implementation file and - The utility has not dependencies other than the standard library The first ensures that namespace pollution is localised. The latter limits you to cases where there is no chance of there being any conflicts (if you're defining a symbol in a program that has the same name as an STL one then you should probably be referring to it by its fully qualified name anyway or the code will be unreadable). David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268491 - head/usr.bin/users
On 11 Jul 2014, at 15:03, John Baldwin wrote: > > http://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice > > is a decent start on the multitude of reasons to avoid using it. > > I also avoid 'import * from foo' in Python for similar reasons. > > OTOH, most of the C++ code bases I've had to work with do have a global > 'using namespace std'. Great fun when someone decides it would be > convenient to add 'using namespace boost' to the mix. Note that, even though 'using namespace std' is a bad idea, 'using std::vector; using std::string' and so on is not so bad. For things that live in the base system, there's not much danger of boost conflicts. 'using namespace std' is mostly a problem when it's in headers (especially library headers), because it can break large amounts of code. In a tiny utility, it's probably the right thing to do. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268491 - head/usr.bin/users
On 10 Jul 2014, at 18:13, Adrian Chadd wrote: > ... I think this particular commit highlights our almost complete lack > of useful data types in our C libraries. > > I think it's about time we grew a similar list of basic DSAs. > > I had to reimplement hash tables, trees and callwheels at work recently. Ugh. This is important in a wider context. For example, in the project to add machine-readable output to core utilities, we'd like to be able to parse these into the same machine-readable format. Apple has the CoreFoundation library for this, which provides a load of stuff, but most importantly number, string, date, dictionary, and array types (i.e. the sorts of things that you'd want in JSON-like serialisation formats). The simplest way of implementing this would be to just provide some C wrappers around the libc++ implementations, but that might not be ideal... David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r266974 - in head/sys: dev/dc dev/fxp dev/mii dev/netmap kern net
On 3 Jun 2014, at 06:01, Adrian Chadd wrote: > I wonder if in the short term we should just use inlines for now, at > least so the methodization can get done without hurting people on > ARM/MIPS. It's probably worth thinking a bit more carefully about the KPI, since it's something we'll likely be stuck with for a long time... If access to a particular field is on the hot path, and you're never going to want to do interposition, then the obvious thing to do is have a method that returns a pointer to the field so that you can cache it in the caller. Some thought needs to be given there as to whether these things are _Atomic() qualified for when we (eventually) move to C11 for the kernel. For drivers that are compiled into the kernel, there's no issue with making the call inline, but if we want to have a stable KBI for modules then that needs to be conditional. I'm a bit wary about things that will introduce significant performance differences between things built as modules and compiled into the kernel. Longer term, there's also the possibility of shipping modules as LLVM IR and doing install-time specialisation of them against the current kernel, which would make avoiding the function call a premature optimisation that we'd have to keep living with. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r266865 - in head: include include/xlocale lib/libc/string
On 30 May 2014, at 06:18, Rui Paulo wrote: > Is this going to cause any ports fallout? It shouldn't do. Any code that compiles on OS X will expect these to be in the correct place, and since DragonFly applied the fix first we'd hopefully have found any fallout via dports. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r266423 - in head/sys: conf dev/i40e modules/i40e
On 20 May 2014, at 18:16, Gleb Smirnoff wrote: > Would be cool if most of tools (netstat, systat, etc...) could > determine size of terminal and dynamically widen all their fields. > Thus, tool can run w/o any abbreviations when run in a script mode, > run abbreviated on a small terminal, and run verbose on a wide > terminal. > > This sounds like a generic library providing a special version > of printf(3), which specifies minimal and maximum sizes for fields > and when extra terminal width is available it distributes this > width evenly between all fields. Name it 'elastic printf'. > Sounds like a nice Google SoC project. Or might be that such > library already exists. We have a summer of code project to teach (some of) these tools to produce a structured, machine-readable, output and write a few generic tools for processing them. This should make it a lot easier to produce simple tools that can fit the information that you actually want into a terminal (or send HTML to netcat, or whatever). David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r265861 - in head/sys: arm/include modules
On 11 May 2014, at 14:05, Ian Lepore wrote: > On Sun, 2014-05-11 at 13:58 +0100, David Chisnall wrote: >> On 11 May 2014, at 13:53, Ian Lepore wrote: >> >>> Ooops, indeed, thanks. Although... it's a good change in terms of >>> speeding up the build, I just didn't intend to commit it until it got >>> tested with -j levels higher than I can test with my little 6-core >>> machine. >> >> I'd be happy to test it on a 32-core machine. Are there any specific >> configs you need, or is buildkernel enough? >> >> David >> >> > > Well eventually it'll need a universe build test, but any kernel/modules > build at -j32 would be a good start. $ make universe -j64 JFLAG=-j64 ... -- >>> make universe completed on Sun May 11 15:39:02 UTC 2014 (started Sun May 11 13:22:56 UTC 2014) -- This is with the revision immediately before the one where you reverted the change. (e9e7ccdea56a38ab5bee2efec955f8b14b05fd15 from the github mirror, which corresponds to svn r265876). David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r265861 - in head/sys: arm/include modules
On 11 May 2014, at 13:53, Ian Lepore wrote: > Ooops, indeed, thanks. Although... it's a good change in terms of > speeding up the build, I just didn't intend to commit it until it got > tested with -j levels higher than I can test with my little 6-core > machine. I'd be happy to test it on a 32-core machine. Are there any specific configs you need, or is buildkernel enough? David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r265367 - head/lib/libc/regex
Bruce, On 6 May 2014, at 05:46, Bruce Evans wrote: > The standard behaviour is undefined. It cannot be relied on. From C99 > (n869.txt): > > %7.20.3.1 The calloc function > % %Synopsis > % %[#1] > % %#include > %void *calloc(size_t nmemb, size_t size); > % %Description > % %[#2] The calloc function allocates space for an array of > %nmemb objects, each of whose size is size. The space is > %initialized to all bits zero.238) > > Oops, there is no object to begin with, so perhaps the behaviour is > defined after all. This is unclear. You're missing off the next line: > • 3 The calloc function returns either a null pointer or a pointer to > the allocated space. Clarifications from WG14 have indicated that this means that calloc() *must* return either NULL or enough space for nmemb objects of size size. The text of the standard was not changed in C11 because it seemed to be the consensus of library authors that this is obvious from the existing text. See the CERT report from my previous email - in 2002 it was regarded as a security hole (and a lack of standards conformance) if your calloc did not do this and all known calloc implementations that did not were fixed. Now, you can argue that either: - In this case, we can statically prove that the multiplication won't overflow so we don't need a check, or - It is better to do the overflow check on the caller side and increase i-cache usage to save some memory zeroing. But please don't try to argue that it is permitted for calloc() to not correctly handle integer overflow. It is both non-conformant and dangerous for it to fail to do so. > It is also unclear if objects > can have size too large to represent as a size_t That is implementation defined, however if sizeof(ptrdiff_t) <= sizeof(size_t) then they can not because you must be able to represent the difference between any two pointers as a ptrdiff_t[1]. If you want to be pedantic, _Static_assert(sizeof(ptrdiff_t) <= sizeof(size_t), "Unsupported platform!") to make sure you catch it at compile time if this might change. David [1] This also means, on our platforms, that the maximum size of an object must be one byte less than the total size of the address space, as C only defines pointer comparisons between valid pointers to the same object and allows pointers to be one element past the end of an array. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r265367 - head/lib/libc/regex
On 5 May 2014, at 22:51, Andrey Chernov wrote: > For standard malloc/realloc interface it is up to the caller to check > n*size not overflows. You must trust caller already does such check. Do a search of the CVE database sometime to see how well placed that trust generally is. Or even look at the code in question, where none of the realloc() or malloc() calls does overflow checking. > Using calloc() to enforce it instead of caller is semantically wrong, Relying on a standard function to behave according to the standard is semantically wrong? > and especially strange when the caller is standard C library under your > control. I don't follow this. If libc can't rely on standards conformance from itself then other code stands no chance. > It was unclear what type of ckecking you mean initially You mean when I said 'the overflow-checking behaviour of calloc'? I'm sorry, but I'm not sure how I could have made that clearer. > and confirm my > statement that such code is hard to understand. I disagree. Favouring calloc() over malloc() unless profiling indicates that calloc() is a bottleneck has been recommended practice for a *very* long time and I'm honestly surprised to encounter C programmers who have not come across the advice. > Even if it is for > arithmetic overflow, it is still semantically incorrect, see my other > answer. Your other answer did not say *why* you think it's 'semantically incorrect'. The standard requires calloc() to do overflow checking and that is the reason for its use in the overwhelming number of cases. > Main purpose of calloc is to zero memory, not to check its > argument, so its argument checking is side effect. It should be > implemented by the caller (as I already answer) and not by the price of > zeroing. It is unfortunate that the zeroing and the overflow checking were conflated in the standard, but that certainly doesn't mean that it is the only purpose of calloc. If you want to argue that the price of zeroing is too high, then I would like to see some profiling data to back it up. Between the cost of performing an allocation and the cost of doing a regex search, I'd be surprised if the cost of a bzero() were not in the noise. To offset this, you'd be increasing i-cache usage at every malloc() call site by wrapping it in an overflow check (if you want the code to be *correct* as well as fast), which is likely to be a bigger hit. The reason that calloc() does zeroing in the first place rather than just having malloc() followed by memset() / bzero() is that the memory that malloc() gets from the kernel is already zero'd, and so the 'price' for the zeroing is often nothing. David P.S. A quick look at Coverity shows 4 other bugs in this file, one of which looks like it might actually be serious. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r265367 - head/lib/libc/regex
On 5 May 2014, at 22:40, Andrey Chernov wrote: > On 05.05.2014 22:28, David Chisnall wrote: >> On 5 May 2014, at 18:42, Andrey Chernov wrote: >> >>> Please don't commit OpenBSD errors. Now you mix calloc() with the >>> realloc() for the same variable later which makes calloc() zeroing >>> pointless and waste of CPU. >> >> The purpose of calloc() here is not (primarily) to get the zero'd size, it's >> to get the overflow-checking behaviour for calloc. > > It is better to avoid using undocumented intrinsic knowledge of standard > function particular implementation, this is unportable at least and hard > to understand too. calloc() is required to return either NULL or a valid pointer to the requested amount of memory. An implementation that does not correctly check for overflow is buggy and will be regarded as a security hole (see: http://cert.uni-stuttgart.de/ticker/advisories/calloc.html), but fortunately these were all fixed by around 2004. This is not relying on undocumented intrinsic knowledge, this is relying on the standard library doing what is required of it. There is a reason why secure coding standards have, for over a decade, said to prefer calloc() over malloc() unless profiling shows that calloc() is a bottleneck: it means that only one person needs to get the overflow checking right in one place, rather than everyone getting it right everywhere. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r265367 - head/lib/libc/regex
On 5 May 2014, at 22:33, Warner Losh wrote: > reallocf(): > The reallocf() function is identical to the realloc() function, except > that it will free the passed pointer when the requested memory cannot be > allocated. This is a FreeBSD specific API designed to ease the problems > with traditional coding styles for realloc() causing memory leaks in > libraries. > ... > The reallocf() function first appeared in FreeBSD 3.0. While reallocf() is nice, it doesn't address the problem of overflow. It takes a single size, forcing the caller to do the number-of-elements * element-size multiplication, which is the problematic one. If an attacker can control the number of elements, then it's possible to make the multiplication overflow so reallocf() will return a valid pointer to an area of memory that is much smaller than the caller was expecting. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r265367 - head/lib/libc/regex
On 5 May 2014, at 20:49, Pedro Giffuni wrote: > Yes, but I reverted it because there are other ways to check for overflows > without the performance hit. Do we have a good reusable routine for doing this somewhere? Clang and gcc both have some idiom recognisers that try to spot when people are attempting to do this. Clang also has a builtin, which would be good to use when available. Overflow checking is very cheap on modern CPUs (add, branch on carry), so it would be nice if we could start looking for this malloc() and realloc() pattern and replacing the multiply with something that checks for the error. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r265367 - head/lib/libc/regex
On 5 May 2014, at 18:42, Andrey Chernov wrote: > Please don't commit OpenBSD errors. Now you mix calloc() with the > realloc() for the same variable later which makes calloc() zeroing > pointless and waste of CPU. The purpose of calloc() here is not (primarily) to get the zero'd size, it's to get the overflow-checking behaviour for calloc. The uses of realloc() later do still potentially overflow, as they follow the realloc(pointer, size * sizeof(type)) antipattern. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r264265 - in head: crypto/openssl/crypto/bn crypto/openssl/crypto/ec crypto/openssl/ssl sys/fs/nfsserver
On 9 Apr 2014, at 15:19, Kubilay Kocak wrote: > That expectation is orthogonal to whether we or other projects do it one > way or another. RHEL users may well be as confused as ours (whether of > not ours are). It may be relevant as a data point, but not for decision > making. I can confirm that, as a user (albeit a slightly sleep-deprived one at the time) I was confused. I believe that I'm now running the correct version, as my libssl.so has a creation date of yesterday, but I don't have a good way of verifying it. It would be great for future security advisories to have a 'how to tell if you're affected' and 'how to tell if you're patched' section. I noticed that freebsd-update told me (after the fetch phase) that I should rebuild all third-party software. I have been following the instructions that we give to users and not building most software on that machine myself. I don't know if there are any packages that statically link to libssl.a (or even if we have a mechanism for determining that), but I'd hope that these would get separate VuXML reports for pkg audit to pick up. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r264196 - head/lib/libc/rpc
Author: theraven
Date: Sun Apr 6 17:06:27 2014
New Revision: 264196
URL: http://svnweb.freebsd.org/changeset/base/264196
Log:
Move definitions out of rpc_com so that the linker doesn't complain about
multiple definitions.
Reported by: sbruno
Modified:
head/lib/libc/rpc/rpc_com.h
head/lib/libc/rpc/svc.c
Modified: head/lib/libc/rpc/rpc_com.h
==
--- head/lib/libc/rpc/rpc_com.h Sun Apr 6 16:48:00 2014(r264195)
+++ head/lib/libc/rpc/rpc_com.h Sun Apr 6 17:06:27 2014(r264196)
@@ -86,8 +86,8 @@ bool_t __xdrrec_setnonblock(XDR *, int);
bool_t __xdrrec_getrec(XDR *, enum xprt_stat *, bool_t);
void __xprt_unregister_unlocked(SVCXPRT *);
-SVCXPRT **__svc_xports;
-int __svc_maxrec;
+extern SVCXPRT **__svc_xports;
+extern int __svc_maxrec;
__END_DECLS
Modified: head/lib/libc/rpc/svc.c
==
--- head/lib/libc/rpc/svc.c Sun Apr 6 16:48:00 2014(r264195)
+++ head/lib/libc/rpc/svc.c Sun Apr 6 17:06:27 2014(r264196)
@@ -84,6 +84,9 @@ static struct svc_callout {
void(*sc_dispatch)(struct svc_req *, SVCXPRT *);
} *svc_head;
+SVCXPRT **__svc_xports;
+int __svc_maxrec;
+
static struct svc_callout *svc_find(rpcprog_t, rpcvers_t,
struct svc_callout **, char *);
static void __xprt_do_unregister (SVCXPRT *xprt, bool_t dolock);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r264143 - head/lib/libc/stdlib
Author: theraven
Date: Sat Apr 5 08:17:48 2014
New Revision: 264143
URL: http://svnweb.freebsd.org/changeset/base/264143
Log:
Silence a warning with GCC that was breaking the build with Juniper's GCC.
Reviewed by: marcel
Modified:
head/lib/libc/stdlib/atexit.c
head/lib/libc/stdlib/heapsort.c
head/lib/libc/stdlib/qsort_r.c
Modified: head/lib/libc/stdlib/atexit.c
==
--- head/lib/libc/stdlib/atexit.c Sat Apr 5 03:01:29 2014
(r264142)
+++ head/lib/libc/stdlib/atexit.c Sat Apr 5 08:17:48 2014
(r264143)
@@ -80,6 +80,7 @@ struct atexit {
};
static struct atexit *__atexit;/* points to head of LIFO stack
*/
+typedef DECLARE_BLOCK(void, atexit_block, void);
/*
* Register the function described by 'fptr' to be called at application
@@ -141,7 +142,7 @@ atexit(void (*func)(void))
* Register a block to be performed at exit.
*/
int
-atexit_b(DECLARE_BLOCK(void, func, void))
+atexit_b(atexit_block func)
{
struct atexit_fn fn;
int error;
Modified: head/lib/libc/stdlib/heapsort.c
==
--- head/lib/libc/stdlib/heapsort.c Sat Apr 5 03:01:29 2014
(r264142)
+++ head/lib/libc/stdlib/heapsort.c Sat Apr 5 08:17:48 2014
(r264143)
@@ -45,6 +45,7 @@ __FBSDID("$FreeBSD$");
#ifdef I_AM_HEAPSORT_B
#include "block_abi.h"
#define COMPAR(x, y) CALL_BLOCK(compar, x, y)
+typedef DECLARE_BLOCK(int, heapsort_block, const void *, const void *);
#else
#define COMPAR(x, y) compar(x, y)
#endif
@@ -149,7 +150,7 @@ int
heapsort_b(vbase, nmemb, size, compar)
void *vbase;
size_t nmemb, size;
- DECLARE_BLOCK(int, compar, const void *, const void *);
+ heapsort_block compar;
#else
int
heapsort(vbase, nmemb, size, compar)
Modified: head/lib/libc/stdlib/qsort_r.c
==
--- head/lib/libc/stdlib/qsort_r.c Sat Apr 5 03:01:29 2014
(r264142)
+++ head/lib/libc/stdlib/qsort_r.c Sat Apr 5 08:17:48 2014
(r264143)
@@ -8,9 +8,10 @@
#define I_AM_QSORT_R
#include "qsort.c"
+typedef DECLARE_BLOCK(int, qsort_block, const void *, const void *);
+
void
-qsort_b(void *base, size_t nel, size_t width,
- DECLARE_BLOCK(int, compar, const void *, const void *))
+qsort_b(void *base, size_t nel, size_t width, qsort_block compar)
{
qsort_r(base, nel, width, compar,
(int (*)(void *, const void *, const void *))
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib
On 4 Apr 2014, at 14:44, Jordan Hubbard wrote: > Ah, OK. And I’m guessing there’s been no interest in forward-porting the > blocks support to 4.7? That’s kind of… a bummer. I don't think so. Warner has been forward-porting some of the FreeBSD binutils changes, but even Pedro (who did the blocks port to FreeBSD gcc 4.2.1) doesn't want to touch gcc anymore. > I’m guessing the great white hope for all the platforms is a slow > convergence on clang then? What is the compiler toolchain master plan? If > there’s a wiki somewhere describing it, I’d also be happy to just go read > that. Not really. Converging on clang is nice, but even then it's good to have (at least) a second working compiler for several reasons: - As we discovered with gcc, having a single source for a core component is usually not ideal, as they can change the rules suddenly - If there's a bug in clang (and, given that it's getting on for a million lines of C++ code now, the odds are good that there are always going to be a few), it's helpful to have another compiler for testing. - Periodic testing with another compiler stops us shipping code that relies on non-conformant behaviour. The amount of effort that it's required to get the Linux kernel to build with clang should be a warning for us - we don't want to fall into the same trap. That said, I think we're increasingly going to be using LLVM for things that are beyond just simple AOT compilation, so platforms with no LLVM back end are likely to be left behind. >> For embedded uses, we'd also like to build FreeBSD with >> vendor's-ugly-hacked-up-gcc-of-the-week. This is less of an issue now for >> ARM, but MIPS vendors still hack up gcc in such a way that there's no way >> that they can get their changes upstreamed and then ship the result with >> their chips. > > I see. That’s pretty ugly indeed - is there a list of FreeBSD MIPS folks > doing this somewhere? I ask out of curiosity to know if there’s any > collective attempt to chain them all together and insist that they improve > clang/MIPS to the point where they can stop doing ugly-ass gcc ports. :) I'm working with the MIPS people (who are now Imagination Technologies people) to get my MIPS improvements upstreamed. You can see quite a few of them in the commit log over the past week or two: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/Mips/?view=log Since we also have a hacked-up LLVM that adds support for a custom MIPS chip, I'm also looking at improving the general infrastructure in the MIPS back end, so that we can minimise diffs and make it easy for vendors to push their custom code upstream to LLVM without breaking everyone else. Or, at the very least, make it cheaper to ship a hacked-up LLVM toolchain than a hacked-up GCC toolchain... The MIPS people are working hard to get Linux/MIPS building with Clang, so there's a good chance that they'll convince their downstream people to go with it. I imagine that they're in more or less the same situation as ARM, which can divide their customers nearly into two categories: - Those that won't touch gcc over the license - Those that don't care what their compiler is as long as it works ARM has noticed that LLVM makes both of these groups happy (and is actually using it as the basis for their proprietary compiler as well now). Hopefully MIPS will too... David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib
On 4 Apr 2014, at 13:44, Jordan Hubbard wrote: > On Apr 4, 2014, at 5:33 PM, David Chisnall wrote: > >> The slight problem, however, is that we would still like to be able to build >> the base system with a more or less standard C compiler. Blocks are in >> clang and are slowly making their way into commercial compilers, but the >> only two versions of gcc that support them are the ones shipped by Apple and >> FreeBSD. > > Huh. Can I ask what specific need is driving that? As you point out, you’ve > got clang and you’ve also got the blocks support from Apple gcc back-ported, > so that covers all the architectures you could possibly want to generate code > for. Wanting to hold base to some retro K&R standard for its own sake seems… > weird… so I must be missing some part of the need statement, hence my > question? There are two requirements: We'd like to kill off gcc 4.2.1 in base, because it doesn't support C11 or C++11. The lack of C++11 support is a problem because it means gcc architectures can't build libc++, so they need to use an old libstdc++ to build C++ things in the base system (which also means that these things can't take advantage of C++11, which cleans up the language a huge amount). The prerequisite for this is the availability of external toolchains for the non-clang platforms. If we could build base with gcc47 from ports, that would be okay, because then we'd have a modern C/C++ compiler in the base system and a modern(ish - 4.8 / 4.9 would be better, but 4.7 is a reasonable baseline) C/C++ compiler in ports to drive an external toolchain. For embedded uses, we'd also like to build FreeBSD with vendor's-ugly-hacked-up-gcc-of-the-week. This is less of an issue now for ARM, but MIPS vendors still hack up gcc in such a way that there's no way that they can get their changes upstreamed and then ship the result with their chips. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib
On 4 Apr 2014, at 13:23, Jordan Hubbard wrote: > On Apr 4, 2014, at 4:59 PM, David Chisnall wrote: > >> I believe that libdispatch most likely won't be imported until there is an >> in-tree consumer, but it's in ports and there's nothing stopping ports >> depending on it if they want to use it... > > I certainly get and even generally agree with that point of view. It seems > like putting the cart before the horse to bring in any technology before > there is a use case demanding said technology, right? > > Right. However, I think there are also occasional exceptions to that rule. > The strlcpy() / strlcat() / … family of functions, for example. Until they > existed (outside of OpenBSD), nobody really used them pervasively enough to > achieve their intended purpose (death to buffer overflows in string handling) > and it took bringing them in and essentially saying “see? there! use those > now please!” for adoption and conversion of existing string handling code to > eventually, over the course of years, become second nature. > > I think libdispatch is in a very similar category, and you’ll just have to > trust me when I say that I’ve had the benefit of watching multiple years > worth of slow adoption work its magic there, too. Without libdispatch, you > just use pthreads whenever you need to do something in the background. > Without libdispatch, you don’t write code (in libraries or applications) > which assumes any sort of run loop at all because, well, there isn’t one. > Without libdispatch, you still write careful and limited signal handling > functions because there’s no signal trampoline to save your butt if you try > to do to much in a signal handler. I could go on at length! > > Libdispatch (with blocks) is, in short, more akin to a programming idiom than > a library. Without them, you simply write an entirely different style of > synchronous, multi-threaded code with mutex locks and pthread join and > cancellation points, yada yada yada. Once libdispatch and blocks are part of > the runtime, you slowly leave the old style stuff behind because it’s > limited, painful and just nowhere near as sophisticated. To paraphrase > something I heard from more than a few dozen software engineers over the > years: “Libdispatch is the multithreaded programming paradigm I never knew I > always wanted.” > > There’s a reason it’s been ported to everything from Windows to Android. > It’s hard to go back, once you have made the switch. > > Back to my point, however: I don’t think FreeBSD programmers are ever going > to embrace an idiomatic change of that nature (and it’s pretty significant) > until it is part of base, so there’s really a deadlock here. What’s worse, I > also don’t think anyone in *BSD-land is writing code that’s particularly > event-aware (the lack of system-wide notifications kind of speaks to that) > largely *because* it’s a PITA to do that without a runloop or handy glue code > which makes it trivial, the alternative being to use a background thread that > tries to coordinate said events with the foreground and that’s just icky. > The end-result of this is that an entire somewhat more modern style of > programming, where things are more dynamic in the face of things changing on > the system, simply doesn’t happen at the OS level and that’s a shame, because > the OS *is* a dynamic environment, particularly in the mobile space. > > I guess what I’m advocating is nothing less than a leap of faith? I would certainly be in favour of importing it. The package seems to be on every FreeBSD machine that I use, so I've become accustomed to having it there and just work. The slight problem, however, is that we would still like to be able to build the base system with a more or less standard C compiler. Blocks are in clang and are slowly making their way into commercial compilers, but the only two versions of gcc that support them are the ones shipped by Apple and FreeBSD. In the commit that started this thread, I was careful to ensure that the code that consumes blocks works correctly with a C compiler that doesn't support blocks. Unfortunately, libdispatch just does #ifdef __BLOCKS__ all over the place, and so you get a binary with a different interface. This gets worse when we start to actually use blocks in the base system. Hopefully, gcc upstream will gain blocks support soon (apparently someone at Mentor Embedded is working on it?), and then we can start to more seriously consider them for things in the base system. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib
On 4 Apr 2014, at 13:14, Baptiste Daroussin wrote: > On Fri, Apr 04, 2014 at 01:10:24PM +0100, David Chisnall wrote: >> On 4 Apr 2014, at 12:52, Baptiste Daroussin wrote: >> >>> This breaks a couple of ports starting with cups, those ports do expect >>> libdispatch to be available if _BLOCK_ exists. Do you plan to import >>> libdispatch soon? >> >> I've just tried building the print/cups-client port and it builds correctly >> for me with base-clang, base-gcc, and ports-gcc47. Can you provide any more >> steps to reproduce? >> >> David >> > I have CCed you about this case Thanks. It looks like it's unrelated to this commit, but due to the earlier addition of blocks support to base-gcc. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib
On 4 Apr 2014, at 12:52, Baptiste Daroussin wrote: > This breaks a couple of ports starting with cups, those ports do expect > libdispatch to be available if _BLOCK_ exists. Do you plan to import > libdispatch soon? I've just tried building the print/cups-client port and it builds correctly for me with base-clang, base-gcc, and ports-gcc47. Can you provide any more steps to reproduce? David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib
On 4 Apr 2014, at 12:52, Baptiste Daroussin wrote: > On Wed, Apr 02, 2014 at 04:07:48PM +0000, David Chisnall wrote: >> Author: theraven >> Date: Wed Apr 2 16:07:48 2014 >> New Revision: 264042 >> URL: http://svnweb.freebsd.org/changeset/base/264042 >> >> Log: >> Add support for some block functions that come from OS X. These are >> intended to build with any C compiler. >> >> Reviewed by:pfg >> MFC after: 3 weeks > > This breaks a couple of ports starting with cups, those ports do expect > libdispatch to be available if _BLOCK_ exists. Do you plan to import > libdispatch soon? __BLOCKS__ is a compiler predefine, which this doesn't change - it just exposes some other functions *if* __BLOCKS__ is defined. I'm not sure what _BLOCK_ is - is it something that their configure script is defining? We do currently have some inconsistency in the base system, because gcc defaults to -fblocks, whereas clang defaults to -fno-blocks on FreeBSD. This means that __BLOCKS__ is defined when building with gcc from base, but with clang from base or gcc from ports, but that's independent of this change. I believe that libdispatch most likely won't be imported until there is an in-tree consumer, but it's in ports and there's nothing stopping ports depending on it if they want to use it... David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r264082 - head/lib/libc
Author: theraven
Date: Thu Apr 3 17:31:38 2014
New Revision: 264082
URL: http://svnweb.freebsd.org/changeset/base/264082
Log:
Fix the inheritance of the FBSDprivate_1.0 namespace.
Modified:
head/lib/libc/Versions.def
Modified: head/lib/libc/Versions.def
==
--- head/lib/libc/Versions.def Thu Apr 3 17:26:45 2014(r264081)
+++ head/lib/libc/Versions.def Thu Apr 3 17:31:38 2014(r264082)
@@ -35,4 +35,4 @@ FBSD_1.4 {
#
# Please do NOT increment the version of this namespace.
FBSDprivate_1.0 {
-} FBSD_1.3;
+} FBSD_1.4;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r264070 - in head/lib/libc: . gen stdlib
Author: theraven
Date: Thu Apr 3 08:16:45 2014
New Revision: 264070
URL: http://svnweb.freebsd.org/changeset/base/264070
Log:
Move _b functions into the 11.x symbol version namespace.
Modified:
head/lib/libc/Versions.def
head/lib/libc/gen/Symbol.map
head/lib/libc/stdlib/Symbol.map
Modified: head/lib/libc/Versions.def
==
--- head/lib/libc/Versions.def Thu Apr 3 08:08:36 2014(r264069)
+++ head/lib/libc/Versions.def Thu Apr 3 08:16:45 2014(r264070)
@@ -23,6 +23,11 @@ FBSD_1.2 {
FBSD_1.3 {
} FBSD_1.2;
+# This version was first added to 11.0-current.
+FBSD_1.4 {
+} FBSD_1.3;
+
+
# This is our private namespace. Any global interfaces that are
# strictly for use only by other FreeBSD applications and libraries
# are listed here. We use a separate namespace so we can write
Modified: head/lib/libc/gen/Symbol.map
==
--- head/lib/libc/gen/Symbol.mapThu Apr 3 08:08:36 2014
(r264069)
+++ head/lib/libc/gen/Symbol.mapThu Apr 3 08:16:45 2014
(r264070)
@@ -392,7 +392,6 @@ FBSD_1.3 {
nvis;
pwcache_userdb;
pwcache_groupdb;
- scandir_b;
snvis;
strenvisx;
strnunvis;
@@ -410,6 +409,10 @@ FBSD_1.3 {
waitid;
};
+FBSD_1.4 {
+ scandir_b;
+};
+
FBSDprivate_1.0 {
/* needed by thread libraries */
__thr_jtable;
Modified: head/lib/libc/stdlib/Symbol.map
==
--- head/lib/libc/stdlib/Symbol.map Thu Apr 3 08:08:36 2014
(r264069)
+++ head/lib/libc/stdlib/Symbol.map Thu Apr 3 08:16:45 2014
(r264070)
@@ -86,14 +86,10 @@ FBSD_1.0 {
FBSD_1.3 {
at_quick_exit;
- atexit_b;
atof_l;
atoi_l;
atol_l;
atoll_l;
- heapsort_b;
- mergesort_b;
- qsort_b;
quick_exit;
strtod_l;
strtof_l;
@@ -108,6 +104,13 @@ FBSD_1.3 {
strtouq_l;
};
+FBSD_1.4 {
+ atexit_b;
+ heapsort_b;
+ mergesort_b;
+ qsort_b;
+};
+
FBSDprivate_1.0 {
__system;
_system;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r264069 - head/lib/libc/include
Author: theraven Date: Thu Apr 3 08:08:36 2014 New Revision: 264069 URL: http://svnweb.freebsd.org/changeset/base/264069 Log: Add an extra void* cast to work around a bug in FreeBSD-gcc inherited from Apple. Modified: head/lib/libc/include/block_abi.h Modified: head/lib/libc/include/block_abi.h == --- head/lib/libc/include/block_abi.h Thu Apr 3 07:28:36 2014 (r264068) +++ head/lib/libc/include/block_abi.h Thu Apr 3 08:08:36 2014 (r264069) @@ -60,4 +60,4 @@ int flags;\ int reserved;\ void (*invoke)(void *, ...);\ - }*)x)->invoke) + }*)(void*)x)->invoke) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib
On 2 Apr 2014, at 18:24, Konstantin Belousov wrote: > It does, I read it. Read the code again. Or even just read the comments. In particular the blocks_abi.h file contains a detailed description of why the rest of what you say is wrong. > Now libc depends on the non-standard ABI Not true, the ABI is documented and is as standard as the C++ ABI. We have code in ports and in the base system that relies on this ABI already. > of non-standard C extension, The extension is non-standard, however (if you'd read the code, or the comments in the code you'd already know that) the code in libc does not require this extension to exist. > implemented by only one compiler. Actually, by two, both of which are in the base system. Well, three if you count Apple-GCC as different from FSF-GCC. Oh, and a couple of proprietary compilers. All of which are only required for *callers* of these functions. libc itself still builds correctly (and is tested building) with compilers that don't support blocks. If you have helpful comments, then I suggest you try to phrase them in a less confrontational tone. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r264043 - head/lib/libc/gen
Author: theraven
Date: Wed Apr 2 16:29:29 2014
New Revision: 264043
URL: http://svnweb.freebsd.org/changeset/base/264043
Log:
Move scandir_b to a later symbol version.
Modified:
head/lib/libc/gen/Symbol.map
Modified: head/lib/libc/gen/Symbol.map
==
--- head/lib/libc/gen/Symbol.mapWed Apr 2 16:07:48 2014
(r264042)
+++ head/lib/libc/gen/Symbol.mapWed Apr 2 16:29:29 2014
(r264043)
@@ -349,7 +349,6 @@ FBSD_1.1 {
posix_spawnattr_setsigdefault;
posix_spawnattr_setsigmask;
posix_spawnp;
- scandir_b;
semctl;
tcgetsid;
tcsetsid;
@@ -393,6 +392,7 @@ FBSD_1.3 {
nvis;
pwcache_userdb;
pwcache_groupdb;
+ scandir_b;
snvis;
strenvisx;
strnunvis;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib
On 2 Apr 2014, at 17:18, Konstantin Belousov wrote: > This is completely wrong. You cannot modify FreeBSD 8.x namespace in > 11.x HEAD time. That was an error, however we are using symbol versioning completely wrongly in FreeBSD anyway (see the last two DevSummit discussions and the wiki page). New entries should *always* go in the version 0 namespace (so that when they're MFCd the changes Just Work™) and only ever be moved out of there when they are replaced with versions with different semantics. The weird hybrid we have that tries to conflate symbol versions and OS releases manages to get the worst of both worlds. I've now moved it to the FBSD_1.3 namespace, but I would be more in favour of going with the consensus from the last DevSummit and using symbol versioning properly and move them all into the FBSD_1.0 namespace. > Also, the ABI of the libc now depends on the compiler which was used to > build the library, which is also wrong and ugly. No it doesn't. Read the patch. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib
s
+.Fn scandir ,
+but takes blocks as arguments instead of function pointers and calls
+.Fn qsort_b
+rather than
+.Fn qsort .
.Sh DIAGNOSTICS
Returns \-1 if the directory cannot be opened for reading or if
.Xr malloc 3
Modified: head/lib/libc/gen/scandir.c
==
--- head/lib/libc/gen/scandir.c Wed Apr 2 15:56:11 2014(r264041)
+++ head/lib/libc/gen/scandir.c Wed Apr 2 16:07:48 2014(r264042)
@@ -46,6 +46,17 @@ __FBSDID("$FreeBSD$");
#include
#include "un-namespace.h"
+#ifdef I_AM_SCANDIR_B
+#include "block_abi.h"
+#defineSELECT(x) CALL_BLOCK(select, x)
+#ifndef __BLOCKS__
+void
+qsort_b(void *, size_t, size_t, void*);
+#endif
+#else
+#defineSELECT(x) select(x)
+#endif
+
static int alphasort_thunk(void *thunk, const void *p1, const void *p2);
/*
@@ -60,9 +71,15 @@ static int alphasort_thunk(void *thunk,
(((dp)->d_namlen + 1 + 3) &~ 3))
int
+#ifdef I_AM_SCANDIR_B
+scandir_b(const char *dirname, struct dirent ***namelist,
+DECLARE_BLOCK(int, select, const struct dirent *),
+DECLARE_BLOCK(int, dcomp, const struct dirent **, const struct dirent **))
+#else
scandir(const char *dirname, struct dirent ***namelist,
int (*select)(const struct dirent *), int (*dcomp)(const struct dirent **,
const struct dirent **))
+#endif
{
struct dirent *d, *p, **names = NULL;
size_t nitems = 0;
@@ -78,7 +95,7 @@ scandir(const char *dirname, struct dire
goto fail;
while ((d = readdir(dirp)) != NULL) {
- if (select != NULL && !(*select)(d))
+ if (select != NULL && !SELECT(d))
continue; /* just selected names */
/*
* Make a minimum size copy of the data
@@ -111,8 +128,12 @@ scandir(const char *dirname, struct dire
}
closedir(dirp);
if (nitems && dcomp != NULL)
+#ifdef I_AM_SCANDIR_B
+ qsort_b(names, nitems, sizeof(struct dirent *), (void*)dcomp);
+#else
qsort_r(names, nitems, sizeof(struct dirent *),
&dcomp, alphasort_thunk);
+#endif
*namelist = names;
return (nitems);
Added: head/lib/libc/gen/scandir_b.c
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/lib/libc/gen/scandir_b.c Wed Apr 2 16:07:48 2014
(r264042)
@@ -0,0 +1,29 @@
+/*-
+ * Copyright (c) 2014 David Chisnall
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * $FreeBSD$
+ */
+#define I_AM_SCANDIR_B
+#include "scandir.c"
Added: head/lib/libc/include/block_abi.h
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/lib/libc/include/block_abi.h Wed Apr 2 16:07:48 2014
(r264042)
@@ -0,0 +1,63 @@
+/*-
+ * Copyright (c) 2014 David T Chisnall
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PR
svn commit: r264038 - head/lib/libc/locale
Author: theraven
Date: Wed Apr 2 11:10:46 2014
New Revision: 264038
URL: http://svnweb.freebsd.org/changeset/base/264038
Log:
Fix an issue where the locale and rune locale could become out of sync,
causing mb* functions (and similar) to be called with the wrong data
(possibly a null pointer, causing a crash).
PR: standards/188036
MFC after:1 week
Modified:
head/lib/libc/locale/setrunelocale.c
head/lib/libc/locale/xlocale.c
Modified: head/lib/libc/locale/setrunelocale.c
==
--- head/lib/libc/locale/setrunelocale.cWed Apr 2 10:57:11 2014
(r264037)
+++ head/lib/libc/locale/setrunelocale.cWed Apr 2 11:10:46 2014
(r264038)
@@ -202,6 +202,8 @@ __set_thread_rune_locale(locale_t loc)
if (loc == NULL) {
_ThreadRuneLocale = &_DefaultRuneLocale;
+ } else if (loc == LC_GLOBAL_LOCALE) {
+ _ThreadRuneLocale = 0;
} else {
_ThreadRuneLocale = XLOCALE_CTYPE(loc)->runes;
}
Modified: head/lib/libc/locale/xlocale.c
==
--- head/lib/libc/locale/xlocale.c Wed Apr 2 10:57:11 2014
(r264037)
+++ head/lib/libc/locale/xlocale.c Wed Apr 2 11:10:46 2014
(r264038)
@@ -154,23 +154,24 @@ __get_locale(void)
static void
set_thread_locale(locale_t loc)
{
+ locale_t l = (loc == LC_GLOBAL_LOCALE) ? 0 : loc;
_once(&once_control, init_key);
- if (NULL != loc) {
- xlocale_retain((struct xlocale_refcounted*)loc);
+ if (NULL != l) {
+ xlocale_retain((struct xlocale_refcounted*)l);
}
locale_t old = pthread_getspecific(locale_info_key);
- if ((NULL != old) && (loc != old)) {
+ if ((NULL != old) && (l != old)) {
xlocale_release((struct xlocale_refcounted*)old);
}
if (fake_tls) {
- thread_local_locale = loc;
+ thread_local_locale = l;
} else {
- pthread_setspecific(locale_info_key, loc);
+ pthread_setspecific(locale_info_key, l);
}
#ifndef __NO_TLS
- __thread_locale = loc;
+ __thread_locale = l;
__set_thread_rune_locale(loc);
#endif
}
@@ -361,9 +362,6 @@ locale_t uselocale(locale_t loc)
{
locale_t old = get_thread_locale();
if (NULL != loc) {
- if (LC_GLOBAL_LOCALE == loc) {
- loc = NULL;
- }
set_thread_locale(loc);
}
return (old ? old : LC_GLOBAL_LOCALE);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r263778 - in head: bin lib lib/clang sbin share/mk usr.bin usr.sbin
On 26 Mar 2014, at 22:30, Dimitry Andric wrote: > Add a SUBDIR_PARALLEL option to bsd.subdir.mk, to allow make to process > all the SUBDIR entries in parallel, instead of serially. Apply this > option to a selected number of Makefiles, which can greatly speed up the > build on multi-core machines, when using make -j. THANK YOU! That's really excellent. We can probably parallelise pretty much all of usr.lib and usr.bin as well, but going from using 8 cores to 17 is a very nice improvement. This should help tinderbox / Jenkins build a LOT! David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r262810 - in head: release release/arm release/tools share/man/man7
On 6 Mar 2014, at 17:47, Glen Barber wrote: > On Thu, Mar 06, 2014 at 04:37:11PM +0000, David Chisnall wrote: >> On 5 Mar 2014, at 23:17, Glen Barber wrote: >> >>> After several months of testing and fixing (and breaking) >>> various parts of release/release.sh changes, it is now >>> possible to build FreeBSD/arm images as part of the release >>> process. >> >> That's great! How much effort would it be to add QEMU images for >> ARM and MIPS images to the things that we build by default? I'd >> love to see these built for ARM and MIPS as part of the Jenkins >> builds and for releases. >> > > It should be fairly trivial, however I've never had luck getting qemu to > run non-x86 images. Maybe I am doing it wrong, though. Stacey may be able to help there. I think he did some FreeBSD/MIPS-on-QEMU testing with the system emulation mode before working on the user-mode emulation. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r262810 - in head: release release/arm release/tools share/man/man7
On 5 Mar 2014, at 23:17, Glen Barber wrote: > After several months of testing and fixing (and breaking) > various parts of release/release.sh changes, it is now > possible to build FreeBSD/arm images as part of the release > process. That's great! How much effort would it be to add QEMU images for ARM and MIPS images to the things that we build by default? I'd love to see these built for ARM and MIPS as part of the Jenkins builds and for releases. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil
On 25 Feb 2014, at 07:52, Baptiste Daroussin wrote: > On Tue, Feb 25, 2014 at 05:22:22PM +1100, Peter Jeremy wrote: >> On 2014-Feb-22 13:14:38 +0100, Baptiste Daroussin wrote: >>> On Sat, Feb 22, 2014 at 07:23:50PM +1100, Peter Jeremy wrote: I'd also query the reason for including Debian-specific code in the FreeBSD base. >> >>> Where have you seen debian specific code? >> >> /usr/src/contrib/dma/debian - as far as I can tell, this directory is >> Debion specific. I thought we stripped out irrelevant code from third >> party imports but looking wider, there is similarly irrelevant code in >> a variety of other contrib imports. I'll withdraw that objection. >> >> -- >> Peter Jeremy > > Have you already looked at how contrib works? who cares FYI you can also find > some win32 specific code in there, debian packaging code, rpm spec files etc. For the libc++ imports, we strip out the support directory, which contains Solaris and Win32-specific stuff. If we end up with a support/freebsd, then we'll bring that in, but not support/solaris and support/win32. That stuff is in the vendor branch, but it just seems polite not to make people who check out head get files that are never used when building FreeBSD in any configuration. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r262394 - head/usr.bin/dtc
Author: theraven
Date: Sun Feb 23 21:13:07 2014
New Revision: 262394
URL: http://svnweb.freebsd.org/changeset/base/262394
Log:
Fix parsing multiple roots with whitespace between them.
Patch by: Patrick Wildt
Modified:
head/usr.bin/dtc/fdt.cc
Modified: head/usr.bin/dtc/fdt.cc
==
--- head/usr.bin/dtc/fdt.cc Sun Feb 23 21:13:04 2014(r262393)
+++ head/usr.bin/dtc/fdt.cc Sun Feb 23 21:13:07 2014(r262394)
@@ -1059,6 +1059,7 @@ device_tree::parse_roots(input_buffer &i
{
valid = false;
}
+ input.next_token();
}
}
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r261916 - head/sys/dev/xen/console
On 16 Feb 2014, at 04:09, Bruce Evans wrote: > [a long list of corner cases where the warning may not be correct] Fortunately, the goal of compiler warnings is not to address every possible case, but rather to minimise false positives while still giving useful results. The warning can be turned off if you are using the C preprocessor in a way designed to provide cautionary tales to young programmers, but for everyone else it makes sense to have it on by default. Anyone using a single file as both the main file for a compilation unit and as an included file in others, deserves to have a new antipattern named after them so that their name can live in infamy, but should not in any way be allowed to influence the design of compiler warnings. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r261916 - head/sys/dev/xen/console
On 15 Feb 2014, at 17:02, Bruce Evans wrote: > Why? There are hundreds if not thousands of static inline functions in > headers, and most of these functions are not always used, so there would > be [hundreds if not thousands] * [number of #includes] compiler warnings > if compilers warned about things like this. They could handle include > files specially, but shouldn't. They do, and absolutely should, handle include files separately. If you have a static inline function in a header that is not used in a specific compilation unit, then that is a little bit of extra work for the compiler as it has to parse it without it being used, but it is not a problem. It is a safe assumption that it is used by at least one compilation unit and so is not dead code (and even if it isn't yet, it is part of an API, and so removing it would be an error). In contrast, a static inline function in the main source file for a compilation unit is definitely a bug. It is obviously dead code. It is likely that it either should have been removed when all callers were deleted, or should not have been static but accidentally was. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r261801 - head/contrib/libc++/include
On 13 Feb 2014, at 01:04, Alexander Kabaev wrote: > The refusal to use tools that are there precisely to help to help with > the binary compatibility in favor of mindless library bumps is just sad. Perhaps you could share with the class. What is the correct way of solving this problem? For those just joining the discussion, the issue is that std::pair was originally declared with an explicit constructor and should have an implicit constructor, which has a different calling convention. This means that we can't share the two std::pair implementations across libraries, because they will try to call the constructor with the wrong arguments. Because of templates and C++ name mangling, this ends up being propagated into most libraries that link against libc++, and calling from one with the old definition to one with the new definition end up causing segfaults (if we're lucky - I think the symptom that we're seeing is actually dereferencing a junk value in a register, so it may cause random memory writes, but I'd have to check the ABI). Given that neither redeclaring the new std::pair in a new namespace, nor exporting both constructor symbols using symbol versioning (the two approaches that we've already discussed) will work, what are the tools that apparently we're refusing to use that will work? David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r261801 - head/contrib/libc++/include
On 12 Feb 2014, at 18:42, Jung-uk Kim wrote: > It seems Apple removed it later. > > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131125/094181.html > > Do you know what they did? They decided to break ABI compatibility with the version of XCode that ships with the bug. This is probably not an option for us, although we might consider it for FreeBSD 11 with a library version bump (it would still be a lot of pain, as you wouldn't be able to mix C++ libraries), but probably not unless we see bug reports related to our slight standards non-compliance (std::pair having an explicit constructor) causing real problems. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r261283 - in head: contrib/libc++ contrib/libc++/include contrib/libc++/include/experimental contrib/libc++/include/ext contrib/libc++/src etc/mtree lib/libc++ sys/sys tools/build/mk
On 3 Feb 2014, at 22:00, Alexander Kabaev wrote: > At the very least, new library did remove > _ZNKSt3__111__libcpp_db12__comparableEPKvS2_ which was public before. This symbol is part of the debugging infrastructure and is used when you build your code with aggressive debug checks by defining _LIBCPP_DEBUG2 when you build your code. It is not intended for deployment builds and so is not part of the stable API. You can only access it by explicitly enabling debug builds. > Your definition of ABI stability might be different from mine, but in > my book that counts as a backward compatibility breakage. And even if > that symbol was not supposed to be lined to by anyone, it should not > have been exported in the first place. It sounds like you're just looking at the output from nm, without bothering to check how the symbols are used. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r261283 - in head: contrib/libc++ contrib/libc++/include contrib/libc++/include/experimental contrib/libc++/include/ext contrib/libc++/src etc/mtree lib/libc++ sys/sys tools/build/mk
On 3 Feb 2014, at 18:32, Alexander Kabaev wrote: > More than likely. It does appear libc++ does not go through same pains > to maintain ABI stable as libstdc++ does. The lack of all and any > symbol versions in shared library binary strongly suggests that not > only they do not bother with ABI stability, they simply can't enforce > it at the moment even if they wanted to. libc++ aims to provide a stable ABI, however it does so in a manner that is intended to integrate with the source language, rather than by applying linker hacks post facto (which is very hard to do write with C++). Every std:: class in libc++ is implemented inside a version namespace inside std, and then imported into std:: in the header. ABI-breaking classes should be inside a new version namespace. If you have examples where the ABI was not accidentally changed, then please report them as bugs and we will try to fix them. If you just have unfounded supposition, then it is not helpful to the discussion. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r261031 - in head: . etc usr.sbin/etcupdate usr.sbin/mergemaster
On 22 Jan 2014, at 22:36, Glen Barber wrote: > It needs to use the build host version, because using (for example) > powerpc resulting binary won't work on and amd64 system. If it's used as part of the build, then it should be part of the toolchain target and we should be using the version built there. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
