equating symbols to undefined

[Jan Beulich]

I don't get it... Where is the problem with restoring the old behavior?
And additionally, why would you think allowing a local .set to a global
defined symbol is any more useful/useless than doing so with an
undefined global? Jan

>>> "H. J. Lu" <hjl@lucon.org> 21.10.05 16:53:23 >>>
On Fri, Oct 21, 2005 at 08:52:37AM +0200, Jan Beulich wrote:
> >> alias.c has to include alias.h according to good programming
> practice,
> >> and suppressing the __asm__-s (which indeed aren't necessary for
> >> alias.c, but also [should] do no harm) would only clutter the
> header
> >> file. Besides this or anything else, this problem is what I'd
call
> a
> >> classical regression (because it obviously worked and there was
no
> >> notion anywhere that this should not work).
> >
> >I don't think the __asm__ statement belongs to alias.c. It
shouldn't
> be
> >there to begin with. The old behavior silently makes a local symbol
> >global. I don't think it is a good idea. Can someone check out
other
> >assemblers to see what they do?
> 
> This is not true, the alias symbol remained to be local in the
defining
> file with the old behavior. And the alias symbol didn't even appear
in
> the symbol table for the consuming file(s).

We can agree to disagree. What do Solaris/HPUX/IRIX/AIX assemblers do
for this case if they support ".set/.equiv/="?

> 
> >> And yes, as agreed to before, .alias would be a lot better suited
> for
> >> this purpose, but we don't have it (yet).
> >
> >I can dig out my old patch and make it generic.
> 
> Which would be useful for the future, but not for code that is
expected
> to be buildable not only with the very latest binutils version (i.e.
the
> linux kernel, which in the given case is where I ran into the
problem).

It just needs to add 2 lines to your alias.h and one line to your
alias.c if you have to include alias.h in alias.c. That will work
will ALL assemblers.


H.J.