Support weak alias in shared object

[GoogleCodeExporter]

Shared object can contain weak alias:

[hjl@gnu-32 hash-1]$ cat alias.s
    .data
    .type b, @object
    .global b
    .weak b
b:  .byte 0
    .size b, .-b
    .global __b
    __b=b
[hjl@gnu-32 hash-1]$ 

where b is a weak alias of __b.  Access to b defined in shared
object should access __b since b is the alias of __b.  Both gold
and GNU ld support it.  But mclinker doesn't

[hjl@gnu-32 hash-1]$ cat ref.s
    .text
        .type _start,"function"
        .global _start
_start:
    mov $b,%eax
[hjl@gnu-32 hash-1]$ make
as --32  -o ref.o ref.s
./ld.mcld -march=x86  -filetype=exe -o ref ref.o alias.so
readelf -D -s ref

Symbol table for image:
  Num Buc:    Value  Size   Type   Bind Vis      Ndx Name
    1   0: 08049050     0 NOTYPE  GLOBAL DEFAULT ABS _edata
    3   1: 08049051     0 NOTYPE  GLOBAL DEFAULT ABS _end
    5   2: 08049050     1 OBJECT  GLOBAL DEFAULT   8 b
    4   2: 080481e8     0 FUNC    GLOBAL DEFAULT   6 _start
    2   2: 08049050     0 NOTYPE  GLOBAL DEFAULT ABS __bss_start
[hjl@gnu-32 hash-1]$ 

It generates incorrect executable with copy relocation where
access to __b in shared object isn't redirected to b in executable.
This causes mclinker test failure:

readelf -s -D 
/export/build/google/mclinker/build-x86_64-linux/test/Relocation/X86/Dynamic/Out
put/exec_copy.ll.tmp.exe | FileCheck 
/export/gnu/import/git/google/mclinker/test/Relocation/X86/Dynamic/exec_copy.ll 
-check-prefix=SYM
--
Exit Code: 1
Command Output (stderr):
--
/export/gnu/import/git/google/mclinker/test/Relocation/X86/Dynamic/exec_copy.ll:
16:8: error: expected string not found in input
; SYM: 8 OBJECT GLOBAL DEFAULT {{[0-9]+}} __tzname
       ^
<stdin>:2:1: note: scanning from here
Symbol table for image:
^
<stdin>:5:16: note: possible intended match here
 1 2: 080490ac 8 OBJECT GLOBAL DEFAULT 18 tzname

Original issue reported on code.google.com by hjl.to...@gmail.com on 11 Feb 2013 at 6:27

[GoogleCodeExporter]

Hi, H.J.,

I will support weak alias by treating the alias symbols as indirect symbols.
MCLinker's StaticResolver can resolve indirect symbols. Trent and Diana will 
implement the rest parts.

The test case is really solid. It helps me to explain the behavior of weak 
alias to the other team members.

Big thanks,
Luba

Original comment by LubaTang on 20 Feb 2013 at 10:45

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Hi HJ,

I've added alias support for X86 in MCLinker. You can check rev. 1f697 to see 
it. I've tested and passed both cases you gave.

However, since we perform alias analysis when reading symbols in ELFReader, we 
currently may not accurately gather some overriding information for analysis 
due to the limitation of the MCLinker architecture (e.g. whether the processing 
symbol can override the previous one and become a potential alias).

That affects the alias analysis accuracy. This only affects cases when two 
dynamic objects (.so) have the same alias names.

We decided to refactor the architecture instead of hacking it and making code 
dirty. So, I will fix the issue after Luba refactors the architecture.

Original comment by lo.chenk...@gmail.com on 27 Mar 2013 at 3:50

[GoogleCodeExporter]

I checked a patch to enable x86 weak alias test.  Thanks.

Original comment by hjl.to...@gmail.com on 27 Mar 2013 at 5:18

[GoogleCodeExporter]

Original comment by pete.c...@gmail.com on 5 Sep 2013 at 3:20

• Changed state: Fixed