On 11.05.2020 16:19, Joerg Sonnenberger wrote:
> On Mon, May 11, 2020 at 11:38:28AM +0200, Kamil Rytarowski wrote:
>> On 11.05.2020 01:49, Joerg Sonnenberger wrote:
>>> On Mon, May 11, 2020 at 01:11:32AM +0200, Kamil Rytarowski wrote:
On 10.05.2020 18:38, Kamil Rytarowski wrote:
> LLDB wi
On Mon, May 11, 2020 at 11:38:28AM +0200, Kamil Rytarowski wrote:
> On 11.05.2020 01:49, Joerg Sonnenberger wrote:
> > On Mon, May 11, 2020 at 01:11:32AM +0200, Kamil Rytarowski wrote:
> >> On 10.05.2020 18:38, Kamil Rytarowski wrote:
> >>> LLDB will be patched to avoid atomics.
> >> I have checke
On 11.05.2020 01:49, Joerg Sonnenberger wrote:
> On Mon, May 11, 2020 at 01:11:32AM +0200, Kamil Rytarowski wrote:
>> On 10.05.2020 18:38, Kamil Rytarowski wrote:
>>> LLDB will be patched to avoid atomics.
>> I have checked LLDB and std::atomic is used on purpose and was
>> switched from mutexes 3
Kamil Rytarowski wrote:
> I have checked LLDB and std::atomic is used on purpose and was
> switched from mutexes 3 years ago.
I guess that explains why so many packages now break on i386 because the
lack of 64 bit atomic operations. libreoffice and freeradius are that
last one I stumbled upon. I
On Mon, May 11, 2020 at 01:11:32AM +0200, Kamil Rytarowski wrote:
> On 10.05.2020 18:38, Kamil Rytarowski wrote:
> > LLDB will be patched to avoid atomics.
> I have checked LLDB and std::atomic is used on purpose and was
> switched from mutexes 3 years ago.
>
> https://github.com/llvm/llvm-projec
On 10.05.2020 18:38, Kamil Rytarowski wrote:
> LLDB will be patched to avoid atomics.
I have checked LLDB and std::atomic is used on purpose and was
switched from mutexes 3 years ago.
https://github.com/llvm/llvm-project/commit/f9d16476573e16856bdb3250c817b0a2c631d2b1
Reverting this (or rewritin
In article <9d775d79-026a-f52a-ae3c-39a00eea4...@gmx.com>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 08.05.2020 21:33, m...@netbsd.org wrote:
>> On Fri, May 08, 2020 at 04:09:02PM +0200, Kamil Rytarowski wrote:
>>> I object to opinions that libatomic is generally broken, if that wou
Le dim. 10 mai 2020 à 22:16, Joerg Sonnenberger a écrit :
> Emitting libcalls for 128bit atomics when explicitly instructed that
> the support is present is a bug. That's why this is an issue with GCC
> and not with Clang.
Of course, no argument here, the GCC bug needs to be fixed regardless,
if
On Sun, May 10, 2020 at 10:03:27PM +0200, Jaromír Doleček wrote:
> Le dim. 10 mai 2020 à 20:25, Joerg Sonnenberger a écrit :
> > I find it funny that you pick an example where correctly working
> > atomic implementation is essential and where the only reason it is
> > pulled in is a bug in GCC.
>
On 10.05.2020 20:25, Joerg Sonnenberger wrote:
> On Sun, May 10, 2020 at 06:16:49PM +0200, Kamil Rytarowski wrote:
>> On 08.05.2020 21:33, m...@netbsd.org wrote:
>>> On Fri, May 08, 2020 at 04:09:02PM +0200, Kamil Rytarowski wrote:
I object to opinions that libatomic is generally broken, if th
Le dim. 10 mai 2020 à 20:25, Joerg Sonnenberger a écrit :
> I find it funny that you pick an example where correctly working
> atomic implementation is essential and where the only reason it is
> pulled in is a bug in GCC.
Yet the developers made conscious choice to depend on libatomic by
explici
On Sun, May 10, 2020 at 06:16:49PM +0200, Kamil Rytarowski wrote:
> On 08.05.2020 21:33, m...@netbsd.org wrote:
> > On Fri, May 08, 2020 at 04:09:02PM +0200, Kamil Rytarowski wrote:
> >> I object to opinions that libatomic is generally broken, if that would
> >> be the cause, it wouldn't be availab
On 09.05.2020 18:51, Christos Zoulas wrote:
> I am with Martin here. This belongs in pkgsrc and not in base. There is
> an overhead using libatomic and we should not be penalizing everyone.
> There are very few cases where applications should be using raw atomics,
> and in these situations the appl
On 08.05.2020 21:33, m...@netbsd.org wrote:
> On Fri, May 08, 2020 at 04:09:02PM +0200, Kamil Rytarowski wrote:
>> I object to opinions that libatomic is generally broken, if that would
>> be the cause, it wouldn't be available and used on relatively all
>> relevant generic purpose Operating System
In article <20200509045010.gb4...@mail.duskware.de>,
Martin Husemann wrote:
>On Fri, May 08, 2020 at 10:24:43PM +, m...@netbsd.org wrote:
>> The indirection only applies to the first call. The magic is within
>> rtld.
>
>You are comparing PLT calls with ifunc (where even normal PLT calls have
On Fri, May 08, 2020 at 10:24:43PM +, m...@netbsd.org wrote:
> The indirection only applies to the first call. The magic is within
> rtld.
You are comparing PLT calls with ifunc (where even normal PLT calls have
initial resolution overhead, but very tiny - while ifuncs may have
arbitrary first
On Fri, May 08, 2020 at 10:24:43PM +, m...@netbsd.org wrote:
>
> The indirection only applies to the first call. The magic is within
> rtld.
If it's not binary patch, no magic can avoid at least one level of
indirection.
--
Thor Lancelot Simon t...@p
On Fri, May 08, 2020 at 06:23:01PM -0400, Thor Lancelot Simon wrote:
> On Fri, May 08, 2020 at 10:03:06AM +0200, Kamil Rytarowski wrote:
> > On 08.05.2020 02:14, Thor Lancelot Simon wrote:
> > >
> > > Not without performance penalty for every atomic operation, unless you
> > > propose
> > > to do
On Fri, May 08, 2020 at 10:03:06AM +0200, Kamil Rytarowski wrote:
> On 08.05.2020 02:14, Thor Lancelot Simon wrote:
> >
> > Not without performance penalty for every atomic operation, unless you
> > propose
> > to do this by binary patch as is done in the kernel.
>
> There is atomic penalty, but
On Fri, May 08, 2020 at 04:09:02PM +0200, Kamil Rytarowski wrote:
> I object to opinions that libatomic is generally broken, if that would
> be the cause, it wouldn't be available and used on relatively all
> relevant generic purpose Operating Systems. Personally, I already
> received last year a f
On 08.05.2020 14:44, Martin Husemann wrote:
> On Fri, May 08, 2020 at 02:26:45PM +0200, Kamil Rytarowski wrote:
>> With _Atomic() we can mark any arbitrary struct to have serialized
>> accesses. As I said, with your attitude we shall remove FPU support (and
>> softfloat) as they are not async safe,
On Fri, May 08, 2020 at 02:44:14PM +0200, Martin Husemann wrote:
> On Fri, May 08, 2020 at 02:26:45PM +0200, Kamil Rytarowski wrote:
> > With _Atomic() we can mark any arbitrary struct to have serialized
> > accesses. As I said, with your attitude we shall remove FPU support (and
> > softfloat) as
On Fri, May 08, 2020 at 02:26:45PM +0200, Kamil Rytarowski wrote:
> With _Atomic() we can mark any arbitrary struct to have serialized
> accesses. As I said, with your attitude we shall remove FPU support (and
> softfloat) as they are not async safe, not safe in virtualization for
> MMU accesses an
On 08.05.2020 14:12, Joerg Sonnenberger wrote:
> On Thu, May 07, 2020 at 11:09:03PM +0200, Kamil Rytarowski wrote:
>>> (1) They introduce non-trivial blocking conditions, often defeating the
>>> reason for using atomics in first place.
>>> (2) They don't work in a constrained environment and are br
On Thu, May 07, 2020 at 10:49:39PM +, m...@netbsd.org wrote:
> I am under the impression that (at least GCC) compilers will not emit
> intrinsic calls if they are guaranteed to be available on the target.
This is true, but only a minor complication compared to the rest.
Joerg
On Thu, May 07, 2020 at 11:09:03PM +0200, Kamil Rytarowski wrote:
> > (1) They introduce non-trivial blocking conditions, often defeating the
> > reason for using atomics in first place.
> > (2) They don't work in a constrained environment and are broken by
> > common UNIX primitives like memory ma
On 08.05.2020 02:14, Thor Lancelot Simon wrote:
> On Fri, May 08, 2020 at 01:51:16AM +0200, Kamil Rytarowski wrote:
>> A runtime detection could be a part of ifunc (is it ready for NetBSD?).
>>
>> The standard C/C++ feature is to detect whether atomic operations are
>> real (lock-free) through atom
On Thu, May 07, 2020 at 08:14:57PM -0400, Thor Lancelot Simon wrote:
> On Fri, May 08, 2020 at 01:51:16AM +0200, Kamil Rytarowski wrote:
> > A runtime detection could be a part of ifunc (is it ready for NetBSD?).
> >
> > The standard C/C++ feature is to detect whether atomic operations are
> > rea
On Fri, May 08, 2020 at 01:51:16AM +0200, Kamil Rytarowski wrote:
> A runtime detection could be a part of ifunc (is it ready for NetBSD?).
>
> The standard C/C++ feature is to detect whether atomic operations are
> real (lock-free) through atomic_is_lock_free(). This is a feature, not a
> bug (as
On 08.05.2020 00:49, m...@netbsd.org wrote:
> I am under the impression that (at least GCC) compilers will not emit
> intrinsic calls if they are guaranteed to be available on the target.
>
> This means libatomic needs to:
>
> - Optimize: we can runtime detect, which emitted code cannot do.
>
>
I am under the impression that (at least GCC) compilers will not emit
intrinsic calls if they are guaranteed to be available on the target.
This means libatomic needs to:
- Optimize: we can runtime detect, which emitted code cannot do.
Note that this means providing this libatomic will cause us
On 07.05.2020 22:45, Joerg Sonnenberger wrote:
> On Thu, May 07, 2020 at 10:13:30PM +0200, Kamil Rytarowski wrote:
>> On 07.05.2020 21:45, Joerg Sonnenberger wrote:
>>> On Thu, May 07, 2020 at 05:43:02AM +0200, Kamil Rytarowski wrote:
Lack of libatomic is increasingly hard to deal with. This l
On Thu, May 07, 2020 at 10:13:30PM +0200, Kamil Rytarowski wrote:
> On 07.05.2020 21:45, Joerg Sonnenberger wrote:
> > On Thu, May 07, 2020 at 05:43:02AM +0200, Kamil Rytarowski wrote:
> >> Lack of libatomic is increasingly hard to deal with. This library
> >> implements function calls for atomic o
On 07.05.2020 21:45, Joerg Sonnenberger wrote:
> On Thu, May 07, 2020 at 05:43:02AM +0200, Kamil Rytarowski wrote:
>> Lack of libatomic is increasingly hard to deal with. This library
>> implements function calls for atomic operations.
>
> I'm sure you have done the research on why the existing ar
On Thu, May 07, 2020 at 05:43:02AM +0200, Kamil Rytarowski wrote:
> Lack of libatomic is increasingly hard to deal with. This library
> implements function calls for atomic operations.
I'm sure you have done the research on why the existing arguments
against providing libatomic are wrong. For some
On 07.05.2020 05:56, Martin Husemann wrote:
> On Thu, May 07, 2020 at 05:43:02AM +0200, Kamil Rytarowski wrote:
>> I propose the following patch:
>>
>> http://netbsd.org/~kamil/patch-00250-libatomic.txt
>
> +__inline static int
> +__futex(volatile uint32_t *uaddr, int op, int val, const struct tim
On Thu, May 07, 2020 at 05:43:02AM +0200, Kamil Rytarowski wrote:
> I propose the following patch:
>
> http://netbsd.org/~kamil/patch-00250-libatomic.txt
+__inline static int
+__futex(volatile uint32_t *uaddr, int op, int val, const struct timespec
*timeout,
+volatile uint32_t *uaddr2, i
Lack of libatomic is increasingly hard to deal with. This library
implements function calls for atomic operations.
Personally I stopped testing sanitizers year ago as they required
libatomic. We want libatomic for LLDB in base. Rewritting everything to
stop using libatomic is no viable as this is
38 matches
Mail list logo
