Re: equating symbols to undefined

["H. J. Lu" <hjl at lucon dot org>]

".set" can be used to define a local symbol from a global symbol to
avoid relocation. The change was made to prevent the gcc bug.

I still like to see what other assemblers do.


H.J.
----
On Fri, Oct 21, 2005 at 05:34:00PM +0200, Jan Beulich wrote:
> 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.