On Sun, Dec 10, 2017 at 08:25:54PM -0600, David Young wrote: > > > The problem raised earlier as ps(1) wasn't buildable because of > > > duplicate symbol. This unveils the problems very early and so there is > > > no observed misbehavior. > > > > If the issue occures purely at link time, then the problem is that the > > sanitizer library isn't doing the right ELF manipulations. > > Can you elaborate? What are the "right" ELF manipulations?
Traditionally in Unix if I compile and link a C program that contains its own symbol "getpid", the rules for inclusion from .a files (and the way libc is built, with mostly each thing in its own .o file) means that mine will take precedence and there will not be link errors. With the advent of shared libraries, suddenly libc is a single file that can either be linked or not, and so in the absence of a compensating mechanism this traditional behavior is broken: getpid is now multiply defined and the link fails. That isn't what anyone wanted, so to allow approximating the static link behavior ELF added a concept called a "weak symbol" that is ignored by the linker if a definition of that symbol already exists. In netbsd everything in libc with a name that isn't from Standard C (and thus not reusable by application code) is marked weak and aliased to a version of the name with a _ in front; also internal uses by libc are routed to those names so application use of conflicting symbols doesn't break libc. This is what libc's namespace.h is for, and somewhere there's actual documentation about it. The sanitizer libraries should be doing the same things, and apparently they aren't. Also, where the sanitizer libraries are trying to intercept and wrap libc calls they should be using the ELF dynamic linker's wrap functionality, and I'm not sure if they're doing that properly either. -- David A. Holland [email protected]
