libgomp platform customization

libgomp platform customization

[Sebastian Huber]

Hello,

we would like to use libgomp in a quite constraint environment. In this 
environment using for example the C locale support, errno, malloc(), 
realloc(), free(), and abort() are problematic. One option would be to 
introduce a new header file "config/*/platform.h" which is included in 
libgomp.h right after the #include "config.h". A platform could then do 
something like this:

#define malloc(size) platform_malloc(size)
...

In env.c there are some uses of strto*() like this:

   errno = 0;
   stride = strtol (env, &env, 10);
   if (errno)
     return false;

I would like to introduce a new header file "strto.h" which defines 
something like this:

static inline char *
gomp_strtol (char *s, long *value)
{
   char *end;

   errno = 0;
   *value = strtol (s, &end, 10);
   if (errno != 0)
     return NULL;

   return end;
}

Then use:

   env = gomp_strtol (env, &stride);
   if (env == NULL)
     return false;

A platform could then provide its own "config/*/strto.h" with an 
alternative implementation.

Would this be acceptable after the GCC 9 release?

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: libgomp platform customization

[Richard Biener]

On Wed, Jan 30, 2019 at 3:46 PM Sebastian Huber
<sebastian.huber@embedded-brains.de> wrote:
>
> Hello,
>
> we would like to use libgomp in a quite constraint environment. In this
> environment using for example the C locale support, errno, malloc(),
> realloc(), free(), and abort() are problematic. One option would be to
> introduce a new header file "config/*/platform.h" which is included in
> libgomp.h right after the #include "config.h". A platform could then do
> something like this:
>
> #define malloc(size) platform_malloc(size)
> ...
>
> In env.c there are some uses of strto*() like this:
>
>    errno = 0;
>    stride = strtol (env, &env, 10);
>    if (errno)
>      return false;
>
> I would like to introduce a new header file "strto.h" which defines
> something like this:
>
> static inline char *
> gomp_strtol (char *s, long *value)
> {
>    char *end;
>
>    errno = 0;
>    *value = strtol (s, &end, 10);
>    if (errno != 0)
>      return NULL;
>
>    return end;
> }
>
> Then use:
>
>    env = gomp_strtol (env, &stride);
>    if (env == NULL)
>      return false;
>
> A platform could then provide its own "config/*/strto.h" with an
> alternative implementation.
>
> Would this be acceptable after the GCC 9 release?

I guess you could look at what nvptx and HSA (and GCN on some branch)
do here?

Richard.

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber@embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>

Re: libgomp platform customization

[Sebastian Huber]

On 31/01/2019 10:29, Richard Biener wrote:
> On Wed, Jan 30, 2019 at 3:46 PM Sebastian Huber
> <sebastian.huber@embedded-brains.de>  wrote:
>> Hello,
>>
>> we would like to use libgomp in a quite constraint environment. In this
>> environment using for example the C locale support, errno, malloc(),
>> realloc(), free(), and abort() are problematic. One option would be to
>> introduce a new header file "config/*/platform.h" which is included in
>> libgomp.h right after the #include "config.h". A platform could then do
>> something like this:
>>
>> #define malloc(size) platform_malloc(size)
>> ...
>>
>> In env.c there are some uses of strto*() like this:
>>
>>     errno = 0;
>>     stride = strtol (env, &env, 10);
>>     if (errno)
>>       return false;
>>
>> I would like to introduce a new header file "strto.h" which defines
>> something like this:
>>
>> static inline char *
>> gomp_strtol (char *s, long *value)
>> {
>>     char *end;
>>
>>     errno = 0;
>>     *value = strtol (s, &end, 10);
>>     if (errno != 0)
>>       return NULL;
>>
>>     return end;
>> }
>>
>> Then use:
>>
>>     env = gomp_strtol (env, &stride);
>>     if (env == NULL)
>>       return false;
>>
>> A platform could then provide its own "config/*/strto.h" with an
>> alternative implementation.
>>
>> Would this be acceptable after the GCC 9 release?
> I guess you could look at what nvptx and HSA (and GCN on some branch)
> do here?

My problem is that our real-time operating system (RTEMS) is somewhere 
in between a full blown Linux and the offload hardware. I would like to 
get rid of stuff which depends on the Newlib struct _reent since this 
pulls in a lot of dependencies. The heavy weight functions are just used 
for the initialization (env.c) and error reporting. Containing the heap 
allocation functions helps to control the memory used by OpenMP 
computations.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: libgomp platform customization

[Richard Biener]

On Thu, Jan 31, 2019 at 10:37 AM Sebastian Huber
<sebastian.huber@embedded-brains.de> wrote:
>
> On 31/01/2019 10:29, Richard Biener wrote:
> > On Wed, Jan 30, 2019 at 3:46 PM Sebastian Huber
> > <sebastian.huber@embedded-brains.de>  wrote:
> >> Hello,
> >>
> >> we would like to use libgomp in a quite constraint environment. In this
> >> environment using for example the C locale support, errno, malloc(),
> >> realloc(), free(), and abort() are problematic. One option would be to
> >> introduce a new header file "config/*/platform.h" which is included in
> >> libgomp.h right after the #include "config.h". A platform could then do
> >> something like this:
> >>
> >> #define malloc(size) platform_malloc(size)
> >> ...
> >>
> >> In env.c there are some uses of strto*() like this:
> >>
> >>     errno = 0;
> >>     stride = strtol (env, &env, 10);
> >>     if (errno)
> >>       return false;
> >>
> >> I would like to introduce a new header file "strto.h" which defines
> >> something like this:
> >>
> >> static inline char *
> >> gomp_strtol (char *s, long *value)
> >> {
> >>     char *end;
> >>
> >>     errno = 0;
> >>     *value = strtol (s, &end, 10);
> >>     if (errno != 0)
> >>       return NULL;
> >>
> >>     return end;
> >> }
> >>
> >> Then use:
> >>
> >>     env = gomp_strtol (env, &stride);
> >>     if (env == NULL)
> >>       return false;
> >>
> >> A platform could then provide its own "config/*/strto.h" with an
> >> alternative implementation.
> >>
> >> Would this be acceptable after the GCC 9 release?
> > I guess you could look at what nvptx and HSA (and GCN on some branch)
> > do here?
>
> My problem is that our real-time operating system (RTEMS) is somewhere
> in between a full blown Linux and the offload hardware. I would like to
> get rid of stuff which depends on the Newlib struct _reent since this
> pulls in a lot of dependencies. The heavy weight functions are just used
> for the initialization (env.c) and error reporting. Containing the heap
> allocation functions helps to control the memory used by OpenMP
> computations.

I suppose supplying a RTEMS specific noop-stub would work here
and that's close enough to what the offload stuff does.  But I'm not
very familiar with this so sorry if misleading you.

Richard.

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber@embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>

Re: libgomp platform customization

[Jakub Jelinek]

On Thu, Jan 31, 2019 at 10:37:29AM +0100, Sebastian Huber wrote:
> My problem is that our real-time operating system (RTEMS) is somewhere in
> between a full blown Linux and the offload hardware. I would like to get rid
> of stuff which depends on the Newlib struct _reent since this pulls in a lot
> of dependencies. The heavy weight functions are just used for the
> initialization (env.c) and error reporting. Containing the heap allocation
> functions helps to control the memory used by OpenMP computations.

Heap allocations are everywhere in libgomp, not just in initialization,
for parallel, offloading, tasking, worksharing constructs, ...
You won't get far without that.

	Jakub

Re: libgomp platform customization

[Sebastian Huber]

On 31/01/2019 10:56, Jakub Jelinek wrote:
> On Thu, Jan 31, 2019 at 10:37:29AM +0100, Sebastian Huber wrote:
>> My problem is that our real-time operating system (RTEMS) is somewhere in
>> between a full blown Linux and the offload hardware. I would like to get rid
>> of stuff which depends on the Newlib struct _reent since this pulls in a lot
>> of dependencies. The heavy weight functions are just used for the
>> initialization (env.c) and error reporting. Containing the heap allocation
>> functions helps to control the memory used by OpenMP computations.
> Heap allocations are everywhere in libgomp, not just in initialization,
> for parallel, offloading, tasking, worksharing constructs, ...
> You won't get far without that.

I would like to use a specialized heap for OpenMP and not the general 
purpose malloc(), etc.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: libgomp platform customization

[Jakub Jelinek]

On Thu, Jan 31, 2019 at 10:58:27AM +0100, Sebastian Huber wrote:
> On 31/01/2019 10:56, Jakub Jelinek wrote:
> > On Thu, Jan 31, 2019 at 10:37:29AM +0100, Sebastian Huber wrote:
> > > My problem is that our real-time operating system (RTEMS) is somewhere in
> > > between a full blown Linux and the offload hardware. I would like to get rid
> > > of stuff which depends on the Newlib struct _reent since this pulls in a lot
> > > of dependencies. The heavy weight functions are just used for the
> > > initialization (env.c) and error reporting. Containing the heap allocation
> > > functions helps to control the memory used by OpenMP computations.
> > Heap allocations are everywhere in libgomp, not just in initialization,
> > for parallel, offloading, tasking, worksharing constructs, ...
> > You won't get far without that.
> 
> I would like to use a specialized heap for OpenMP and not the general
> purpose malloc(), etc.

I'd prefer not to clobber the generic code with that though.
So, if you in some config/rtems/ header or overriding *.c file
#undef strtoul
#define strtoul(p, e, b) rtems_strtoul (p, e, b)
and similarly for malloc, free, calloc, I won't object, but I'm against
introducing gomp_strtoul, etc. (we do already have gomp_malloc, but expect
free to be usable against that).

	Jakub

Re: libgomp platform customization

[Sebastian Huber]

On 31/01/2019 11:07, Jakub Jelinek wrote:
> On Thu, Jan 31, 2019 at 10:58:27AM +0100, Sebastian Huber wrote:
>> On 31/01/2019 10:56, Jakub Jelinek wrote:
>>> On Thu, Jan 31, 2019 at 10:37:29AM +0100, Sebastian Huber wrote:
>>>> My problem is that our real-time operating system (RTEMS) is somewhere in
>>>> between a full blown Linux and the offload hardware. I would like to get rid
>>>> of stuff which depends on the Newlib struct _reent since this pulls in a lot
>>>> of dependencies. The heavy weight functions are just used for the
>>>> initialization (env.c) and error reporting. Containing the heap allocation
>>>> functions helps to control the memory used by OpenMP computations.
>>> Heap allocations are everywhere in libgomp, not just in initialization,
>>> for parallel, offloading, tasking, worksharing constructs, ...
>>> You won't get far without that.
>> I would like to use a specialized heap for OpenMP and not the general
>> purpose malloc(), etc.
> I'd prefer not to clobber the generic code with that though.
> So, if you in some config/rtems/ header or overriding *.c file
> #undef strtoul
> #define strtoul(p, e, b) rtems_strtoul (p, e, b)
> and similarly for malloc, free, calloc, I won't object, but I'm against
> introducing gomp_strtoul, etc. (we do already have gomp_malloc, but expect
> free to be usable against that).

The strtoul() is used in combination with errno, so using a macro is not 
enough. I really would like to be able to use env.c in general, since 
the standard configuration via environment variables is fine.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: libgomp platform customization

[Jakub Jelinek]

On Thu, Jan 31, 2019 at 11:13:44AM +0100, Sebastian Huber wrote:
> On 31/01/2019 11:07, Jakub Jelinek wrote:
> > On Thu, Jan 31, 2019 at 10:58:27AM +0100, Sebastian Huber wrote:
> > > On 31/01/2019 10:56, Jakub Jelinek wrote:
> > > > On Thu, Jan 31, 2019 at 10:37:29AM +0100, Sebastian Huber wrote:
> > > > > My problem is that our real-time operating system (RTEMS) is somewhere in
> > > > > between a full blown Linux and the offload hardware. I would like to get rid
> > > > > of stuff which depends on the Newlib struct _reent since this pulls in a lot
> > > > > of dependencies. The heavy weight functions are just used for the
> > > > > initialization (env.c) and error reporting. Containing the heap allocation
> > > > > functions helps to control the memory used by OpenMP computations.
> > > > Heap allocations are everywhere in libgomp, not just in initialization,
> > > > for parallel, offloading, tasking, worksharing constructs, ...
> > > > You won't get far without that.
> > > I would like to use a specialized heap for OpenMP and not the general
> > > purpose malloc(), etc.
> > I'd prefer not to clobber the generic code with that though.
> > So, if you in some config/rtems/ header or overriding *.c file
> > #undef strtoul
> > #define strtoul(p, e, b) rtems_strtoul (p, e, b)
> > and similarly for malloc, free, calloc, I won't object, but I'm against
> > introducing gomp_strtoul, etc. (we do already have gomp_malloc, but expect
> > free to be usable against that).
> 
> The strtoul() is used in combination with errno, so using a macro is not
> enough. I really would like to be able to use env.c in general, since the
> standard configuration via environment variables is fine.

You can
#undef errno
#define errno whatever
too.  And that can be done just in config/rtems/env.c, which will do that
stuff and then
#include_next <env.c>

	Jakub