musl/src/internal, branch v1.0.2

use hidden visibility rather than protected for syscall internals

2014-04-16T06:46:05+00:00

the use of visibility at all is purely an optimization to avoid the
need for the caller to load the GOT register or similar to prepare for
a call via the PLT. there is no reason for these symbols to be
externally visible, so hidden works just as well as protected, and
using protected visibility is undesirable due to toolchain bugs and
the lack of testing it receives.

in particular, GCC's microblaze target is known to generate symbolic
relocations in the GOT for functions with protected visibility. this
in turn results in a dynamic linker which crashes under any nontrivial
usage that requires making a syscall before symbolic relocations are
processed.

(cherry picked from commit 83c98aac4c43f9571e8f92a1c795afe02c237d4b)

include header that declares __syscall_ret where it's defined

2014-04-16T06:46:04+00:00

in general, we aim to always include the header that's declaring a
function before defining it so that the compiler can check that
prototypes match.

additionally, the internal syscall.h declares __syscall_ret with a
visibility attribute to improve code generation for shared libc (to
prevent gratuitous GOT-register loads). this declaration should be
visible at the point where __syscall_ret is defined, too, or the
inconsistency could theoretically lead to problems at link-time.

(cherry picked from commit 30c1205acd73c8481ca34f0a41de1d41884d07b5)

rename superh port to "sh" for consistency

2014-02-28T03:03:25+00:00

linux, gcc, etc. all use "sh" as the name for the superh arch. there
was already some inconsistency internally in musl: the dynamic linker
was searching for "ld-musl-sh.path" as its path file despite its own
name being "ld-musl-superh.so.1". there was some sentiment in both
directions as to how to resolve the inconsistency, but overall "sh"
was favored.

superh port

2014-02-23T22:15:54+00:00

mostly-cosmetic fixups to x32 port merge

2014-02-23T10:43:09+00:00

import vanilla x86_64 code as x32

2014-02-23T10:07:18+00:00

internal/syscall.h: add syscall_arg_t macro

2014-02-22T11:24:35+00:00

some 32-on-64 archs require that the actual syscall args be long long.
in that case syscall_arch.h can define syscall_arg_t to whatever it needs
and syscall.h picks it up.
all other archs just use long as usual.

internal/syscall.h: use a macro for the syscall args casts

2014-02-22T08:50:39+00:00

this allows syscall_arch.h to define the macro __scc if special
casting is needed, as is the case for x32, where the actual syscall
arguments are 64bit, but, in case of pointers, would get sign-extended
and thus become invalid.

fix ftello result for append streams with unflushed output

2014-02-07T05:57:50+00:00

when there is unflushed output, ftello (and ftell) compute the logical
stream position as the underlying file descriptor's offset plus an
adjustment for the amount of buffered data. however, this can give the
wrong result for append-mode streams where the unflushed writes should
adjust the logical position to be at the end of the file, as if a seek
to end-of-file takes place before the write.

the solution turns out to be a simple trick: when ftello (indirectly)
calls lseek to determine the current file offset, use SEEK_END instead
of SEEK_CUR if the stream is append-mode and there's unwritten
buffered data.

the ISO C rules regarding switching between reading and writing for a
stream opened in an update mode, along with the POSIX rules regarding
switching "active handles", conveniently leave undefined the
hypothetical usage cases where this fix might lead to observably
incorrect offsets.

the bug being fixed was discovered via the test case for glibc issue

include cleanups: remove unused headers and add feature test macros

2013-12-12T05:09:18+00:00