This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, newlib] Allow locking routine to be retargeted


On Wed, 2016-12-14 at 11:54 +0000, Thomas Preudhomme wrote:
> On 13/12/16 20:12, Freddie Chopin wrote:
> > Great!
> > 
> > I've already managed to compile the toolchain for ARM, now I'm
> > trying
> > to implement all these "retargeting" functions and required lock
> > objects. We'll see how it works (;
> > 
> > BTW - maybe it would be better to leave the functions undefined and
> > provide the stubs only in libnosys.a? This would be consistent with
> > other newlib stubs (like _sbrk_r(), _read_r() and so on)?
> 
> I need to look into how does that work when not using libnosys

It's worth trying. I think that as long as the project doesn't use any
code which requires locking, there will be no problem at all.

When the user _DOES_ use some code which requires them, he'll get the
linking errors (withou libnosys.a). But given the fact that the two
most "popular" locks which will be used are atexit and malloc, the
situation is not so bad:
1. atexit usually uses malloc anyway,
2. malloc requires you to provide _sbrk_r() - if you don't you'll get a
linking error,
3. the fact that the functions are provided as weak symbols probably
doesn't change much - the user would get linking errors anyway, because
the storage for locks is not provided.

With item 3 in mind, I guess that if you provide weak functions, some
dummy storage should also be provided as a weak symbol - either in
lock.c or in libnosys.a.

Regards,
FCh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]