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
37 matches
Mail list logo
