equating symbols to undefined

[H. J. Lu]

On Tue, Oct 11, 2005 at 05:21:42PM +0200, Jan Beulich wrote:
> >>> "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.
> 

A testcase?


H.J.