Re: [RFC] Un-staticise the toolchain
On Thursday, April 26, 2012 7:38:03 am Bob Bishop wrote: > Hi, > > On 26 Apr 2012, at 10:35, 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 > > 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 dynamically linked [etc] > > That seems like a bad mistake, because it would prevent even booting single- 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.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: LLVM Image Activator
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 components of a toolchain for it (this is what Google's > pNACL uses) and that you can end up producing binary files that are in > IR instead of native code. The IR isn't really cross-platform, but does > let you do CPU-specific optimizations when executed by the JIT, etc. > > The attached patch causes the LLVM JIT (lli) to be built by default > (adding ~20 seconds to buildworld on my five-year-old laptop) and adds a > kernel image activator that invokes it when passed LLVM bitcode files. > It's not completely finished (see the XXX comment in the middle), but it > does work, as follows: > > $ clang -emit-llvm -c -o hw.ll hw.c > $ file hw.ll > hw.ll: LLVM bitcode > $ lli hw.ll > Hello world! > $ chmod a+x hw.ll > $ ./hw.ll > Hello world! > $ > > Is there any interest in having features like this? It seems like this > could provides some interesting possibilities 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 configurable via a tunable and/or sysctl (e.g. if using a newer version of clang in /usr/local). -- John Baldwin ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Fast sigblock (AKA rtld speedup)
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 case. It does seem a bit complicated to me as well. > Most of the extra atomics in multi-threaded applications are conditional > on __isthreaded (or can be made so); therefore, performance loss from > linking in libthr should be negligible in most cases. Sadly, this is not true. libstdc++ turns on locking if you merely link against libthr, not based on testing __isthreaded. (It does this by testing to see if pthread_once() works during startup, and we have to intentionally sabotage the pthread_once() in libc to fail for this to work which annoys me for an entirely different set of reasons.) At work we go to great lengths to avoid linking in libthr for exactly this reason (e.g. we have a custom port of boost that builds 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 mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Fast sigblock (AKA rtld speedup)
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 case. > > It does seem a bit complicated to me as well. > > > >> Most of the extra atomics in multi-threaded applications are conditional > >> on __isthreaded (or can be made so); therefore, performance loss from > >> linking in libthr should be negligible in most cases. > > Sadly, this is not true. libstdc++ turns on locking if you merely link > > against libthr, not based on testing __isthreaded. (It does this by testing > > to see if pthread_once() works during startup, and we have to intentionally > > sabotage the pthread_once() in libc to fail for this to work which annoys me > > for an entirely different set of reasons.) > > > > At work we go to great lengths to avoid linking in libthr for exactly this > > reason (e.g. we have a custom port of boost that builds 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). > > > I get frustrated when people ask me "but why are you doing that?", but I > have to know... why do we/you need fast exception handling? > > Are you throwing a high rate of exceptions? Or is it just that your > application is that sensitive to exceptions being thrown that a single > slowish one has an impact? More that it is sensitive. Not all exceptions result in an immediate call to exit(). -- John Baldwin ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Fast sigblock (AKA rtld speedup)
On Monday, January 14, 2013 1:24:04 pm David Chisnall wrote: > On 14 Jan 2013, at 17:47, Jilles Tjoelker wrote: > > > The code which does that check is actually under contrib/gcc. Problem > > is, they designed __gthread_active_p() to distinguish threaded and > > unthreaded programming environments -- it must be known in advance and > > cannot be changed later. The code for the unthreaded environment then > > takes advantage of this by not even allocating memory for mutexes in > > some cases. > > It's worth taking a step back and asking why this code exists at all, and the main reason is that acquiring a mutex used to be really expensive. It still is on some fruit-flavoured operating systems, but elsewhere it's a single atomic operation in the uncontended case, and in that case the cache line will already be exclusively owned by the calling core in single-threaded code. > > I would much rather that we followed the example of Solaris and made the multithreaded case fast and the default than keep piling on hacks that allow code to shave off a few clock cycles in the single-threaded case. In particular, the popularity of multicore systems means that it is increasingly rare for code to be both single threaded and performance critical, so this seems like misplaced optimisation. We have single-threaded performance critical applications that run on multicore systems (we just run several copies) and if we link in libthr, then pthread_mutex operations (even on uncontested locks) show up as one of the top consumers of CPU time when we profile our applications. > I strongly suspect that making it possible to inline the uncontended lock case for a pthread mutex and eliminating all of the branches 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 ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Fast sigblock (AKA rtld speedup)
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 > > be opaque). > > This is one of the things that will be required anyway if we wish to support process-shared mutexes (they've been in POSIX since 1997, so it's probably getting on for time we did), as the current mutex-is-a-pointer implementation depends on the virtual address space of the creator, and so does not work if the mutex is created in a shared memory segment. Yes, David Xu has a p4 branch with this done already. My point is that I would rather effort be spent on getting that in before attempting your suggestion for our current primitives as the inlining you do now requires that David's changes honor the same ABI in the future. -- John Baldwin ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GCC withdraw
On Saturday, August 24, 2013 7:19:22 am David Chisnall wrote: > On 24 Aug 2013, at 11:30, "Sam Fourman Jr." wrote: > > > So I vote, let's not give ourselves the burden of "lugging" dead weight in > > base > > for another 5 years. (in 2017 do we still want to be worrying about gcc in > > base?) > > Perhaps more to the point, in 2017 do we want to be responsible for > maintaining a fork of a 2007 release of gcc and libstdc++? This is a red herring and I'd wish you'd stop bringing it up constantly. GCC has not needed 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 platforms we can't really start using clang-specific features yet anyway. -- John Baldwin ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GCC withdraw
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, nor does it support C++14. An increasing number of ports are depending on C++11, because it provides much cleaner syntax than C++98 and so these are being forced to depend on gcc46 or gcc47 to build. Unfortunately, libstdc++ in ports is not ABI compatible with the libstdc++ that we ship, which causes library ABI versions. This problem will only get worse over the coming years. An increasing number of these ports do build with libc++ (since it's the only option on OS X / iOS - most do already and most of the fixes needed are just adding some inclusions since libc++ doesn't leak C headers as much as libstdc++), so defaulting to libc++ will reduce these problems over time. How does removing GCC from base change this? I already deal with having 3 different GCC versions at work by building them from ports and building things with the right rpath, etc. so I am familiar with this, and having GCC in the base doesn't make that problem any worse. In fact, I'd argue that this is an argument for not shipping an STL in the base system at all (though I'd be loathe to do that) if it is an argument for disabling GCC. > Maintaining our libstdc++ is not a zero-effort operation. We have to modify it whenever libc gains new features (e.g. POSIX2008 locales, new libm functions) and this requires developer time tracking down the new bugs (because the static configuration files no longer match the included headers) and fixing them. Strictly speaking you do not have to modify it in all cases. The recent change to make it work with log10 does not appear to have been a requirement to fix anything (at least judging from the log message). There does seem to have been about 10 changes to libstdc++ in the past year, though a few were 2-3 line changes in config.h which isn't but so earth-shattering. Also, unless you plan on desupporting all non-x86 platforms, you _still_ have to do all this work while those platforms require GCC anyway. Just turning off GCC on x86 doesn't change this problem one iota. And that point is actually relevant to many of the other concerns you raised. It's not at all clear what disabling GCC on x86 will buy you unless you are intending on short-changing support for GCC on non-x86. > Maintaining out gcc is also not a zero-effort operation. Even though it is not the default compiler for amd64 or i386, we still have to add support for new instructions to them, even if we only want to use them in machine- dependent code on these architecture. The new instructions (and I've added some) go into binutils, not gcc per se. Even the ARM ABI changes only touched Makefiles and one config header in contrib/gcc, not actual code changes. The code changes in contrib/gcc to add more AMD instrinics were done because someone felt like doing it, not because it was a requirement or blocking issue for someone. > When we enable LLDB during the 10.x timeframe (emaste has been working hard, but it's probably not quite ready for 10.0), it will have to link against both LLVM libraries and libc++ (as it uses C++11 and doesn't work with our libc++). This is a minor issue, as the only requirement here is that we switch to linking LLVM against libc++ instead of libstdc++, but it is an example of one more piece of code that won't build with our gcc that is in the base system (not yet enabled by default). Clang 3.4 will not build with our gcc either (which will cause some bootstrapping problems that we'll have to address for people going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as long as we tweak the build system to use clang and not cc for the bootstrap build). Eh, it sounds like if you have to force them to use clang for 9.x bootstrapping that also solves your problem in 10, so it's the same amount of work either way. > Last but not quite least, people keep complaining about ever-increasing build times and the size of the base system. Building a gcc and libstdc++ by default every time, that we're telling people not to use, won't help with that... This is your worst argument as clang is known to take far longer than GCC to build. :) > I have not heard any compelling arguments for keeping gcc and libstdc++ as part of the default install on x86, and I have listed a number of reasons why doing so creates extra work for people who maintain the toolchain and who work on ports. I intend to commit the change to remove both from the default build and make libc++ the default STL for clang++ as soon as I get an okay from bapt. I posit that it only saves you work if you sh
Re: GCC withdraw
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_ > > have to do all this work while those platforms require GCC anyway. Just > > turning off GCC on x86 doesn't change this problem one iota. And that point > > is actually relevant to many of the other concerns you raised. It's not at > > all clear what disabling GCC on x86 will buy you unless you are intending on > > short-changing support for GCC on non-x86. > > It gives us a much cleaner deprecation strategy. Ports on tier-2 are best > effort. We don't need to be quite as careful to ensure that they build with the base system compiler on tier-2 architectures. We don't make as strong guarantees about compatibility on tier-2 architectures, so removing gcc from their build at some point over the next five years is fine, but this is not the case for tier 1 architectures, where we can be reasonably expected to support anything that is in the base system for the next five years. > [snip] So my take away from this is that you have no plans to support any platform that doesn't support clang as you just expect ia64 and sparc64 to die and not be present in 11.0. That may be the best path, but I've certainly not seen that goal discussed publically. > > Don't get me wrong, I don't love GCC per se, and on my laptop I've hacked > > the relevant ports so that everything is built with clang. I would also > > love to be able to build the base system with GCC 47 instead of 42, it just > > doesn't seem that we are there yet. > > The time to raise objections for this was when the plan was originally raised > over a year ago, or at any of the points when it's been discussed in between. It is not after we're ready to flip the switch. So I think the crux of the issue might be this: I have no doubt that this has been discussed extensively on toolchain@ and in toolchain-specific devsummit sessions. The proposal to disable GCC by default does not appear to have been discussed in a wider audience from what I can tell. (I can't find any relevant threads on arch@ or current@ prior to this one.) While this is a toolchain-specific decision, it is a very broad decision. Also, we aren't here because of a new thread started intentionally to say "Hey, we as the toolchain folks think we should disable GCC by default on 10 for x86". Instead, we started off in a thread about adding AES instructions to our binutils and out of left field there is an e-mail of "Oh, don't bother cause I'm disabling GCC next week" (paraphrase). Can you appreciate at all that this is a total surprise to people who aren't subscribed to toolchain@ and haven't been to a toolchain session at a devsummit and that this looks like a drive-by change? -- John Baldwin ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang confuses kgdb on static symbols
On Tuesday, October 20, 2015 02:38:48 PM Andriy Gapon wrote:
>
> I see exactly the same behavior both kgdb and kgdb710 (devel/gdb with KGDB
> option):
> (kgdb) p/x intr_cpus
> No symbol "intr_cpus" in current context.
> (kgdb) p/x 'intr_cpus.0'
> $1 = 0xf
>
> Not sure if clang should try to not produce that '.0' suffix (especially given
> that there are no other intr_cpus symbols) or if kgdb should somehow figure
> out
> the suffix.
What if you disable the hack in sys/conf/kern.mk to use dwarf-2?
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 compiling -g. The default starting in clang v3.4
# and gcc 4.8 is to generate DWARF version 4. However, our tools don't
# cope well with DWARF 4, so 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
___
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"
Re: Can we have a toolchain that works?
On Thursday, December 03, 2015 01:15:00 AM Craig Rodrigues wrote: > [Moving discussion to freebsd-toolchain] > > Dag, > > Regarding your question about a working debugger, due to your problems > debugging > code with the in-tree gdb on latest current, we have a few options: > > (1) Enable WITH_LLDB by default in the make infrastructure, and install > lldb. > >We already have lldb in the tree: > https://svnweb.freebsd.org/base/head/contrib/llvm/tools/lldb/ >but it is not built by default. > > lldb does not have kgdb support though. > > (2) Kick gdb out of the base system, and tell people to install the > devel/gdb port. >This will install gdb 7.10 from ports. >This port also installs kgdb As noted in a recent thread on arch@ it is not quite that simple. lldb only supports amd64 and arm64 AFAIK (perhaps arm as well?). It does not support i386 yet, and it does not have meaningful support for kernel debugging (there was an SoC project to add a subset of amd64-only kgdb support that is a decent start). devel/gdb only supports x86 and powerpc. sparc64 is also supported upstream, but not in the port IIRC. It supports kgdb for x86 well, but on powerpc64 (the only other arch I've been able to test under qemu), kgdb isn't able to unwind the stack past the initial frame in cpu_switch, though with some small patches to at least get the initial frame more correct I can see all the threads in info threads and kld symbols are loaded ok. devel/gdb is also the only debugger (to my knowledge) that handles some more exotic uses like fork following and AVX (on x86). The only debugger we have for mips (possibly arm?) and sparc64 and for kgdb on mips, arm, sparc64 is in-tree gdb. One limitation of this debugger is it is native-only. Both lldb and devel/gdb are cross debuggers out of the box (e.g. devel/gdb should be able to examine a process core and (after my libkvm commit) a kernel core from any platform it supports on any platform where it runs). I believe lldb includes all supported platforms out of the box as well. Somewhat in my spare time I want to fill in more of the gaps in devel/gdb coverage (rewrite threads to use ptrace directly and be MI without requiring hacks in each backend the way the current fbsd-threads.c target does; 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-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call
On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote:
> [The following has been reported in:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213778 .]
>
> In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In trying
> to track things down I ran into truss getting a SIGSEGV when it tries to
> handle the situation. . .
>
> In truss's enter_syscall there is (from a live gdb on truss, after the
> segmentation fault):
>
> 380 t->cs.name = sysdecode_syscallname(t->proc->abi->abi,
> t->cs.number);
> 381 if (t->cs.name == NULL)
> (gdb)
> 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d --\n",
> 383 t->proc->abi->type, t->cs.number);
> 384
> 385 sc = get_syscall(t->cs.name, narg);
> 386 t->cs.nargs = sc->nargs;
> 387 assert(sc->nargs <= nitems(t->cs.s_args));
> 388
> 389 t->cs.sc = sc;
>
> (gdb) print *t
> $2 = {entries = {le_next = 0x0, le_prev = 0x20617070}, proc = 0x20617060, tid
> = 100150, in_syscall = 1, cs = {sc = 0x0, name = 0x0, number = 580828064,
> args = 0x2061b0c0, nargs = 0,
> s_args = 0x2061b0ec}, before = {tv_sec = 1477418265, tv_nsec =
> 492342263}, after = {tv_sec = 1477418265, tv_nsec = 492496630}}
>
> (gdb) print sc
> $3 = (struct syscall *) 0x0
>
> So line 386 listed above gets a segmentation fault for sc->nargs when
> t->cs.name is a NULL pointer: sc ends up NULL.
>
> Looking at the two things that the fprintf on lines 382 and 383 would report:
>
> (gdb) print t->proc->abi->type
> $4 = 0x10166 "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 I have tested some in a git branch that I believe fixes
handling of
unknown system calls. Please try this:
https://github.com/freebsd/freebsd/compare/master...bsdjhb:truss_unknown
(Add .diff to get a diff you can apply with patch)
--
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"
Re: 6.2.0 based devel/powerpc64-gcc rejects sys/powerpc/powerpc/db_trace.c for very old code
On Tuesday, December 27, 2016 12:37:08 AM Mark Millard wrote:
> I have submitted:
>
> Bug 215600 - devel/powerpc64-gcc based buildkernel:
> sys/powerpc/powerpc/db_trace.c rejected for: '__builtin_frame_address' with a
> nonzero argument is unsafe
>
> sys/powerpc/powerpc/db_trace.c -r132070 2004-Jul-12 is when this
> __builtin_frame_address use was introduced:
>
> void
> db_trace_self(void)
> {
> db_addr_t addr;
>
> addr = (db_addr_t)__builtin_frame_address(1);
> db_backtrace(curthread, addr, -1);
> }
>
>
>
> head was at -r310556 for this discovery but with a patch for libdwarf
> in ctfconvert to enable buildkernel to get this far. I have not yet
> updated to the 6.3.0 based devel/powerpc64-gcc .
Try using '0' instead of '1'. You might get an extra frame 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"
Re: Lack of TARGET_ARCH=powerpc support in kgdb from devel/gdb (e.g., -r440115 of /usr/ports): "ABI doesn't support a vmcore target"
On Saturday, May 06, 2017 10:03:57 PM Mark Millard wrote:
> THING #0:
>
> It appears that usr.sbin/crashinfo/crashinfo.sh assumes
> that /usr/local/bin/gdb will work better for all architectures,
> including for kgdb types of activity:
>
> find_gdb()
> {
> local binary
>
> for binary in /usr/local/bin/gdb /usr/libexec/gdb /usr/bin/gdb; do
> if [ -x ${binary} ]; then
> GDB=${binary}
> return
> fi
> done
> }
>
> But it appears that on powerpc /usr/local/bin/gdb and
> /usr/local/bin/kgdb do not support TARGET_ARCH=powerpc
> at all for such activity.
Not really. kgdb on powerpc doesn't work period as neither the base nor ports
kgdb can unwind a stack frame. I spent some time last year trying to get the
unwind out of cpu_switch() to work to no avail. The current hack attempts are
here:
https://github.com/bsdjhb/gdb/compare/freebsd-7.11-kgdb...kgdb-ppc
> THING #1:
>
> Another oddity is for the combination:
>
> ${MK_GDB} == no && ${MK_GDB_LIBEXEC} == yes
As I think you figured out, MK_GDB_LIBEXEC depends on MK_GDB=yes.
If WITHOUT_GDB=yes is set, then no "base" GDB is installed at all.
WITH_GDB_LIBEXEC is just to decide in the MK_GDB=yes case where
"base" GDB goes: /usr/bin vs /usr/libexec.
> THING #2:
>
> /usr/libexec/kgdb (when present) does not support the
> powerpc architecture for head either . . .
>
> On a head -r317820 powerpc I attempted:
>
> # /usr/libexec/kgdb /usr/lib/debug/boot/kernel/kernel.debug
> /var/crash/vmcore.7
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> 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
libkvm to see why the appropriate probe routine isn't claiming the core.
--
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"
Re: svn commit: r322824 - in head: lib/clang share/mk usr.bin/clang
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 > > >> Date: Wed Aug 23 23:30:25 2017 > > >> New Revision: 322824 > > >> URL: https://svnweb.freebsd.org/changeset/base/322824 > > >> > > >> Log: > > >> Improve the coverage of debug symbols for MK_DEBUG_FILES. > > >> > > ... > > > This causes llvm to emit hundreds of new warnings [1] for > > > "DWARF2 only supports one section per compilation unit" > > > > > > Are these expected? Are they a concern? Should we silence them? > > > Is this an upstream llvm bug [2]? > > > > I'm not sure they were "expected" but I guess are an unsurprising > > consequence of building more things with debug. In any case they're > > not a concern. > > > > It is an llvm bug (the warning really ought not be emitted for empty > > sections), but upstream is probably not too concerned as (most? all) > > other platforms are not using dwarf2. > > > > The right answer for us is likely to just stop defaulting to dwarf2 > > (and specifying it via CFLAGS for kernel if necessary). > > > > What's the status of kicking gdb out of the tree? If we kick it out, we can > stop doing dwarf2 and move to something more modern. Last time this issue > came up, that was the decision, pending a few issues with the gdb port > which I think John Baldwin is getting close to reaching closure on. gdb is mostly disabled in-tree, but there is no in-tree replacement for the kgdb stack trace from /usr/sbin/crashinfo if the gdb port is not installed, and there won't be until lldb grows some kernel support. OTOH, for most platforms /usr/bin/gdb is now disabled (hidden in /usr/libexec) so isn't relevant for userland binaries certainly. The kernel probably doesn't benefit much from DWARF > 2 (except perhaps for .dwo files if we decide to use those at some point) as the other things added since DWARF2 are largely about handling C++ features like r-value references, etc. -- 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"
Re: stable/11 -r322591 using WITH_LLD_IS_LD= : delete-old removes . . ./usr/bin/ld
On Tuesday, August 29, 2017 12:52:16 PM Mark Millard wrote: > In some build experiments for amd64 -> aarch64 cross > builds/local-file-system-installs for stable/11 > -r322591 with WITH_LLD_IS_LD= I got examples of > delete-old delete-old-libs deleting the path to ld > after a 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 https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: FCP-100: armv7 plan
On 9/9/17 3:25 PM, Jan Beich wrote: > Warner Losh writes: > >> On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: >> >>> Warner Losh writes: >> The goal, if it doesn't work already, is for NEON to work if used, >> but not be required, just like all the other optional features of a CPU. > > FreeBSD doesn't support detecting NEON at runtime unlike Linux. Do you > mean at compile time? If so then the following probably needs to change > > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - -i neon > #define __ARM_NEON 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. -- 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"
Re: amd64-binutils file name structure for utils vs. for powerpc64-binutils and aarch64-binutils
On Saturday, April 07, 2018 10:14:47 PM Alexander Kabaev wrote: > On Sat, 7 Apr 2018 17:01:30 -0700 > Mark Millard wrote: > > > On 2018-Apr-7, at 4:37 PM, Alexander Kabaev > > wrote: > > > > > On Sat, 7 Apr 2018 18:43:17 -0400 > > > Alexander Kabaev wrote: > > > > > > Come to think of it, I am not sure I understand the problem. > > > amd64-binutils installs "proper" x86_64-freebsd-prefixed binaries. > > > Did you expect amd64-freebsd-* ? > > > > My understanding was that cross-build tools are now supposed > > to have the -unknown and the os version (12.0 here) even > > when the cross-build is targeting the same environment as the > > host environment. In other words: that it is not supposed to > > be the same as plain binutils for the host but as-if it was > > from a different architecture. > > > > But I was checking my understanding. In part because it used > > to be that, for example, on amd64 the aarch64-binutils also > > omitted the -unknown and 12.0 but now has them. I just had > > to update my environment's references to such for that. (This > > was not a self-hosted cross-build context and it changed.) > > > > Also, there is a recent check-in, -r466699 , for ports that, > > in part, says: > > > > Log: > > Fix two more issues with r465416. > > > > - Force build of a cross-compiler by defining > > CROSS_DIRECTORY_STRUCTURE in CFLAGS even if the build host matches > > the build target. This fixes such a cross compiler to not > > include /usr/local/lib in its default library path (e.g. amd64-gcc > > when built on amd64). > > > > > > > > But that was for powerpc64-gcc, not powerpc64-binutils (for example). > > I do not know for sure if similar points should also apply to > > *-binutils ports. So, again, I was checking. > > > > (I might have just got involved between already-made and other pending > > updates for all I know.) > > > > > > Since I am not the maintainer of binutils ports, I missed wholesale > rename. I suspect something like the patch below will make > amd64-binutils follow the convention: > > P164: https://reviews.freebsd.org/P164 Huh, I didn't need this change when using amd64-xtoolchain-gcc, but it does seem correct. I wonder if you will need to fix the amd64-xtoolchain-gcc package as well. In general I actually don't like having the OS version present as the xtoolchain packages should not be version-specific (that is, I can use mips-gcc to compile 10, 11, or 12), and even if it was, it the _host's_ OS version is not necessarily the OS version of the target I want to build. However, GCC's FreeBSD specific bits currently require a major version for 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 FBSD_MAJOR is not set it should assume some minimum default version (I think any value >= 6 is treated the same). We could then drop OSREL from the external toolchain ports (binutils and GCC) which I would prefer. -- 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"
Re: amd64-binutils file name structure for utils vs. for powerpc64-binutils and aarch64-binutils
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:
> > >
> > > > On 2018-Apr-7, at 4:37 PM, Alexander Kabaev
> > > > wrote:
> > > >
> > > > > On Sat, 7 Apr 2018 18:43:17 -0400
> > > > > Alexander Kabaev wrote:
> > > > >
> > > > > Come to think of it, I am not sure I understand the problem.
> > > > > amd64-binutils installs "proper" x86_64-freebsd-prefixed
> > > > > binaries. Did you expect amd64-freebsd-* ?
> > > >
> > > > My understanding was that cross-build tools are now supposed
> > > > to have the -unknown and the os version (12.0 here) even
> > > > when the cross-build is targeting the same environment as the
> > > > host environment. In other words: that it is not supposed to
> > > > be the same as plain binutils for the host but as-if it was
> > > > from a different architecture.
> > > >
> > > > But I was checking my understanding. In part because it used
> > > > to be that, for example, on amd64 the aarch64-binutils also
> > > > omitted the -unknown and 12.0 but now has them. I just had
> > > > to update my environment's references to such for that. (This
> > > > was not a self-hosted cross-build context and it changed.)
> > > >
> > > > Also, there is a recent check-in, -r466699 , for ports that,
> > > > in part, says:
> > > >
> > > > Log:
> > > > Fix two more issues with r465416.
> > > >
> > > > - Force build of a cross-compiler by defining
> > > > CROSS_DIRECTORY_STRUCTURE in CFLAGS even if the build host matches
> > > > the build target. This fixes such a cross compiler to not
> > > > include /usr/local/lib in its default library path (e.g. amd64-gcc
> > > > when built on amd64).
> > > >
> > > >
> > > >
> > > > But that was for powerpc64-gcc, not powerpc64-binutils (for
> > > > example). I do not know for sure if similar points should also
> > > > apply to *-binutils ports. So, again, I was checking.
> > > >
> > > > (I might have just got involved between already-made and other
> > > > pending updates for all I know.)
> > > >
> > > >
> > >
> > > Since I am not the maintainer of binutils ports, I missed wholesale
> > > rename. I suspect something like the patch below will make
> > > amd64-binutils follow the convention:
> > >
> > > P164: https://reviews.freebsd.org/P164
> >
> > Huh, I didn't need this change when using amd64-xtoolchain-gcc, but it
> > does seem correct. I wonder if you will need to fix the
> > amd64-xtoolchain-gcc package as well.
> >
> > In general I actually don't like having the OS version present as the
> > xtoolchain packages should not be version-specific (that is, I can use
> > mips-gcc to compile 10, 11, or 12), and even if it was, it the
> > _host's_ OS version is not necessarily the OS version of the target I
> > want to build. However, GCC's FreeBSD specific bits currently require
> > a major version for 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 FBSD_MAJOR is not set it
> > should assume some minimum default version (I think any value >= 6 is
> > treated the same). We could then drop OSREL from the external
> > toolchain ports (binutils and GCC) which I would prefer.
> >
>
> OSREL is an artifact of old times where we had wildly different specs.
> This is not true anymore, so deorbiting the OSREL suffix makes sense.
> For the time being, having binutils with same prefox as corresponding
> GCC is actually a good thing.
Note that the riscv64-binutils hack in Makefile.inc1 doesn't currently
work since it assumes no OSREL suffix btw:
src/Makefile.inc1:
# If we do not have a bootstrap binutils (because the in-tree one does not
# support the target architecture), provide a default cross-binutils prefix.
# This allows riscv64 builds, for example, to automatically use the
# riscv64-binutils port or package.
.if !make(showconfig)
.if !empty(BROKEN_OPTIONS:MBINUTILS_BOOTSTRAP) && \
${MK_LLD_BOOTSTRAP} == "no" && \
!defined(CROSS_BINUTILS_PREFIX)
CROSS_BINUTILS_PREFIX=/usr/local/${TARGET_ARCH}-freebsd/bin/
However, it's hard to fix this right, so long term I'd like us to strip
the OSREL instead. (Right now make tinderbox still happens to work for
riscv64 because src/Makefile forces CROSS_TOOLCHAIN for riscv64 before
Makefile.inc1 is included which sets CROSS_BINUTILS_PREFIX explicitly.)
--
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"
Re: svn commit: r469449 - in head: Mk base/binutils base/gcc base/gcc/files
On Saturday, May 12, 2018 10:38:20 PM Mark Millard wrote:
> pkg-plist.mips seems to be missing any objcopy variant. (Is objcopy not
> needed?)
> (Only this mips variant uses %%BUTARGET%% notation in the pkg-plist.* file.)
>
> pkg.plist.powerpc64 has 3 objcopy variants/places but 2 man1's.
>
> pkg.plist.sparc64 has 2 objcopy variants/places but one man1.
> (no bin/sparc64-unknown-freebsd*-objcopy nor
> man1/sparc64-unknown-freebsd*-objcopy.1.gz compared to powerpc64)
>
> pkg.plist.sparc64 is not using the *-unknown-freebsd* style of naming
> at all. (Not limited to objcopy.) I'm guessing it was not updated when
> base/binutils/Makefile got:
>
> BUTARGET= ${ARCH}-unknown-${OPSYS:tl}${OSREL}
>
> and base/gcc/Makefile got:
>
> GCC_TARGET= ${ARCH}-unknown-${OPSYS:tl}${OSREL}
>
>
>
> Details:
>
> # pwd
> /usr/ports/base/binutils
>
> # grep objcopy pkg-plist.*
> pkg-plist.powerpc64:bin/objcopy
> pkg-plist.powerpc64:bin/powerpc64-unknown-freebsd12.0-objcopy
> pkg-plist.powerpc64:powerpc64-unknown-freebsd12.0/bin/objcopy
> pkg-plist.powerpc64:share/man/man1/objcopy.1.gz
> pkg-plist.powerpc64:share/man/man1/powerpc64-unknown-freebsd12.0-objcopy.1.gz
> pkg-plist.sparc64:bin/objcopy
> pkg-plist.sparc64:share/man/man1/objcopy.1.gz
> pkg-plist.sparc64:sparc64-freebsd/bin/objcopy
>
> # svnlite info /usr/ports/ | grep "Re[plv]"
> Relative URL: ^/head
> Repository Root: svn://svn.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 469767
> Last Changed Rev: 469767
>
> (I've never used/targeted mips or sparc64 but
> I've targeted powerpc64 some of the time.)
Yes, we are now using objcopy from elftoolchain and it seems that
base/binutils was not updated when that happened. We should probably
remove objcopy from the other plists.
It would probably be best to use BUTARGET in the plist files.
It would perhaps be really useful to start building base/binutils 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 as CROSS_SYSROOTs to build pkg, base/binutils,
and base/gcc in Jenkins.
--
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"
Re: Do we need FreeBSD's minor version in gcc and binutils paths?
On 7/5/18 8:43 AM, Li-Wen Hsu wrote: > For example, currently packages of 11.x are built on 11.1 so > aarch64-gcc installs /usr/local/bin/aarch64-unknown-freebsd11.1-gcc > and aarch64-binutils install /usr/local/aarch64-unknown-freebsd11.1/bin/ld > > This is a bit weird to see these on a 11.2 system, also causes some > problem while testing alone with local-built toolchains. > > Does it make sense to strip the minor version in the paths? > i.e. change to something like /usr/local/bin/aarch64-unknown-freebsd11-gcc > > I think this should be fine since we 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 be the latter). -- 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"
Re: [toolchain] svn commit: r474650 - in head/lang: . gcc8 [ not added to bsd.gcc.mk nor to the comment in bsd.default-versions.mk ]
On 7/28/18 8:05 AM, Gerald Pfeifer wrote:
> On Sun, 15 Jul 2018, Gerald Pfeifer wrote:
>>> https://svnweb.freebsd.org/ports/head/Mk/bsd.default-versions.mk :
>>>
>>> # Possible values: 4.9, 5, 6, 7
>>> GCC_DEFAULT?= 6
>> Given that this is still the first release of the GCC 8 series,
>> I'm a bit hesitant to add it there. Too many folks too eager
>> running into problems and then not knowing how to go about it.
>>
>> I'd rather wait for GCC 8.2 which is due this summer.
>
> With GCC 8.2 out now (and hence also the fix of an minor C++
> ABI bug introduced with GCC 8.1) I have now made this change
> to Mk/bsd.default-versions.mk.
>
>
> If anyone can help me with the finishing touches of changed the
> default to GCC 7 and start working on GCC 8, that would be great
> and much appreciated!
One random thing to consider that is GCC related. For FreeBSD 12.0
and later we are planning to use init_array and fini_array instead of
ctors/dtors for lists of constructor and destructor functions. clang
in head has already been changed to do this, and I've patched the
external toolchain versions of GCC in devel/*-gcc and base/gcc to do
this. lang/gcc* should also probably be patched with a similar patch
to what I used in base/gcc to enable it based on OSVERSION:
--- head/base/gcc/Makefile 2018/06/08 16:06:49 472012
+++ head/base/gcc/Makefile 2018/07/11 16:50:00 474469
@@ -2,6 +2,7 @@
PORTNAME= gcc
PORTVERSION= 6.4.0
+PORTREVISION= 1
CATEGORIES=base
MASTER_SITES= GCC/releases/gcc-${DISTVERSION} \
http://www.mpfr.org/mpfr-3.1.6/:mpfr \
@@ -61,6 +62,10 @@ INSTALL_TARGET?= install-gcc
.include
+.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"
Re: base/binutils vs. /usr/local/lib references and also: undefined reference to `pthread_create' (powerpc64 targeting example)
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 > libtool: link: /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --sysroot=. . > . > It looks like the /usr/local/lib references are correct but the wrong linker > was > being used. About 5 other ports have a similar status for making base/binutils > as a cross build.] base/binutils should not be pulling in any other ports at all. Everytime I've built it it has had no other dependencies beyond pkg. As far as I'm aware, the only ports which work with CROSS_TOOLCHAIN and CROSS_SYSROOT are ports-mgmt/pkg, base/gcc, and base/binutils. > On 2018-Oct-5, at 11:00 PM, Mark Millard wrote: > >> In trying to follow the base/binutils part of >> https://wiki.freebsd.org/ExternalGCC >> (or /usr/ports/base/README) for targeting powerpc64 I got: >> >> ( My /etc/make.conf has: WRKDIRPREFIX?=/wrkdirs .) >> >> # cd ../../base/binutils/ >> # make CROSS_TOOLCHAIN=powerpc64-gcc >> CROSS_SYSROOT=/usr/obj/DESTDIRs/xtcgcc-powerpc64-installworld package >> . . . > > Note: This should involve building devel/gettext-tools targetting amd64 > (the host environment in this example) because devel/gettext-tools is > a build-time dependency, not to be run on the target system. Maybe install gettext on your system first before doing the build. Probably the CROSS_* aren't stripped from the environment when building dependencies. > May be if devel/gettext-tools had been pre-built and installed > before trying the CROSS_TOOLCHAIN=powerpc64-gcc > CROSS_SYSROOT=/usr/obj/DESTDIRs/xtcgcc-powerpc64-installworld > based build activity it would have been okay? > > [I try such later below and report on the results.] > > There are no words on https://wiki.freebsd.org/ExternalGCC or > in /usr/ports/base/README for such special build-sequence > instructions. You're maybe the 3rd person trying it. :-/ >> (It is also unclear how the process involving base/* mixes with doing >> later FreeBSD updates from source --including any use of a delete-old >> step if WITHOUT_BINUTILS= is used at the time. For the cross buildworld >> itself it is not clear what options are intended.) So I plan on having a freebsd-gcc.mk (or freebsd-cc.mk) toolchain file that base/gcc will install that will set WITHOUT_BINUTILS and some other things. I have manually done that for now when building world inside a MIPS qemu instance using base/binutils and base/gcc as the native toolchain. Once I have a build that actually finishes I plan to add the toolchain to the port and then have Makefile.inc1 automatically include the file it is present. >> Notes about some typos on: https://wiki.freebsd.org/ExternalGCC >> >> /usr/ports/devel/ports-mgmt/pkg should be: >> /usr/ports/ports-mgmt/pkg >> >> 3 examples of CROSS_TOOCLAHIN should be: >> CROSS_TOOLCHAIN Fixed. >> Notes about the /usr/ports/base/README : >> >> No mention is made of the pkg build so that it can be >> set up on the target. Only https://wiki.freebsd.org/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 that it improperly looks for libraries in /usr/lib when --sysroot is used. I need to get that fixed so that a buildworld via base/gcc works correctly and then I will probably get back to working on more of the todo items on the wiki page. -- 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"
Re: "base/binutils should not be pulling in any other ports at all"? (That confuses me.)
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 >>> libtool: link: /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --sysroot=. >>> . . >>> It looks like the /usr/local/lib references are correct but the wrong >>> linker was >>> being used. About 5 other ports have a similar status for making >>> base/binutils >>> as a cross build.] >> >> base/binutils should not be pulling in any other ports at all. > > That last quote confuses me still. May be it means > it is all to be manually managed instead of automatic? No, it means it doesn't work as you ran into. :) > (The actual build using things link devel/bison on > the host if base/binutils is to build at all.) > > All versions of binutils have direct build dependencies on: > > math/gmp > math/mpfr > devel/bison > devel/gmake > > as far as I know. Some of those in turn have more > build dependencies. Some of all that have Runtime > dependencies and/or library dependencies as well. > (Host context of usage.) For the purposes of the instructions we only need to provide the top-level "leaf" packages as a list of things to install before trying to build. -- 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"
Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build
On 10/12/18 6:51 AM, Mark Millard wrote: > The following is from attempting to build devel/powerpc-gcc > via poudriere-devel on the powerpc64 system after having > bootstrapped via (in part) base/binutils and the .txz > produced on the host (amd64). > > Looks like having both: > > /usr/bin/powerpc64-unknown-freebsd12.0-* > and: > /usr/local/bin/powerpc64-unknown-freebsd12.0-* > > in a powerpc64 environment confuses "phase: build-depends" > in poudriere for the devel/powerpc64-gcc build: Ah, I could see that. I had kept the longer binary names with the full tuple since the original base/binutils had them, but I've considered stripping them as we only really need /usr/bin/as, etc. for the base system. I hadn't gotten to the point of trying to build any ports with base/* as I'm still trying to just do a buildworld (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 ___ 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"
Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build
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 poudriere-devel on the powerpc64 system after having > > bootstrapped via (in part) base/binutils and the .txz > > produced on the host (amd64). > > > > Looks like having both: > > > > /usr/bin/powerpc64-unknown-freebsd12.0-* > > and: > > /usr/local/bin/powerpc64-unknown-freebsd12.0-* > > > > in a powerpc64 environment confuses "phase: build-depends" > > in poudriere for the devel/powerpc64-gcc build: > > Ah, I could see that. I had kept the longer binary names with the full > tuple > since the original base/binutils had them, but I've considered stripping > them > as we only really need /usr/bin/as, etc. for the base system. I hadn't > gotten > to the point of trying to build any ports with base/* as I'm still trying > to > just do a buildworld (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. > > > Having symlinks to the long names plays nicer with autoconf, of at least has > in the past. Our build system doesn't care, though... I think it only plays nicer for the port. We've never had /usr/bin/x86_64-freebsd-ld linked to /usr/bin/ld in base, and base/binutils' role is to provide /usr/bin/as, /usr/bin/ld, etc. -- 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"
Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build
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 Baldwin <mailto:j...@freebsd.org> <mailto:j...@freebsd.org > <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 poudriere-devel on the powerpc64 system after having > > > bootstrapped via (in part) base/binutils and the .txz > > > produced on the host (amd64). > > > > > > Looks like having both: > > > > > > /usr/bin/powerpc64-unknown-freebsd12.0-* > > > and: > > > /usr/local/bin/powerpc64-unknown-freebsd12.0-* > > > > > > in a powerpc64 environment confuses "phase: build-depends" > > > in poudriere for the devel/powerpc64-gcc build: > > > > Ah, I could see that. I had kept the longer binary names with the > full tuple > > since the original base/binutils had them, but I've considered > stripping them > > as we only really need /usr/bin/as, etc. for the base system. I > hadn't gotten > > to the point of trying to build any ports with base/* as I'm still > trying to > > just do a buildworld (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. > > > > > > Having symlinks to the long names plays nicer with autoconf, of at > least has in the past. Our build system doesn't care, though... > > I think it only plays nicer for the port. We've never had > /usr/bin/x86_64-freebsd-ld > linked to /usr/bin/ld in base, and base/binutils' role is to provide > /usr/bin/as, > /usr/bin/ld, etc. > > > The tools built by xdev did, though not that specific link... I do agree that > if we do this, it's only of marginal benefit. The xdev tools are probably more inline with the devel/-binutils and devel/-gcc ports which do install those links to be cross-build friendly. -- 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"
Re: Reasons to still not build buildworld buildkernel via system-clang --John Baldwin notes one I was unaware of
On 10/19/18 7:23 AM, Mark Millard wrote: > [I'm adding toolchain and John B. to the TO: list. John B. > may want to reply to Sean F. I'm also adding a > /lib/libgcc_s.so related item to the list of 3 known > issues.] > >> On 2018-Oct-19, at 6:21 AM, Sean Fertile wrote: >> >> Clang isn't getting the tls model wrong, it actually generates pic code by >> default as if -fpic were specified. I think the original intent behind >> switching >> to pic by default was due to incorrectly thinking gcc was pic by default >> (I'm not sure if this was meant as only gcc on BSD or gcc on powerpc64 in >> general), >> as well as working around some problems that clangs non-pic codegen has/had >> for the ELF V1 abi. There are some patches on phabricator for switching >> the default back to non-pic codegen, but they leave the pic default for BSD: >> https://reviews.llvm.org/D53384 and https://reviews.llvm.org/D53383 >> >> According to what you and John are saying the pic default is incorrect for >> BSD as well. If thats the case please either comment on the reviews to let >> Stefan know, >> or let me know here and we can update the patches accordingly. No, what I am saying is that in GCC, the decision for dynamic TLS model vs static TLS model is based on whether or not -fPIC is explicitly given on the command line. For MIPS at least (where I am familiar with this), both GCC and clang default to implicit PIC. However, GCC uses static TLS models (initial-exec, etc.) when -fPIC isn't given on the command line even if PIC is still implicitly enabled. It only uses the dynamic TLS models (intended for use in shared libraries) if -fPIC is explicitly passed on the command line. However, clang implements implicit PIC by passing the equivalent of -fPIC to the llvm backend, so on MIPS at least, the result is that llvm _always_ uses the dynamic TLS models including for static libraries and binaries where this is wrong. I have some patches from one of the LLVM MIPS folks that kind of hackishly fix this, but by adding a new flag only for MIPS. I wanted to adjust their patches to be more generic so that there's a new '-mshared-library' or some such passed from clang to llvm and have clang only set that to true if -fPIC 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 setting for the purposes of choosing the TLS model to use. -- 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"
External GCC Update
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 committed from this, but I have some source patches before the final ports patches can be finished. The source patches are here: https://github.com/bsdjhb/freebsd/compare/master...base_gcc They do a couple of things I'd like some feedback on: 1) MK_GDB no longer depends on MK_BINUTILS so that /usr/libexec/gdb can still be built/installed when WITHOUT_BINUTILS=yes is true 2) WITH_BASE_GCC and WITH_BASE_BINUTILS knobs can be set in src.conf to ensure that 'make delete-old' doesn't delete files installed by the base/* packages if you also set WITHOUT_BINUTILS=yes, and similar knobs (because you don't want to build/install the ones from src) 3) I add support for an /etc/src.conf.d dir that can hold files that get treated as if they are part of /etc/src.conf. The current patch on github for this only fixes world and not yet kern.pre.mk and probably needs the most review if we want to go forward with this route. With this, I plan to have the base/* packages install suitable files in this dir that disable build of the src-based components and also set WITH_BASE_ to make sure 'delete-old' DTRT. The file for base/binutils would be: CROSS_BINUTILS_PREFIX=/usr/bin/ WITH_BASE_BINUTILS=yes WITHOUT_BINUTILS=yes WITHOUT_LLD_IS_LD=yes The file for base/gcc would be: 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-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: External GCC Update
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 >> and do a self-hosted build and install. Some of the port patches have been >> committed from this, but I have some source patches before the final ports >> 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 if folks run screaming or not. -- 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"
Re: External GCC Update
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 >>>>> and do a self-hosted build and install. Some of the port patches have >>> been >>>>> committed from this, but I have some source patches before the final >>> ports >>>>> 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 if >>> folks run screaming or not. > > Huh? It is 5 files and not even 200 lines of diff??? > My first Phab review for CPU topology was 10 files and over 300 lines. The "run screaming" is about the ideas, not the amount of code. It's similar to posting to arch@ to say "I have this idea and proof-of-concept, does this look like the right path so I should spend time refining it into the a review-ready product, or should I drop it". I never said I would not use phab, so stop putting words in my mouth. This is not unusual project practice to get "idea" review before detailed code review. >> Thank you. Phabricator isn't good with larger patches. Git let's me see >> things in a number of different views that are hard with the one size fits >> all phab ui. > > Its rather hypocritical for core to announce a "recomendation to do reviews, > and the tool of choice is phabricator" and then have 2 core team members > advocate a code review in git just a short time later. > > This sets bad examples from the top :-( No. Phab is the preferred tool, but it is not the only tool as was clearly noted in the recent recommendation. As I said above, I will push the actual patches for review to phab when the time comes, but they aren't ready for that yet and I'm trying to get a review of the ideas to determine how to spend my time. -- 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"
Re: External GCC Update
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
>> committed from this, but I have some source patches before the final ports
>> patches can be finished.
>>
>> The source patches are here:
>> https://github.com/bsdjhb/freebsd/compare/master...base_gcc
>>
>> They do a couple of things I'd like some feedback on:
>>
>> 1) MK_GDB no longer depends on MK_BINUTILS so that /usr/libexec/gdb can
>>still be built/installed when WITHOUT_BINUTILS=yes is true
>
> Good thinking.
>
>> 2) WITH_BASE_GCC and WITH_BASE_BINUTILS knobs can be set in src.conf to
>>ensure that 'make delete-old' doesn't delete files installed by the
>>base/* packages if you also set WITHOUT_BINUTILS=yes, and similar
>>knobs (because you don't want to build/install the ones from src)
>
> I was really confused about the naming when I read through the diff.
> Bikeshedding but I think WITH_PORTS_BASE_BINUTILS / WITH_PORTS_BASE_GCC would
> help quite a lot cognitively, to differentiate between "base as in in-tree
> binutils" and "base as in the base/binutils port"
In the future there won't be a "base as in in-tree binutils", only the
special ports from base/ that are used to build components of the base
system that come as packages, but I don't care strongly about the names.
>> 3) I add support for an /etc/src.conf.d dir that can hold files that get
>>treated as if they are part of /etc/src.conf. The current patch on
>>github for this only fixes world and not yet kern.pre.mk and probably
>>needs the most review if we want to go forward with this route. With
>>this, I plan to have the base/* packages install suitable files in this
>>dir that disable build of the src-based components and also set
>>WITH_BASE_ to make sure 'delete-old' DTRT.
>
> Not sure if I like this. Can't src.opts.mk just call `pkg info -e
> base/binutils` and so forth and use the exit result to adjust the defaults?
That requires src.opts.mk to encode the policy that each package wants to
enforce rather than letting the package choose the policy it wants to
enforce. I think we want the latter.
>> The file for base/binutils would be:
>>
>> CROSS_BINUTILS_PREFIX=/usr/bin/
>> WITH_BASE_BINUTILS=yes
>> WITHOUT_BINUTILS=yes
>> WITHOUT_LLD_IS_LD=yes
>>
>> The file for base/gcc would be:
>>
>> 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
>
> I don't like the concept of packages messing with anything related to
> src.conf. I have a bunch of conditional stuff in mine broken out by
> ${TARGET_ARCH} and extra config suddenly appearing would break a lot of my
> cross compiling stuff, even if it is in a separate *.d folder.
>
> Seems to me that just influencing src.opts.mk's defaults would be more robust.
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
/usr/share/toolchains and modify Makefile.inc1 to use this as the default
CROSS_TOOLCHAIN if present. I mostly didn't like this because it would be
a single file that so you can't set separate policy if, for example, some
arch or install only wanted base/binutils and not base/gcc. On the other
hand, it had the advantage that setting an explicit CROSS_TOOLCHAIN when you
are cross compiling would work correctly.
Perhaps I can rework this to use two files in /usr/share/toolchains and have
Makefile.inc1 explicitly include any files in that directory if
CROSS_TOOLCHAIN isn't set?
--
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"
Re: External GCC Update
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 >> /usr/share/toolchains and modify Makefile.inc1 to use this as the default >> CROSS_TOOLCHAIN if present. I mostly didn't like this because it would be >> a single file that so you can't set separate policy if, for example, some >> arch or install only wanted base/binutils and not base/gcc. On the other >> hand, it had the advantage that setting an explicit CROSS_TOOLCHAIN when you >> are cross compiling would work correctly. >> >> Perhaps I can rework this to use two files in /usr/share/toolchains and have >> Makefile.inc1 explicitly include any files in that directory if >> CROSS_TOOLCHAIN isn't set? > > I think I like that option best. > > Another way to deal with the two-files issue would be to have a > base/toolchain metaport with options that installs the consolidated file > you want. That mirrors (somewhat) the setup in devel/*xtoolchain*, but > I'm not convinced it won't just lead to confusion. I've rebased and repushed the 'base_gcc' branch again to follow this approach. Rather than using a glob, it just hardcodes the two possible files. I did have to make one change which is that the helper files have to use 'export' for the WITH/WITHOUT variables or they weren't being honored in child makes. However, this approach works even for 'make buildenv' in my testing. -- 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"
Re: amd64 -> powerpc64 port base/gcc use: "checking whether the C compiler works... Unable to load interpreter" and "If you meant to cross compile, use `--host'"
On 3/5/19 8:19 PM, Mark Millard wrote: > In trying to update powerpc64 from head -r344018 based to -r344825 based > context via amd64->powerpc64 cross builds: base/binutils worked okay > but base/gcc failed. This reports for base/gcc . > > (I actually only use base/binutils 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-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Optimization bug with floating-point?
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
>> gcc8 (FreeBSD Ports Collection) 8.3.0
>>
>> gcc8 -fno-builtin -o z a.c -lm && ./z
>> gcc8 -O -fno-builtin -o z a.c -lm && ./z
>> gcc8 -O2 -fno-builtin -o z a.c -lm && ./z
>> gcc8 -O3 -fno-builtin -o z a.c -lm && ./z
>>
>> Max ULP: 2.297073
>> Count: 0 (# of ULP that exceed 21)
>>
>
> clang agrees with gcc8 if one changes ...
>
>> int
>> 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
___
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"
Re: Optimization bug with floating-point?
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
>>>> gcc8 (FreeBSD Ports Collection) 8.3.0
>>>>
>>>> gcc8 -fno-builtin -o z a.c -lm && ./z
>>>> gcc8 -O -fno-builtin -o z a.c -lm && ./z
>>>> gcc8 -O2 -fno-builtin -o z a.c -lm && ./z
>>>> gcc8 -O3 -fno-builtin -o z a.c -lm && ./z
>>>>
>>>> Max ULP: 2.297073
>>>> Count: 0 (# of ULP that exceed 21)
>>>>
>>>
>>> clang agrees with gcc8 if one changes ...
>>>
>>>> int
>>>> 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?
>>
>
> /usr/local/bin/clang60 has the same problem.
>
> % /usr/local/bin/clang60 -o z -O2 a.c -lm && ./z
> Maximum ULP: 23.061242
> # of ULP > 21: 39
>
> Adding volatile as in the above "fixes" the problem.
>
> AFAICT, this a i386/387 code generation problem. Perhaps,
> an alignment issue?
Oh, I misread your earlier e-mail to say that clang60 worked.
One issue I'm aware of is that clang does not have any support for the
special arrangement FreeBSD/i386 uses where it uses different precision
for registers vs in-memory for some of the floating point types (GCC has
a special hack that is only used on FreeBSD for this but isn't used on
any other OS's). I wonder if that could be a factor? Volatile probably
forces a round trip between memory which might explain why this is the
case.
I wonder what your test program does on i386 Linux with GCC?
--
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"
Re: Optimization bug with floating-point?
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 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 to issue an erratum about >>> the numerical issues with clang. >> >> I vaguely recall looking into the x87 initialisation a long time ago >> and STR that the startup code (either crtX or in the kernel) does >> a fninit() to set the precision. I don't recall exactly where. > At boot, a clean initial FPU state is stored in fpu_initialstate. > Then on first FPU access from userspace (first for the given process > context), this saved state is copied into hardware registers. The > quirk is that for i386 binaries on amd64, we adjust fpu control word > to what is expected by i386 binaries. > >> >> IMO, calling fpsetprec() in every libm float function is overkill. It >> should be enough to fpsetprec() before main() and add a note in the >> man pages that libm is built to use the default FPU configuration and >> changing the configuration (precision or rounding) may result in larger >> errors. > Changing default precision in crt1 would break the ABI. So what I don't understand then is what 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 ___ 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"
Re: Optimization bug with floating-point?
On 3/14/19 1:08 PM, Steve Kargl 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 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 to issue an erratum about >>> the numerical issues with clang. >> >> I vaguely recall looking into the x87 initialisation a long time ago >> and STR that the startup code (either crtX or in the kernel) does >> a fninit() to set the precision. I don't recall exactly where. >> >> IMO, calling fpsetprec() in every libm float function is overkill. It >> should be enough to fpsetprec() before main() and add a note in the >> man pages that libm is built to use the default FPU configuration and >> changing the configuration (precision or rounding) may result in larger >> errors. > > My understanding of the situation is that FreeBSD i386/387 sets > the FPU to 53-bit precision (whether at start up or first access > is immaterial). This was done long ago to prevent issues with > different optimization levels leaving different intermediate > results is registers with extended precision. You can observe > the problem with the toy program I posted and clang. Compile it > with -O0 and -O2. With the former 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 unconditionally assume > the FPU is set to 64-bit precision. It is unclear if clang is > generated the desired result for float routines in libm. The > only to gaurantee the desired resut is to use fpsetprec(FP_PD), > or fix clang to take into account the FPU environment. OTOH, note that every other OS in 32-bit mode uses 64-bit precision, and amd64 also uses 64-bit precision by default IIUC. FreeBSD/i386 is definitely unique in this regard. Linux doesn't do it, none of the other BSD's do it (only Dragonfly does b/c they inherited it from FreeBSD). None of Solaris, Windows, etc. do it either if the gcc sources are to be trusted as a reference. That said, I think it must have to do with how clang vs GCC is handling saving the values in memory and whether or not it does truncation to 53 bits when stored in memory somehow. I was trying to poke around in GCC's sources to figure out if it was doing anything differently, but I couldn't find a difference in terms of function pointers, etc. The only difference is is the constants used in a set of structures. I haven't tried to track down what those struct member values control though. -- 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"
Re: Fwd: [Bug 239813] Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and lang/gcc8-devel to ELFv2 ABI on powerpc64
On 11/19/19 10:34 AM, Mark Millard wrote: > [A similar question to the below exists for base/gcc . The lang/gcc* are > being ELFv2 enabled for powerpc64 by checking the environment for if it is > new enough and already is ELFv2 based.] > > Begin forwarded message: > > From: bugzilla-nore...@freebsd.org > Subject: [Bug 239813] Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and > lang/gcc8-devel to ELFv2 ABI on powerpc64 > Date: November 19, 2019 at 09:32:52 PST > To: marklmi26-f...@yahoo.com > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239813 > > Gerald Pfeifer changed: > > What|Removed |Added > >Summary|Update lang/gcc8 and|Update lang/gcc9, > |lang/gcc9 to ELFv2 ABI on |lang/gcc9-devel, lang/gcc8, > |powerpc64 |and lang/gcc8-devel to > ||ELFv2 ABI on powerpc64 > > --- Comment #38 from Gerald Pfeifer --- > (In reply to Mark Millard from comment #35) >> I do not know the intent for devel/powerpc64-gcc relative >> to future ELFv2 ABI use. Does it need anything? (May be >> it is updating to gcc9 or some such first?) > > Updating to GCC 9 would be my recomendation, though I have no > involvement with that port. > > lang/gcc9-devel should be fine now, both wrt. the new ABI as well > as building with clang. > > Next I'll make the remaining equivalent changes to lang/gcc9 and > lang/gcc8-devel. I've just committed a new devel/freebsd-gcc6 port (with flavors) to replace the powerp64-gcc port (and slaves) with an intention of creating a freebsd-gcc9 port as a followup. It seems once freebsd-gcc9 exists we can apply this change to that. base/gcc will also similarly be adjusted to base/gcc6 and base/gcc9 in the future. The reason to keep old versions is that gcc6 is known to work (for some 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-gcc port we wouldn't be able to provide a working compiler for stable/11 if we changed powerpc64-gcc to GCC 9). -- 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"
New external GCC toolchain ports/packages
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 as flavors of a new devel/freebsd-gcc6 port. The xtoolchain package is not used for these new packages, instead one does 'pkg install mips-gcc6' to get the GCC 6.x MIPS compiler and uses 'CROSS_TOOLCHAIN=mips-gcc6'. I've also gone ahead and updated this compiler to 6.5.0. I will leave the old ports/packages around for now to permit an easy transition, but going forward, the -gcc6 packages should be preferred to -xtoolchain-gcc for all but riscv (riscv64-gcc and riscv64-xtoolchain-gcc are separate from the powerpc64-gcc set of packages). In addition, I've also just added a devel/freebsd-gcc9 package which builds -gcc9 packages. It adds powerpc and riscv flavors relative to freebsd-gcc6 and uses GCC 9.2.0. To date in my testing I've yet to be able to finish a buildworld on any of the platforms I've tried (amd64, mips, sparc64), but the packages should permit other developers to get the tree building with GCC 9. To use these packages one would do something like: # pkg install amd64-gcc9 # make buildworld CROSS_TOOLCHAIN=amd64-gcc9 You can install both the gcc6 and gcc9 versions of a package at the same time, e.g. amd64-gcc6 and amd64-gcc9. Having different packages for major versions is similar to llvm and will also let us keep a known-good toolchain package for older 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 variants in the next week or so. -- 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"
Re: New external GCC toolchain ports/packages
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 built as flavors of a new devel/freebsd-gcc6 >> port. The xtoolchain package is not used for these new packages, instead >> one does 'pkg install mips-gcc6' to get the GCC 6.x MIPS compiler and >> uses 'CROSS_TOOLCHAIN=mips-gcc6'. I've also gone ahead and updated this >> compiler to 6.5.0. >> >> I will leave the old ports/packages around for now to permit an easy >> transition, but going forward, the -gcc6 packages should be preferred >> to -xtoolchain-gcc for all but riscv (riscv64-gcc and >> riscv64-xtoolchain-gcc >> are separate from the powerpc64-gcc set of packages). >> >> In addition, I've also just added a devel/freebsd-gcc9 package which >> builds -gcc9 packages. It adds powerpc and riscv flavors relative >> to freebsd-gcc6 and uses GCC 9.2.0. To date in my testing I've yet to >> be able to finish a buildworld on any of the platforms I've tried >> (amd64, mips, sparc64), but the packages should permit other developers >> to get the tree building with GCC 9. To use these packages one would do >> something like: >> >> # pkg install amd64-gcc9 >> # make buildworld CROSS_TOOLCHAIN=amd64-gcc9 >> >> You can install both the gcc6 and gcc9 versions of a package at the same >> time, e.g. amd64-gcc6 and amd64-gcc9. Having different packages for major >> versions is similar to llvm and will also let us keep a known-good >> toolchain package for older 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 variants in the next week or so. >> > > How about base/binutils and base/gcc ? Is their (future?) status > changed by any of this activity? I plan to rename base/gcc to base/gcc6 (and update it to 6.5) and then add a base/gcc9 that would provide GCC 9 as /usr/bin/cc. -- 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"
Re: New external GCC toolchain ports/packages
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 as flavors of a new devel/freebsd-gcc6 >> port. The xtoolchain package is not used for these new packages, instead >> one does 'pkg install mips-gcc6' to get the GCC 6.x MIPS compiler and >> uses 'CROSS_TOOLCHAIN=mips-gcc6'. I've also gone ahead and updated this >> compiler to 6.5.0. >> >> I will leave the old ports/packages around for now to permit an easy >> transition, but going forward, the -gcc6 packages should be preferred >> to -xtoolchain-gcc for all but riscv (riscv64-gcc and >> riscv64-xtoolchain-gcc >> are separate from the powerpc64-gcc set of packages). >> >> In addition, I've also just added a devel/freebsd-gcc9 package which >> builds -gcc9 packages. It adds powerpc and riscv flavors relative >> to freebsd-gcc6 and uses GCC 9.2.0. To date in my testing I've yet to >> be able to finish a buildworld on any of the platforms I've tried >> (amd64, mips, sparc64), but the packages should permit other developers >> to get the tree building with GCC 9. To use these packages one would do >> something like: >> >> # pkg install amd64-gcc9 >> # make buildworld CROSS_TOOLCHAIN=amd64-gcc9 >> >> You can install both the gcc6 and gcc9 versions of a package at the same >> time, e.g. amd64-gcc6 and amd64-gcc9. Having different packages for major >> versions is similar to llvm and will also let us keep a known-good >> toolchain package for older 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 variants in the next week or so. >> >> -- >> John Baldwin > > Awesome, thanks! I was able to get amd64 buildworld and buildkernel to > succeed with just a few changes, and none to the port. I'll work on > getting the changes in. I have been able to get it building as well, mostly by muting a few warnings, adding libcompiler_rt to rtld's link for i386, disabling googletest (needs an upstream patch to stop using signed wchar_t), and a hack to jemalloc. I was able to build riscv as well with those same changes and am working through builds of other platforms. I'm happy to compare notes. The jemalloc one is a bit weird. -- 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"
Re: A devel/freebsd-gcc*/Makefile suggestion to avoid base/binutil preventing freebsd-gcc* builds
On 12/26/19 7:54 PM, Mark Millard wrote:
> Context: devel/freebsd-gcc* (for example)
> using:
>
> --with-as=${LOCALBASE}/bin/${BU_PREFIX}-as \
> --with-ld=${LOCALBASE}/bin/${BU_PREFIX}-ld
>
> The likes of ${BU_PREFIX}-ld possibly also
> exists someplace else on the path in use.
> So I suggest that the BUILD_DEPENDS and
> RUN_DEPENDS cause the full path to be
> checked so that the full path will be
> created if they do not exist already.
> So, using devel/freebsd-gcc9 as an example,
> . . .
>
>
> # svnlite diff /usr/ports/devel/freebsd-gcc9/
> Index: /usr/ports/devel/freebsd-gcc9/Makefile
> ===
> --- /usr/ports/devel/freebsd-gcc9/Makefile(revision 520539)
> +++ /usr/ports/devel/freebsd-gcc9/Makefile(working copy)
> @@ -16,8 +16,8 @@
> LIB_DEPENDS= libgmp.so:math/gmp \
> libmpfr.so:math/mpfr \
> libmpc.so:math/mpc
> -BUILD_DEPENDS= ${BU_PREFIX}-as:devel/binutils@${TARGETARCH}
> -RUN_DEPENDS= ${BU_PREFIX}-as:devel/binutils@${TARGETARCH}
> +BUILD_DEPENDS= ${LOCALBASE}/bin/${BU_PREFIX}-as:devel/binutils@${TARGETARCH}
> +RUN_DEPENDS=${LOCALBASE}/bin/${BU_PREFIX}-as:devel/binutils@${TARGETARCH}
>
> FLAVORS= aarch64 amd64 i386 mips mips64 powerpc powerpc64 riscv64 sparc64
> TARGETARCH= ${FLAVOR}
>
> This avoids later not finding the file via
> the full path in such contexts.
I don't see why this would ever be the case that we'd have, say,
x86_64-unknown-freebsd13.0-ld anywhere but in LOCALBASE from the
amd64-binutils package.
base/binutils only installs /usr/bin/ld and /usr/${BUTARGET}/bin/ld.
It doesn'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 list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: devel/freebsd-gcc9@powerpc (for example) : it has the clang vs. gcc vec_step name conflict (for powerpc families): build fails under clang
On 12/26/19 11:39 PM, Mark Millard wrote: >>> is missing the patch-clang-vec_step that is in: >>> >>> FBSDG5L2# ls -laT /usr/ports/lang/gcc9/files/ >> >> That is a hack that can be used to work around the issue; I strongly >> recommend addressing this 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/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: devel/aarch64-none-elf-gcc build failed with long list of "pkg-static: Unable to access file . . ." during package stage
On 12/28/19 1:27 PM, Mark Millard wrote: > Stop. > make: stopped in /usr/ports/devel/aarch64-none-elf-gcc > =>> Cleaning up wrkdir > ===> Cleaning for aarch64-none-elf-gcc-6.4.0_7 > build of devel/aarch64-none-elf-gcc | aarch64-none-elf-gcc-6.4.0_7 ended at > Sat Dec 28 04:40:12 PST 2019 > > FreeBSD head -r356109 based context. > ports -r520539 based context. I intentionally don't maintain the non-xtoolchain gcc's. :) Probably these need the PLUGINS plist treatment that devel/freebsd-gcc* use. Alternatively, it might be nice to figure out why 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"
Re: svn commit: r356289 - head
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 >>> URL: https://svnweb.freebsd.org/changeset/base/356289 >>> >>> Log: >>> Look for cross toolchain makefiles in /usr/share/toolchains. >>> >>> The freebsd-binutils and freebsd-gcc* packages install toolchain >>> makefiles to /usr/share/toolchains rather than LOCALBASE. >> >> The short version is that you can do something like this to use GCC >> as the system compiler (/usr/bin/cc): >> >> cd /usr/ports/base/binutils ; make install clean >> cd ../gcc6 ; make install clean >> >> Then 'make CROSS_TOOLCHAIN=freebsd-gcc6 buildworld', etc. If you aren't >> planning on doing cross-builds you can set CROSS_TOOLCHAIN in /etc/src.conf. >> >> As described elsewhere, the base/* packages can be cross-built (along >> with pkg), so for any architectures not yet using clang we could fairly >> easily provide a cross-built package repo (though that architecture list >> is becoming rather small). I will probably add a base/gcc9 port once we >> can build a full system with gcc9. > > Just an FYI from some experiments that I did recently: > > devel/binutils@powerpc and devel/binutils@powerpc64 and > base/binutils@powerpc and base_binutils@powerpc64 do > not put out the same content as lld or the old > toolchain's ld (still used normally for 32-bit powerpc). > buildkernel runs to completion but the result > crashes from the kernel sseflf-loading and what was > produced not matching. For example, binutils put out > very few ABS symbols compared to lld/old-ld and > classifies the kernel as ET_EXEC, not ET_DYN, because > of the non-zero VirtAddr in: > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > . . . > LOAD 0x00 0x0010 0x0010 0xd9786c 0x1083648 RWE 0x1 > . . . > > (I'm not claiming that is all there is that matters.) > > > These points are true using system-clang as the > compiler. (I've only cross-built so far.) > > I do not know if other architectures have similar issues > or not. But, it appears that in some cases, there is more > work to allowing the GNU linker to be used, for at least > buildkernel . > > I do not know if there is an intent to support a (modern) > GNU binutils ld (in addition to lld) or not. So it may be > that the effort would not be put in. (I'm not claiming > which side(s) would change if the effort was put in.) I have only really tested amd64, mips, and risc-v with GCC. Other platform maintainers would have to work through any MD issues. The expectation is that GCC + ld.bfd should hopefully work as well as clang + lld. Trying to cross-thread those (GCC + lld or clang + ld.bfd) might also work in theory, but is a bit harder to guarantee, especially GCC + lld. -- 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"
Re: head -r358966 on aarch64 fails to build base/gcc6: fatal error: bracket nesting level exceeded maximum of 256
On 3/20/20 11:02 PM, Mark Millard wrote: > While trying to build base/gcc6 on aarch64 (implicitly targeting aarch64: > self hosted), it failed with: > > . . . > c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is > deprecated [-Wdeprecated] > /wrkdirs/usr/ports/base/gcc6/work/gcc-6.5.0/gcc/config/aarch64/aarch64.md:817:10873: > fatal error: bracket nesting level exceeded maximum of 256 > /wrkdirs/usr/ports/base/gcc6/work/gcc-6.5.0/gcc/config/aarch64/aarch64.md:817:10873: > note: use -fbracket-depth=N to increase maximum nesting level > 116 warnings and 1 error generated. > gmake[2]: *** [Makefile:1086: insn-attrtab.o] Error 1 > gmake[2]: *** Waiting for unfinished jobs > . . . > > amd64 (implicitly targeting amd64: self hosted) did not have the problem. > > (These were just build-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 probably need the same fix for base/gcc when the build host is aarch64. -- 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"
