__getreent in libgloss

__getreent in libgloss

[Stefan Wallentowitz]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

Dear all,

I am currently porting (baremetal) libgloss/newlib for OpenRISC (or1k). 
I want to use dynamic reentrancy and think I basically understood it.
Can you please confirm that the following steps are correct and the 
proper way to go:

I specify __DYNAMIC_REENT__ for the machine in 
newlib/libc/include/sys/config.h. I also set 
newlib_cflags="${newlib_cflags} -DREENTRANT_SYSCALLS_PROVIDED " and 
syscall_dir=syscalls in configure.host for the target. By default newlib 
takes __getreent() and I can overwrite __getreent to my own function. 
Where should I do this? I set it in config.h (#define __getreent 
or1k_getreent), but then I also need to define the external function 
(extern struct _reent *or1k_getreent(void)), correct?

Thanks for your help.

Best regards,
Stefan


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4929 bytes --]

Re: __getreent in libgloss

[Jeff Johnston]

----- Original Message -----
> From: "Stefan Wallentowitz" <stefan.wallentowitz@tum.de>
> To: newlib@sourceware.org
> Sent: Monday, November 3, 2014 8:50:05 AM
> Subject: __getreent in libgloss
> 
> Dear all,
> 
> I am currently porting (baremetal) libgloss/newlib for OpenRISC (or1k).
> I want to use dynamic reentrancy and think I basically understood it.
> Can you please confirm that the following steps are correct and the
> proper way to go:
> 
> I specify __DYNAMIC_REENT__ for the machine in
> newlib/libc/include/sys/config.h. 

Correct.

> I also set
> newlib_cflags="${newlib_cflags} -DREENTRANT_SYSCALLS_PROVIDED " and
> syscall_dir=syscalls in configure.host for the target. 

Sure, this means that you are supplying _r syscalls which is good.  I assume
you have read libc/include/reent.h for the various alternatives.

> By default newlib
> takes __getreent() and I can overwrite __getreent to my own function.
> Where should I do this? I set it in config.h (#define __getreent
> or1k_getreent), but then I also need to define the external function
> (extern struct _reent *or1k_getreent(void)), correct?

Actually, overriding is much easier.  Newlib is designed to override shared functions with ones
that are found in the libc/machine or libc/sys directories.  In your case, if
you have a getreent.c or getreent.S that is found in libc/machine/or1k (or whatever you designate
your machine_dir in configure.host), it will override the object file built in libc/reent.

If you don't actually have multiple threads, you might as well just use the
default one found in libc/reent.  There is a sample multithread version in
libc/sys/linux/linuxthreads/getreent.c which uses the thread specific storage
to get the current reentrancy structure for the current thread.

-- Jeff J.

> 
> Thanks for your help.
> 
> Best regards,
> Stefan
> 
> 

Re: __getreent in libgloss

[Stefan Wallentowitz]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

On 03.11.2014 22:50, Jeff Johnston wrote:
>> By default newlib
>> takes __getreent() and I can overwrite __getreent to my own function.
>> Where should I do this? I set it in config.h (#define __getreent
>> or1k_getreent), but then I also need to define the external function
>> (extern struct _reent *or1k_getreent(void)), correct?
> Actually, overriding is much easier.  Newlib is designed to override shared functions with ones
> that are found in the libc/machine or libc/sys directories.  In your case, if
> you have a getreent.c or getreent.S that is found in libc/machine/or1k (or whatever you designate
> your machine_dir in configure.host), it will override the object file built in libc/reent.
Ah, yes, I just found that this did not work properly as I forgot to run 
automake again after adding a the file to Makefile.am..
>
> If you don't actually have multiple threads, you might as well just use the
> default one found in libc/reent.  There is a sample multithread version in
> libc/sys/linux/linuxthreads/getreent.c which uses the thread specific storage
> to get the current reentrancy structure for the current thread.
>
I am more looking into baremetal multicore support and found that it 
might be a good option to use re-entrancy on the different cores. Do you 
agree on this?

Thanks for your support.

Best regards,
Stefan


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4929 bytes --]

Re: __getreent in libgloss

[Jeff Johnston]

----- Original Message -----
> From: "Stefan Wallentowitz" <stefan.wallentowitz@tum.de>
> To: "Jeff Johnston" <jjohnstn@redhat.com>
> Cc: newlib@sourceware.org
> Sent: Tuesday, November 4, 2014 5:53:41 AM
> Subject: Re: __getreent in libgloss
> 
> On 03.11.2014 22:50, Jeff Johnston wrote:
> >> By default newlib
> >> takes __getreent() and I can overwrite __getreent to my own function.
> >> Where should I do this? I set it in config.h (#define __getreent
> >> or1k_getreent), but then I also need to define the external function
> >> (extern struct _reent *or1k_getreent(void)), correct?
> > Actually, overriding is much easier.  Newlib is designed to override shared
> > functions with ones
> > that are found in the libc/machine or libc/sys directories.  In your case,
> > if
> > you have a getreent.c or getreent.S that is found in libc/machine/or1k (or
> > whatever you designate
> > your machine_dir in configure.host), it will override the object file built
> > in libc/reent.
> Ah, yes, I just found that this did not work properly as I forgot to run
> automake again after adding a the file to Makefile.am..
> >
> > If you don't actually have multiple threads, you might as well just use the
> > default one found in libc/reent.  There is a sample multithread version in
> > libc/sys/linux/linuxthreads/getreent.c which uses the thread specific
> > storage
> > to get the current reentrancy structure for the current thread.
> >
> I am more looking into baremetal multicore support and found that it
> might be a good option to use re-entrancy on the different cores. Do you
> agree on this?
> 

That makes sense if you are going to support multiple threads running on
the cores.

> Thanks for your support.

No problem.

> 
> Best regards,
> Stefan
> 
> 

Re: __getreent in libgloss

[Stefan Wallentowitz]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

On 04.11.2014 22:14, Jeff Johnston wrote:
> That makes sense if you are going to support multiple threads running on
> the cores.
>
Hi,

perfect, thanks!

There is just one last thing I am not sure about: I (and the most 
OpenRISC guys) used newlib primarily for baremetal applications 
(or1k-elf), while the RTEMS port of course uses it differently (say 
or1k-rtems).
I now handle all the reentrany stuff for baremetal in libgloss [1] (is 
that correct?) and access it from my newlib __getreent [2]. This will of 
course not work with RTEMS (and therefore maybe not accepted). What is 
the legitimate way to handle this? Some preprocessor magic? Or am I 
getting something entirely wrong?

My solution would be: Distinguish between or1k-*-elf and or1k-*-* in 
configure.host and either set __DYNAMIC_REENT__ and __getreent there or 
set some defines that are then used in [2].

Thanks again for for quick help.

Best regards,
Stefan

[1]: 
https://github.com/wallento/or1k-newlib/blob/master/libgloss/or1k/impure.c
[2]: 
https://github.com/wallento/or1k-newlib/blob/master/newlib/libc/machine/or1k/getreent.c


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4929 bytes --]

Re: __getreent in libgloss

[Joel Sherrill]

On November 5, 2014 2:03:31 AM CST, Stefan Wallentowitz <stefan.wallentowitz@tum.de> wrote:
>On 04.11.2014 22:14, Jeff Johnston wrote:
>> That makes sense if you are going to support multiple threads running
>on
>> the cores.
>>
>Hi,
>
>perfect, thanks!
>
>There is just one last thing I am not sure about: I (and the most 
>OpenRISC guys) used newlib primarily for baremetal applications 
>(or1k-elf), while the RTEMS port of course uses it differently (say 
>or1k-rtems).

The configure magic will pick up the settings, defines, directory selection, etc. RTEMS will have more enabled than a bare metal target and set things so we use our malloc implementation.

>I now handle all the reentrany stuff for baremetal in libgloss [1] (is 
>that correct?) and access it from my newlib __getreent [2]. This will
>of 
>course not work with RTEMS (and therefore maybe not accepted). What is 
>the legitimate way to handle this? Some preprocessor magic? Or am I 
>getting something entirely wrong?

If your bare metal target doesn't have threads, this reentrancy isn't an issue. If it does, then I would tend to think that the target should not be or1k-elf but something indicating the thread package. It would also have lock support. 

I think all the bare *-elf targets are single threaded focused although some RTOSes use them anyway.

>My solution would be: Distinguish between or1k-*-elf and or1k-*-* in 
>configure.host and either set __DYNAMIC_REENT__ and __getreent there or
>
>set some defines that are then used in [2].
 
Elf should be simple and single threaded IMO. Another target name should be used for a threaded runtime.

--joel

>Thanks again for for quick help.
>
>Best regards,
>Stefan
>
>[1]: 
>https://github.com/wallento/or1k-newlib/blob/master/libgloss/or1k/impure.c
>[2]: 
>https://github.com/wallento/or1k-newlib/blob/master/newlib/libc/machine/or1k/getreent.c

Re: __getreent in libgloss

[Stefan Wallentowitz]

[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]

On 05.11.2014 15:05, Joel Sherrill wrote:
>
> If your bare metal target doesn't have threads, this reentrancy isn't an issue. If it does, then I would tend to think that the target should not be or1k-elf but something indicating the thread package. It would also have lock support.
>
> I think all the bare *-elf targets are single threaded focused although some RTOSes use them anyway.
>
Hi,

there are two things:

First, I added the reentrancy to support the use of C library routines 
in exceptions and therefore implement two impure structs, just to not 
mess up printf buffers during exceptions etc.. Solely for this we don't 
need dynamic reentrancy, but can just exchange the _impure_ptr. The goal 
of the whole implementation of exception and interrupt hooks is that 
people can use the or1k-elf toolchain to build everything including a 
small scheduler or virtual memory threads, if they need. It is of course 
debatable that this is necessary.

Second, we have multiple cores running the same baremetal code from 
shared memory. I think this is the point where we need dynamic 
reentrancy, as we have multiple threads of execution (not meaning "OS 
threads") that share the code. I am not sure if this already qualifies 
for another target than *-elf.

Thanks.

Bye,


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4929 bytes --]

Re: __getreent in libgloss

[Stefan Wallentowitz]

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

On 05.11.2014 15:33, Stefan Wallentowitz wrote:
> On 05.11.2014 15:05, Joel Sherrill wrote:
>>
>> If your bare metal target doesn't have threads, this reentrancy isn't 
>> an issue. If it does, then I would tend to think that the target 
>> should not be or1k-elf but something indicating the thread package. 
>> It would also have lock support.
>>
>> I think all the bare *-elf targets are single threaded focused 
>> although some RTOSes use them anyway.
>>
> Hi,
>
> there are two things:
>
> First, I added the reentrancy to support the use of C library routines 
> in exceptions and therefore implement two impure structs, just to not 
> mess up printf buffers during exceptions etc.. Solely for this we 
> don't need dynamic reentrancy, but can just exchange the _impure_ptr. 
> The goal of the whole implementation of exception and interrupt hooks 
> is that people can use the or1k-elf toolchain to build everything 
> including a small scheduler or virtual memory threads, if they need. 
> It is of course debatable that this is necessary.
>
> Second, we have multiple cores running the same baremetal code from 
> shared memory. I think this is the point where we need dynamic 
> reentrancy, as we have multiple threads of execution (not meaning "OS 
> threads") that share the code. I am not sure if this already qualifies 
> for another target than *-elf.
>
> Thanks.
>
> Bye,
>
Can this be an option? 
https://github.com/wallento/or1k-newlib/commit/53a4f1584ec8702ec1a92eea15fbe937b27a5bd4

Thanks, Stefan


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4929 bytes --]

Re: __getreent in libgloss

[Joel Sherrill]

On 11/5/2014 9:19 AM, Stefan Wallentowitz wrote:
> On 05.11.2014 15:33, Stefan Wallentowitz wrote:
>> On 05.11.2014 15:05, Joel Sherrill wrote:
>>>
>>> If your bare metal target doesn't have threads, this reentrancy
>>> isn't an issue. If it does, then I would tend to think that the
>>> target should not be or1k-elf but something indicating the thread
>>> package. It would also have lock support.
>>>
>>> I think all the bare *-elf targets are single threaded focused
>>> although some RTOSes use them anyway.
>>>
>> Hi,
>>
>> there are two things:
>>
>> First, I added the reentrancy to support the use of C library
>> routines in exceptions and therefore implement two impure structs,
>> just to not mess up printf buffers during exceptions etc.. Solely for
>> this we don't need dynamic reentrancy, but can just exchange the
>> _impure_ptr. The goal of the whole implementation of exception and
>> interrupt hooks is that people can use the or1k-elf toolchain to
>> build everything including a small scheduler or virtual memory
>> threads, if they need. It is of course debatable that this is necessary.
>>
>> Second, we have multiple cores running the same baremetal code from
>> shared memory. I think this is the point where we need dynamic
>> reentrancy, as we have multiple threads of execution (not meaning "OS
>> threads") that share the code. I am not sure if this already
>> qualifies for another target than *-elf.
>>
OK. Not sure either.  For sure there is some added code to know core
number in that configuration that is not needed in uniprocessor
configurations. That's not necessarily a big deal.

But is the same information available for current core number and
maximum cores available in a uniprocessor or1k CPU?

Does the or1k simulator do multicore? Does it have synchronization
instructions? Just curious since SMP RTEMS on or1k is something
I really hadn't thought about. We already support ARM, SPARC,
PowerPC, and x86.
>> Thanks.
>>
>> Bye,
>>
> Can this be an option?
> https://github.com/wallento/or1k-newlib/commit/53a4f1584ec8702ec1a92eea15fbe937b27a5bd4
>
I don't have problems with this patch. As long as the libgloss code includes
all that is needed.
> Thanks, Stefan
>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: __getreent in libgloss

[Stefan Wallentowitz]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

On 05.11.2014 18:06, Joel Sherrill wrote:
>
> But is the same information available for current core number and
> maximum cores available in a uniprocessor or1k CPU?
Only after the latest architecture manual revision. Thats why there will 
be multilib or similar for multicore support in the toolchain to still 
support old implementations. All current work supports it.
> Does the or1k simulator do multicore? Does it have synchronization
> instructions? Just curious since SMP RTEMS on or1k is something
> I really hadn't thought about. We already support ARM, SPARC,
> PowerPC, and x86.
or1ksim does not allow multiple cores, which is a major problem. It 
nevertheless has the multicore support in it (SPR_COREID reads 0, 
SPR_NUMCORES 1) plus the LL/SC instructions (lwa and swa). qemu does not 
have multicore, but I am not sure, but executes the code also correctly 
in uniprocessor mode.
The current HDL implementation mor1kx supports it fully. Using fusesoc 
you can easily build a Verilator simulation from it (which is of course 
slower than an ISS). Contact me, if you need a QuickStart.
We use Multicore or1k in our projects and would be happy to try RTEMS. 
What do you think is the required effort? Linux SMP for OpenRISC already 
works.

HTH,
Stefan


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4929 bytes --]

Re: __getreent in libgloss

[Sebastian Huber]

On 06/11/14 09:56, Stefan Wallentowitz wrote:
> We use Multicore or1k in our projects and would be happy to try RTEMS. What do
> you think is the required effort?

Sorry, for being off topic to the Newlib list.  This should probably addressed 
in devel@rtems.org.

Enabling SMP support for a particular architecture/BSP is quite simple in 
RTEMS.  You need:

1. Support for C11 atomic operations.

2. A couple of defines and functions in the CPU port header file.

3. The implementation of these functions.

4. Some additional assembly code in the context switch function.

This can be done in one day depending on your experience with RTEMS and the 
actual architecture.

-- 
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.