Re: Profiled libraries on freebsd-current

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
>>>> <sgk@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