[PATCH, newlib] Allow locking routine to be retargeted

[Freddie Chopin]

On Fri, 2016-11-25 at 12:04 +0000, Thomas Preudhomme wrote:
> > Oh nice, clever. I've check whether there is name collision in the
> > source where
> > this would lead them to use the same lock and found:
> > 
> > newlib/libc/sys/linux/iconv/gconv_db.c: __LOCK_INIT(static, lock);
> > newlib/libc/sys/linux/iconv/gconv_trans.c: __LOCK_INIT(static,
> > lock);
> > 
> > The one thing I worry is the risk of new lock being added with the
> > same name.
> > Fortunately this could be detected at link time by looking for
> > relocation to
> > "_lock_.*" in newlib library and check that there is no duplicate.
> 
> One issue though, this means the OS needs to be updated each time a
> statically 
> initialized lock is added to newlib. That seems to be a bit too much
> coupling. 
> Or am I misunderstanding how this should be used?

The solution with array and function - which is basically very similar
to this one - solves both these issues. But this has a downside of
exposing all the locks, even if they are considered to be file-local
"static" in newlib.

The second issue in Sebastian's solution can also be solved with a
special header - a source file fragment really - with declaration of
storage for all locks. Sth like:

struct _lock _lock_malloc;
struct _lock _lock_tz;
struct _lock _lock_whatever;
struct _lock _lock_xxx;

The OS would then just need to include this file _AFTER_ the _lock
struct is defined. And you would see all name collisions then.

Regards,
FCh