Re: Basesystem programs redefine routine symbols from libc

[David Holland <dholland-tech%netbsd.org@localhost>]

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
dholland%netbsd.org@localhost