> Date: Sat, 10 Sep 2016 13:55:15 -0700 > From: Philip Guenther <[email protected]> > > On Sat, 10 Sep 2016, Mark Kettenis wrote: > > Thanks. Now the only issue seems to be: > > > > barber$ check_sym > > /usr/lib/libc.so.89.1 --> obj/libc.so.89.1 > > Dynamic export changes: > > PLT added: > > __stack_smash_handler > > memcpy > > memmove > > memset > > > > Not sure how to tackle those yet. > > Harumph. That's what that chunk at the bottom of include/namespace.h is > there for. This will take some research to figure out how to get clang to > apply asm names to calls that it generates. :-( Not the end of the > world, just annoying. > > (gcc's support for renames like this is incomplete, btw, at least in our > old version: I couldn't find a way to do this sort of renaming on calls > generated to math helper functions like __umodsi3. gcc also ignores the > renaming on certain functions when it tries to optimize out calls to them > but ends up calling them anway, including ffs() on archs like sparc64 and > mips64 which don't have it as a compiler builtin, so that even though we > do an internal renaming, gcc still generates a call to ffs() instead of > _libc_ffs(). Fail) > > > Also interesting that it generates memmove() calls. Wonder where it ended > up doing that.
Well, clang actually calls the functions with their standard name even for the cases where we explicitly call those functions in the source code. And since we do call memmove() in various places in the source code, that's where they come from.
