e-
user if rtld/libraries are broken.
You could use /rescue/sh as your single-user shell. Of course, that would
perhaps let you still be able to recompile things if you had a static
toolchain. :)
--
John Baldwin
___
freebsd-toolchain@freebsd.o
ties for us and nice
> integration from having imported clang into base.
> -Nathan
This sounds neat indeed. Does the IR format provide any sort of notation for
encoding the path to the interpreter (similar to ELF)? If not, you might want
to at least make the path to 'lli' be conf
a separate set of
boost libraries that are explicitly not linked against libthr), and we also
care about exception performance (one of my co-workers submitted the PR about
exception performance).
--
John Baldwin
___
freebsd-toolchain@freebsd.org ma
On Monday, January 14, 2013 11:50:03 am Alfred Perlstein wrote:
> On 1/14/13 11:06 AM, John Baldwin wrote:
> > On Saturday, January 12, 2013 11:25:47 am Jilles Tjoelker wrote:
> >> With that, I think fast sigblock is too much code and complication for a
> >> niche c
ranches on __isthreaded
would give us a net speedup in both single and multithreaded cases.
I'm less certain. Note that you can't inline mutex ops until you expose
the mutexes themselves to userland (that is, making pthread_mutex_t not
be opaque).
--
John Baldwin
__
On Tuesday, January 15, 2013 4:21:25 am David Chisnall wrote:
> On 14 Jan 2013, at 18:58, John Baldwin wrote:
>
> > I'm less certain. Note that you can't inline mutex ops until you expose
> > the mutexes themselves to userland (that is, making pthread_mutex_t not
>
constant care and feeding in the 7.x/8.x/9.x branches
and it won't need it in 10.x either. I have not seen any convincing
argument as to why leaving GCC in the base for 10.x impedes anything.
Because clang isn't sufficient for so many non-x86 platfor
On Thursday, August 29, 2013 1:02:06 pm David Chisnall wrote:
> On 29 Aug 2013, at 15:57, John Baldwin wrote:
> To summarise the current issues:
>
> Our libstdc++ is ancient. It supports C++98 well, it kind-of supports
C++03. It doesn't support C++11 at all and never will, no
Only a few comments in reply to avoid banging my head against a brick wall and
then I'm done:
On Friday, August 30, 2013 3:33:21 am David Chisnall wrote:
> On 29 Aug 2013, at 18:44, John Baldwin wrote:
> > Also, unless you plan on desupporting all non-x86 platforms, you _still_
force it to genereate DWARF2, which they
# understand. Do this unconditionally as it is harmless when not needed,
# but critical for these newer versions.
#
.if ${CFLAGS:M-g} != "" && ${CFLAGS:M-gdwarf*} == ""
CFLAGS+=-gdwarf-2
.endif
--
John Baldwin
___
; other platforms like arm; kgdb on other platforms).
Realistically this means we can't axe gdb in base from all platforms today as
we'd have platforms with no debugger.
As I mentioned previously, there was a recent thread on arch@ on this
very topic.
--
John Baldwin
_
"FreeBSD ELF32"
>
> (gdb) print t->cs.number
> $5 = 580828064
>
> (gdb) print narg
> $6 = 0
>
> (that last is for context for the get_syscall arguments).
>
> FYI: 580828064 = 0x229EBBA0
I have a patchset
e in the backtrace
compared to before. A simple way to test is to add 'options KDB_TRACE' and
then trigger a panic (e.g. sysctl debug.kdb.panic=1)
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
ls.
> This GDB was configured as "powerpc-marcel-freebsd"...
> Failed to open vmcore: unsupported architecture
This is a different problem with libkvm. I would start with 'ps -M' and use
a debugger to step through the _powerpc_probe and _powerpc64_probe routines in
libkv
On Friday, August 25, 2017 12:30:11 PM Warner Losh wrote:
> On Fri, Aug 25, 2017 at 12:27 PM, Ed Maste wrote:
>
> > On 25 August 2017 at 14:07, Ryan Libby wrote:
> > > On Wed, Aug 23, 2017 at 4:30 PM, John Baldwin wrote:
> > >> Author: jhb
> > >&
from-scratch build:
This was fixed in HEAD in r309775 which hasn't been MFC'd. There were some
followup fixes in r312897 as well. I'll merge those two to 11 in a sec.
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
1
> #define __ARM_NEON_FP 0x4
> #define __ARM_NEON__ 1
Re: runtime, I have patches in review to add AT_HWCAP for native FreeBSD/arm
binaries. Right now it doesn't support a NEON hwcap but it should be easy to
add the flag using the same check to enable it that Linux does.
--
FBSD_MAJOR, and I had to resort to the hack in the commit above to
set CROSS_DIRECTORY_STRUCTURE explicitly. If we were to drop OSREL from
the GCC and BU targets then the normal cross logic in GCC would work such
that I wouldn't have needed the hack.
We could perhaps patch GCC to assume that if FB
On Monday, April 09, 2018 08:58:29 PM Alexander Kabaev wrote:
> On Mon, 09 Apr 2018 12:27:18 -0700
> John Baldwin wrote:
>
> > On Saturday, April 07, 2018 10:14:47 PM Alexander Kabaev wrote:
> > > On Sat, 7 Apr 2018 17:01:30 -0700
> > > Mark Millard wrote:
>
tils and
base/gcc on a regular basis on platforms they have been ported to to
detect regressions. At some point we are going to want to have
package repositories with those available as well, but perhaps I can
work with Xin Li to start building worlds via external toolchains
which can then be used
guarantee ABI stable in a stable branch.
For the xtoolchain packages I want to strip the versions entirely since they
are the OS version of the machine that built the package and not the target
version of the OS being built (and they should really
+.if ${OSVERSION} >= 120
+CONFIGURE_ARGS+= --enable-initfini-array
+.endif
+
.if ${ARCH:Mmips*}
PLIST_SUB+=MIPS=""
.else
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
g/ExternalGCC
>> has that information. /usr/ports/base/README does not
>> reference https://wiki.freebsd.org/ExternalGCC either.
The README predates the wiki page by a fair bit.
The current known issue I need to get back to with base/gcc is tha
On 10/12/18 5:48 PM, Mark Millard wrote:
> On 2018-Oct-10, at 3:13 PM, John Baldwin wrote:
>
>> On 10/6/18 12:22 PM, Mark Millard via freebsd-toolchain wrote:
>>> [Actually devel/gettext-tools is a build time dependency: it should not be
>>> using
>>>
d (and running poudriere in a qemu image of mips64 would
be very unpleasant). I think probably base/binutils just needs to drop the
names with a full tuple if possible.
--
John Baldwin
On 10/15/18 11:06 AM, Warner Losh wrote:
>
>
> On Mon, Oct 15, 2018, 10:20 AM John Baldwin <mailto:j...@freebsd.org>> wrote:
>
> On 10/12/18 6:51 AM, Mark Millard wrote:
> > The following is from attempting to build devel/powerpc-gcc
> > via pou
On 10/15/18 11:55 AM, Warner Losh wrote:
>
>
> On Mon, Oct 15, 2018 at 12:25 PM John Baldwin <mailto:j...@freebsd.org>> wrote:
>
> On 10/15/18 11:06 AM, Warner Losh wrote:
> >
> >
> > On Mon, Oct 15, 2018, 10:20 AM John Ba
PIC is explicitly
given on the command line to match GCC's behavior.
So to be clear, this isn't saying that the implicit PIC setting is
wrong. It is saying that the llvm backend incorrectly interprets
the clang front-end's implicit PIC setting as being an explicit PIC
s
e:
XCC=/usr/bin/cc
XCXX=/usr/bin/c++
XCPP=/usr/bin/cpp
X_COMPILER_TYPE=gcc
WITH_BASE_GCC=yes
WITHOUT_GCC=yes
WITHOUT_CLANG_IS_CC=yes
Thoughts?
--
John Baldwin
___
freebsd-toolc
>> patches can be finished.
>>
>> The source patches are here:
>> https://github.com/bsdjhb/freebsd/compare/master...base_gcc
>
> Phabricator?
Eventually, wanted a first cut of the entire patchset in context to see
On 2/22/19 8:05 PM, Rodney W. Grimes wrote:
>> On Fri, Feb 22, 2019, 5:09 PM John Baldwin wrote:
>>
>>> On 2/22/19 11:45 AM, Rodney W. Grimes wrote:
>>>>> I was recently able to install base/binutils and base/gcc into an amd64
>>> VM
>>>>&g
On 2/22/19 6:03 PM, Brandon Bergren wrote:
>
>
> On Fri, Feb 22, 2019, at 1:01 PM, John Baldwin wrote:
>> I was recently able to install base/binutils and base/gcc into an amd64 VM
>> and do a self-hosted build and install. Some of the port patches have been
>> comm
On 2/25/19 12:24 PM, Brooks Davis wrote:
> On Mon, Feb 25, 2019 at 10:50:40AM -0800, John Baldwin wrote:
>> Hmm, cross compiling is indeed a bear. My original version of this was to
>> have base/gcc install a special 'freebsd-gcc.mk' toolchain file to
>> /
normally but I try base/gcc in case it
> turns out that I need it.)
Patch pending review at https://reviews.freebsd.org/D19484
Thanks.
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-too
nt
>> main(void)
>> {
>>double re, im, u, ur, ui;
>>float complex f;
>>float x, y;
>
> this line to "volatile float x, y".
So it seems to be a regression in clang 7 vs clang 6?
--
John Baldwin
On 3/13/19 9:40 AM, Steve Kargl wrote:
> On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote:
>> On 3/13/19 8:16 AM, Steve Kargl wrote:
>>> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote:
>>>>
>>>> gcc8 --version
>>>> gcc
hat is gcc doing different than clang
in this case. I assume neither GCC _nor_ clang are adjusting the FPU in
compiler-generated code, and in fact as Steve's earlier tests shows, the
precision is set to PD by default when a clang-built binary is run.
--
John Baldwin
_
r you have max ULP of 2.9 (the
> desired result); with the latter you have a max ULP of 23.xxx.
> I have observed a 6 billion ULP issue when running my testsuite.
> As pointed out by John Baldwin, GCC is aware of the FPU setting.
> The problem with clang is that it seems to unconditio
value
of work) for existing releases, so we want to provide different packages for
different major compiler versions to cope with newer OS releases supporting
newer compilers (e.g. we will patch head to work with freebsd-gcc9, but if
we only had a single powerpc64
releases while using newer major versions on
newer FreeBSD releases (e.g gcc9 for 13.0 and gcc6 for 12.x).
I do plan to switch the default toolchains for make universe/tinderbox
for targets using -xtoolchain-gcc based on GCC 6 over to the
freebsd-gcc6 varia
On 12/18/19 4:16 PM, Mark Millard wrote:
>
>
> On 2019-Dec-18, at 13:48, John Baldwin wrote:
>
>> In the interest of supporting newer versions of GCC for a base system
>> toolchain, I've renamed the external GCC packages from -gcc
>> to -gcc6. These are buil
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 from -gcc
>> to -gcc6. These are built a
sn't install a BUTARGET-ld binary anywhere. I might end up
axeing /usr/BUTARGET/bin from the base/binutils package. I've
trimmed most of the similar type files from base/gcc6 recently.
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing l
in clang properly, though.
I think using the hack patch in devel/freebsd-gcc* is fine for now, but can
you confirm if both 6 and 9 need it or only 9?
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listin
hy the plugins don't build
when aarch64 is the native host.
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
On 1/3/20 2:34 AM, Mark Millard wrote:
> John Baldwin jhb at FreeBSD.org wrote on
> Thu Jan 2 21:41:07 UTC 2020 :
>
>> On 1/2/20 1:34 PM, John Baldwin wrote:
>>> Author: jhb
>>> Date: Thu Jan 2 21:34:44 2020
>>> New Revision: 356289
>>> UR
ild-ability tests, no intent to install as stands.)
>
> base/binutils did not have such problems. (Actually installed on 32-bit
> powerpc so more ports can build.)
I think the devel/freebsd-gcc* ports have a workaround for this when being built
on aarch64. We probab
47 matches
Mail list logo
