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: False syscall dependencies


Shaun Jackman wrote:

For an embedded system with no kernel, and thus no system call
support, I wanted to check that the application didn't call any
syscalls, because havoc would surely result. I found system calls were
in fact included in the resulting binary. This realisation led to a
two day jaunt to discover why. I finall found that...

	(where `->' reads as `is sucked in by')
	_write_r -> __swrite -> __sinit -> __svfscanf_r -> sscanf ->
	_tzset_r -> tzset -> _setenv_r -> _putenv_r -> putenv

... and so the application's use of putenv caused stdio and the system
calls to be sucked in.

I'm wondering if it's possible to break two of these dependencies. One
is the dependency of setenv on tzset. The second is of sscanf on
_write.

Rather than setenv calling tzset, which is an unfortunate dependency,
the time formatting functions, namely ctime, localtime, mktime, and
strftime, could call tzset. This is the approach suggested by SUSv3.
Would a patch be well received?



I'm not enthused about this. You're solving your problem and causing a problem
for others. The putenv function is not commonly used in embedded applications
where-as the time functions are. Besides, there is libnosys for just such a situation.


Due to the rather elegant super-function, __svfscanf_r, depending on
__sinit and thus _write, I don't see a simple way of avoiding sscanf
sucking in the syscalls. One idea is to replace __sinit with
__sinit_without_syscalls and __sinit_with_syscalls (named
extra-verbosely for clarity), and remove the call to __sinit in
__svfscanf_r, and have sscanf call __sinit_without_syscalls, whereas
fscanf would call __sinit_with_syscalls.



I'm more interested in this idea because it could potentially lower the size of a simple
application. One idea might be to push the CHECK_INIT call back to the calling functions that actually use files and leave it out for the string I/O functions that don't require reent
I/O setup.


-- Jeff J.

Cheers,
Shaun




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