On 03/02/15 09:19, Ilya Enkovich wrote:
On 09 Dec 23:56, Ilya Enkovich wrote:
2014-12-09 22:57 GMT+03:00 Jeff Law :
Wasn't this duplicated in the mpx-wrapper patch?
Wrappers patch introduces similar option static-libmpxwrappers.
I think this is OK on the technical side. I need to do to s
On 09 Dec 23:56, Ilya Enkovich wrote:
> 2014-12-09 22:57 GMT+03:00 Jeff Law :
> >
> > Wasn't this duplicated in the mpx-wrapper patch?
>
> Wrappers patch introduces similar option static-libmpxwrappers.
>
> >
> > I think this is OK on the technical side. I need to do to some vote
> > tallying on
2014-12-09 22:57 GMT+03:00 Jeff Law :
> On 12/09/14 01:24, Ilya Enkovich wrote:
>>
>> On 24 Nov 17:02, Ilya Enkovich wrote:
>>>
>>>
>>> Right. This works for both top level and multilib checks because failing
>>> test is used and CC is usually not set when it's called by the top level
>>> configur
On 12/09/14 01:24, Ilya Enkovich wrote:
On 24 Nov 17:02, Ilya Enkovich wrote:
Right. This works for both top level and multilib checks because failing test
is used and CC is usually not set when it's called by the top level configure.
If we configure with CC=... then it may go wrong. I lef
On 24 Nov 17:02, Ilya Enkovich wrote:
>
> Right. This works for both top level and multilib checks because failing
> test is used and CC is usually not set when it's called by the top level
> configure. If we configure with CC=... then it may go wrong. I left only
> target check in configure
On 21 Nov 23:20, Joseph Myers wrote:
> On Fri, 21 Nov 2014, Ilya Enkovich wrote:
>
> > +# Disable libmpx on unsupported systems.
> > +if test -d ${srcdir}/libmpx; then
> > +if test x$enable_libmpx = x; then
> > + AC_MSG_CHECKING([for libmpx support])
> > + if (srcdir=${srcdir}/libm
On Wed, 19 Nov 2014, Ilya Enkovich wrote:
> > If it's intended only as the latter - and this is documented - then you
> > don't have the libgcc-like requirements, and there's no point in having
> > multiple libraries. If it's intended for both, that points the way to
> > separate libraries (wh
On Fri, 21 Nov 2014, Ilya Enkovich wrote:
> +# Disable libmpx on unsupported systems.
> +if test -d ${srcdir}/libmpx; then
> +if test x$enable_libmpx = x; then
> + AC_MSG_CHECKING([for libmpx support])
> + if (srcdir=${srcdir}/libmpx; \
> + . ${srcdir}/configure.tgt;
On 19 Nov 21:11, Ilya Enkovich wrote:
> 2014-11-19 20:55 GMT+03:00 Jeff Law :
> > On 11/19/14 07:15, Ilya Enkovich wrote:
> >
> >> --
> >> 2014-11-19 Ilya Enkovich
> >>
> >> * Makefile.def: Add libmpx.
> >> * configure.ac: Add libmpx.
> >> * Makefile.in: Regenerate.
> >>
2014-11-19 20:55 GMT+03:00 Jeff Law :
> On 11/19/14 07:15, Ilya Enkovich wrote:
>
>> --
>> 2014-11-19 Ilya Enkovich
>>
>> * Makefile.def: Add libmpx.
>> * configure.ac: Add libmpx.
>> * Makefile.in: Regenerate.
>> * configure: Regenerate.
>>
>> gcc/
>>
>> 2014-11-
On 11/19/14 07:15, Ilya Enkovich wrote:
--
2014-11-19 Ilya Enkovich
* Makefile.def: Add libmpx.
* configure.ac: Add libmpx.
* Makefile.in: Regenerate.
* configure: Regenerate.
gcc/
2014-11-19 Ilya Enkovich
* gcc.c (LIBMPX_LIBS): New.
(LIB
On 13 Nov 20:56, Joseph Myers wrote:
> On Thu, 13 Nov 2014, Ilya Enkovich wrote:
>
> > > You can leave it as a single library - it's just that imposes libgcc-like
> > > constraints on what the library does and how it does things, so as to be
> > > usable for arbitrary programs built with MPX (e.g.
On Thu, 13 Nov 2014, Ilya Enkovich wrote:
> > You can leave it as a single library - it's just that imposes libgcc-like
> > constraints on what the library does and how it does things, so as to be
> > usable for arbitrary programs built with MPX (e.g. using
> > reserved-namespace names such as __w
2014-11-13 2:03 GMT+03:00 Joseph Myers :
> On Thu, 13 Nov 2014, Ilya Enkovich wrote:
>
>> It's hard to decide which of runtime functionality should be
>> considered as basic and how it should be used. We may say that the
>> only basic thing is hardware enabling which is enable_mpx and stop
>> here
On Thu, 13 Nov 2014, Ilya Enkovich wrote:
> It's hard to decide which of runtime functionality should be
> considered as basic and how it should be used. We may say that the
> only basic thing is hardware enabling which is enable_mpx and stop
> here. But then you get minimal but quite useless li
2014-11-13 0:40 GMT+03:00 Joseph Myers :
> On Wed, 12 Nov 2014, Ilya Enkovich wrote:
>
>> MPX runtime needs to be linked with programs using MPX because it
>> initializes hardware. Without it all MPX instructions are just NOPs.
>> Thus it's not an extra functionality, but is for basic MPX
>> funct
On Wed, 12 Nov 2014, Ilya Enkovich wrote:
> MPX runtime needs to be linked with programs using MPX because it
> initializes hardware. Without it all MPX instructions are just NOPs.
> Thus it's not an extra functionality, but is for basic MPX
> functionality.
So what if you just have the cons
On 11/11/14 13:22, Ilya Enkovich wrote:
This library (some version of it) was only published in a binary form
some time ago. AFAIK currently it is not a part of any product.
Sources were never made public before. Sources go under the same
license as Cilk runtime and therefore require approval
On 11 Nov 20:25, Joseph Myers wrote:
> On Tue, 11 Nov 2014, Andi Kleen wrote:
>
> > Joseph Myers writes:
> >
> > > On Tue, 11 Nov 2014, Ilya Enkovich wrote:
> > >
> > >> Hi,
> > >>
> > >> This patch integrates MPX runtime library into GCC source tree. MPX
> > >> runtime is responsible for ini
On Wed, Nov 12, 2014 at 09:30:59AM +0100, Richard Biener wrote:
> On Tue, Nov 11, 2014 at 4:34 PM, Ilya Enkovich wrote:
> > Hi,
> >
> > This patch integrates MPX runtime library into GCC source tree. MPX
> > runtime is responsible for initialization of MPX feature in HW, signal
> > handling, re
On Tue, Nov 11, 2014 at 4:34 PM, Ilya Enkovich wrote:
> Hi,
>
> This patch integrates MPX runtime library into GCC source tree. MPX runtime
> is responsible for initialization of MPX feature in HW, signal handling,
> reporting etc. Library is linked to codes compiled with -mmpx.
What happens
On Tue, 11 Nov 2014, H.J. Lu wrote:
> Currently mpx-runtime uses
>
> dlsym(RTLD_NEXT, "sigaction");
>
> to get the original sigaction in liibc.so. Glibc does provides __sigaction
> for the original sigaction. But dlsym(RTLD_NEXT, is more portable.
I guess there's a question of what the portab
On Tue, Nov 11, 2014 at 1:33 PM, Joseph Myers wrote:
> On Tue, 11 Nov 2014, Andi Kleen wrote:
>
>> On Tue, Nov 11, 2014 at 01:04:42PM -0800, H.J. Lu wrote:
>> > On Tue, Nov 11, 2014 at 1:01 PM, Andi Kleen wrote:
>> > >> It is similar to libsanitizer. Put it in glibc isn't going to work well
>> >
On Tue, 11 Nov 2014, Andi Kleen wrote:
> On Tue, Nov 11, 2014 at 01:04:42PM -0800, H.J. Lu wrote:
> > On Tue, Nov 11, 2014 at 1:01 PM, Andi Kleen wrote:
> > >> It is similar to libsanitizer. Put it in glibc isn't going to work well
> > >> for MPX.
> > >
> > > Can you explain it more please?
> >
On Tue, Nov 11, 2014 at 01:04:42PM -0800, H.J. Lu wrote:
> On Tue, Nov 11, 2014 at 1:01 PM, Andi Kleen wrote:
> >> It is similar to libsanitizer. Put it in glibc isn't going to work well
> >> for MPX.
> >
> > Can you explain it more please?
> >
>
> Are you suggesting putting MPX run-time in glib
On Tue, Nov 11, 2014 at 1:01 PM, Andi Kleen wrote:
>> It is similar to libsanitizer. Put it in glibc isn't going to work well
>> for MPX.
>
> Can you explain it more please?
>
Are you suggesting putting MPX run-time in glibc? Will we have
2 glibc, one with MPX run-time and one without MPX run-t
> It is similar to libsanitizer. Put it in glibc isn't going to work well
> for MPX.
Can you explain it more please?
-Andi
On Tue, 11 Nov 2014, Andi Kleen wrote:
> Joseph Myers writes:
>
> > On Tue, 11 Nov 2014, Ilya Enkovich wrote:
> >
> >> Hi,
> >>
> >> This patch integrates MPX runtime library into GCC source tree. MPX
> >> runtime is responsible for initialization of MPX feature in HW, signal
> >> handling,
2014-11-11 21:09 GMT+03:00 Joseph Myers :
> On Tue, 11 Nov 2014, Joseph Myers wrote:
>
>> You have lots of static writable variables. Are you sure all those
>> variables are handled in a thread-safe way (e.g. only modified before any
>> threads start)?
>
> Another general multi-thread issue for li
2014-11-11 23:02 GMT+03:00 Jeff Law :
> On 11/11/14 08:34, Ilya Enkovich wrote:
>>
>> Hi,
>>
>> This patch integrates MPX runtime library into GCC source tree. MPX
>> runtime is responsible for initialization of MPX feature in HW, signal
>> handling, reporting etc. Library is linked to codes comp
On Tue, Nov 11, 2014 at 10:49 AM, Andi Kleen wrote:
> Joseph Myers writes:
>
>> On Tue, 11 Nov 2014, Ilya Enkovich wrote:
>>
>>> Hi,
>>>
>>> This patch integrates MPX runtime library into GCC source tree. MPX
>>> runtime is responsible for initialization of MPX feature in HW, signal
>>> handling
On 11/11/14 08:34, Ilya Enkovich wrote:
Hi,
This patch integrates MPX runtime library into GCC source tree. MPX runtime is
responsible for initialization of MPX feature in HW, signal handling, reporting
etc. Library is linked to codes compiled with -mmpx.
Bootstrap is OK for x86_64-unknown-
Joseph Myers writes:
> On Tue, 11 Nov 2014, Ilya Enkovich wrote:
>
>> Hi,
>>
>> This patch integrates MPX runtime library into GCC source tree. MPX
>> runtime is responsible for initialization of MPX feature in HW, signal
>> handling, reporting etc. Library is linked to codes compiled with
On Tue, 11 Nov 2014, Joseph Myers wrote:
> You have lots of static writable variables. Are you sure all those
> variables are handled in a thread-safe way (e.g. only modified before any
> threads start)?
Another general multi-thread issue for libraries: files should be opened
with O_CLOEXEC (
On Tue, 11 Nov 2014, Ilya Enkovich wrote:
> Hi,
>
> This patch integrates MPX runtime library into GCC source tree. MPX
> runtime is responsible for initialization of MPX feature in HW, signal
> handling, reporting etc. Library is linked to codes compiled with
> -mmpx.
>
> Bootstrap is OK f
Hi,
This patch integrates MPX runtime library into GCC source tree. MPX runtime is
responsible for initialization of MPX feature in HW, signal handling, reporting
etc. Library is linked to codes compiled with -mmpx.
Bootstrap is OK for x86_64-unknown-linux-gnu. OK for trunk?
Thanks,
Ilya
--
36 matches
Mail list logo
