Re: Undefined reference to __atomic_store_8

2020-08-12 Thread Konstantin Belousov
On Wed, Aug 12, 2020 at 01:41:58PM +0200, Tijl Coosemans wrote: > On Wed, 12 Aug 2020 09:44:25 +0400 Gleb Popov wrote: > > On Wed, Aug 12, 2020 at 9:21 AM Gleb Popov wrote: > >> Indeed, this looks like a culprit! When compiling using first command line > >> (the long one) I get following warnings:

Re: Undefined reference to __atomic_store_8

2020-08-11 Thread Konstantin Belousov
On Tue, Aug 11, 2020 at 03:56:35PM +0400, Gleb Popov wrote: > On Sun, Aug 9, 2020 at 7:43 PM Konstantin Belousov > wrote: > > > I do not believe there were any change in the toolchain between p2 and p7, > > this is more likely indicates some fluctuation in the build. The

Re: Undefined reference to __atomic_store_8

2020-08-09 Thread Konstantin Belousov
On Sun, Aug 09, 2020 at 02:37:42PM +0200, Tijl Coosemans wrote: > On Sun, 9 Aug 2020 15:36:51 +0400 Gleb Popov wrote: > > On Sat, Aug 8, 2020 at 5:30 PM Konstantin Belousov > > wrote: > >> For code generated by gcc or clang, yes. > >> If the reference to the symbo

Re: Undefined reference to __atomic_store_8

2020-08-08 Thread Konstantin Belousov
On Sat, Aug 08, 2020 at 12:37:42PM +0400, Gleb Popov wrote: > On Sat, Aug 8, 2020 at 1:29 AM Konstantin Belousov > wrote: > > > On Fri, Aug 07, 2020 at 08:42:12PM +0400, Gleb Popov wrote: > > > Hello toolchain@ > > > > > > I'm testing a new release

Re: Undefined reference to __atomic_store_8

2020-08-07 Thread Konstantin Belousov
On Fri, Aug 07, 2020 at 08:42:12PM +0400, Gleb Popov wrote: > Hello toolchain@ > > I'm testing a new release of GHC (Haskell compiler) and it fails to link to > i386 architectures with > > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/dist-install/build/ > libHSghc-prim-0.6.1-ghc

Re: Getting started with clang debuginfo

2020-07-27 Thread Konstantin Belousov
On Mon, Jul 27, 2020 at 10:37:53AM -0400, Mark Johnston wrote: > On Mon, Jul 27, 2020 at 11:27:40AM +0200, Paul FLOYD wrote: > > Hi > >   > > I'm investigating some of the remaining issues with Valgrind on FreeBSD. > > One of the two remaining major issues that I'm aware of is with Valgrind > > r

Re: x86 process memory map

2020-03-31 Thread Konstantin Belousov
On Tue, Mar 31, 2020 at 03:04:18PM +0200, Paul FLOYD wrote: > > It is the stack grow area and the guard, combined. Read the mmap(2), in> > > particular explanation of MAP_STACK and MAP_GUARD. > I see from the mmap man page that this appeared in FreeBSD 11.1. >   > Do you know where the size of the

Re: x86 process memory map

2020-03-30 Thread Konstantin Belousov
On Mon, Mar 30, 2020 at 08:18:08AM +0200, Paul Floyd wrote: > When I run procstat on a small 32bit app that just calls sleep (on FreeBSD > 12.1 amd64) then I see at the end of the map > > 22353 0xfbffe000 0xfffde000 ---00 0 0 - -- > 22353 0xfffde000

Re: New external GCC toolchain ports/packages

2019-12-20 Thread Konstantin Belousov
On Fri, Dec 20, 2019 at 09:51:15AM -0800, Ryan Libby wrote: > On Fri, Dec 20, 2019 at 9:31 AM Konstantin Belousov > wrote: > > > > On Fri, Dec 20, 2019 at 09:24:00AM -0800, John Baldwin wrote: > > > On 12/19/19 12:06 PM, Ryan Libby wrote: > > > > On We

Re: New external GCC toolchain ports/packages

2019-12-20 Thread Konstantin Belousov
On Fri, Dec 20, 2019 at 09:24:00AM -0800, John Baldwin wrote: > On 12/19/19 12:06 PM, Ryan Libby wrote: > > On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote: > >> > >> In the interest of supporting newer versions of GCC for a base system > >> toolchain, I've renamed the external GCC packages fro

Re: Optimization bug with floating-point?

2019-03-14 Thread Konstantin Belousov
On Thu, Mar 14, 2019 at 12:59:14PM -0700, John Baldwin wrote: > On 3/14/19 12:20 PM, Konstantin Belousov wrote: > > On Fri, Mar 15, 2019 at 05:50:37AM +1100, Peter Jeremy wrote: > >> On 2019-Mar-13 23:30:07 -0700, Steve Kargl > >> wrote: > >>> AFAICT, all

Re: Optimization bug with floating-point?

2019-03-14 Thread Konstantin Belousov
On Fri, Mar 15, 2019 at 05:50:37AM +1100, Peter Jeremy wrote: > On 2019-Mar-13 23:30:07 -0700, Steve Kargl > wrote: > >AFAICT, all libm float routines need to be modified to conditional > >include ieeefp.h and call fpsetprec(FP_PD). This will work around > >issues is FP and libm. FreeBSD needs

Re: Problem with mutex.lock()

2019-02-11 Thread Konstantin Belousov
On Mon, Feb 11, 2019 at 02:04:38PM +, Banta Plan wrote: > I think you can reduce the problem to: > ## > int main() { > std::mutex m; > m.lock(); > m.lock(); > > return 0; > } > ## > > This should deadlock. Where is it specified that the program should deadlock ? The behaviour

Re: Problem with mutex.lock()

2019-02-11 Thread Konstantin Belousov
On Mon, Feb 11, 2019 at 11:09:29AM +, Banta Plan wrote: > I compiled this program and it crashes if executed. > > Compiled with: FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) > (based on LLVM 6.0.1) > > ## CMakeLists.txt > cmake_minimum_required(VERSION 3.13) > project(mainP) >

Re: svn commit: r339898 - head/lib/libc/amd64/sys

2018-11-05 Thread Konstantin Belousov
On Mon, Nov 05, 2018 at 09:10:13PM -0500, Charlie Li wrote: > On 03/11/2018 19:45, Konstantin Belousov wrote: > > Or rather, it is a middle of the valid instruction. > > Next frame looks like it is process_irelocs(), if trusting the line > > numbers. So most likely it is

Re: svn commit: r339898 - head/lib/libc/amd64/sys

2018-11-04 Thread Konstantin Belousov
On Sun, Nov 04, 2018 at 12:43:34AM -0700, Julian Elischer wrote: > what's an ifunc? > A special kind of relocation, controlled by the user code. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain T

Re: svn commit: r339898 - head/lib/libc/amd64/sys

2018-11-03 Thread Konstantin Belousov
On Sat, Nov 03, 2018 at 06:59:02PM -0400, Charlie Li wrote: > On 03/11/2018 11:29, Konstantin Belousov wrote: > > Some minimal amount of facts instead of guesses would be much more useful. > > > Yeah, being sleep deprived and hurried (on my end) certainly doesn't help. >

Re: svn commit: r339898 - head/lib/libc/amd64/sys

2018-11-03 Thread Konstantin Belousov
On Sat, Nov 03, 2018 at 08:52:16AM -0400, Charlie Li wrote: > On 01/11/2018 15:43, Charlie Li wrote: > > On 01/11/2018 12:04, Brooks Davis wrote: > >> Is this failure with devel/llvm70? It's currently missing the patch > >> required to make this work. https://reviews.freebsd.org/D17709 contains >

Re: A head buildworld race visible in the ci.freebsd.org build history

2018-06-18 Thread Konstantin Belousov
On Mon, Jun 18, 2018 at 12:42:46PM -0700, Bryan Drewery wrote: > On 6/15/2018 10:55 PM, Mark Millard wrote: > > In watching ci.freebsd.org builds I've seen a notable > > number of one time failures, such as (example from > > powerpc64): > > > > --- all_subdir_lib/libufs --- > > ranlib -D libufs.a

Re: splitting libc -> libc + libsys and static linking

2018-04-03 Thread Konstantin Belousov
On Tue, Apr 03, 2018 at 10:39:44PM +0200, Dimitry Andric wrote: > On 3 Apr 2018, at 22:32, Brooks Davis wrote: > > > > We (mostly Ali) are working on a patch to to split the actual syscalls > > (__sys_) out of libc and into a libsys. For dynamic linking, > > this is fairly straightforward (link

Re: FCP-100: armv7 plan

2017-09-09 Thread Konstantin Belousov
On Sat, Sep 09, 2017 at 02:34:10PM -0600, Ian Lepore wrote: > Adding the AT_HWCAP stuff would be relatively easy.  I'm not as sure > what to do about getauxval().  To be maximally linux-compatible (which > would be good for ports) we'd put getauxval() in libc and make it work > just like the linux

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

2017-07-19 Thread Konstantin Belousov
On Wed, Jul 19, 2017 at 10:06:13PM -0400, Alexander Kabaev wrote: > On Wed, 19 Jul 2017 22:50:04 +0200 (CEST) > Gerald Pfeifer wrote: > > > On Fri, 14 Apr 2017, Alexander Kabaev wrote: > > > it was suggested multiple times that the whole fixinc step is > > > ultimately harmful and serves no usefu

Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

2017-06-29 Thread Konstantin Belousov
On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote: > One nasty problem with this is that it is not possible to figure out at > compile time what the size of time_t is. You always need some sort of > configure-time test, and an external define. It is arguably possible, with constexpr.

Re: Function attribute for optimization level

2017-06-05 Thread Konstantin Belousov
On Mon, Jun 05, 2017 at 01:03:24PM +0300, Konstantin Belousov wrote: > I think that toolchain@ is more suitable list for the discussion. > > On Sun, Jun 04, 2017 at 05:44:31PM -0500, Eric van Gyzen wrote: > > _thr_rtld_init() calls memcpy() for the sole purpose of resolving it

Re: Function attribute for optimization level

2017-06-05 Thread Konstantin Belousov
I think that toolchain@ is more suitable list for the discussion. On Sun, Jun 04, 2017 at 05:44:31PM -0500, Eric van Gyzen wrote: > _thr_rtld_init() calls memcpy() for the sole purpose of resolving its > PLT entry. With clang 4.0 and the current code, compiler optimization > defeats this attempt b

Re: How to turn off SSP stack-protector on 11.0S

2016-11-29 Thread Konstantin Belousov
On Tue, Nov 29, 2016 at 12:32:28PM +1100, Dewayne Geraghty wrote: > Is WITHOUT_SSP actually honoured and is building a world and/or ports > without SSP possible? Advise/suggestions appreciated. > > Amongst the 9 different server configurations that we build/support, we've > been asked to build a m

Re: Time to enable partial relro

2016-08-27 Thread Konstantin Belousov
On Sat, Aug 27, 2016 at 11:06:54AM -0500, Pedro Giffuni wrote: > > > On 08/26/16 20:10, Pedro Giffuni wrote: > > > > > ...>> I think we should move forward, just want to make sure it doesn???t > >> break some arch completely before moving ahead. While lld is a goal, > >> the goal is also to have

Re: Time to enable partial relro

2016-08-26 Thread Konstantin Belousov
On Fri, Aug 26, 2016 at 10:00:58AM -0500, Pedro Giffuni wrote: > > > On 08/26/16 05:56, Konstantin Belousov wrote: > > On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: > >> Hello; > >> > >> GNU RELRO support was committed in r230784 (2

Re: Time to enable partial relro

2016-08-26 Thread Konstantin Belousov
On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: > Hello; > > GNU RELRO support was committed in r230784 (2012-01-30) but we never > enabled it by default. > > There was some discussion about it on > https://reviews.freebsd.org/D3001 > > By now, all Linux distributions, NetBSD and

Re: Problems with out libgcc_s.so in base

2016-08-20 Thread Konstantin Belousov
On Fri, Aug 19, 2016 at 09:50:28PM +0200, Tijl Coosemans wrote: > On Fri, 19 Aug 2016 10:28:14 +0300 Konstantin Belousov > wrote: > > The option which would fix all this mess is: > > 1. add rpath for gcc lib/ directory into spec file > > and > > 2. make ports c

Re: Problems with out libgcc_s.so in base

2016-08-19 Thread Konstantin Belousov
On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote: > On Thu, 18 Aug 2016 14:48:28 +0200 Dimitry Andric wrote: > > On 18 Aug 2016, at 11:15, Tijl Coosemans wrote: > >> On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl > >> wrote: > >>> % gfortran6 -o z foo.f90 && ./z > >>> /lib/libgcc

Re: warning: DWARF2 only supports one section per compilation unit

2016-03-29 Thread Konstantin Belousov
On Tue, Mar 29, 2016 at 07:49:14PM +0200, Dimitry Andric wrote: > These are harmless, and have been showing up for at least a year now. > Clang is just notifying you that due to DWARF2 limitations, it will not > emit debug info for more than one code section. > > All such warnings in our tree are

Re: clang -pg, libm and the _end symbol

2016-02-24 Thread Konstantin Belousov
On Wed, Feb 24, 2016 at 01:54:25PM +0100, Dimitry Andric wrote: > On 24 Feb 2016, at 12:27, Raphael Kubo da Costa wrote: > > > > I'm reviewing an update to the textproc/miller port in bug 207194, and > > noticed it does some ugly things in post-configure to seemingly > > work around the following

Re: clang -pg, libm and the _end symbol

2016-02-24 Thread Konstantin Belousov
On Wed, Feb 24, 2016 at 12:27:03PM +0100, Raphael Kubo da Costa wrote: > I'm reviewing an update to the textproc/miller port in bug 207194, and > noticed it does some ugly things in post-configure to seemingly > work around the following problem (on 11-HEAD at least): > > % echo 'int main(void) {

Re: 3 quick questions about stack alignment for powerpc (32-bit) signal handlers [the change that caused misaligned]

2016-02-02 Thread Konstantin Belousov
On Tue, Feb 02, 2016 at 10:05:16AM -0600, Justin Hibbits wrote: > Good catch! I'll commit the change tonight. I looked once at the powerpc sigsend(), and I think that it has an issue. The usfp is calculated by taking the stack pointer at the time of signal delivery and substracting the sigframe si

Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error?

2015-12-28 Thread Konstantin Belousov
On Mon, Dec 28, 2015 at 02:07:29PM +, Andrew Turner wrote: > There was some concern about reading non-naturally aligned data in the > kernel not being atomic, this could be checked by, in debug > configurations, enabling alignment checks on entry to the kernel and > disabling them on exit. We c

Re: powerpc64 11.0-CURRENT's clang binds -m32 -mcpu=powerpc a.out to /libexec/ld-elf.so.1

2015-12-15 Thread Konstantin Belousov
On Mon, Dec 14, 2015 at 11:06:51PM -0800, Mark Millard wrote: > # more main.c > int main() > { > return 0; > } > > > > # ls -l `which cc` > -r-xr-xr-x 7 root wheel 54137976 Dec 14 00:06 /usr/bin/cc > > # cc --version > FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906

Re: clang confuses kgdb on static symbols

2015-10-20 Thread Konstantin Belousov
On Tue, Oct 20, 2015 at 04:07:35PM -0400, Ed Maste wrote: > On 20 October 2015 at 15:55, Konstantin Belousov wrote: > > > > We cannot stop generating dwarf-2 until in tree gdb and kgdb are substituted > > by a working replacement. > > Note that I'm only suggesti

Re: clang confuses kgdb on static symbols

2015-10-20 Thread Konstantin Belousov
On Tue, Oct 20, 2015 at 03:44:13PM -0400, Ed Maste wrote: > On 20 October 2015 at 13:27, John Baldwin wrote: > > > > If '-gdwarf-4' works then you can just set that in the DEBUG makeoptions as > > a > > test, otherwise try hacking kern.mk to disable this bit: > > > > # > > # Add -gdwarf-2 when co

[Differential] [Accepted] D2933: Significantly speed up ar(1) on UFS file systems

2015-06-29 Thread kib (Konstantin Belousov)
kib accepted this revision. This revision has a positive review. REVISION DETAIL https://reviews.freebsd.org/D2933 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: emaste, eadler, kib Cc: kib, freebsd-toolchain-list, dim, davide _

[Differential] [Commented On] D2933: Significantly speed up ar(1) on UFS file systems

2015-06-29 Thread kib (Konstantin Belousov)
kib added inline comments. INLINE COMMENTS usr.bin/ar/write.c:568 It is simpler to do if (s == 0) return; for (p = buf; p < buf + s; p += page_size) *p; *(volatile const char *)(buf + s - 1); I do not insist. REVISION DETAIL https://reviews.freebsd.org/D2933

[Differential] [Commented On] D1932: Remove the non-standard CC alias for c++

2015-05-27 Thread kib (Konstantin Belousov)
kib added a subscriber: kib. kib added a comment. On what standard the name of the C++ compiler is based, at all ? What are supposed benefits of the change ? I believe I already noted elsewhere to dim that the CC is long-time established name. Not all software built on FreeBSD live in the ports

[Differential] [Changed Subscribers] D2285: gcc 4.9.1 compilation fixes for aesni

2015-04-14 Thread kostikbel (Konstantin Belousov)
kostikbel added a subscriber: kostikbel. INLINE COMMENTS sys/crypto/aesni/aesencdec.h:30 Why this line uses "" ? REVISION DETAIL https://reviews.freebsd.org/D2285 To: rodrigc, jmg Cc: kostikbel, emaste, dim, freebsd-toolchain ___ freebsd-toolchain@

[Differential] [Accepted] D1826: libdwarf: Add symbol value when processing .rela relocations

2015-02-11 Thread kostikbel (Konstantin Belousov)
kostikbel accepted this revision. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1826 To: emaste, rpaulo, kostikbel Cc: freebsd-toolchain ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebs

[Differential] [Accepted] D1826: libdwarf: Add symbol value when processing .rela relocations

2015-02-11 Thread kostikbel (Konstantin Belousov)
kostikbel accepted this revision. kostikbel added a comment. This revision is now accepted and ready to land. It looks fine, but definitely is extremely subtle. The dwarf_get_reloc_size() returns zero for non-abs relocations, so dwarf_write_{m.l}sb() does nothing for other relocation types. Th

[Differential] [Accepted] D1428: readelf: Handle note types from different operating systems

2015-01-04 Thread kostikbel (Konstantin Belousov)
kostikbel accepted this revision. kostikbel added a reviewer: kostikbel. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1428 To: emaste, kostikbel Cc: rpaulo, freebsd-toolchain ___ freebsd-toolchain@freeb

Re: llvm build error on ppc

2014-11-13 Thread Konstantin Belousov
On Thu, Nov 13, 2014 at 07:11:45PM +0100, Dimitry Andric wrote: > On 13 Nov 2014, at 18:13, Konstantin Belousov wrote:FYI, > > > > I did make tinderbox today for HEAD at r274464, and got the following > > both for ppc and ppc64 worlds. Other arches build successfully. &g

llvm build error on ppc

2014-11-13 Thread Konstantin Belousov
FYI, I did make tinderbox today for HEAD at r274464, and got the following both for ppc and ppc64 worlds. Other arches build successfully. ===> lib/clang/libllvmtablegen (all) /scratch/tmp/kib/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp: In m

Re: Intercepting calls in PIC mode

2014-07-04 Thread Konstantin Belousov
On Fri, Jul 04, 2014 at 04:12:51PM +0400, Ivan A. Kosarev wrote: > Hello, > > Consider the following: > > --- > #include > #include > > extern "C" void* memset(void *block, int c, size_t size) > __attribute__((weak, alias("__int_memset"), visibility("default"))); > > extern "C" __attribu

Re: clang++ 3.3 issue (excessively slow compile vs. gcc 4.6 in just one file of a port)

2013-11-18 Thread Konstantin Belousov
On Mon, Nov 18, 2013 at 11:54:00PM +0100, Matthias Andree wrote: > Glib shares the fate, because it defers to std:: containers where possible. > > A nice way would require additional work and get the linkers to complain > that symbols resolve with a different, incompatible ABI. That would, > howev

Re: C++ runtime version patch for testing

2013-01-27 Thread Konstantin Belousov
On Sun, Jan 27, 2013 at 06:15:51PM +0200, Konstantin Belousov wrote: > On Sun, Jan 27, 2013 at 04:01:48PM +, David Chisnall wrote: > > On 27 Jan 2013, at 15:52, Konstantin Belousov wrote: > > > > > On Sun, Jan 27, 2013 at 03:17:51PM +, David Chisnall wrote: > &g

Re: C++ runtime version patch for testing

2013-01-27 Thread Konstantin Belousov
On Sun, Jan 27, 2013 at 04:01:48PM +, David Chisnall wrote: > On 27 Jan 2013, at 15:52, Konstantin Belousov wrote: > > > On Sun, Jan 27, 2013 at 03:17:51PM +, David Chisnall wrote: > > > > Apparently c++filt from 2.23.1 binutils has bug, c++filt is >

Re: C++ runtime version patch for testing

2013-01-27 Thread Konstantin Belousov
On Sun, Jan 27, 2013 at 03:17:51PM +, David Chisnall wrote: > On 27 Jan 2013, at 15:03, Konstantin Belousov wrote: > > > On Sun, Jan 27, 2013 at 01:28:44PM +, David Chisnall wrote: > >> + std::set_new_handler*; > > What are the symbols you assigning the ve

Re: C++ runtime version patch for testing

2013-01-27 Thread Konstantin Belousov
On Sun, Jan 27, 2013 at 01:28:44PM +, David Chisnall wrote: > Hi All, > > Here is a patch that, I believe, should fix the symbol version mismatches > between the runtime and the STL implementation. I have run the exception > tests from libcxxrt with this patch applied and: > > - libsupc++

Re: Removing default build of gcc

2013-01-26 Thread Konstantin Belousov
On Sat, Jan 26, 2013 at 02:53:16AM -0600, Mark Linimon wrote: > On Fri, Jan 25, 2013 at 03:36:15PM -0500, Pedro Giffuni wrote: > > I don't care much about gcc in current. > > clang, even on -9, can't build the following: > > - most of kde > - graphics/GraphicsMagick > - editors/emacs21 > - ww

Re: Removing default build of gcc

2013-01-26 Thread Konstantin Belousov
On Sat, Jan 26, 2013 at 10:23:58AM +, David Chisnall wrote: > On 25 Jan 2013, at 19:59, Konstantin Belousov wrote: > > > I am really tired of the constant struggle against the consumation of > > the FreeBSD as the test-bed for the pre-alpha quality software. E.g., > >

Re: Removing default build of gcc

2013-01-25 Thread Konstantin Belousov
On Fri, Jan 25, 2013 at 03:36:15PM -0500, Pedro Giffuni wrote: > On 01/25/2013 14:59, Konstantin Belousov wrote: > > On Fri, Jan 25, 2013 at 12:31:39PM -0700, Warner Losh wrote: > >> On Jan 25, 2013, at 4:31 AM, Konstantin Belousov wrote: > >> > >>> On Fri,

Re: Removing default build of gcc

2013-01-25 Thread Konstantin Belousov
On Fri, Jan 25, 2013 at 12:31:39PM -0700, Warner Losh wrote: > > On Jan 25, 2013, at 4:31 AM, Konstantin Belousov wrote: > > > On Fri, Jan 25, 2013 at 08:41:11AM +, David Chisnall wrote: > >> Hi All, > >> > >> In 10.0, the plan is not to

Re: Removing default build of gcc

2013-01-25 Thread Konstantin Belousov
On Fri, Jan 25, 2013 at 08:41:11AM +, David Chisnall wrote: > Hi All, > > In 10.0, the plan is not to ship any GPL'd code, so I'd like to start > disconnecting things from the default build, starting with gcc. I've been > running a gcc-free system for a while, and I think all of the ports t

Re: [patch] DEBUG_FLAGS cleanup

2013-01-23 Thread Konstantin Belousov
On Wed, Jan 23, 2013 at 09:23:41AM +0100, Erik Cederstrand wrote: > Hello folks, > > Attached is a patch to clean up unconditional use of "-g" in Makefiles, > instead respecting the global DEBUG_FLAGS setting. > > I need this as part of my quest to support deterministic builds. Currently, > deb

Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1

2013-01-21 Thread Konstantin Belousov
On Mon, Jan 21, 2013 at 05:26:29PM +, David Chisnall wrote: > On 21 Jan 2013, at 17:24, Konstantin Belousov wrote: > > > So can you provide self-contained test.tgz with Makefile and neccessary > > .c files which demonstrate exactly the behaviour you see ? > > I don

Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1

2013-01-21 Thread Konstantin Belousov
On Mon, Jan 21, 2013 at 05:09:25PM +, David Chisnall wrote: > On 21 Jan 2013, at 16:54, Konstantin Belousov wrote: > > > On Mon, Jan 21, 2013 at 04:12:00PM +, David Chisnall wrote: > >> On 21 Jan 2013, at 04:49, Konstantin Belousov wrote: > >> > >>&

Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1

2013-01-21 Thread Konstantin Belousov
On Mon, Jan 21, 2013 at 04:12:00PM +, David Chisnall wrote: > On 21 Jan 2013, at 04:49, Konstantin Belousov wrote: > > > Yes, quite possible. AFAIR, the 'catch' code compares the exception classes > > by the shared object ownership. It might get confused due to fi

Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1

2013-01-20 Thread Konstantin Belousov
On Sun, Jan 20, 2013 at 08:08:21PM -0800, Pedro Giffuni wrote: > > > > > - Messaggio originale - > > Da: Konstantin Belousov  > > > > On Sun, Jan 20, 2013 at 04:52:00PM +, Hongli Lai wrote: > >> > >> >Number:        1

Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1

2013-01-20 Thread Konstantin Belousov
On Sun, Jan 20, 2013 at 04:52:00PM +, Hongli Lai wrote: > > >Number: 175453 > >Category: standards > >Synopsis: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 > >Confidential: no > >Severity: non-critical > >Priority: low > >Responsible:freebsd-sta

Re: patch to add aes and pclmulqdq instructions to gcc

2013-01-17 Thread Konstantin Belousov
On Thu, Jan 17, 2013 at 09:31:40AM -0800, John-Mark Gurney wrote: > Konstantin Belousov wrote this message on Thu, Jan 17, 2013 at 13:12 +0200: > > On Wed, Jan 16, 2013 at 11:05:16PM -0800, John-Mark Gurney wrote: > > > Mike Belopuhov pointed me to the patch in OpenBSD: > &g

Re: patch to add aes and pclmulqdq instructions to gcc

2013-01-17 Thread Konstantin Belousov
On Wed, Jan 16, 2013 at 11:05:16PM -0800, John-Mark Gurney wrote: > Mike Belopuhov pointed me to the patch in OpenBSD: > http://freshbsd.org/commit/openbsd/0babc91a00b1f1953637bb39c8ec97aef704629e/diff.txt > > While OpenBSD's binutils is quite different than FreeBSD's, I was able > to use his patc

Re: Fast sigblock (AKA rtld speedup)

2013-01-13 Thread Konstantin Belousov
On Sun, Jan 13, 2013 at 10:46:27AM -0700, Ian Lepore wrote: > On Sun, 2013-01-13 at 17:06 +0200, Konstantin Belousov wrote: > > On Sun, Jan 13, 2013 at 07:50:14AM -0700, Ian Lepore wrote: > > > On Sat, 2013-01-12 at 15:04 -0800, John-Mark Gurney wrote: > > > > Davi

Re: LLVM Image Activator

2013-01-13 Thread Konstantin Belousov
On Sun, Jan 13, 2013 at 08:21:37AM -0800, Nathan Whitehorn wrote: > On 01/13/13 05:20, Konstantin Belousov wrote: > > On Sun, Jan 13, 2013 at 12:41:09PM +0100, Ed Schouten wrote: > >> Hi Kostik, > >> > >> 2013/1/7 Konstantin Belousov : > >>> I st

Re: Fast sigblock (AKA rtld speedup)

2013-01-13 Thread Konstantin Belousov
On Sun, Jan 13, 2013 at 07:50:14AM -0700, Ian Lepore wrote: > On Sat, 2013-01-12 at 15:04 -0800, John-Mark Gurney wrote: > > David Xu wrote this message on Tue, Jan 08, 2013 at 13:09 +0800: > > > and can not be freed until process is exited, the page is doubly > > > mapped into in kernel and userla

Re: Fast sigblock (AKA rtld speedup)

2013-01-13 Thread Konstantin Belousov
On Sun, Jan 13, 2013 at 02:32:00PM +0100, Jilles Tjoelker wrote: > On Sat, Jan 12, 2013 at 05:25:47PM +0100, Jilles Tjoelker wrote: > > This suggests a different rather simpler change. Libthr can always use > > its rtld lock implementation instead of only when multiple threads > > exist. This avoid

Re: LLVM Image Activator

2013-01-13 Thread Konstantin Belousov
On Sun, Jan 13, 2013 at 12:41:09PM +0100, Ed Schouten wrote: > Hi Kostik, > > 2013/1/7 Konstantin Belousov : > > I still do remember the buzz about the binary format 0xCAFEBABE, which > > AFAIR gained image activator support on several OSes, to be garbage > > collecte

Re: Fast sigblock (AKA rtld speedup)

2013-01-12 Thread Konstantin Belousov
On Sat, Jan 12, 2013 at 05:25:47PM +0100, Jilles Tjoelker wrote: > On Sat, Jan 12, 2013 at 07:31:48AM +0200, Konstantin Belousov wrote: > > On Sat, Jan 12, 2013 at 12:29:06AM +0100, Jilles Tjoelker wrote: > > > On Fri, Jan 11, 2013 at 10:49:38PM +0200, Konstantin Belousov w

Re: Fast sigblock (AKA rtld speedup)

2013-01-11 Thread Konstantin Belousov
On Sat, Jan 12, 2013 at 08:27:06AM +0800, David Xu wrote: > On 2013/01/12 07:29, Jilles Tjoelker wrote: > > On Fri, Jan 11, 2013 at 10:49:38PM +0200, Konstantin Belousov wrote: > >> http://people.freebsd.org/~kib/misc/rtld-sigblock.3.patch > > The new fields td_sigblock_ptr

Re: Fast sigblock (AKA rtld speedup)

2013-01-11 Thread Konstantin Belousov
On Sat, Jan 12, 2013 at 12:29:06AM +0100, Jilles Tjoelker wrote: > On Fri, Jan 11, 2013 at 10:49:38PM +0200, Konstantin Belousov wrote: > > http://people.freebsd.org/~kib/misc/rtld-sigblock.3.patch > > The new fields td_sigblock_ptr and td_sigblock_val are in the part that >

Re: Fast sigblock (AKA rtld speedup)

2013-01-11 Thread Konstantin Belousov
On Sat, Jan 12, 2013 at 12:51:56AM +0400, Lev Serebryakov wrote: > Hello, Konstantin. > You wrote 11 января 2013 г., 13:54:59: > > > KB> http://people.freebsd.org/~kib/misc/rtld-sigblock.2.patch > KB> is the commit candidate. Now kernel informs rtld about supprt for > Is it first patch in t

Re: Fast sigblock (AKA rtld speedup)

2013-01-11 Thread Konstantin Belousov
On Fri, Jan 11, 2013 at 06:23:44PM +0800, David Xu wrote: > On 2013/01/11 17:54, Konstantin Belousov wrote: > > On Mon, Jan 07, 2013 at 08:22:35PM +0200, Konstantin Belousov wrote: > >> Below is the forward of the patch for which I failed to obtain a private > >>

Re: Fast sigblock (AKA rtld speedup)

2013-01-11 Thread Konstantin Belousov
On Mon, Jan 07, 2013 at 08:22:35PM +0200, Konstantin Belousov wrote: > Below is the forward of the patch for which I failed to obtain a private > review. Might be, the list generates more responses. > > Our rtld has a performance bootleneck, typically exposed by the images > with

Re: Fast sigblock (AKA rtld speedup)

2013-01-08 Thread Konstantin Belousov
On Tue, Jan 08, 2013 at 10:02:22AM -0500, Alfred Perlstein wrote: > I think it would be great if it works, I just haven't had time to fully > understand your more recent patch. If you feel it's safe and maybe do a > few test programs to see what happens, that would be best. I revived the test p

Re: Fast sigblock (AKA rtld speedup)

2013-01-08 Thread Konstantin Belousov
On Tue, Jan 08, 2013 at 01:21:48AM -0500, Alfred Perlstein wrote: > On 1/7/13 7:08 PM, Konstantin Belousov wrote: > > On Mon, Jan 07, 2013 at 03:42:01PM -0500, Alfred Perlstein wrote: > >> On 1/7/13 1:22 PM, Konstantin Belousov wrote: > >>> Below is the forward of t

Re: Fast sigblock (AKA rtld speedup)

2013-01-08 Thread Konstantin Belousov
On Tue, Jan 08, 2013 at 01:09:51PM +0800, David Xu wrote: > On 2013/01/08 02:22, Konstantin Belousov wrote: > > Below is the forward of the patch for which I failed to obtain a private > > review. Might be, the list generates more responses. > > > > Our rtld has a perfor

Re: Fast sigblock (AKA rtld speedup)

2013-01-07 Thread Konstantin Belousov
On Mon, Jan 07, 2013 at 03:42:01PM -0500, Alfred Perlstein wrote: > On 1/7/13 1:22 PM, Konstantin Belousov wrote: > > Below is the forward of the patch for which I failed to obtain a private > > review. Might be, the list generates more responses. > Very cool. > > Sorry f

Re: Fast sigblock (AKA rtld speedup)

2013-01-07 Thread Konstantin Belousov
On Mon, Jan 07, 2013 at 12:18:41PM -0800, Julian Elischer wrote: > On 1/7/13 10:22 AM, Konstantin Belousov wrote: > > Below is the forward of the patch for which I failed to obtain a private > > review. Might be, the list generates more responses. > > > > Our rtld h

Fast sigblock (AKA rtld speedup)

2013-01-07 Thread Konstantin Belousov
overhead per each rtld entry. The proposed approach allows to shave off those two syscalls, doubling the FreeBSD performance for the (silly) throw/catch C++ microbenchmark. Date: Mon, 13 Aug 2012 15:26:00 +0300 From: Konstantin Belousov ... The basic idea is to implement sigprocmask() as single

Re: LLVM Image Activator

2013-01-07 Thread Konstantin Belousov
On Mon, Jan 07, 2013 at 09:36:38AM -0500, John Baldwin wrote: > On Sunday, January 06, 2013 01:02:21 PM Nathan Whitehorn wrote: > > Having LLVM/clang in the base system lets us do some interesting things > > that we couldn't do with GCC. One is that LLVM ships with a JIT for LLVM > > IR as well as

Re: More kernel performance tests on FreeBSD 10.0-CURRENT

2012-09-22 Thread Konstantin Belousov
On Fri, Sep 21, 2012 at 11:39:40PM +0200, Dimitry Andric wrote: > Hi all, > > As a followup to my previous post about the performance of FreeBSD 10.0 > kernels compiled with different compilers (clang and gcc), I did another > series of tests, now on a more modern machine (Core i5-based). I also

Re: Compiler performance tests on FreeBSD 10.0-CURRENT

2012-09-15 Thread Konstantin Belousov
On Sun, Sep 16, 2012 at 12:34:45AM +0200, Dimitry Andric wrote: > Hi all, > > By request, I performed a series of kernel performance tests on FreeBSD > 10.0-CURRENT, particularly comparing the runtime performance of GENERIC > kernels compiled by gcc 4.2.1 and by clang 3.2. > > The attached text f

Re: Clang as default compiler November 4th

2012-09-11 Thread Konstantin Belousov
On Tue, Sep 11, 2012 at 09:27:07AM -0700, Pedro Giffuni wrote: > Hello; >   > Just my $0.02. >   > - Original Message - >  ... > > Can you, please, read what I wrote ? Fixing _ports_ to compile with > > clang is plain wrong. Upstream developers use gcc almost always for > > development and

Re: Clang as default compiler November 4th

2012-09-11 Thread Konstantin Belousov
On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote: > > > tl;dr: Clang will become the default compiler for x86 architectures on > > > 2012-11-04 > > > > There was a chorus of voices talking about ports already. My POV > > is that suggesting to 'fix remaining ports to work with clang'

Re: Clang as default compiler November 4th

2012-09-11 Thread Konstantin Belousov
On Mon, Sep 10, 2012 at 04:12:07PM -0500, Brooks Davis wrote: > [Please confine your replies to toolch...@freebsd.org to keep the thread > on the most relevant list.] I do not see how removing current@ can be done, toolchain@ is not relevant for this discussion. Proposed is not a local change in th

Re: BSD ld (was Re: MCLinker and llvm-config)

2012-07-28 Thread Konstantin Belousov
On Sat, Jul 28, 2012 at 06:15:29PM +0200, Dimitry Andric wrote: > On 2012-07-28 16:15, Pedro Giffuni wrote: > > The Elftoolchain project has been developing a BSD ld: > > > > http://sourceforge.net/apps/trac/elftoolchain/ > > > > > > http://sourceforge.net/apps/trac/elftoolchain/browser/trunk/l

Re: libunwind-based pstack(1)

2012-06-05 Thread Konstantin Belousov
On Tue, Jun 05, 2012 at 04:34:17PM +0200, Jeremie Le Hen wrote: > Hi Kostik, > > On Thu, May 24, 2012 at 03:25:18PM +0300, Konstantin Belousov wrote: > > Hi, > > I reimplemented pstack(1) using libunwind. The source is available at > > the git repository at http://

libunwind-based pstack(1)

2012-05-24 Thread Konstantin Belousov
Hi, I reimplemented pstack(1) using libunwind. The source is available at the git repository at http://people.freebsd.org/~kib/git/pstacku.git/ . To use it, you should also use git HEAD of the libunwind from http://libunwind.nongnu.org, I do not think that version from ports will work. Due to libun

Re: [GDB follow-fork] behavior change for wait()

2012-04-29 Thread Konstantin Belousov
On Fri, Apr 27, 2012 at 03:33:49PM -0700, Marcel Moolenaar wrote: > Hi Dmitry, > > I've been testing the follow-fork changes in GDB and ran into some weird > behavior. Without gdb, my test program (attached) prints something like: > > fbsdvm% ./fe > fe(41042): initial process. Doing fork &

Re: [RFC] Un-staticise the toolchain

2012-04-27 Thread Konstantin Belousov
On Fri, Apr 27, 2012 at 02:58:06PM +0400, Ruslan Ermilov wrote: > Regarding your patch... > > By placing SHARED_TOOLCHAIN to __DEFAULT_NO_OPTIONS list in > bsd.own.mk, you already had MK_SHARED_TOOLCHAIN set to "no" by > default, which preserves the current status quo of building > toolchain stati

Re: [RFC] Un-staticise the toolchain

2012-04-27 Thread Konstantin Belousov
On Thu, Apr 26, 2012 at 05:41:40PM +0400, Ruslan Ermilov wrote: > On Thu, Apr 26, 2012 at 12:35:48PM +0300, Konstantin Belousov wrote: > > I think it is time to stop building the toolchain static. I was told that > > original reasoning for static linking was the fear of loosing the

[RFC] Un-staticise the toolchain

2012-04-26 Thread Konstantin Belousov
I think it is time to stop building the toolchain static. I was told that original reasoning for static linking was the fear of loosing the ability to recompile if some problem appears with rtld and any required dynamic library. Apparently, current dependencies are much more spread, e.g. /bin/sh is

Re: gdb support for follow-fork

2012-04-15 Thread Konstantin Belousov
On Thu, Apr 12, 2012 at 01:15:37PM -0700, Dmitry Mikulin wrote: > Hi, > > I implemented support for follow-fork mode in gdb and would like to submit > it for a review. The feature allows users to specify which process to > follow when the inferior does a fork(). The default mode is to stay with

Re: DragonFly added DT_GNU_HASH support to rtld

2012-04-15 Thread Konstantin Belousov
On Sun, Mar 11, 2012 at 10:59:00AM +0100, John Marino wrote: > Hi Konstantin, > > It seems that no BSD supported DT_GNU_HASH despite this option being > available on the base binutils (FreeBSD's 2.17.50 binutils supports it). > This gnu extension is a big performance improvement over the specif

init arrays patch

2012-03-08 Thread Konstantin Belousov
Hi, The latest version of the patch to add support for init and fini arrays for FreeBSD is available at http://people.freebsd.org/~kib/misc/init_array.7.patch Apparently, some variant of ARM ABI mandates the use of arrays, so there is a demand for the change. Also, it is another step to bring us c

  1   2   >