inconsistency in alias to undefined symbol

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

inconsistency in alias to undefined symbol

Alexandre Oliva-2
Is it correct that we reject:

.set x, y
.long x

but we accept:

.set x, y

such that x is not even mentioned in the symbol table, even if it's
declared .global or .weak?

I know this is what the code does, and I understand how it does it,
but the question is on whether the silent acceptance of the latter is
just an oversight, rather than something intentional.

Comments?

--
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}
Reply | Threaded
Open this post in threaded view
|

Re: inconsistency in alias to undefined symbol

Jan Beulich
>>> Alexandre Oliva <[hidden email]> 26.10.05 08:19:29 >>>
>Is it correct that we reject:
>
>.set x, y
>.long x

As of yesterday this should be accepted again (as it used to be up to
2.16.1).

>but we accept:
>
>.set x, y
>
>such that x is not even mentioned in the symbol table, even if it's
>declared .global or .weak?
>
>I know this is what the code does, and I understand how it does it,
>but the question is on whether the silent acceptance of the latter is
>just an oversight, rather than something intentional.

So it's actually the other way around - not accepting the former was a
regression that is now fixed...

Jan
Reply | Threaded
Open this post in threaded view
|

Re: inconsistency in alias to undefined symbol

Alexandre Oliva-2
On Oct 26, 2005, "Jan Beulich" <[hidden email]> wrote:

>>>> Alexandre Oliva <[hidden email]> 26.10.05 08:19:29 >>>
>> Is it correct that we reject:

>> .set x, y
>> .long x

> As of yesterday this should be accepted again (as it used to be up to
> 2.16.1).

Even if x is declared .global, .weak, .hidden, etc?  That doesn't
sound right to me.  I'd expect .set x, whatever to introduce a symbol
x in the symbol table or fail, not simply drop it if the definition
turned out to be an undefined symbol.

--
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}
Reply | Threaded
Open this post in threaded view
|

Re: inconsistency in alias to undefined symbol

Jan Beulich
>>> Alexandre Oliva <[hidden email]> 27.10.05 07:00:53 >>>
>On Oct 26, 2005, "Jan Beulich" <[hidden email]> wrote:
>
>>>>> Alexandre Oliva <[hidden email]> 26.10.05 08:19:29 >>>
>>> Is it correct that we reject:
>
>>> .set x, y
>>> .long x
>
>> As of yesterday this should be accepted again (as it used to be up
to
>> 2.16.1).
>
>Even if x is declared .global, .weak, .hidden, etc?  That doesn't
>sound right to me.  I'd expect .set x, whatever to introduce a symbol
>x in the symbol table or fail, not simply drop it if the definition
>turned out to be an undefined symbol.

Not really. Without ia64's .alias becoming common there's no way to
define an alias of a symbol without also making that alias global. There
was some lengthy discussion about that during the past couple of weeks,
if you want to refer to that (and see a use case of the construct). And
even if ia64's .alias was generalized, removing support for the older
construct should be done only after one or two main releases.

Jan