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


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

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

Jan


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