On Wed, 24 Apr 2019 at 13:03, Kamil Rytarowski <n...@gmx.com> wrote:
>
> On 24.04.2019 03:30, Iain Buclaw wrote:
> > On Wed, 24 Apr 2019 at 01:56, Kamil Rytarowski <n...@gmx.com> wrote:
> >>
> >> On 24.04.2019 01:13, Iain Buclaw wrote:
> >>> Hi,
> >>>
> >>> This patch adds missing implementation of TARGET_D_CRITSEC_SIZE, which
> >>> would be noticed when using any bare synchronized statements.
> >>>
> >>> I couldn't see any target-specific alternatives of pthread_mutex_t in
> >>> netbsd headers, so the condition should be right.
> >>>
> >>> OK for trunk?
> >>>
> >>
> >> This patch is wrong.
> >>
> >> sizeof(pthread_mutex_t) depends on CPU.
> >>
> >> Just check that __cpu_simple_lock_nv_t that can be char, int, struct.
> >>
> >
> > Ah, thanks for pointing to that. I've made a small working example,
> > and it looks like only three have a different size, aarch64, hppa, and
> > hppa64.
> >
> > https://explore.dgnu.org/z/U29cni
> >
> > I'll add special handling for them, but otherwise 48/28 looks like the
> > reasonable default.
> >
>
> I recommend to solve it differently: autodetect the size during
> ./configure. I'm not sure that it is still correct.
>
That would not work when building crosses.
> The sizes can also change over time. There is coming refactoring of
> libpthread(3) in NetBSD that can change sizes of these types, at least
> on some platforms.
>
Maybe explaining the intended use better might help. This is only for
the following lowering done in the front-end (my upstream):
synchronized { var = 0; }
Loosely converted into equivalent C.
static char __critsec64[48];
_d_criticalenter(& __critsec64);
var = 0;
_d_criticalexit(& __critsec64);
So long as the statically allocated pthread_mutex_t is big enough,
there should be no problems.
--
Iain
