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] |
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
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |