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
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 op
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
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 y
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
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
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
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
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
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
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 &
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
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://
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
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
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'
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
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
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
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
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
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
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
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
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
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
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
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
> >>
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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:
> >>
> >>&
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
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
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
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
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,
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.,
> >
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
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++
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
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
>
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
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
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
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
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
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
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
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
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
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
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) {
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
>
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.
>
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
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
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)
>
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
1 - 100 of 104 matches
Mail list logo
