This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: equating symbols to undefined
>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