ithout breaking FreeBSD builds.
>
> Am I right? Will anything break if jemalloc needs a C++ compiler to build?
> We will of course not use exceptions, RTTI, global constructors, the C++
> stdlib, or anything else that might affect C source or link compatibility.
>
> Thanks,
> David
[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
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.
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
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
[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.
[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
[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
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:
>
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
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
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++
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
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
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
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
mented in Haskell or
Rust as well.
>
> Am I right? Will anything break if jemalloc needs a C++ compiler to build?
> We will of course not use exceptions, RTTI, global constructors, the C++
> stdlib, or anything else that might affect C source or link compatibility.
I wonder how can you
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
gling scheme
>>>>> > > for internal symbols to one using C++ namespaces). We'd been
>>>>> holding off
>>>>> > > because we thought that FreeBSD base all had to compile on GCC
>>>>> 4.2, in
>>>>> > > order
gt; > order to support some esoteric architectures[1].
> >>> > >
> >>> > > The other day though, I noticed that there is some C++ shipping with
> >>> > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the
> >>> HACKIN
GCC 4.2,
>>>> in
>>>> > > order to support some esoteric architectures[1].
>>>> > >
>>>> > > The other day though, I noticed that there is some C++ shipping with
>>>> > > FreeBSD; /usr/bin/dtc and
g with
>>> > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the
>>> HACKING
>>> > > document that C++11 is a minimum for FreeBSD 11). This, combined
>>> with the
>>> > > fact that ports now points to a modern gcc, ma
>
>> > > The other day though, I noticed that there is some C++ shipping with
>> > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the
>> HACKING
>> > > document that C++11 is a minimum for FreeBSD 11). This, combined with
>> the
>> >
> fact that ports now points to a modern gcc, makes me think we were
> > > incorrect, and can turn on C++ without breaking FreeBSD builds.
> > >
> > > Am I right? Will anything break if jemalloc needs a C++ compiler to
> build?
> > > We will of course not use exc
ACKING
> > document that C++11 is a minimum for FreeBSD 11). This, combined with the
> > fact that ports now points to a modern gcc, makes me think we were
> > incorrect, and can turn on C++ without breaking FreeBSD builds.
> >
> > Am I right? Will anything
d /sbin/devd (the former claiming in the HACKING
>> document that C++11 is a minimum for FreeBSD 11). This, combined with the
>> fact that ports now points to a modern gcc, makes me think we were
>> incorrect, and can turn on C++ without breaking FreeBSD builds.
>>
>> Am I right?
rts now points to a modern gcc, makes me think we were
> incorrect, and can turn on C++ without breaking FreeBSD builds.
>
> Am I right? Will anything break if jemalloc needs a C++ compiler to build?
> We will of course not use exceptions, RTTI, global constructors, the C++
> stdl
/sbin/devd (the former claiming in the HACKING
document that C++11 is a minimum for FreeBSD 11). This, combined with the
fact that ports now points to a modern gcc, makes me think we were
incorrect, and can turn on C++ without breaking FreeBSD builds.
Am I right? Will anything break if jemalloc
30 matches
Mail list logo