d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
e048186a62
freebsd-dev/lib/libc/gen/Symbol.map

499 lines
7.8 KiB
Plaintext
Raw Normal View History

Use C comments since we now preprocess these files with CPP.
2007-04-29 14:05:22 +00:00
/*
* $FreeBSD$
*/
Add symbol maps and initial symbol version definitions to libc. Reviewed by: davidxu
2006-03-13 00:53:21 +00:00
FBSD_1.0 {
__xuname;
pthread_atfork;
pthread_attr_destroy;
pthread_attr_getdetachstate;
pthread_attr_getguardsize;
pthread_attr_getinheritsched;
pthread_attr_getschedparam;
pthread_attr_getschedpolicy;
pthread_attr_getscope;
pthread_attr_getstackaddr;
pthread_attr_getstacksize;
pthread_attr_init;
pthread_attr_setdetachstate;
pthread_attr_setguardsize;
pthread_attr_setinheritsched;
pthread_attr_setschedparam;
pthread_attr_setschedpolicy;
pthread_attr_setscope;
pthread_attr_setstackaddr;
pthread_attr_setstacksize;
pthread_cancel;
pthread_cleanup_pop;
pthread_cleanup_push;
pthread_cond_broadcast;
pthread_cond_destroy;
pthread_cond_init;
pthread_cond_signal;
pthread_cond_timedwait;
pthread_cond_wait;
pthread_detach;
pthread_equal;
pthread_exit;
pthread_getspecific;
pthread_join;
pthread_key_create;
pthread_key_delete;
pthread_kill;
pthread_main_np;
pthread_mutex_destroy;
pthread_mutex_init;
pthread_mutex_lock;
pthread_mutex_trylock;
pthread_mutex_unlock;
pthread_mutexattr_destroy;
pthread_mutexattr_init;
pthread_mutexattr_settype;
pthread_once;
pthread_rwlock_destroy;
pthread_rwlock_init;
pthread_rwlock_rdlock;
pthread_rwlock_tryrdlock;
pthread_rwlock_trywrlock;
pthread_rwlock_unlock;
pthread_rwlock_wrlock;
pthread_self;
pthread_setcancelstate;
pthread_setcanceltype;
pthread_setspecific;
pthread_sigmask;
pthread_testcancel;
alarm;
arc4random;
arc4random_addrandom;
arc4random_stir;
__assert;
basename;
check_utility_compat;
clock;
closedir;
confstr;
encrypt;
des_setkey;
des_cipher;
setkey;
ctermid;
ctermid_r;
daemon;
devname;
devname_r;
dirname;
getdiskbyname;
dladdr;
dlclose;
dlerror;
dlfunc;
dllockinit;
dlopen;
dlsym;
dlvsym;
dlinfo;
Add entry for dl_iterate_phdr.
2007-04-03 18:38:01 +00:00
dl_iterate_phdr;
Add symbol maps and initial symbol version definitions to libc. Reviewed by: davidxu
2006-03-13 00:53:21 +00:00
drand48;
erand48;
err_set_file;
err_set_exit;
err;
verr;
errc;
verrc;
errx;
verrx;
warn;
vwarn;
warnc;
vwarnc;
warnx;
vwarnx;
sys_errlist;
sys_nerr;
errno;
execl;
execle;
execlp;
execv;
execvp;
execvP;
fmtcheck;
fmtmsg;
fnmatch;
__fpclassifyf;
__fpclassifyd;
__fpclassifyl;
frexp;
setfstab;
getfstab;
getfsent;
getfsspec;
getfsfile;
setfsent;
endfsent;
ftok;
ftw;
glob;
globfree;
getbootfile;
getbsize;
cgetset;
cgetcap;
cgetent;
cgetmatch;
cgetfirst;
cgetclose;
cgetnext;
cgetstr;
cgetustr;
cgetnum;
getcwd;
getdomainname;
setgrent;
setgroupent;
endgrent;
getgrent_r;
getgrnam_r;
getgrgid_r;
getgrnam;
getgrgid;
getgrent;
Use C comments since we now preprocess these files with CPP.
2007-04-29 14:05:22 +00:00
/*
* Why are __gr_parse_entry() and __gr_match_entry() not static in
* gen/getgrent.c?
*/
Add symbol maps and initial symbol version definitions to libc. Reviewed by: davidxu
2006-03-13 00:53:21 +00:00
getgrouplist;
gethostname;
getloadavg;
getlogin;
getlogin_r;
getmntinfo;
setnetgrent;
getnetgrent;
endnetgrent;
innetgr;
getosreldate;
getpagesize;
getpeereid;
_getprogname;
getprogname;
setpwent;
setpassent;
endpwent;
getpwent_r;
getpwnam_r;
getpwuid_r;
getpwnam;
getpwuid;
getpwent;
getttynam;
getttyent;
setttyent;
endttyent;
isdialuptty;
isnettty;
getusershell;
endusershell;
setusershell;
getvfsbyname;
__isnan;
isnan;
__isnanf;
isnanf;
__isinf;
isinf;
__isinff;
__isinfl;
isatty;
initgroups;
jrand48;
lcong48;
ldexp;
lockf;
lrand48;
mrand48;
nftw;
nice;
nlist;
nrand48;
opendir;
pause;
posix_madvise;
popen;
pclose;
psignal;
raise;
readdir;
readdir_r;
readpassphrase;
getpass;
rewinddir;
scandir;
alphasort;
seed48;
seekdir;
user_from_uid;
group_from_gid;
setdomainname;
sethostname;
longjmperror;
getmode;
setmode;
setproctitle;
setprogname;
siginterrupt;
sys_signame;
sys_siglist;
sys_nsig;
signal;
sigaddset;
sigdelset;
sigemptyset;
sigfillset;
sigismember;
sleep;
srand48;
fstatvfs;
statvfs;
sl_init;
sl_add;
sl_free;
sl_find;
fflagstostr;
strtofflags;
sysconf;
sysctl;
sysctlbyname;
sysctlnametomib;
syslog;
vsyslog;
openlog;
closelog;
setlogmask;
ttyname_r;
ttyname;
timezone;
times;
time;
telldir;
tcgetattr;
tcsetattr;
tcsetpgrp;
tcgetpgrp;
cfgetospeed;
cfgetispeed;
cfsetospeed;
cfsetispeed;
cfsetspeed;
cfmakeraw;
tcsendbreak;
_init_tls;
Use C comments since we now preprocess these files with CPP.
2007-04-29 14:05:22 +00:00
__tls_get_addr;
Add symbol maps and initial symbol version definitions to libc. Reviewed by: davidxu
2006-03-13 00:53:21 +00:00
tcdrain;
tcflush;
tcflow;
ualarm;
ulimit;
Revert r202447 by re-exposing the old uname(3) function. It makes hardly any sense to expose a symbol which should only be provided for binary compatibility, but it seems we don't have a lot of choice here. There are many autoconf scripts out there that try to create a binary that links against the old symbol to see whether uname(3) is present. These scripts fail to detect uname(3) now. It should be noted that the behaviour we implement is not against the standards: | The following shall be declared as a function and may also be defined | as a macro: | | int uname(struct utsname *);
2010-01-19 23:07:12 +00:00
uname;
Add symbol maps and initial symbol version definitions to libc. Reviewed by: davidxu
2006-03-13 00:53:21 +00:00
unvis;
strunvis;
strunvisx;
usleep;
utime;
valloc;
vis;
strvis;
strvisx;
wait;
wait3;
waitpid;
wordexp;
wordfree;
};
Our fts(3) API, as inherited from 4.4BSD, suffers from integer fields in FTS and FTSENT structs being too narrow. In addition, the narrow types creep from there into fts.c. As a result, fts(3) consumers, e.g., find(1) or rm(1), can't handle file trees an ordinary user can create, which can have security implications. To fix the historic implementation of fts(3), OpenBSD and NetBSD have already changed <fts.h> in somewhat incompatible ways, so we are free to do so, too. This change is a superset of changes from the other BSDs with a few more improvements. It doesn't touch fts(3) functionality; it just extends integer types used by it to match modern reality and the C standard. Here are its points: o For C object sizes, use size_t unless it's 100% certain that the object will be really small. (Note that fts(3) can construct pathnames _much_ longer than PATH_MAX for its consumers.) o Avoid the short types because on modern platforms using them results in larger and slower code. Change shorts to ints as follows: - For variables than count simple, limited things like states, use plain vanilla `int' as it's the type of choice in C. - For a limited number of bit flags use `unsigned' because signed bit-wise operations are implementation-defined, i.e., unportable, in C. o For things that should be at least 64 bits wide, use long long and not int64_t, as the latter is an optional type. See FTSENT.fts_number aka FTS.fts_bignum. Extending fts_number `to satisfy future needs' is pointless because there is fts_pointer, which can be used to link to arbitrary data from an FTSENT. However, there already are fts(3) consumers that require fts_number, or fts_bignum, have at least 64 bits in it, so we must allow for them. o For the tree depth, use `long'. This is a trade-off between making this field too wide and allowing for 64-bit inode numbers and/or chain-mounted filesystems. On the one hand, `long' is almost enough for 32-bit filesystems on a 32-bit platform (our ino_t is uint32_t now). On the other hand, platforms with a 64-bit (or wider) `long' will be ready for 64-bit inode numbers, as well as for several 32-bit filesystems mounted one under another. Note that fts_level has to be signed because -1 is a magic value for it, FTS_ROOTPARENTLEVEL. o For the `nlinks' local var in fts_build(), use `long'. The logic in fts_build() requires that `nlinks' be signed, but our nlink_t currently is uint16_t. Therefore let's make the signed var wide enough to be able to represent 2^16-1 in pure C99, and even 2^32-1 on a 64-bit platform. Perhaps the logic should be changed just to use nlink_t, but it can be done later w/o breaking fts(3) ABI any more because `nlinks' is just a local var. This commit also inludes supporting stuff for the fts change: o Preserve the old versions of fts(3) functions through libc symbol versioning because the old versions appeared in all our former releases. o Bump __FreeBSD_version just in case. There is a small chance that some ill-written 3-rd party apps may fail to build or work correctly if compiled after this change. o Update the fts(3) manpage accordingly. In particular, remove references to fts_bignum, which was a FreeBSD-specific hack to work around the too narrow types of FTSENT members. Now fts_number is at least 64 bits wide (long long) and fts_bignum is an undocumented alias for fts_number kept around for compatibility reasons. According to Google Code Search, the only big consumers of fts_bignum are in our own source tree, so they can be fixed easily to use fts_number. o Mention the change in src/UPDATING. PR: bin/104458 Approved by: re (quite a while ago) Discussed with: deischen (the symbol versioning part) Reviewed by: -arch (mostly silence); das (generally OK, but we didn't agree on some types used; assuming that no objections on -arch let me to stick to my opinion)
2008-01-26 17:09:40 +00:00
FBSD_1.1 {
Add arc4random_buf to FBSD_1.1 space
2008-07-21 18:03:31 +00:00
arc4random_buf;
Add arc4random_uniform() function (to avoid "modulo bias") Obtained from: OpenBSD
2008-07-22 11:33:49 +00:00
arc4random_uniform;
Add two new routines: fdevname() and fdevname_r(). A more elegant way of obtaining a name of a character device by its file descriptor on FreeBSD, is to use the FIODGNAME ioctl. Because a valid file descriptor implies a file descriptor is visible in /dev, it will always resolve a valid device name. I'm adding a more friendly wrapper for this ioctl, called fdevname(). It is a lot easier to use than devname() and also has better error handling. When a device name cannot be resolved, it will just return NULL instead of a generated device name that makes no sense. Discussed with: kib
2009-02-11 20:24:59 +00:00
fdevname;
fdevname_r;
Implement fdopendir(3) by splitting __opendir2() into two parts, the upper part deals with the usual __opendir2() calls, and the rest part with an interface translator to expose fdopendir(3) functionality. Manual page was obtained from kib@'s work for *at(2) system calls.
2008-04-16 18:59:36 +00:00
fdopendir;
Add feature_present(3) to the FBSD 1.1 symbol map.
2008-07-21 22:07:59 +00:00
feature_present;
Our fts(3) API, as inherited from 4.4BSD, suffers from integer fields in FTS and FTSENT structs being too narrow. In addition, the narrow types creep from there into fts.c. As a result, fts(3) consumers, e.g., find(1) or rm(1), can't handle file trees an ordinary user can create, which can have security implications. To fix the historic implementation of fts(3), OpenBSD and NetBSD have already changed <fts.h> in somewhat incompatible ways, so we are free to do so, too. This change is a superset of changes from the other BSDs with a few more improvements. It doesn't touch fts(3) functionality; it just extends integer types used by it to match modern reality and the C standard. Here are its points: o For C object sizes, use size_t unless it's 100% certain that the object will be really small. (Note that fts(3) can construct pathnames _much_ longer than PATH_MAX for its consumers.) o Avoid the short types because on modern platforms using them results in larger and slower code. Change shorts to ints as follows: - For variables than count simple, limited things like states, use plain vanilla `int' as it's the type of choice in C. - For a limited number of bit flags use `unsigned' because signed bit-wise operations are implementation-defined, i.e., unportable, in C. o For things that should be at least 64 bits wide, use long long and not int64_t, as the latter is an optional type. See FTSENT.fts_number aka FTS.fts_bignum. Extending fts_number `to satisfy future needs' is pointless because there is fts_pointer, which can be used to link to arbitrary data from an FTSENT. However, there already are fts(3) consumers that require fts_number, or fts_bignum, have at least 64 bits in it, so we must allow for them. o For the tree depth, use `long'. This is a trade-off between making this field too wide and allowing for 64-bit inode numbers and/or chain-mounted filesystems. On the one hand, `long' is almost enough for 32-bit filesystems on a 32-bit platform (our ino_t is uint32_t now). On the other hand, platforms with a 64-bit (or wider) `long' will be ready for 64-bit inode numbers, as well as for several 32-bit filesystems mounted one under another. Note that fts_level has to be signed because -1 is a magic value for it, FTS_ROOTPARENTLEVEL. o For the `nlinks' local var in fts_build(), use `long'. The logic in fts_build() requires that `nlinks' be signed, but our nlink_t currently is uint16_t. Therefore let's make the signed var wide enough to be able to represent 2^16-1 in pure C99, and even 2^32-1 on a 64-bit platform. Perhaps the logic should be changed just to use nlink_t, but it can be done later w/o breaking fts(3) ABI any more because `nlinks' is just a local var. This commit also inludes supporting stuff for the fts change: o Preserve the old versions of fts(3) functions through libc symbol versioning because the old versions appeared in all our former releases. o Bump __FreeBSD_version just in case. There is a small chance that some ill-written 3-rd party apps may fail to build or work correctly if compiled after this change. o Update the fts(3) manpage accordingly. In particular, remove references to fts_bignum, which was a FreeBSD-specific hack to work around the too narrow types of FTSENT members. Now fts_number is at least 64 bits wide (long long) and fts_bignum is an undocumented alias for fts_number kept around for compatibility reasons. According to Google Code Search, the only big consumers of fts_bignum are in our own source tree, so they can be fixed easily to use fts_number. o Mention the change in src/UPDATING. PR: bin/104458 Approved by: re (quite a while ago) Discussed with: deischen (the symbol versioning part) Reviewed by: -arch (mostly silence); das (generally OK, but we didn't agree on some types used; assuming that no objections on -arch let me to stick to my opinion)
2008-01-26 17:09:40 +00:00
fts_children;
Fix whitespace and sorting in Symbol.map.
2009-05-04 08:06:52 +00:00
fts_close;
Our fts(3) API, as inherited from 4.4BSD, suffers from integer fields in FTS and FTSENT structs being too narrow. In addition, the narrow types creep from there into fts.c. As a result, fts(3) consumers, e.g., find(1) or rm(1), can't handle file trees an ordinary user can create, which can have security implications. To fix the historic implementation of fts(3), OpenBSD and NetBSD have already changed <fts.h> in somewhat incompatible ways, so we are free to do so, too. This change is a superset of changes from the other BSDs with a few more improvements. It doesn't touch fts(3) functionality; it just extends integer types used by it to match modern reality and the C standard. Here are its points: o For C object sizes, use size_t unless it's 100% certain that the object will be really small. (Note that fts(3) can construct pathnames _much_ longer than PATH_MAX for its consumers.) o Avoid the short types because on modern platforms using them results in larger and slower code. Change shorts to ints as follows: - For variables than count simple, limited things like states, use plain vanilla `int' as it's the type of choice in C. - For a limited number of bit flags use `unsigned' because signed bit-wise operations are implementation-defined, i.e., unportable, in C. o For things that should be at least 64 bits wide, use long long and not int64_t, as the latter is an optional type. See FTSENT.fts_number aka FTS.fts_bignum. Extending fts_number `to satisfy future needs' is pointless because there is fts_pointer, which can be used to link to arbitrary data from an FTSENT. However, there already are fts(3) consumers that require fts_number, or fts_bignum, have at least 64 bits in it, so we must allow for them. o For the tree depth, use `long'. This is a trade-off between making this field too wide and allowing for 64-bit inode numbers and/or chain-mounted filesystems. On the one hand, `long' is almost enough for 32-bit filesystems on a 32-bit platform (our ino_t is uint32_t now). On the other hand, platforms with a 64-bit (or wider) `long' will be ready for 64-bit inode numbers, as well as for several 32-bit filesystems mounted one under another. Note that fts_level has to be signed because -1 is a magic value for it, FTS_ROOTPARENTLEVEL. o For the `nlinks' local var in fts_build(), use `long'. The logic in fts_build() requires that `nlinks' be signed, but our nlink_t currently is uint16_t. Therefore let's make the signed var wide enough to be able to represent 2^16-1 in pure C99, and even 2^32-1 on a 64-bit platform. Perhaps the logic should be changed just to use nlink_t, but it can be done later w/o breaking fts(3) ABI any more because `nlinks' is just a local var. This commit also inludes supporting stuff for the fts change: o Preserve the old versions of fts(3) functions through libc symbol versioning because the old versions appeared in all our former releases. o Bump __FreeBSD_version just in case. There is a small chance that some ill-written 3-rd party apps may fail to build or work correctly if compiled after this change. o Update the fts(3) manpage accordingly. In particular, remove references to fts_bignum, which was a FreeBSD-specific hack to work around the too narrow types of FTSENT members. Now fts_number is at least 64 bits wide (long long) and fts_bignum is an undocumented alias for fts_number kept around for compatibility reasons. According to Google Code Search, the only big consumers of fts_bignum are in our own source tree, so they can be fixed easily to use fts_number. o Mention the change in src/UPDATING. PR: bin/104458 Approved by: re (quite a while ago) Discussed with: deischen (the symbol versioning part) Reviewed by: -arch (mostly silence); das (generally OK, but we didn't agree on some types used; assuming that no objections on -arch let me to stick to my opinion)
2008-01-26 17:09:40 +00:00
fts_get_clientptr;
fts_get_stream;
Fix whitespace and sorting in Symbol.map.
2009-05-04 08:06:52 +00:00
fts_open;
fts_read;
fts_set;
Our fts(3) API, as inherited from 4.4BSD, suffers from integer fields in FTS and FTSENT structs being too narrow. In addition, the narrow types creep from there into fts.c. As a result, fts(3) consumers, e.g., find(1) or rm(1), can't handle file trees an ordinary user can create, which can have security implications. To fix the historic implementation of fts(3), OpenBSD and NetBSD have already changed <fts.h> in somewhat incompatible ways, so we are free to do so, too. This change is a superset of changes from the other BSDs with a few more improvements. It doesn't touch fts(3) functionality; it just extends integer types used by it to match modern reality and the C standard. Here are its points: o For C object sizes, use size_t unless it's 100% certain that the object will be really small. (Note that fts(3) can construct pathnames _much_ longer than PATH_MAX for its consumers.) o Avoid the short types because on modern platforms using them results in larger and slower code. Change shorts to ints as follows: - For variables than count simple, limited things like states, use plain vanilla `int' as it's the type of choice in C. - For a limited number of bit flags use `unsigned' because signed bit-wise operations are implementation-defined, i.e., unportable, in C. o For things that should be at least 64 bits wide, use long long and not int64_t, as the latter is an optional type. See FTSENT.fts_number aka FTS.fts_bignum. Extending fts_number `to satisfy future needs' is pointless because there is fts_pointer, which can be used to link to arbitrary data from an FTSENT. However, there already are fts(3) consumers that require fts_number, or fts_bignum, have at least 64 bits in it, so we must allow for them. o For the tree depth, use `long'. This is a trade-off between making this field too wide and allowing for 64-bit inode numbers and/or chain-mounted filesystems. On the one hand, `long' is almost enough for 32-bit filesystems on a 32-bit platform (our ino_t is uint32_t now). On the other hand, platforms with a 64-bit (or wider) `long' will be ready for 64-bit inode numbers, as well as for several 32-bit filesystems mounted one under another. Note that fts_level has to be signed because -1 is a magic value for it, FTS_ROOTPARENTLEVEL. o For the `nlinks' local var in fts_build(), use `long'. The logic in fts_build() requires that `nlinks' be signed, but our nlink_t currently is uint16_t. Therefore let's make the signed var wide enough to be able to represent 2^16-1 in pure C99, and even 2^32-1 on a 64-bit platform. Perhaps the logic should be changed just to use nlink_t, but it can be done later w/o breaking fts(3) ABI any more because `nlinks' is just a local var. This commit also inludes supporting stuff for the fts change: o Preserve the old versions of fts(3) functions through libc symbol versioning because the old versions appeared in all our former releases. o Bump __FreeBSD_version just in case. There is a small chance that some ill-written 3-rd party apps may fail to build or work correctly if compiled after this change. o Update the fts(3) manpage accordingly. In particular, remove references to fts_bignum, which was a FreeBSD-specific hack to work around the too narrow types of FTSENT members. Now fts_number is at least 64 bits wide (long long) and fts_bignum is an undocumented alias for fts_number kept around for compatibility reasons. According to Google Code Search, the only big consumers of fts_bignum are in our own source tree, so they can be fixed easily to use fts_number. o Mention the change in src/UPDATING. PR: bin/104458 Approved by: re (quite a while ago) Discussed with: deischen (the symbol versioning part) Reviewed by: -arch (mostly silence); das (generally OK, but we didn't agree on some types used; assuming that no objections on -arch let me to stick to my opinion)
2008-01-26 17:09:40 +00:00
fts_set_clientptr;
Fix whitespace and sorting in Symbol.map.
2009-05-04 08:06:52 +00:00
posix_spawn;
posix_spawn_file_actions_addclose;
posix_spawn_file_actions_adddup2;
posix_spawn_file_actions_addopen;
posix_spawn_file_actions_destroy;
posix_spawn_file_actions_init;
posix_spawnattr_destroy;
posix_spawnattr_getflags;
posix_spawnattr_getpgroup;
posix_spawnattr_getschedparam;
posix_spawnattr_getschedpolicy;
posix_spawnattr_getsigdefault;
posix_spawnattr_getsigmask;
posix_spawnattr_init;
posix_spawnattr_setflags;
posix_spawnattr_setpgroup;
posix_spawnattr_setschedparam;
posix_spawnattr_setschedpolicy;
posix_spawnattr_setsigdefault;
posix_spawnattr_setsigmask;
posix_spawnp;
Change the ABI of some of the structures used by the SYSV IPC API: - The uid/cuid members of struct ipc_perm are now uid_t instead of unsigned short. - The gid/cgid members of struct ipc_perm are now gid_t instead of unsigned short. - The mode member of struct ipc_perm is now mode_t instead of unsigned short (this is merely a style bug). - The rather dubious padding fields for ABI compat with SV/I386 have been removed from struct msqid_ds and struct semid_ds. - The shm_segsz member of struct shmid_ds is now a size_t instead of an int. This removes the need for the shm_bsegsz member in struct shmid_kernel and should allow for complete support of SYSV SHM regions >= 2GB. - The shm_nattch member of struct shmid_ds is now an int instead of a short. - The shm_internal member of struct shmid_ds is now gone. The internal VM object pointer for SHM regions has been moved into struct shmid_kernel. - The existing __semctl(), msgctl(), and shmctl() system call entries are now marked COMPAT7 and new versions of those system calls which support the new ABI are now present. - The new system calls are assigned to the FBSD-1.1 version in libc. The FBSD-1.0 symbols in libc now refer to the old COMPAT7 system calls. - A simplistic framework for tagging system calls with compatibility symbol versions has been added to libc. Version tags are added to system calls by adding an appropriate __sym_compat() entry to src/lib/libc/incldue/compat.h. [1] PR: kern/16195 kern/113218 bin/129855 Reviewed by: arch@, rwatson Discussed with: kan, kib [1]
2009-06-24 21:10:52 +00:00
semctl;
Implement POSIX function tcgetsid() which returns session id. PR: stand/107561
2008-04-15 08:33:32 +00:00
tcgetsid;
Add tcsetsid(3). The entire world seems to use the non-standard TIOCSCTTY ioctl to make a TTY a controlling terminal of a session. Even though tcsetsid(3) is also non-standard, I think it's a lot better to use in our own source code, mainly because it's similar to tcsetpgrp(), tcgetpgrp() and tcgetsid(). I stole the idea from QNX. They do it the other way around; their TIOCSCTTY is just a wrapper around tcsetsid(). tcsetsid() then calls into an IPC framework.
2009-05-07 13:49:48 +00:00
tcsetsid;
Use umtx to implement process sharable semaphore, to make this work, now type sema_t is a structure which can be put in a shared memory area, and multiple processes can operate it concurrently. User can either use mmap(MAP_SHARED) + sem_init(pshared=1) or use sem_open() to initialize a shared semaphore. Named semaphore uses file system and is located in /tmp directory, and its file name is prefixed with 'SEMD', so now it is chroot or jail friendly. In simplist cases, both for named and un-named semaphore, userland code does not have to enter kernel to reduce/increase semaphore's count. The semaphore is designed to be crash-safe, it means even if an application is crashed in the middle of operating semaphore, the semaphore state is still safely recovered by later use, there is no waiter counter maintained by userland code. The main semaphore code is in libc and libthr only has some necessary stubs, this makes it possible that a non-threaded application can use semaphore without linking to thread library. Old semaphore implementation is kept libc to maintain binary compatibility. The kernel ksem API is no longer used in the new implemenation. Discussed on: threads@
2010-01-05 02:37:59 +00:00
__pthread_cleanup_pop_imp;
__pthread_cleanup_push_imp;
Our fts(3) API, as inherited from 4.4BSD, suffers from integer fields in FTS and FTSENT structs being too narrow. In addition, the narrow types creep from there into fts.c. As a result, fts(3) consumers, e.g., find(1) or rm(1), can't handle file trees an ordinary user can create, which can have security implications. To fix the historic implementation of fts(3), OpenBSD and NetBSD have already changed <fts.h> in somewhat incompatible ways, so we are free to do so, too. This change is a superset of changes from the other BSDs with a few more improvements. It doesn't touch fts(3) functionality; it just extends integer types used by it to match modern reality and the C standard. Here are its points: o For C object sizes, use size_t unless it's 100% certain that the object will be really small. (Note that fts(3) can construct pathnames _much_ longer than PATH_MAX for its consumers.) o Avoid the short types because on modern platforms using them results in larger and slower code. Change shorts to ints as follows: - For variables than count simple, limited things like states, use plain vanilla `int' as it's the type of choice in C. - For a limited number of bit flags use `unsigned' because signed bit-wise operations are implementation-defined, i.e., unportable, in C. o For things that should be at least 64 bits wide, use long long and not int64_t, as the latter is an optional type. See FTSENT.fts_number aka FTS.fts_bignum. Extending fts_number `to satisfy future needs' is pointless because there is fts_pointer, which can be used to link to arbitrary data from an FTSENT. However, there already are fts(3) consumers that require fts_number, or fts_bignum, have at least 64 bits in it, so we must allow for them. o For the tree depth, use `long'. This is a trade-off between making this field too wide and allowing for 64-bit inode numbers and/or chain-mounted filesystems. On the one hand, `long' is almost enough for 32-bit filesystems on a 32-bit platform (our ino_t is uint32_t now). On the other hand, platforms with a 64-bit (or wider) `long' will be ready for 64-bit inode numbers, as well as for several 32-bit filesystems mounted one under another. Note that fts_level has to be signed because -1 is a magic value for it, FTS_ROOTPARENTLEVEL. o For the `nlinks' local var in fts_build(), use `long'. The logic in fts_build() requires that `nlinks' be signed, but our nlink_t currently is uint16_t. Therefore let's make the signed var wide enough to be able to represent 2^16-1 in pure C99, and even 2^32-1 on a 64-bit platform. Perhaps the logic should be changed just to use nlink_t, but it can be done later w/o breaking fts(3) ABI any more because `nlinks' is just a local var. This commit also inludes supporting stuff for the fts change: o Preserve the old versions of fts(3) functions through libc symbol versioning because the old versions appeared in all our former releases. o Bump __FreeBSD_version just in case. There is a small chance that some ill-written 3-rd party apps may fail to build or work correctly if compiled after this change. o Update the fts(3) manpage accordingly. In particular, remove references to fts_bignum, which was a FreeBSD-specific hack to work around the too narrow types of FTSENT members. Now fts_number is at least 64 bits wide (long long) and fts_bignum is an undocumented alias for fts_number kept around for compatibility reasons. According to Google Code Search, the only big consumers of fts_bignum are in our own source tree, so they can be fixed easily to use fts_number. o Mention the change in src/UPDATING. PR: bin/104458 Approved by: re (quite a while ago) Discussed with: deischen (the symbol versioning part) Reviewed by: -arch (mostly silence); das (generally OK, but we didn't agree on some types used; assuming that no objections on -arch let me to stick to my opinion)
2008-01-26 17:09:40 +00:00
};
Add getpagesizes(3). This functions either the number of supported page sizes or some number of the sizes themselves. It is functionally compatible with a function by the same name under Solaris. Reviewed by: jhb
2009-09-19 18:01:32 +00:00
FBSD_1.2 {
Add basename_r(3) to complement basename(3). basename_r(3) which accepts a caller-allocated buffer of at least MAXPATHLEN, rather than using a global buffer. MFC after: 1 month Sponsored by: Google
2009-10-06 14:05:57 +00:00
basename_r;
Implement <utmpx.h>. The utmpx interface is the standardized interface of the user accounting database. The standard only defines a subset of the functions that were present in System V-like systems. I'd like to highlight some of the traits my implementation has: - The standard allows the on-disk format to be different than the in-memory representation (struct utmpx). Most operating systems don't do this, but we do. This allows us to keep our ABI more stable, while giving us the opportunity to modify the on-disk format. It also allows us to use a common file format across different architectures (i.e. byte ordering). - Our implementation of pututxline() also updates wtmp and lastlog (now called utx.log and utx.lastlogin). This means the databases are more likely to be in sync. - Care must be taken that our implementation discard any fields that are not applicable. For example, our DEAD_PROCESS records do not hold a TTY name. Just a time stamp, a record identifier and a process identifier. It also guarantees that strings (ut_host, ut_line and ut_user) are null terminated. ut_id is obviously not null terminated, because it's not a string. - The API and its behaviour should be conformant to POSIX, but there may be things that slightly deviate from the standard. This implementation uses separate file descriptors when writing to the log files. It also doesn't use getutxid() to search for a field to overwrite. It uses an allocation strategy similar to getutxid(), but prevents DEAD_PROCESS records from accumulating. Make sure libulog doesn't overwrite the manpages shipped with our C library. Also keep the symbol list in Symbol.map sorted. I'll bump __FreeBSD_version later this evening. I first want to convert everything to <utmpx.h> and get rid of <utmp.h>.
2010-01-13 17:29:55 +00:00
endutxent;
Add getpagesizes(3). This functions either the number of supported page sizes or some number of the sizes themselves. It is functionally compatible with a function by the same name under Solaris. Reviewed by: jhb
2009-09-19 18:01:32 +00:00
getpagesizes;
Implement <utmpx.h>. The utmpx interface is the standardized interface of the user accounting database. The standard only defines a subset of the functions that were present in System V-like systems. I'd like to highlight some of the traits my implementation has: - The standard allows the on-disk format to be different than the in-memory representation (struct utmpx). Most operating systems don't do this, but we do. This allows us to keep our ABI more stable, while giving us the opportunity to modify the on-disk format. It also allows us to use a common file format across different architectures (i.e. byte ordering). - Our implementation of pututxline() also updates wtmp and lastlog (now called utx.log and utx.lastlogin). This means the databases are more likely to be in sync. - Care must be taken that our implementation discard any fields that are not applicable. For example, our DEAD_PROCESS records do not hold a TTY name. Just a time stamp, a record identifier and a process identifier. It also guarantees that strings (ut_host, ut_line and ut_user) are null terminated. ut_id is obviously not null terminated, because it's not a string. - The API and its behaviour should be conformant to POSIX, but there may be things that slightly deviate from the standard. This implementation uses separate file descriptors when writing to the log files. It also doesn't use getutxid() to search for a field to overwrite. It uses an allocation strategy similar to getutxid(), but prevents DEAD_PROCESS records from accumulating. Make sure libulog doesn't overwrite the manpages shipped with our C library. Also keep the symbol list in Symbol.map sorted. I'll bump __FreeBSD_version later this evening. I first want to convert everything to <utmpx.h> and get rid of <utmp.h>.
2010-01-13 17:29:55 +00:00
getutxent;
getutxid;
getutxline;
getutxuser;
pututxline;
Use umtx to implement process sharable semaphore, to make this work, now type sema_t is a structure which can be put in a shared memory area, and multiple processes can operate it concurrently. User can either use mmap(MAP_SHARED) + sem_init(pshared=1) or use sem_open() to initialize a shared semaphore. Named semaphore uses file system and is located in /tmp directory, and its file name is prefixed with 'SEMD', so now it is chroot or jail friendly. In simplist cases, both for named and un-named semaphore, userland code does not have to enter kernel to reduce/increase semaphore's count. The semaphore is designed to be crash-safe, it means even if an application is crashed in the middle of operating semaphore, the semaphore state is still safely recovered by later use, there is no waiter counter maintained by userland code. The main semaphore code is in libc and libthr only has some necessary stubs, this makes it possible that a non-threaded application can use semaphore without linking to thread library. Old semaphore implementation is kept libc to maintain binary compatibility. The kernel ksem API is no longer used in the new implemenation. Discussed on: threads@
2010-01-05 02:37:59 +00:00
sem_close;
sem_destroy;
sem_getvalue;
sem_init;
sem_open;
Implement <utmpx.h>. The utmpx interface is the standardized interface of the user accounting database. The standard only defines a subset of the functions that were present in System V-like systems. I'd like to highlight some of the traits my implementation has: - The standard allows the on-disk format to be different than the in-memory representation (struct utmpx). Most operating systems don't do this, but we do. This allows us to keep our ABI more stable, while giving us the opportunity to modify the on-disk format. It also allows us to use a common file format across different architectures (i.e. byte ordering). - Our implementation of pututxline() also updates wtmp and lastlog (now called utx.log and utx.lastlogin). This means the databases are more likely to be in sync. - Care must be taken that our implementation discard any fields that are not applicable. For example, our DEAD_PROCESS records do not hold a TTY name. Just a time stamp, a record identifier and a process identifier. It also guarantees that strings (ut_host, ut_line and ut_user) are null terminated. ut_id is obviously not null terminated, because it's not a string. - The API and its behaviour should be conformant to POSIX, but there may be things that slightly deviate from the standard. This implementation uses separate file descriptors when writing to the log files. It also doesn't use getutxid() to search for a field to overwrite. It uses an allocation strategy similar to getutxid(), but prevents DEAD_PROCESS records from accumulating. Make sure libulog doesn't overwrite the manpages shipped with our C library. Also keep the symbol list in Symbol.map sorted. I'll bump __FreeBSD_version later this evening. I first want to convert everything to <utmpx.h> and get rid of <utmp.h>.
2010-01-13 17:29:55 +00:00
sem_post;
Use umtx to implement process sharable semaphore, to make this work, now type sema_t is a structure which can be put in a shared memory area, and multiple processes can operate it concurrently. User can either use mmap(MAP_SHARED) + sem_init(pshared=1) or use sem_open() to initialize a shared semaphore. Named semaphore uses file system and is located in /tmp directory, and its file name is prefixed with 'SEMD', so now it is chroot or jail friendly. In simplist cases, both for named and un-named semaphore, userland code does not have to enter kernel to reduce/increase semaphore's count. The semaphore is designed to be crash-safe, it means even if an application is crashed in the middle of operating semaphore, the semaphore state is still safely recovered by later use, there is no waiter counter maintained by userland code. The main semaphore code is in libc and libthr only has some necessary stubs, this makes it possible that a non-threaded application can use semaphore without linking to thread library. Old semaphore implementation is kept libc to maintain binary compatibility. The kernel ksem API is no longer used in the new implemenation. Discussed on: threads@
2010-01-05 02:37:59 +00:00
sem_timedwait;
sem_trywait;
sem_unlink;
Implement <utmpx.h>. The utmpx interface is the standardized interface of the user accounting database. The standard only defines a subset of the functions that were present in System V-like systems. I'd like to highlight some of the traits my implementation has: - The standard allows the on-disk format to be different than the in-memory representation (struct utmpx). Most operating systems don't do this, but we do. This allows us to keep our ABI more stable, while giving us the opportunity to modify the on-disk format. It also allows us to use a common file format across different architectures (i.e. byte ordering). - Our implementation of pututxline() also updates wtmp and lastlog (now called utx.log and utx.lastlogin). This means the databases are more likely to be in sync. - Care must be taken that our implementation discard any fields that are not applicable. For example, our DEAD_PROCESS records do not hold a TTY name. Just a time stamp, a record identifier and a process identifier. It also guarantees that strings (ut_host, ut_line and ut_user) are null terminated. ut_id is obviously not null terminated, because it's not a string. - The API and its behaviour should be conformant to POSIX, but there may be things that slightly deviate from the standard. This implementation uses separate file descriptors when writing to the log files. It also doesn't use getutxid() to search for a field to overwrite. It uses an allocation strategy similar to getutxid(), but prevents DEAD_PROCESS records from accumulating. Make sure libulog doesn't overwrite the manpages shipped with our C library. Also keep the symbol list in Symbol.map sorted. I'll bump __FreeBSD_version later this evening. I first want to convert everything to <utmpx.h> and get rid of <utmp.h>.
2010-01-13 17:29:55 +00:00
sem_wait;
setutxdb;
setutxent;
Add getpagesizes(3). This functions either the number of supported page sizes or some number of the sizes themselves. It is functionally compatible with a function by the same name under Solaris. Reviewed by: jhb
2009-09-19 18:01:32 +00:00
};
Use C comments since we now preprocess these files with CPP.
2007-04-29 14:05:22 +00:00
FBSDprivate_1.0 {
/* needed by thread libraries */
Add symbol maps and initial symbol version definitions to libc. Reviewed by: davidxu
2006-03-13 00:53:21 +00:00
__thr_jtable;
_pthread_atfork;
_pthread_attr_destroy;
_pthread_attr_getdetachstate;
_pthread_attr_getguardsize;
_pthread_attr_getinheritsched;
_pthread_attr_getschedparam;
_pthread_attr_getschedpolicy;
_pthread_attr_getscope;
_pthread_attr_getstackaddr;
_pthread_attr_getstacksize;
_pthread_attr_init;
_pthread_attr_setdetachstate;
_pthread_attr_setguardsize;
_pthread_attr_setinheritsched;
_pthread_attr_setschedparam;
_pthread_attr_setschedpolicy;
_pthread_attr_setscope;
_pthread_attr_setstackaddr;
_pthread_attr_setstacksize;
_pthread_cancel;
_pthread_cleanup_pop;
_pthread_cleanup_push;
_pthread_cond_broadcast;
_pthread_cond_destroy;
_pthread_cond_init;
_pthread_cond_signal;
_pthread_cond_timedwait;
_pthread_cond_wait;
_pthread_detach;
_pthread_equal;
_pthread_exit;
_pthread_getspecific;
_pthread_join;
_pthread_key_create;
_pthread_key_delete;
_pthread_kill;
_pthread_main_np;
_pthread_mutex_destroy;
Add _pthread_mutex_init_calloc_cb to libc's map, for which malloc defines a stub.
2007-11-27 16:22:21 +00:00
_pthread_mutex_init_calloc_cb;
Add symbol maps and initial symbol version definitions to libc. Reviewed by: davidxu
2006-03-13 00:53:21 +00:00
_pthread_mutex_init;
_pthread_mutex_lock;
_pthread_mutex_trylock;
_pthread_mutex_unlock;
_pthread_mutexattr_destroy;
_pthread_mutexattr_init;
_pthread_mutexattr_settype;
_pthread_once;
_pthread_rwlock_destroy;
_pthread_rwlock_init;
_pthread_rwlock_rdlock;
_pthread_rwlock_tryrdlock;
_pthread_rwlock_trywrlock;
_pthread_rwlock_unlock;
_pthread_rwlock_wrlock;
_pthread_self;
_pthread_setcancelstate;
_pthread_setcanceltype;
_pthread_setspecific;
_pthread_sigmask;
_pthread_testcancel;
_spinlock;
_spinlock_debug;
_spinunlock;
Introduce implementation-private rtld interface _rtld_addr_phdr, which fills struct dl_phdr_info for the shared object that contains the specified address, if any. Idea and reviewed by: kan MFC after: 3 weeks
2010-08-23 15:27:03 +00:00
_rtld_addr_phdr;
Add two rtld exported symbols, _rtld_atfork_pre and _rtld_atfork_post. Threading library calls _pre before the fork, allowing the rtld to lock itself to ensure that other threads of the process are out of dynamic linker. _post releases the locks. This allows the rtld to have consistent state in the child. Although child may legitimately call only async-safe functions, the call may need plt relocation resolution, and this requires working rtld. Reported and debugging help by: rink Reviewed by: kan, davidxu MFC after: 1 month (anyway, not before 7.1 is out)
2008-11-27 11:27:59 +00:00
_rtld_atfork_pre;
_rtld_atfork_post;
Use C comments since we now preprocess these files with CPP.
2007-04-29 14:05:22 +00:00
_rtld_error; /* for private use */
_rtld_thread_init; /* for private use */
Add symbol maps and initial symbol version definitions to libc. Reviewed by: davidxu
2006-03-13 00:53:21 +00:00
_err;
_warn;
__fmtcheck;
Use C comments since we now preprocess these files with CPP.
2007-04-29 14:05:22 +00:00
/* __pw_match_entry; */
/* __pw_parse_entry; */
__fdnlist; /* used by libkvm */
/* __aout_fdnlist; */
/* __elf_is_okay__; */
/* __elf_fdnlist; */
Add symbol maps and initial symbol version definitions to libc. Reviewed by: davidxu
2006-03-13 00:53:21 +00:00
__opendir2;
__pause;
_pause;
Use C comments since we now preprocess these files with CPP.
2007-04-29 14:05:22 +00:00
__pw_scan; /* Used by (at least) libutil */
Add symbol maps and initial symbol version definitions to libc. Reviewed by: davidxu
2006-03-13 00:53:21 +00:00
__raise;
_raise;
__sleep;
_sleep;
_rtld_allocate_tls;
_rtld_free_tls;
Use C comments since we now preprocess these files with CPP.
2007-04-29 14:05:22 +00:00
#if defined(i386)
___libc_tls_get_addr; /* x86 only */
#endif
__libc_tls_get_addr;
Add symbol maps and initial symbol version definitions to libc. Reviewed by: davidxu
2006-03-13 00:53:21 +00:00
__tcdrain;
_tcdrain;
__usleep;
_usleep;
__wait;
_wait;
__waitpid;
_waitpid;
Use umtx to implement process sharable semaphore, to make this work, now type sema_t is a structure which can be put in a shared memory area, and multiple processes can operate it concurrently. User can either use mmap(MAP_SHARED) + sem_init(pshared=1) or use sem_open() to initialize a shared semaphore. Named semaphore uses file system and is located in /tmp directory, and its file name is prefixed with 'SEMD', so now it is chroot or jail friendly. In simplist cases, both for named and un-named semaphore, userland code does not have to enter kernel to reduce/increase semaphore's count. The semaphore is designed to be crash-safe, it means even if an application is crashed in the middle of operating semaphore, the semaphore state is still safely recovered by later use, there is no waiter counter maintained by userland code. The main semaphore code is in libc and libthr only has some necessary stubs, this makes it possible that a non-threaded application can use semaphore without linking to thread library. Old semaphore implementation is kept libc to maintain binary compatibility. The kernel ksem API is no longer used in the new implemenation. Discussed on: threads@
2010-01-05 02:37:59 +00:00
_libc_sem_init_compat;
_libc_sem_destroy_compat;
_libc_sem_open_compat;
_libc_sem_close_compat;
_libc_sem_unlink_compat;
_libc_sem_wait_compat;
_libc_sem_trywait_compat;
_libc_sem_timedwait_compat;
_libc_sem_post_compat;
_libc_sem_getvalue_compat;
Use aux vector to get values for SSP canary, pagesize, pagesizes array, number of host CPUs and osreldate. This eliminates the last sysctl(2) calls from the dynamically linked image startup. No objections from: kan Tested by: marius (sparc64) MFC after: 1 month
2010-08-17 09:13:26 +00:00
__elf_aux_vector;
Add symbol maps and initial symbol version definitions to libc. Reviewed by: davidxu
2006-03-13 00:53:21 +00:00
};
Reference in New Issue Copy Permalink