This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
On Jan 11 22:01, Andrew Pinski wrote:
> On Mon, Jan 11, 2016 at 6:17 PM, Zaibo Xu <xuzaibo@huawei.com> wrote:
> > 1. _VOID _DEFUN(__sinit, (s), struct _reent *s) in ./newlib/libc/stdio/findfp.c.
> > 2. struct _reent in ./newlib/libc/include/sys/reent.h
> > Reasons: We have fount this bug in debuging the function of printf on
> > Sandybridge of Intel as multiple cores print to the cluster communication
> > port at the same time. After the mending above, this bug is fixed.
> >
> > Signed-off-by: Zaibo Xu <xuzaibo@huawei.com>
> > ---
> > newlib/libc/include/sys/reent.h | 4 ++--
> > newlib/libc/stdio/findfp.c | 3 +++
> > 2 files changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/newlib/libc/include/sys/reent.h b/newlib/libc/include/sys/reent.h
> > index 5481ca2..7b882fa 100644
> > --- a/newlib/libc/include/sys/reent.h
> > +++ b/newlib/libc/include/sys/reent.h
> > @@ -382,7 +382,7 @@ struct _reent
> >
> > char *_emergency;
> >
> > - int __sdidinit; /* 1 means stdio has been init'd */
> > + volatile int __sdidinit; /* 1 means stdio has been init'd */
> >
> > int _current_category; /* unused */
> > _CONST char *_current_locale; /* unused */
> > @@ -580,7 +580,7 @@ struct _reent
> > int _current_category; /* used by setlocale */
> > _CONST char *_current_locale;
> >
> > - int __sdidinit; /* 1 means stdio has been init'd */
> > + volatile int __sdidinit; /* 1 means stdio has been init'd */
> >
> > void _EXFNPTR(__cleanup, (struct _reent *));
> >
> > diff --git a/newlib/libc/stdio/findfp.c b/newlib/libc/stdio/findfp.c
> > index 975a855..460809a 100644
> > --- a/newlib/libc/stdio/findfp.c
> > +++ b/newlib/libc/stdio/findfp.c
> > @@ -210,6 +210,7 @@ _DEFUN(__sinit, (s),
> > {
> > __sinit_lock_acquire ();
> >
> > + asm volatile("mfence;":::"memory");
>
>
> __sinit_lock_acquire should be enough for the lock here I think. If
> it is not then the bug is there instead of here.
>
> > if (s->__sdidinit)
> > {
> > __sinit_lock_release ();
> > @@ -254,8 +255,10 @@ _DEFUN(__sinit, (s),
> > when the underlying fd 2 is write-only. */
> > std (s->_stderr, __SRW | __SNBF, 2, s);
> >
> > + asm volatile("mfence;":::"memory");
> > s->__sdidinit = 1;
> >
> > + asm volatile("mfence;":::"memory");
> > __sinit_lock_release ();
>
> __sinit_lock_release should be enough here and if it is not then the
> bug is there instead.
Good point. How are __sinit_lock_acquire/__sinit_lock_release defined
on that system?
Corinna
--
Corinna Vinschen
Cygwin Maintainer
Red Hat
Attachment:
signature.asc
Description: PGP signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |