This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] change the condition preventing symbol replacement in snapshot_symbol()
On Sun, Jul 26, 2009 at 11:58 PM, Jan Beulich<JBeulich@novell.com> wrote:
>>>> "H.J. Lu" <hjl.tools@gmail.com> 24.07.09 18:02 >>>
>>On Fri, Jul 24, 2009 at 8:59 AM, Jan Beulich<JBeulich@novell.com> wrote:
>>>>>> "H.J. Lu" <hjl.tools@gmail.com> 24.07.09 17:45 >>>
>>>>>>I think it may be wrong. We can have
>>>>>>
>>>>>>.globl foo
>>>>>>bar = foo
>>>>>>
>>>>>>where foo is defined/global and bar is local. Will you replace foo with
>>>>>>bar?
>>>>>
>>>>> No, only the other way around: bar (non-global) can be replaced by foo.
>>>>>
>>>>
>>>>That is what I meant and it is wrong. You can't replace a local symbol with
>>>>a global one.
>>>
>>> Why? A non-global equate just serves as an alias. And remember, the
>>> change fixes a problem (you just didn't cover all of the possible cases with
>>> your ltoff22x tests) - how would you suggest addressing that otherwise?
>>
>>Global symbol may be overridden by another definition. You
>>can't change relocation against a local symbol to a global
>>symbol.
>
> The question is whether an equate counts as a local symbol.
It certainly is if source is defined:
[hjl@gnu-6 tmp]$ cat b.s
bar = foo
.globl foo
foo:
nop
jmp bar
[hjl@gnu-6 tmp]$ gcc -c b.s
[hjl@gnu-6 tmp]$ objdump -dr b.o
b.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <foo>:
0: 90 nop
1: eb fd jmp 0 <foo>
[hjl@gnu-6 tmp]$
>>> Also, the logic in resolve_symbol_values() does just that - replace
>>> relocations using non-global (and erroneously as I think also global ones
>>> at present) equates by their global underlying symbols.
>>>
>>
>>A testcase?
>
> Was part of the patch submitted - I just added variants of on of your
> ltoff22x tests, one of which now produces consistent output with the
> patch in question here, while the other was submitted as an xfail one due
> to this remaining issue.
>
> I'd really hope that Alan and or Nick could jump in here clarifying expected
> behavior.
>
Do you have a testcase for x86?
Thanks.
--
H.J.