comparison ChangeLog @ 224:61fff73dbff8

- changelog
author Tassilo Philipp
date Sat, 15 Apr 2017 15:44:33 +0200
parents 6784e74490ba
children 98503af08916
comparison
equal deleted inserted replaced
223:7076f551faf5 224:61fff73dbff8
15 o SPARC32 (v7/v8) support 15 o SPARC32 (v7/v8) support
16 o SPARC64 (v9) support 16 o SPARC64 (v9) support
17 o POSIX compliance: fallback for wx alloc on systems that don't have mmap()'s MAP_ANON 17 o POSIX compliance: fallback for wx alloc on systems that don't have mmap()'s MAP_ANON
18 o allocated space used for thunk now always W^X (req. for e.g. OpenBSD >= 6.0) 18 o allocated space used for thunk now always W^X (req. for e.g. OpenBSD >= 6.0)
19 dynload: 19 dynload:
20 o simplifications of implemention on Darwin 20 o major reliability/stability fixes for Mach-O dlSyms* functions to (thanks Stéphane Mons for help):
21 o reliability/stability fixes for Mach-O dlSyms* lib to better handle loading dylibs by symlink, 21 better handle loading dylibs by symlink, relative path, random casing, etc.
22 relative path, path with random casing, etc., as well as fixes to symbol name lookups that 22 fixes to symbol name lookups that used wrong offsets before
23 used wrong offsets before (thanks Stéphane Mons for finding and help) 23 64-bit platform fixes (was broken on x64 and never supported on others)
24 o allowing Mach-O dlSyms* lib to be used standalone (consistent with ELF and PE impls now) 24 o allowing Mach-O dlSyms* lib to be used standalone (consistent with ELF and PE impls now)
25 o support for non-x64 64-bit platforms when using dlSyms* functions with Macho-O files 25 o simplifications of implemention on Darwin, sharing parts with *nix implementation
26 o potentially breaking change on macos/Darwin platforms: all functions now consistently accept or 26 o potentially breaking change on macos/Darwin platforms: all functions now consistently accept or
27 return symbol names as they would appear in C code, instead of the raw name in object files 27 return symbol names as they would appear in C code, instead of the raw ones in object files
28 general: 28 general:
29 o marked assembly code as not needing an execstack, for safer/easier integration into other 29 o marked assembly code as not needing an execstack, for safer/easier integration into other
30 projects/builds, where needed; this is needed b/c of questionable default behaviours of some 30 projects/builds, where needed; this is needed b/c of questionable default behaviours of some
31 toolchains (thanks Thorsten Behrens for report and analysis) 31 toolchains (thanks Thorsten Behrens for report and analysis)
32 doc: 32 doc: