Archive (library) with syscalls?

[Mike Frysinger]

On 25 Sep 2015 09:01, Freddie Chopin wrote:
> On Friday 25 of September 2015 00:34:10 Mike Frysinger wrote:
> > what you describe is expected linker behavior -- when you have an archive
> > of objects, then things get pulled out only when explicitly requested.
> > you should post to the binutils mailing list to ask for suggestions as
> > this is not specific to newlib.
> 
> OK, I've posted my request to binutils mailing list, but I still think that in 
> here someone might know how to solve it. I'm wondering whether the thing I 
> want to do is at all possible? Maybe I should either recompile the toolchain 
> with REENTRANT_SYSCALLS_PROVIDED defined for newlib (so there would be no 
> syscalls in the toolchain) or maybe the proper way in my situation is to 
> redefine _sbrk(), _write(), etc. instead of _sbrk_r(), _write_r() and other 
> reentrant syscalls? The second option seems easier, because I wouldn't have to 
> recompile the toolchain, but in some of the syscalls access to reent structure 
> would be needed, so going from toolchain's _xxx_r() to my _xxx() syscall just 
> to read the _REENT again seems like a waste of time and code... On the other 
> hand only a few syscalls may need any data from this structure...

the interaction between libgloss stubs and target-specific specs / linker
scripts is ... not optimal ;).  basically whatever the author at the time
of either gcc or libgloss thought was a good idea (perhaps inspired a bit
by looking at existing ports, or trying to stick closely to a proprietary
toolchain that already existed for their target) is what got implemented.
thus every target ends up doing things differently (by a little or lot).

it would be great if we could dictate by fiat a new set of flags that'd
work across all targets.  bare metal folks tend to have strong opinions
about not changing things though :/.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/newlib/attachments/20150928/b4111484/attachment.sig>