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


>>> "H. J. Lu" <hjl@lucon.org> 12.10.05 16:26:06 >>>
>> 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

I have to use a set with identical ALIAS/GLOBAL values where both
IMPLEMENT defined and undefined work.

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

Yes, as described. It'll result in a globally visible definition for
memcpy in the file that implements the real function where none should
appear, which will then conflict with the definition of memcpy provided
elsewhere for all normal code (or provide one where none should exist)
.

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

I want to be able to have a header file that defines an alias memcpy
should resolve to (because there is no way I could tell gcc to not call
memcpy when copying large compound objects), which can be included by
both consumers and producer of the replacement definition, without the
producer (because of inclusion of the header file) providing a global
definition for memcpy.

Similarly, I want to be able to a header file that defines an alias,
say, __divdi3 should resolve to (because there is no way I could tell
gcc to not call __divdi3 when dividing 64-bit integers on a 32-bit
target), which can be included by both consumers and producer of the
replacement definition, without the producer (because of inclusion of
the header file) providing a global definition for __divdi3 (because the
policy in the rest of the component - linux kernel - is to not have such
a function available).

Jan


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