Re: CVS commit: src/external/gpl3/gcc
On 12.09.2020 23:36, Joerg Sonnenberger wrote: > On Sat, Sep 12, 2020 at 10:24:16PM +0200, Kamil Rytarowski wrote: >> On 12.09.2020 22:06, Joerg Sonnenberger wrote: >>> On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote: On 11.09.2020 23:38, Joerg Sonnenberger wrote: > On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote: >> The current code is confusing, as it attempts to use unimplemented >> _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in >> other _lwp_getprivate(). This caused my confusion... as I assumed that >> _lwp_getprivate_fast() is internal and _lwp_getprivate() for public >> consumption. > > _PTHREAD_GETTCB_EXT is a rump hack. There is no _lwp_getprivate_fast. > There is __lwp_getprivate_fast, which originally wasn't implemented on > architectures without a fast path (like VAX). Nowadays, all functional > ports provide either __lwp_getprivate_fast (potentially with a fall-back > to the system call) or __lwp_gettcb_fast. The difference is whether the > TLS register is biased or not. > Do you agree with this patch: http://netbsd.org/~kamil/patch-00278-_rtld_tls_self.txt >>> >>> No, I don't see the point. >>> >> >> What's the alternative to use in 3rd party code? > > Why do you need an alternative? > I need tls_tcb of the calling thread. https://github.com/llvm/llvm-project/blob/15b37e1cfa5f09af376a47a1bc67d67bb5c7848b/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp#L406 https://github.com/llvm/llvm-project/blob/15b37e1cfa5f09af376a47a1bc67d67bb5c7848b/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp#L458 What is the interface (ideally MI) for this for 3rd party code? > Joerg > signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/external/gpl3/gcc
On Sat, Sep 12, 2020 at 10:24:16PM +0200, Kamil Rytarowski wrote: > On 12.09.2020 22:06, Joerg Sonnenberger wrote: > > On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote: > >> On 11.09.2020 23:38, Joerg Sonnenberger wrote: > >>> On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote: > The current code is confusing, as it attempts to use unimplemented > _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in > other _lwp_getprivate(). This caused my confusion... as I assumed that > _lwp_getprivate_fast() is internal and _lwp_getprivate() for public > consumption. > >>> > >>> _PTHREAD_GETTCB_EXT is a rump hack. There is no _lwp_getprivate_fast. > >>> There is __lwp_getprivate_fast, which originally wasn't implemented on > >>> architectures without a fast path (like VAX). Nowadays, all functional > >>> ports provide either __lwp_getprivate_fast (potentially with a fall-back > >>> to the system call) or __lwp_gettcb_fast. The difference is whether the > >>> TLS register is biased or not. > >>> > >> > >> Do you agree with this patch: > >> > >> http://netbsd.org/~kamil/patch-00278-_rtld_tls_self.txt > > > > No, I don't see the point. > > > > What's the alternative to use in 3rd party code? Why do you need an alternative? Joerg
Re: CVS commit: src/external/gpl3/gcc
On 12.09.2020 22:06, Joerg Sonnenberger wrote: > On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote: >> On 11.09.2020 23:38, Joerg Sonnenberger wrote: >>> On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote: The current code is confusing, as it attempts to use unimplemented _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in other _lwp_getprivate(). This caused my confusion... as I assumed that _lwp_getprivate_fast() is internal and _lwp_getprivate() for public consumption. >>> >>> _PTHREAD_GETTCB_EXT is a rump hack. There is no _lwp_getprivate_fast. >>> There is __lwp_getprivate_fast, which originally wasn't implemented on >>> architectures without a fast path (like VAX). Nowadays, all functional >>> ports provide either __lwp_getprivate_fast (potentially with a fall-back >>> to the system call) or __lwp_gettcb_fast. The difference is whether the >>> TLS register is biased or not. >>> >> >> Do you agree with this patch: >> >> http://netbsd.org/~kamil/patch-00278-_rtld_tls_self.txt > > No, I don't see the point. > What's the alternative to use in 3rd party code? > Joerg > signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/external/gpl3/gcc
On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote: > On 11.09.2020 23:38, Joerg Sonnenberger wrote: > > On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote: > >> The current code is confusing, as it attempts to use unimplemented > >> _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in > >> other _lwp_getprivate(). This caused my confusion... as I assumed that > >> _lwp_getprivate_fast() is internal and _lwp_getprivate() for public > >> consumption. > > > > _PTHREAD_GETTCB_EXT is a rump hack. There is no _lwp_getprivate_fast. > > There is __lwp_getprivate_fast, which originally wasn't implemented on > > architectures without a fast path (like VAX). Nowadays, all functional > > ports provide either __lwp_getprivate_fast (potentially with a fall-back > > to the system call) or __lwp_gettcb_fast. The difference is whether the > > TLS register is biased or not. > > > > Do you agree with this patch: > > http://netbsd.org/~kamil/patch-00278-_rtld_tls_self.txt No, I don't see the point. Joerg
Re: CVS commit: src/libexec/httpd
Jared McNeill wrote in
:
|On Sat, 12 Sep 2020, Olaf Seibert wrote:
|
|> bozohttpd: add .m4a and .m4v file extensions.
|
|I don't think audio/mpeg is correct for .m4a. Since .m4a is MPEG audio in
|an MP4 container, I would follow RFC 4337 ("MIME Type Registration for
|MPEG-4") here which says you should use audio/mp4 instead.
audio/mp4 mp4 mp4a m4a m4b
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: CVS commit: src
On 11.09.2020 06:57, Rin Okuyama wrote: > On 2020/09/10 18:28, Kamil Rytarowski wrote: >> On 10.09.2020 10:50, Rin Okuyama wrote: >>> On 2020/09/10 16:41, Kamil Rytarowski wrote: On 10.09.2020 03:53, Rin Okuyama wrote: > Module Name: src > Committed By: rin > Date: Thu Sep 10 01:53:22 UTC 2020 > > Modified Files: > src/distrib/sets/lists/base: mi > src/distrib/sets/lists/comp: mi > src/sys/dev: Makefile > > Log Message: > Unconditionally install kernel headers for iSCSI as required by > sanitizer shipped with GCC9. > > Fix build release with HAVE_GCC=9 for sun2, where MKISCSI=no by > default. > Please redo this commit with __has_include(), example: https://github.com/llvm/llvm-project/commit/7f6b25ad1bb3f8057655a9bad2a3b69621f4a543#diff-fa188a123646bb8c30d7fa22d61ef680 >>> >>> Hmm, I'm not sure whether it is worth the maintenance cost and >>> complexities it adds... Is there any reason why we should not >>> install these headers? >>> >> >> The headers are optional and sanitizers shall not dictate what headers >> are installed. >> >> Meanwhile, I'm going to do this in upstream LLVM. > > Yes, I really appreciate your continuous efforts in syncing our > codes with upstream. > > However, still, there is ``the maintenance cost'' in our local > repository. With __has_include(), we must maintain two copies of > headers in the tree. This is dangerous potentially. > There is no danger in terms of security. > My question was whether it is worth the risk not to install few > number of small headers. > I've updated the LLVM interceptors. Please revert. > Thanks, > rin signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/libexec/httpd
On Sat, 12 Sep 2020, Olaf Seibert wrote:
bozohttpd: add .m4a and .m4v file extensions.
I don't think audio/mpeg is correct for .m4a. Since .m4a is MPEG audio in
an MP4 container, I would follow RFC 4337 ("MIME Type Registration for
MPEG-4") here which says you should use audio/mp4 instead.
Take care,
Jared
