This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: equating symbols to undefined


On Wed, Oct 12, 2005 at 11:15:27AM +0200, Jan Beulich wrote:
> >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)

Then don't use it. You can use

undef		undef	def	accepted by all assemblers (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)

Then don't use it.

> 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,

Just define GLOBAL. Will it do something bad?

> with your patch, leads to an error for all but the defining translation
> unit.

I still don't see how the new assembler will prevent you from doing
things you want to do.


H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]