Re: CVS commit: src/external/gpl3/gcc

2020-09-12 Thread Kamil Rytarowski
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

2020-09-12 Thread Joerg Sonnenberger
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

2020-09-12 Thread Kamil Rytarowski
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

2020-09-12 Thread Joerg Sonnenberger
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

2020-09-12 Thread Steffen Nurpmeso
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

2020-09-12 Thread Kamil Rytarowski
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

2020-09-12 Thread Jared McNeill

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