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> 11.10.05 17:07:53 >>>
>On Tue, Oct 11, 2005 at 04:57:34PM +0200, Jan Beulich wrote:
>> H.J.,
>> 
>> what is the purpose of disallowing equates of non-globals to
undefined
>> symbols? The example you give in bug 857 doesn't seem to point out
an
>> assembler problem, but rather a compiler one. Given that there is
no
>> generic way to create aliases of symbols (ia64 has the .alias
directive
>> for this), this is the only alternative. From the assembler's
>> perspective I see nothing wrong with the 'bad' case of the example.
>> 
>> Specifically, I use this to force compiler generated function calls
>> (i.e. memcpy) to go to certain replacement functions (necessary in
>> specialized environments). Having to additionally specify .global
for
>> the alias seems not only superfluous, but (at least to me) wrong,
since
>> now one must differentiate between the file implementing the
function
>> and files using it (meaning that a common header file implementation
is 
>> no longer possible). This is because in the implementing file using
>> .global on the alias makes it appear as global defined symbol in
the
>> symbol table, which for the given example is wrong (there is a
>> general-purpose memcpy available, it's use is just to be avoided in
the
>> specific files).
>> 
>> Unless you can point out a way to obtain previous behavior by other
>> means I'd like to request to undo this part of the patch (and
instead
>> fix the compiler to fulfill the guarantees made for users of that
>> __attribute__).
>
>Local symbols must be defined. Do you have an example for an
undefined
>local symbol?

This probably depends on the perspective - I don't consider local an
equate of an external symbol. It's just another name. Just consider the
example described; I could extend that if necessary.

>FYI, I proposed to add .alias to the generic assembler. But people
>didn't feel it was useful. It is trivial to move .alias to ia64 to
>generic.

Sure, so would I think.

But that wouldn't help me because (a) there are already releases with
the (considered) broken binutils out there and (b) I have no way, in C
source code, to tell what assembler version is in use (i.e. to adapt
existing code to gas behavior).

Jan


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