On 5/4/22 12:53 PM, Steve Kargl wrote:
On Wed, May 04, 2022 at 11:12:55AM -0700, John Baldwin wrote:
On 5/2/22 10:37 AM, Steve Kargl wrote:
On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote:
On Sun, 1 May 2022 at 11:54, Steve Kargl
<s...@troutmask.apl.washington.edu> wrote:
diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h
index 594487829b5..1e8ab2e1827 100644
--- a/gcc/config/freebsd-spec.h
+++ b/gcc/config/freebsd-spec.h
@@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
If not, see
(similar to the default, except no -lg, and no -p). */
#ifdef FBSD_NO_THREADS
I wonder if we can simplify things now, and remove this
`FBSD_NO_THREADS` case. I didn't see anything similar in other GCC
targets I looked at.
That I don't know. FBSD_NO_THREADS is defined in freebsd-nthr.h.
In fact, it's the only thing in that header (except copyright
broilerplate). freebsd-nthr.h only appears in config.gcc and
seems to only get added to the build if someone runs configure
with --enable-threads=no. Looking at my last config.log for
gcc trunk, I see "Thread model: posix", which appears to be
the default case or if someone does --enable-threads=yes or
--enable-threads=posix. So, I suppose it comes down to
two questions: (1) is libpthread.* available on all supported
targets and versions? (2) does anyone build gcc without
threads support?
libpthread is available on all supported architectures on all
supported versions. libthr has been the default threading library
since 7.0 and the only supported library since 8.0. In GDB I just
assume libthr style threads, and I think GCC can safely do the
same.
I don't know the entire FreeBSD ecosystem. Do people
use FreeBSD on embedded systems (e.g., nanobsd) where
libthr may be stripped out? Thus, --enable-threads=no
is needed.
If they do, they are also using a constrained userland and
probably are not shipping a GCC binary either. However, it's
not clear to me what --enable-threads means.
Does this enable -pthread as an option? If so, that should
definitely just always be on. It's still an option users have
to opt into via a command line flag and doesn't prevent
building non-threaded programs.
If it's enabling use of threads at runtime within GCC itself,
I'd say that also should probably just be allowed to be on.
I can't really imagine what else it might mean (and I doubt
it means the latter).
--
John Baldwin
