Re: Undefined reference to __atomic_store_8

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

Re: Undefined reference to __atomic_store_8

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.

Re: Undefined reference to __atomic_store_8

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 of G

Re: Undefined reference to __atomic_store_8

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/ >

Re: Getting started with clang debuginfo

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 > >

Re: x86 process memory map

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

Re: x86 process memory map

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

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

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

Re: Optimization bug with floating-point?

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?

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()

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()

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

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

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

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

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

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

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

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

Re: FCP-100: armv7 plan

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)

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

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)

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

Re: Function attribute for optimization level

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

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

Re: Time to enable partial relro

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

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 r230

Re: Time to enable partial relro

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

Re: Problems with out libgcc_s.so in base

On Fri, Aug 19, 2016 at 09:50:28PM +0200, Tijl Coosemans wrote: > On Fri, 19 Aug 2016 10:28:14 +0300 Konstantin Belousov <kostik...@gmail.com> > wrote: > > The option which would fix all this mess is: > > 1. add rpath for gcc lib/ directory into spec file > > and &g

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

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

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

Re: clang -pg, libm and the _end symbol

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]

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

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

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

On Tue, Oct 20, 2015 at 04:07:35PM -0400, Ed Maste wrote: > On 20 October 2015 at 15:55, Konstantin Belousov <kostik...@gmail.com> wrote: > > > > We cannot stop generating dwarf-2 until in tree gdb and kgdb are substituted > > by a working replacement. > > Note

Re: clang confuses kgdb on static symbols

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: > > > > # > > #

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

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] [Accepted] D2933: Significantly speed up ar(1) on UFS file systems

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] D1932: Remove the non-standard CC alias for c++

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

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

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 ___

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

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 ___

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

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, however,

Re: C++ runtime version patch for testing

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: Apparently c++filt from 2.23.1

Re: Removing default build of gcc

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 -

Re: Removing default build of gcc

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, Jan 25, 2013 at 08:41:11AM +, David Chisnall

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

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: Yes, quite possible. AFAIR, the 'catch' code

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

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-standards State:

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

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:        175453 Category:      standards Synopsis:      Catching C++ std

Re: patch to add aes and pclmulqdq instructions to gcc

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: http://freshbsd.org/commit

Re: LLVM Image Activator

On Sun, Jan 13, 2013 at 12:41:09PM +0100, Ed Schouten wrote: Hi Kostik, 2013/1/7 Konstantin Belousov kostik...@gmail.com: I still do remember the buzz about the binary format 0xCAFEBABE, which AFAIR gained image activator support on several OSes, to be garbage collected. Maybe

Re: Fast sigblock (AKA rtld speedup)

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 avoids the

Re: Fast sigblock (AKA rtld speedup)

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 userland,

Re: Fast sigblock (AKA rtld speedup)

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: David Xu wrote this message on Tue, Jan 08

Re: LLVM Image Activator

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: Fast sigblock (AKA rtld speedup)

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 has a performance bootleneck, typically

Re: Clang as default compiler November 4th

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 the

Re: libunwind-based pstack(1)

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://people.freebsd.org/~kib/git/pstacku.git

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

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

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 ability

Re: [RFC] Un-staticise the toolchain

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 static. But

[RFC] Un-staticise the toolchain

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

Re: DragonFly added DT_GNU_HASH support to rtld

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 specified

Re: DragonFly added support for ELF preinit, init, and fini arrays

On Sun, Feb 19, 2012 at 09:03:00AM +0100, John Marino wrote: On 2/18/2012 10:38 PM, Konstantin Belousov wrote: Thank you, it was very useful. It seems that test4 needed some adjustments to actually provide the required dso for tests. Yeah. I thought I gave you a version that worked out

Re: DragonFly added support for ELF preinit, init, and fini arrays

On Sat, Feb 18, 2012 at 07:53:22AM +0100, John Marino wrote: On 2/16/2012 9:27 PM, Konstantin Belousov wrote: On Thu, Feb 16, 2012 at 05:51:21PM +0100, John Marino wrote: One obvious case for the immediate use is the building of gold linker in binutils 2.22. By default, it moves constructors

Re: DragonFly added support for ELF preinit, init, and fini arrays

On Wed, Feb 15, 2012 at 08:22:02PM -0500, Pedro Giffuni wrote: Hello; FYI, this commit in DragonFly seems interesting: http://leaf.dragonflybsd.org/mailarchive/commits/2012-02/msg00146.html It appears like linux had them from a while and some years ago they started using them for C++ in

Re: DragonFly added support for ELF preinit, init, and fini arrays

On Thu, Feb 16, 2012 at 05:51:21PM +0100, John Marino wrote: One obvious case for the immediate use is the building of gold linker in binutils 2.22. By default, it moves constructors into the init array, so gold will segfault if it was linked with itself. (The workaround is to patch