Re: [PATCH] change the condition preventing symbol replacement in snapshot_symbol()

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.