Re: nginx introduces extra delay when talking to slow backend (probably FreeBSD kevent specific)
* Dmitry Marakasov (amd...@amdmi3.ru) wrote:
I've gathered ktrace dumps for both cases, and it really looks that
the problem is related to kevent. After nginx sends response back
to client, it calls kevent(2) on client fd (which is 5).
When there is a bug (FreeBSD 11.2), the following happens:
49365 nginx3.099362 CALL
kevent(0x7,0x8022a2000,0,0x8023005c0,0x200,0x7fffe598)
49365 nginx3.099419 STRU struct kevent[] = { }
49365 nginx3.194695 STRU struct kevent[] = { { ident=5,
filter=EVFILT_WRITE, flags=0x20, fflags=0, data=0xbf88,
udata=0x8023633d1 } }
49365 nginx3.194733 RET kevent 1
...
49365 nginx3.194858 CALL
kevent(0x7,0x8022a2000,0,0x8023005c0,0x200,0x7fffe598)
49365 nginx3.194875 STRU struct kevent[] = { }
49365 nginx3.835259 STRU struct kevent[] = { { ident=5,
filter=EVFILT_READ, flags=0x8020, fflags=0, data=0,
udata=0x802346111 } }
49365 nginx3.835299 RET kevent 1
E.g. read and write events come separately, both with huge delays.
On FreeBSD-CURRENT which doesn't experience the problem, kdump looks this way:
8049 nginx3.081367 CALL
kevent(0x7,0x8012d1b40,0,0x8012da040,0x200,0x7fffe598)
8049 nginx3.081371 STRU struct kevent[] = { }
8049 nginx3.081492 STRU struct kevent[] = { { ident=5,
filter=EVFILT_WRITE, flags=0x20, fflags=0, data=0xbf88,
udata=0x801341f11 }
{ ident=5, filter=EVFILT_READ, flags=0x8020,
fflags=0, data=0, udata=0x801324e51 } }
8049 nginx3.081498 RET kevent 2
E.g. both events come immediately and at the same time.
Not sure if that's problem of kevent or something it relies on or the
way nginx uses it.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: https://github.com/AMDmi3
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
nginx introduces extra delay when talking to slow backend (probably FreeBSD kevent specific)
Hi! I've noticed strange behavior of nginx with slow uwsgi backend (turned out to not be uwsgi specific, and acually reproduces with any backend) on FreeBSD 11.2 If backend replies in less than a second, nginx doesn't introduce any additional latency and replies in the same time. However if backend replies no more than around 1.2 seconds, nginx introduces an extra delay and replies in around 2.2 seconds. I've gathered some details here, including the graph of nginx reply time vs. backend reply time: https://github.com/AMDmi3/nginx-bug-demo It reproduces on FreeBSD 11.2 and around year old -CURRENT, but not the recent -CURRENT, so I suspect this may be FreeBSD specific (probably kevent-related) and already fixed. Still, I'm posting to both related nginx and FreeBSD lists for this problem to be known. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: https://github.com/AMDmi3 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[bmake] bmake sigint handling causing tty corruption
"ioctl(1, TIOCGETA) -> %d / %s\n", ret,
strerror(errno));
pid_t p = fork();
if (p > 0) {
// parent would die from SIGTERM early
kill(getpid(), SIGTERM);
} else if (p == 0) {
// child tries to restore terminal state with some delay
usleep(1000);
// because parent is dead now, this will fail with EIO
ret = ioctl(1, TIOCSETAW, );
fprintf(stderr, "ioctl(1, TIOCSETAW) -> %d / %s\n", ret,
strerror(errno));
}
return 0;
}
---
Now to fix this, I suggest that instead of killing itself, make should
signal all its childs carefully and wait() on them, only then die
itself.
Now after a quick glance at bmake sources it seems like the jobs control
code
https://svnweb.freebsd.org/base/head/contrib/bmake/job.c?revision=317239=markup#l2633
does the very same thing that I've just described, however bmake is run
in compat mode by default, and CompatInterrupt does exactly what ktrace
shows - it just kills itself.
https://svnweb.freebsd.org/base/head/contrib/bmake/compat.c?revision=310304=markup#l180
So, to fix this problem it seems that CompatInterrupt should be improved
as described above.
Also wanted to ask kib@, ian@ (as recent committers to tty.c) it this
behavior of tty layer is correct and if it could be improved.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ru http://amdmi3.ru
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Keeping OptionalObsoleteFiles.inc up to date
* Ngie Cooper (yaneurab...@gmail.com) wrote:
> > I'm trying to use "make delete-old" specifying WITHOUT_ keyword for
> > removing some no-more used set of files.
> >
> > I've start by testing WITHOUT_TOOLCHAIN:
> > - Some of files related to clang are correctly delete
> > - But there are still lot's of others (like /usr/bin/cc)
> >
> > Then I've checked tools/build/mk/OptionalObsoleteFiles.in and found that
> > lot's files are missing in the ".if ${MK_TOOLCHAIN} == no" section.
> >
> > I've started a new run of phk's build_options_survey script:
> > https://people.freebsd.org/~olivier/build_option_survey_20160406/
> >
> > And wonder if it's possible to automatically generate the list of
> > conditional files to be put in OptionalObsoleteFiles.in from the result of
> > a build_option_survey script ?
>
> amdmi3 had a method for doing this, but I think it was a bit of a
> brute force approach (I could be wrong).
You are not.
https://github.com/AMDmi3/obsolete-files-checker
> The release-pkg project branch method seems like the best way to go
> about it though because it would kind of do the sanity checking for
> us...
Agreed. make delete-old + OptionalObsoleteFiles.in will never be
complete and work correctly. I'm waiting for packaged base too.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ru http://amdmi3.ru
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for testing: Using ELF Tool Chain elfcopy as objcopy
* Ed Maste (ema...@freebsd.org) wrote: JFYI, I've just updated my desktop to 295763 with WITH_ELFCOPY_AS_OBJCOPY=yes, and rebuilt all ~800 installed ports, no problems so far. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ru http://amdmi3.ru ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Implement base NLS catalog conversion from 8bit locales to utf-8
* Dmitry Marakasov (amd...@amdmi3.ru) wrote: I've just noticed that though we have NLS files for 8bit locales: # ls /usr/share/nls/ru_RU.KOI8-R/ ee.catgrep.catlibc.cattcsh.cat we don't for UTF-8: # ls /usr/share/nls/ru_RU.UTF-8/ tcsh.cat Seemingly this is easily fixable by just converting catalogs with iconv which we have in base system. Could anyone give me a hint on how it's better to implement this, as I'd like to. I've implemented this. See https://reviews.freebsd.org/D2232 -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ru http://amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Implement base NLS catalog conversion from 8bit locales to utf-8
Hi! I've just noticed that though we have NLS files for 8bit locales: # ls /usr/share/nls/ru_RU.KOI8-R/ ee.cat grep.catlibc.cattcsh.cat we don't for UTF-8: # ls /usr/share/nls/ru_RU.UTF-8/ tcsh.cat Seemingly this is easily fixable by just converting catalogs with iconv which we have in base system. Could anyone give me a hint on how it's better to implement this, as I'd like to. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ru http://amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: OptionalObsoleteFiles.inc completeness improvement, try 2
* Dmitry Marakasov (amd...@amdmi3.ru) wrote:
The patch is complete, see https://reviews.freebsd.org/D1600.
- With it, for all knobs from src.conf(5) there are no difference in
file tree contents between `KNOB make installworld` and `make
installworld KNOB make delete-old delete-old-libs`
- Note that some OLD_DIRS were removed - they were incorrect as most
directories are installed unconditionally by mtree. Since empty
directores are not really needed, the install process should be
probably improved
- Some knobs which delete massive number of files (WITHOUT_MAN,
WITHOUT_INCLUDES) were implemented with
FILES!=find ...
OLD_FILES+=${FILES}
(similar construct was already used in WITHOUT_TESTS)
I though of more effective implementation for this, such as
introducing OLD_DIRS_RECURSIVE to fill from OptionalObsoleteFiles,
in which delete-old will just call `find ... -delete`
- Unneeded conditions such as
.if ${TARGET_ARCH} == amd64 || ${TARGET_ARCH} == powerpc64
OLD_FILES+=usr/lib32/...
.else
were not removed yet. Maybe with the next patch.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: OptionalObsoleteFiles.inc completeness improvement, try 2
* Garrett Cooper (yaneurab...@gmail.com) wrote: Hi Dmitry, Seems like we’ve duplicated work a bit. Have you looked at ^/projects/building-blocks yet ? Hm, seems so, partly. How do you gather missing entries? My way is pretty dumb, I just do bunch of installworlds + delete-old's and add diff to the file, you probably do it more cleverly. Will committing my changes interfere with your work? If so, it may be better to direct them to your branch instead. Especially if you are more aware of knob combinations and their effects. I wrote this script to track what files get installed by directories: https://svnweb.freebsd.org/base/projects/building-blocks/tools/add-optional-obsolete-files-entries.sh?revision=275238view=markup . It’s not perfect (doesn’t work for “kitchen sink” directories like etc/ and share/…), but it’s a reasonable starting point for grabbing all of the files. I’m going to hold off on the rc.d deletions/rewrites for dependent services after I do more targeted review/testing, as it might screw up boot order in unexpected ways with services and programs that get run out of order, but I’m reasonably confident that the contents of the branch work. I was going to start cherry-picking changes from the branch this weekend. Forgot to respond on one important point: reviewing and committing the higher-level changes (make remove-old) shouldn’t be a problem, and I’ll be sure to commit the overlapping changes with OptionalObsoleteFiles.inc first to reduce the diff between our branches. Thanks! Okay, the I'll just go on. Nice to know it's useful. Note that the branch may have bugs as on the first run I just extend it, and it's tested on another run, while run takes couple of days on the box I use. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: OptionalObsoleteFiles.inc completeness improvement, try 2
* Dmitry Marakasov (amdmi3@hades.panopticon) wrote:
Also there is a question of delete-old-dirs removing directories
which are created by mtree run by installworld unconditionally.
This seems to be incorrect - either directories should be installed
conditionally or not removed by delete-old-dirs. My patch will
address this issue as well, by not remiving unconditionally installed
dirs.
I'd really like to hear opinions on this.
Another issue is conditional lib32 files:
.if ${MK_ATM} == no
...
.if ${TARGET_ARCH} == amd64 || ${TARGET_ARCH} == powerpc64
...
.endif
...
.endif
I think that this may be simplified by dropping internal condition - it
won't change behavior for end-user.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: OptionalObsoleteFiles.inc completeness improvement, try 2
* Garrett Cooper (yaneurab...@gmail.com) wrote: Some years ago I've started a project of improving OptionalObsoleteFiles.inc completeness, which allows make delete-old / delete-old-libs / delete-old-dirs targets completelty remove files which are normally installed when specific src.conf WITHOUT_* knobs are set. In other words, if a user has some WITHOUT_* set in src.conf, specific files are not installed by installworld, but not removed by remove-old, which I try to fix. In yet other words, I want to make it so `make installworld -DWITHOUT_foo=yes` and `make installworld make delete-old -DWITHOUT_foo=yes` result in the very same file sets. Though the project seems to be useful and have real demand (added to IdeasPage by netchild@, though removed later by brooks@ [1]) and interest ([2]), the change was ignored back then and now the patch is completely rotten. I can redo it, but I need a reviewer. Here's a first small part of the patch: https://reviews.freebsd.org/D1600 The WIP branch with other changes is [3] Also there is a question of delete-old-dirs removing directories which are created by mtree run by installworld unconditionally. This seems to be incorrect - either directories should be installed conditionally or not removed by delete-old-dirs. My patch will address this issue as well, by not remiving unconditionally installed dirs. [1] https://wiki.freebsd.org/action/diff/IdeasPage?action=diffrev1=260rev2=261 [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=168341#c6 [3] https://github.com/AMDmi3/freebsd/compare/obsolete-files Hi Dmitry, Seems like we’ve duplicated work a bit. Have you looked at ^/projects/building-blocks yet ? Hm, seems so, partly. How do you gather missing entries? My way is pretty dumb, I just do bunch of installworlds + delete-old's and add diff to the file, you probably do it more cleverly. Will committing my changes interfere with your work? If so, it may be better to direct them to your branch instead. Especially if you are more aware of knob combinations and their effects. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
OptionalObsoleteFiles.inc completeness improvement, try 2
Hi! Some years ago I've started a project of improving OptionalObsoleteFiles.inc completeness, which allows make delete-old / delete-old-libs / delete-old-dirs targets completelty remove files which are normally installed when specific src.conf WITHOUT_* knobs are set. In other words, if a user has some WITHOUT_* set in src.conf, specific files are not installed by installworld, but not removed by remove-old, which I try to fix. In yet other words, I want to make it so `make installworld -DWITHOUT_foo=yes` and `make installworld make delete-old -DWITHOUT_foo=yes` result in the very same file sets. Though the project seems to be useful and have real demand (added to IdeasPage by netchild@, though removed later by brooks@ [1]) and interest ([2]), the change was ignored back then and now the patch is completely rotten. I can redo it, but I need a reviewer. Here's a first small part of the patch: https://reviews.freebsd.org/D1600 The WIP branch with other changes is [3] Also there is a question of delete-old-dirs removing directories which are created by mtree run by installworld unconditionally. This seems to be incorrect - either directories should be installed conditionally or not removed by delete-old-dirs. My patch will address this issue as well, by not remiving unconditionally installed dirs. [1] https://wiki.freebsd.org/action/diff/IdeasPage?action=diffrev1=260rev2=261 [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=168341#c6 [3] https://github.com/AMDmi3/freebsd/compare/obsolete-files -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: Please help testing the llvm/clang 3.5.0 import
* Dimitry Andric (d...@freebsd.org) wrote: We're working on updating llvm, clang and lldb to 3.5.0 in head. This is quite a big update again, and any help with testing is appreciated. Well, of 4 error logs from exp-run I've checked (one my port and 3 unmaintained ports) two had basically the same problem and it seems to be libc++ related, so I ask: was new version of libc++ imported along with clang/llvm? No, I really prefer to do this after the 3.5.0 import. This is already a very big import job, and I'd rather like to avoid importing too many different components at once. Past experience show that libc++ should be updated along with clang, as it may have bugs new clang versions are not tolerable to. In this case, there is a fairly simple fix: http://llvm.org/viewvc/llvm-project?view=revisionrevision=209785 I have pulled this into head in r275366, and also merged it to the clang350-import project branch in r275367. Please try again after that revision. It should be enough to just rebuild lib/libc++ and install it. Sorry, I haven't tested the branch myself, only seen exp-run results. Would be nice to have another exp-run. Btw, is it possible to merge the patch into stable/10 as well? It will make it possible to use clang35 there. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: Please help testing the llvm/clang 3.5.0 import
' operator()(_Args ...__args) ^ /usr/include/c++/v1/functional:2092:9: note: candidate template ignored: substitution failure [with _Args = ]: implicit instantiation of undefined template 'std::__1::__bind_returnvoid (Foo::*const)() const, const std::__1::tupleFoo, std::__1::tuple, false' operator()(_Args ...__args) const ^ 2 errors generated. --- test.log ends here --- I think this should be fixed in the first place. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD-11.0-CURRENT on ARM: performance and load average
* Maxim V FIlimonov (c...@bein.link) wrote: Recently, I encountered a problem with -CURRENT on an ARM board (cubieboard2 to be precise). The problem was that the load average was above 2. Including the fact that the board has 2 CPU cores, that's strange. Also, the network throughput was way too slow: from 3 kilobytes per second earlier to 20..50 about now. Here's a workaround for that: sysctl kern.eventtimer.periodic=1 With that, the network performance increased while LA decreased to a decent 0.3..0.5. I'm just started to experiment with cubieboard (1) as well. I've also noticed poor network performance at first, however later (without any tuning) it gave out 111 kBps. kern.eventtimer.periodic doesn't seem to affect it. I've also played with clocks a bit, and was able to increase CPU rate 3x by configuring PLL1. I've experienced some instability later (board doesn't always boot from USB, perl build fails), and now I'm checking if reclocking was the cause. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: System libc++ isn't fully compatible with clang 3.4 from ports
* Dimitry Andric (d...@freebsd.org) wrote: JFYI, I've just ran into shortcoming of libc++ from 10-RELEASE when used with clang 3.4 from ports: ... The cause: http://llvm.org/bugs/show_bug.cgi?id=17798, was fixed in libc++ r194154. We probably need to update libc++ or at least backport this into stable branches if we want to support clang 3.4 in ports. Hm, which port is having problems with this? I have built quite a large set, and never encountered this issue. In any case: yes, it is quite long overdue for a libc++ update. :-) I will have a look tonight. New version of games/spring (not in ports yet). std::function and lambdas are not that widely used for this problem to be common, but some time we may run into it for some critical software. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
libm lacks C99 functions - no c++11 cmath in libstdc++
Hi!
Gerald haven't responded yet, so I though I'd better post in on the
list as well for wider discussion.
In short:
- our libm lacks some C99 functions: erfl erfcl lgammal tgammal
- bad enough by itself, it affects libstdc++ from ports' gcc in such a
way that it disables C++11 math completely (along with a lot more
other more widely used math functions)
- we may probably implement these by calling less-precise
erf erfc lgamma tgamma as we do with other functions as we alredy
do with some others
- Forwarded message from Dmitry Marakasov amdmi3@hades.panopticon -
Date: Tue, 21 Jan 2014 19:13:07 +0400
From: Dmitry Marakasov amdmi3@hades.panopticon
To: ger...@freebsd.org
Subject: libstdc++ from ports' gcc's and cmath
Hi!
I've was just curious why one of my ports doesn't build on 10.x and
found the following:
This code:
---
#include cmath
int main() { std::hypot(3.0, 4.0); }
---
won't build even with latest gcc:
---
% g++49 -std=c++11 2.cc
2.cc: In function 'int main()':
2.cc:2:14: error: 'hypot' is not a member of 'std'
int main() { std::hypot(3.0, 4.0); }
^
2.cc:2:14: note: suggested alternative:
In file included from /usr/local/lib/gcc49/include/c++/cmath:44:0,
from 2.cc:1:
/usr/include/math.h:276:8: note: 'hypot'
double hypot(double, double);
^
---
Why's std::hypot not defined?
--- /usr/local/lib/gcc49/include/c++/cmath
...
#ifdef _GLIBCXX_USE_C99_MATH_TR1
...
namespace std _GLIBCXX_VISIBILITY(default)
{
...
constexpr float
hypot(float __x, float __y)
{ return __builtin_hypotf(__x, __y); }
constexpr long double
hypot(long double __x, long double __y)
{ return __builtin_hypotl(__x, __y); }
templatetypename _Tp, typename _Up
constexpr typename __gnu_cxx::__promote_2_Tp, _Up::__type
hypot(_Tp __x, _Up __y)
{
typedef typename __gnu_cxx::__promote_2_Tp, _Up::__type __type;
return hypot(__type(__x), __type(__y));
}
---
As you can see, it's hidden under _GLIBCXX_USE_C99_MATH_TR1.
What if I define _GLIBCXX_USE_C99_MATH_TR1?
---
% g++49 -std=c++11 2.cc
In file included from 2.cc:1:0:
/usr/local/lib/gcc49/include/c++/cmath:1064:11: error: '::erfl' has not been
declared
using ::erfl;
^
/usr/local/lib/gcc49/include/c++/cmath:1068:11: error: '::erfcl' has not been
declared
using ::erfcl;
^
/usr/local/lib/gcc49/include/c++/cmath:1104:11: error: '::lgammal' has not been
declared
using ::lgammal;
^
/usr/local/lib/gcc49/include/c++/cmath:1176:11: error: '::tgammal' has not been
declared
using ::tgammal;
^
---
That's the very reason _GLIBCXX_USE_C99_MATH_TR1 is not defined:
libstdc++ configure checks for availability of all C99 math functions in
our math library, doesn't find these four and disable whole C99 math
set.
libstdc++ works this around by using lower-precision variants (e.g.
erf instead of erfl) and issues a warning on linking.
So I wonder: could libstdc++ be made more usable for C++11 code in some
way? That's crucial for pre-clang FreeBSD branches which will live for
quite some time, and this is useful for gcc users on post-clang world.
The simple solution would be to disable named 4 functions, but make all
others available. The better would be to do what libc++ does, with
corresponding warnings.
What do you think?
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
- End forwarded message -
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [OT] ta-spring
* Michael Schmiedgen (schmied...@gmx.net) wrote: Hm, which port is having problems with this? I have built quite a large set, and never encountered this issue. In any case: yes, it is quite long overdue for a libc++ update. :-) I will have a look tonight. New version of games/spring (not in ports yet). Can we expect a current version of spring in ports soon? That would be nice! Yes and no. The port is ready, however it's unstable - it crashes on start in most cases, however if it doesn't crash on start, it'll work without problems. I don't think that's suitable for ports, but since 94.1 which is currently in ports has build problems, it may be least of two evils. For now, the port is available for testing here: https://github.com/AMDmi3/freebsd-ports/tree/master/games/spring AFAIK newer versions require OpenMP. Will this compile with our (new 3.4 soon) base clang? It compiles fine, so either they doesn't use OpenMP or it's optional, haven't investigated. The cause for clang 3.4 experiments is the instability mentioned above. Disassembly shows that it crashes on thread-local storage access because a null pointer is used as TLS location for some reason. I though that it may be a clang 3.3 miscompilation and tried 3.4, but there's that libc++ problem. We can't also build it with GCC, as it depends on boost which is built with clang and is thus incompatible with GCC-generated code. GCC has another problem, see my following forwarded mail, but that can be circumvented in spring code. My current plans are: 1) Try to patch system libc++ and try 3.4 again to check if that's clang 3.3 specific, however that won't help the port anyway as I libc++ can't be patched on all 10.0 systems. 2) Try to debug TLS access further. That'd be quite painstaking. 3) Write to clang maillist, maybe it's a known problem -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libm lacks C99 functions - no c++11 cmath in libstdc++
* Steve Kargl (s...@troutmask.apl.washington.edu) wrote: - bad enough by itself, it affects libstdc++ from ports' gcc in such a way that it disables C++11 math completely (along with a lot more other more widely used math functions) - we may probably implement these by calling less-precise erf erfc lgamma tgamma as we do with other functions as we alredy do with some others This, unfortuantely, has already been done, although it may only be available in FreeBSD-current. See src/lib/msun/src/imprecise.c. I know, it's available on 10.0 as well. However that's not the case for 9.x, for which it's impossible to build c++11 math using software (even if it doesn't use unimplemented functions), neither with system gcc nor with gcc from ports. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libm lacks C99 functions - no c++11 cmath in libstdc++
* Steve Kargl (s...@troutmask.apl.washington.edu) wrote:
- bad enough by itself, it affects libstdc++ from ports' gcc in such a
way that it disables C++11 math completely (along with a lot more
other more widely used math functions)
- we may probably implement these by calling less-precise
erf erfc lgamma tgamma as we do with other functions as we alredy
do with some others
This, unfortuantely, has already been done, although it may only
be available in FreeBSD-current. See src/lib/msun/src/imprecise.c.
I know, it's available on 10.0 as well. However that's not the case for
9.x, for which it's impossible to build c++11 math using software (even
if it doesn't use unimplemented functions), neither with system gcc
nor with gcc from ports.
It's not impossible. Add whatever C++-fu you need
that is equivalent to
#include math.h
#ifndef fool
#define fool(x) foo((double)(x))
#endif
The point was that one should not be required to do something like this
to build std::hypot - using software on FreeBSD.
---
+#define _GLIBCXX_USE_C99_MATH_TR1
+#include math.h
+long double erfl(long double x) { return erf(x); }
+long double erfcl(long double x) { return erfc(x); }
+long double lgammal(long double x) { return lgamma(x); }
+long double tgammal(long double x) { return tgamma(x); }
+
#include cmath
int main() { std::hypot(3.0, 4.0); }
---
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
System libc++ isn't fully compatible with clang 3.4 from ports
Hi!
JFYI, I've just ran into shortcoming of libc++ from 10-RELEASE when used
with clang 3.4 from ports:
---
% cat test.cc
#include iostream
#include functional
int main() {
std::functionvoid() f = []() { std::cerr test\n; };
return 0;
}
% clang++ -std=c++11 test.cc ---
% clang++34 -std=c++11 test.cc ---
In file included from test.cc:1:
In file included from /usr/include/c++/v1/iostream:38:
In file included from /usr/include/c++/v1/ios:216:
In file included from /usr/include/c++/v1/__locale:15:
In file included from /usr/include/c++/v1/string:434:
In file included from /usr/include/c++/v1/algorithm:627:
In file included from /usr/include/c++/v1/memory:603:
/usr/include/c++/v1/tuple:320:11: error: rvalue reference to type 'lambda at
test.cc:5:28' cannot bind to lvalue of type 'lambda at test.cc:5:28'
: value(__t.get())
^ ~
/usr/include/c++/v1/tuple:444:8: note: in instantiation of member function
'std::__1::__tuple_leaf0, lambda at test.cc:5:28 , false::__tuple_leaf'
requested here
struct __tuple_impl__tuple_indices_Indx..., _Tp...
^
/usr/include/c++/v1/functional:1286:26: note: in instantiation of member
function 'std::__1::__function::__funclambda at test.cc:5:28,
std::__1::allocatorlambda at test.cc:5:28 , void ()::__func' requested here
::new (__f_) _FF(_VSTD::move(__f));
^
test.cc:5:28: note: in instantiation of function template specialization
'std::__1::functionvoid ()::functionlambda at test.cc:5:28 ' requested
here
std::functionvoid() f = []() { std::cerr test\n; };
^
In file included from test.cc:1:
In file included from /usr/include/c++/v1/iostream:38:
In file included from /usr/include/c++/v1/ios:216:
In file included from /usr/include/c++/v1/__locale:15:
In file included from /usr/include/c++/v1/string:434:
In file included from /usr/include/c++/v1/algorithm:627:
In file included from /usr/include/c++/v1/memory:603:
/usr/include/c++/v1/tuple:321:10: error: static_assert failed Can not copy a
tuple with rvalue reference member
{static_assert(!is_rvalue_reference_Hp::value, Can not copy a tuple
with rvalue reference member);}
^
/usr/include/c++/v1/tuple:320:11: error: rvalue reference to type
'allocator[...]' cannot bind to lvalue of type 'allocator[...]'
: value(__t.get())
^ ~
/usr/include/c++/v1/tuple:444:8: note: in instantiation of member function
'std::__1::__tuple_leaf0, std::__1::allocatorlambda at test.cc:5:28 ,
false::__tuple_leaf' requested here
struct __tuple_impl__tuple_indices_Indx..., _Tp...
^
/usr/include/c++/v1/functional:1294:34: note: in instantiation of member
function 'std::__1::__function::__funclambda at test.cc:5:28,
std::__1::allocatorlambda at test.cc:5:28 , void ()::__func' requested here
::new (__hold.get()) _FF(_VSTD::move(__f), allocator_Fp(__a));
^
test.cc:5:28: note: in instantiation of function template specialization
'std::__1::functionvoid ()::functionlambda at test.cc:5:28 ' requested
here
std::functionvoid() f = []() { std::cerr test\n; };
^
In file included from test.cc:1:
In file included from /usr/include/c++/v1/iostream:38:
In file included from /usr/include/c++/v1/ios:216:
In file included from /usr/include/c++/v1/__locale:15:
In file included from /usr/include/c++/v1/string:434:
In file included from /usr/include/c++/v1/algorithm:627:
In file included from /usr/include/c++/v1/memory:603:
/usr/include/c++/v1/tuple:321:10: error: static_assert failed Can not copy a
tuple with rvalue reference member
{static_assert(!is_rvalue_reference_Hp::value, Can not copy a tuple
with rvalue reference member);}
^
4 errors generated.
---
The cause: http://llvm.org/bugs/show_bug.cgi?id=17798, was fixed in
libc++ r194154. We probably need to update libc++ or at least backport
this into stable branches if we want to support clang 3.4 in ports.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CLANG and -fstack-protector
* Kimmo Paasiala (kpaas...@gmail.com) wrote: Does the -fstack-protector option work on CLANG 3.1 and 3.2? There is thread on FreeBSD forums about the stack protector and ports and I'm wondering if it's possible to use the -fstack-protector option with CLANG. http://forums.freebsd.org/showthread.php?t=36927 You might be interested in this patch: https://github.com/AMDmi3/freebsd-ports-mk/compare/master...stack-protector afaik, in prior discussion some years ago an issue was mentioned that some ports don't build with stack-protector, so I suggested to introduce STACK_PROTECTOR_SAFE/_UNSAFE knobs similar to what we have for MAKE_JOBS_SAFE_/_UNSAFE (we might actually only need STACK_PROTECTOR_UNSAFE, as unlike MAKE_JOBS, build errors caused by enabling stack protector are not transient, so we can have an exp-run to just mark all uncompatible ports and consider all others compatible). If there's interest in this, I can refresh the patch and submit it. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: OptionalObsoleteFiles.inc completeness
* Dmitry Marakasov (amd...@amdmi3.ru) wrote: So would someone please commit it? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: OptionalObsoleteFiles.inc completeness
* Doug Barton (do...@freebsd.org) wrote: I'm running a little pet project of improving completeness of tools/build/mk/OptionalObsoleteFiles.inc file and thus delete-old* targets with regard to all possible WITHOUT_* knobs. E.g. when WITHOUT_foo is defined in src.conf, make delete-old should remove related files completely, to make a system look exactly like it's world was installed with that knob set. First of all, an automatic script to check for leftovers after delete-old for all possible knobs is available from [2]. Feel free to run in on different architectures and FreeBSD branches; I'm currently running it on amd64. I also think that it should be run during preparation of each FreeBSD release. There are some questions I'd like to discuss. 1) named config file var/named/etc/namedb/named.conf was intentionally left out from OptionalObsoleteFiles.inc, so I did the same for other configs which may be changed by users. That's one reason to omit it. Another is that the bind ports use the same set of config files. But putting in under OLD_CONFIGS+= would still be ok? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: OptionalObsoleteFiles.inc completeness
* Peter Jeremy (pe...@rulingia.com) wrote: 2) Is this ok to backport the list from current to stable branches? Pro - it's really simple, con - it will contain files never installed with this (old) branch. Another con: make delete-old on -current takes about 2 orders of magnitude longer to run than on 8.x. I would prefer to see some effort put into speeding it up before it was backported. Is that really a reason while it is still under 4 seconds and is not usually run more often than updates (which take minutes if not hours)? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: OptionalObsoleteFiles.inc completeness
* Doug Barton (do...@freebsd.org) wrote: this issue. The numerous problems we've had with it ever since it was introduced seem to bear me out. :) Can you list them? A missing obsolete file doesn't count. It doesn't catch things it needs to It catches things it shouldn't The current incarnation is painfully slow (so I've heard) ... and the biggest problem ... It needs to be updated manually Pretty true. Still I'd like to fix what we have now, than not to have a useful feature. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: OptionalObsoleteFiles.inc completeness
* Peter Jeremy (pe...@rulingia.com) wrote: 2) Is this ok to backport the list from current to stable branches? Pro - it's really simple, con - it will contain files never installed with this (old) branch. Another con: make delete-old on -current takes about 2 orders of magnitude longer to run than on 8.x. I would prefer to see some effort put into speeding it up before it was backported. Is that really a reason while it is still under 4 seconds and is not usually run more often than updates (which take minutes if not hours)? My experience is that it now takes about 2½ minutes on 10.x with warm caches, compared to less than 1 second on 8.x. Now = after applying my patch or after changing system? Which knobs were enabled? OptionalObsoleteFiles.inc is 3x larger after the patch - it's expected for things to become 3x slower, but definitely not 250x. For most of that time, there's no output and there's no warning of the increased time. I actually wrote about the poor performance here a couple of weeks ago. Then you should try to profile it - my script basically runs delete-old delete-old-libs for every knob (131 of them), and it hadn't taken more than 4 seconds even once. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
OptionalObsoleteFiles.inc completeness
Hi! I'm running a little pet project of improving completeness of tools/build/mk/OptionalObsoleteFiles.inc file and thus delete-old* targets with regard to all possible WITHOUT_* knobs. E.g. when WITHOUT_foo is defined in src.conf, make delete-old should remove related files completely, to make a system look exactly like it's world was installed with that knob set. First of all, an automatic script to check for leftovers after delete-old for all possible knobs is available from [2]. Feel free to run in on different architectures and FreeBSD branches; I'm currently running it on amd64. I also think that it should be run during preparation of each FreeBSD release. There are some questions I'd like to discuss. 1) named config file var/named/etc/namedb/named.conf was intentionally left out from OptionalObsoleteFiles.inc, so I did the same for other configs which may be changed by users. Since this approach requires maintaining a whitelist of such files to ignore them in checking leftovers, I think it'd be better to introduce special variable for config files, e.g. OLD_CONFIGS and corresponding target, delete-old-configs, which will by default remove configs interactively, with an option to remove them in batch mode. 2) Is this ok to backport the list from current to stable branches? Pro - it's really simple, con - it will contain files never installed with this (old) branch. I also plan to make similar script for checking completeness of delete-old* targets for the case of system update. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/168341 [2] https://github.com/AMDmi3/obsolete-files-checker -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: need better POSIX semaphore support
* Kostik Belousov (kostik...@gmail.com) wrote: I've tried the second patch, it works fine. It would be very nice to see it in 8.1, thanks. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
need better POSIX semaphore support
Hi! Not long ago, POSIX semaphores support was enabled by default as it's becoming more widely used, by e.g. firefox. However, the support for these is still incomplete: we only have systemwide limit of 30 semaphores, and that doesn't seem to be configurable neither online with sysctl, nor at boottime from loader.conf. I only was able to raise semaphore count by changing SEM_MAX in kernel sources. The real appliaction which needs more semaphores is lightspark (graphics/lightspark-devel) flash plugin - it uses ~40 sems for simple clips and ~250 for something like youtube videos. Until there more apps that require proper semaphore support, I guess we need to improve it asap. Given the amount of memory used by ksem, the least can be done is SEM_MAX bumped up to 5120 or so for non-embedded kernels. 5120 semaphores require just 644k of kernel memory (judging by vmstat), and is ought to be enough for anybody. Another good thing would be to make it configurable at boot-time or even better in runtime. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
