Re: __getreent in libgloss

[Jeff Johnston <jjohnstn at redhat dot com>]

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