Re: equating symbols to undefined

["Jan Beulich" <JBeulich at novell dot com>]

>A testcase?

Here it is:

void*copymem(void*, const void*, unsigned long);

#ifdef FORBIDDEN
# define ALIAS
# undef IMPLEMENT
#endif

#ifdef BROKEN
# undef ALIAS
# define IMPLEMENT
# define GLOBAL
#endif

#ifdef ALIAS

void*memcpy(void*, const void*, unsigned long)
__attribute__((__alias__("copymem")));

#else

__asm__(".equiv memcpy, copymem");
# ifdef GLOBAL
__asm__(".global memcpy");
# endif

#endif

struct s {
	int i[100];
};

void test(struct s*ps, const struct s*pcs) {
	*ps = *pcs;
}

#ifdef IMPLEMENT
void*copymem(void*dst, const void*src, unsigned long n) {
	/* ... */
	return dst;
}
#endif

/**** end of C source ****/

This has the following (expected) behavior:

IMPLEMENT	ALIAS	GLOBAL	effect on object file

undef		undef	undef	error from new assembler, accepted
before
				(relocation against copymem, no notion
of
				memcpy)
def		undef	undef	accepted by all assemblers, but
produces
				local (defined) symbol memcpy (which is
				not presently a problem for me, but the
				symbol is useless at least)
undef		def	undef	illegal as per __attribute__((alias()))
				specification (gcc 4.0.2 doc section
5.24)
def		def	undef	accepted by all assemblers, but
produces
				global (defined) symbol memcpy (which
				definitely is a problem) and relocation
				against it
undef		undef	def	accepted by all assemblers (relocation
				against copymem, no notion of memcpy)
def		undef	def	accepted by all assemblers, but
produces
				global (defined) symbol memcpy (which
				definitely is a problem) and relocation
				against it
undef		def	def	illegal as per __attribute__((alias()))
				specification (gcc 4.0.2 doc section
5.24)
def		def	def	accepted by all assemblers, but
produces
				global (defined) symbol memcpy (which
				definitely is a problem) and relocation
				against it

As you can see, with

- GLOBAL defined, the problem is with the compilation unit defining the
(actual) symbol, because this leads to memcpy also being defined
globally (not that using weak here doesn't help, because for other
symbols it might be desirable [necessary for me] to not have a
definition of the symbol at all, nor can one make guarantees that the
symbol to be used elsewhere isn't also weak)
- ALIAS defined the construct is invalid in all but the defining
translation unit (which is what you try to diagnose in the assembler,
but which should really be diagnosed by the compiler as this is who
makes the assertion about legality)

leaving only the case where both GLOBAL and ALIAS are undefined, which,
with your patch, leads to an error for all but the defining translation
unit.

Jan