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

482 lines
7.4 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;
pselect;
psignal;
raise;
readdir;
readdir_r;
readpassphrase;
getpass;
rewinddir;
scandir;
alphasort;
seed48;
seekdir;
user_from_uid;
group_from_gid;
sem_init;
sem_destroy;
sem_open;
sem_close;
sem_unlink;
sem_wait;
sem_trywait;
sem_timedwait;
sem_post;
sem_getvalue;
semctl;
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;
ttyslot;
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;
uname;
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;
Implement POSIX function tcgetsid() which returns session id. PR: stand/107561
2008-04-15 08:33:32 +00:00
tcgetsid;
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
};
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;
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;
__pselect;
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;
__sem_init;
__sem_destroy;
__sem_open;
__sem_close;
__sem_unlink;
__sem_wait;
__sem_trywait;
__sem_timedwait;
__sem_post;
__sem_getvalue;
__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;
};
Reference in New Issue Copy Permalink