Re: the risk of dependencies on the C++ runtime.
(apologies Konstantin, your email got trapped in a spam filter; "It is in
violation of Google's recommended email sender guidelines", according to
GMail).
Avoiding C++ runtime dependencies is fairly straightforward in practice
(e.g. a program that
[I should have checked for 3 digit numerals in r notation.]
On 2017-Oct-7, at 11:36 PM, Mark Millard wrote:
> With a fresh day after sleep and some pondering
> I finally am thinking straight for where things
> are in files for C++ scratch register usage and
> such:
>
> It is libgcc_s.so.1 that
With a fresh day after sleep and some pondering
I finally am thinking straight for where things
are in files for C++ scratch register usage and
such:
It is libgcc_s.so.1 that has all the extra use of
scratch registers for C++ exception handling --and
lots of other special stuff as well.
This note
It turns out that /usr/local/bin/gdb crashing
for the clang-built powerpc64 world is again
due to C++ exceptions being thrown, this time
in gdb80 itself.
This helps explain why for clang-based buildworld
experiments /usr/libexec/gdb is a better alternative
currently for the powerpc families.
Aga
On 2017-Oct-7, at 3:21 AM, Roman Divacky wrote:
> Answers inline.
>
> On Sat, Oct 07, 2017 at 03:13:43AM -0700, Mark Millard wrote:
>> Just a short top-post as this does not fit well with the
>> other material:
>>
>> I believe Roman only built his example program
>> with clang, not the world th
Answers inline.
On Sat, Oct 07, 2017 at 03:13:43AM -0700, Mark Millard wrote:
> Just a short top-post as this does not fit well with the
> other material:
>
> I believe Roman only built his example program
> with clang, not the world that the program was
> being run under.
I used a machine with
Just to clarify my not agreeing with Mark regarding EH on ppc64.
Last time I tried to fix ppc64 exceptions handling as generated by clang
it turned out that simply using gnu ld from ports fixes the issue.
For details see:
https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html
Just a short top-post as this does not fit well with the
other material:
I believe Roman only built his example program
with clang, not the world that the program was
being run under.
The gcc 4.2.1 based code that is analogous to
__cxa_begin_catch (scratch register initialization)
in a clang base
[The last part of my note has a dumb mistake, not
that it messes up the other evidence. I should have
dwarfdump'd not a.out but the code in the libraries,
such as __cxa_begin_catch in /lib/libcxxrt.so.1 . I
made the same mistake initially back when Roman and
I were dealing with this long ago. Corre
[I'm separately listing backtrace information and related
information from one of core dumps and going back through
the details to see if they seem to be as they were back
then. Read only if you care. It does look the same as I
found back then if I remember right. I reach the same
conclusion I reac
[I'm adding examples with output from clang -v since it explicitly shows
the path used for ld and such.]
On 2017-Oct-7, at 12:58 AM, Mark Millard wrote:
> On 2017-Oct-6, at 11:42 PM, Roman Divacky wrote:
>
>> Just to clarify my not agreeing with Mark regarding EH on ppc64.
>>
>> Last time I t
On 2017-Oct-6, at 11:42 PM, Roman Divacky wrote:
> Just to clarify my not agreeing with Mark regarding EH on ppc64.
>
> Last time I tried to fix ppc64 exceptions handling as generated by clang
> it turned out that simply using gnu ld from ports fixes the issue.
>
> For details see:
> https://l
On 2017-Oct-6, at 9:58 AM, Conrad Meyer wrote:
> On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore wrote:
>> It isn't about "a broken port". All C++ code is broken if exceptions
>> don't work. That means devd is broken. Not to mention clang itself.
>> It may be that neither of those relies on excep
On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore wrote:
> It isn't about "a broken port". All C++ code is broken if exceptions
> don't work. That means devd is broken. Not to mention clang itself.
> It may be that neither of those relies on exceptions for routine
> operation and uses them only for e
On Fri, 2017-10-06 at 09:04 -0700, Conrad Meyer wrote:
> On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard
> wrote:
> >
> > Luckily most kernel and world code that I actively use
> > does not throw C++ exceptions in my use.
> >
> > But devel/kyua is majorly broken by the C++ exception
> > issue: It m
On 2017-Oct-6, at 7:15 AM, Justin Hibbits wrote:
> Hi Mark,
>
> On Thu, Oct 5, 2017 at 11:58 PM, Mark Millard wrote:
>> Warner Losh imp at bsdimp.com wrote on
>> Thu Oct 5 21:01:26 UTC 2017 :
>>
>>> Starting in FreeBSD 11, arm and powerpc are supported by clang,
>>> but not super well. For Fre
On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore wrote:
> On Fri, 2017-10-06 at 09:04 -0700, Conrad Meyer wrote:
> > On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard
> > wrote:
> > >
> > > Luckily most kernel and world code that I actively use
> > > does not throw C++ exceptions in my use.
> > >
> > > But
On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard wrote:
> Luckily most kernel and world code that I actively use
> does not throw C++ exceptions in my use.
>
> But devel/kyua is majorly broken by the C++ exception
> issue: It makes extensive use of C++ exceptions. In my
> view that disqualifies clang
Hi Mark,
On Thu, Oct 5, 2017 at 11:58 PM, Mark Millard wrote:
> Warner Losh imp at bsdimp.com wrote on
> Thu Oct 5 21:01:26 UTC 2017 :
>
>> Starting in FreeBSD 11, arm and powerpc are supported by clang,
>> but not super well. For FreeBSD 12, we're getting close for everything
>> except sparc64 (
On Thu, Oct 05, 2017 at 11:59:03AM -0700, David Goldblatt wrote:
> Hi all,
>
> The jemalloc developers have wanted to start using C++ for a while, to
> enable some targeted refactorings of code we have trouble maintaining due
> to brittleness or complexity (e.g. moving thousand line macro definit
Warner Losh imp at bsdimp.com wrote on
Thu Oct 5 21:01:26 UTC 2017 :
> Starting in FreeBSD 11, arm and powerpc are supported by clang,
> but not super well. For FreeBSD 12, we're getting close for everything
> except sparc64 (whose fate has not yet been finally decided).
My understanding of the p
I'm guessing a realistic timeline for us would be on the order of 3 to 6
months. We've been dithering on this issue for a while, and your request
seems as good a time as any to get people off the fence...
So, if you are targeting FreeBSD 12, then in that time frame, there'd be no
issues with C++11
In particular, it is expected that FreeBSD 12 will not ship with GCC 4.2 and
that all supported architectures in FreeBSD 12 will be using a C++11-capable
toolchain (either external GCC or in-tree clang). However, older releases
will still be restricted to C++03 (or whatever GCC 4.2 supports) inclu
We can avoid it in the short term without a ton of pain. In the long run it
would be nice to have, but I wouldn't want to tie our release schedule to
FreeBSD's too tightly (our CI is improving to the point where the tip of
the dev branch gets tested about as well as releases would be, so we're
tryi
Today C++11 is a no-go generally due to the lagging architectures needing
gcc 4.2.
However, that answer might change soon. Would it be easy for you to avoid
C++11, or would that cause you significant pain? And what's the timeline
you'd be releasing a new jemalloc requiring this stuff? The answers
(apologies if you receive this twice; I subscribed to the list in order to
flip the needs-moderation bit for my posts).
So it sounds like C++03 (or rather, the version of C++ supported by g++
4.2) will be fine.
Is C++11 a no-go, without breaking libc on non-Clang architectures? (It
isn't clear to
On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore wrote:
> On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote:
> > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt
> > wrote:
> >
> > >
> > > Hi all,
> > >
> > > The jemalloc developers have wanted to start using C++ for a while, to
> > > enable some t
On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote:
> On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt
> wrote:
>
> >
> > Hi all,
> >
> > The jemalloc developers have wanted to start using C++ for a while, to
> > enable some targeted refactorings of code we have trouble maintaining due
> > t
On Thu, Oct 5, 2017 at 3:01 PM, Warner Losh wrote:
> On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt
> wrote:
>
>> Hi all,
>>
>> The jemalloc developers have wanted to start using C++ for a while, to
>> enable some targeted refactorings of code we have trouble maintaining due
>> to brittleness
On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt
wrote:
> Hi all,
>
> The jemalloc developers have wanted to start using C++ for a while, to
> enable some targeted refactorings of code we have trouble maintaining due
> to brittleness or complexity (e.g. moving thousand line macro definitions
> t
Hi all,
The jemalloc developers have wanted to start using C++ for a while, to
enable some targeted refactorings of code we have trouble maintaining due
to brittleness or complexity (e.g. moving thousand line macro definitions
to templates, changing the build->extract symbols->rebuild mangling sc
31 matches
Mail list logo
