[LLVMdev] [lld] ELF weak aliases
Michael Spencer
bigcheesegs at gmail.com
Wed Jan 9 04:34:34 PST 2013
On Tue, Jan 8, 2013 at 6:01 PM, Nick Kledzik <kledzik at apple.com> wrote:
> How are you modeling weak aliases in Atoms?
>
> mach-o does not support weak aliases. My mental model of a weak alias is:
>
> If foo is a weak alias for bar, then if nothing else defines bar, use foo in place of bar.
>
> -Nick
ELF doesn't have any specific concept of aliases. The compiler just
assigns multiple symbols to the same address. The reader just creates
a mergeAsWeak atom with the last symbol in the symbol table at that
address getting the content.
- Michael Spencer
>
>
> On Jan 8, 2013, at 4:50 PM, Michael Spencer wrote:
>> So I just got lua to link and run and work on x86-64 Linux with musl
>> and lld. It did require one change to hack around incorrect handling
>> of ELF weak aliases.
>>
>> In musl __stdio_exit.c
>> <http://git.musl-libc.org/cgit/musl/tree/src/stdio/__stdio_exit.c> we
>> have:
>>
>> static FILE *const dummy_file = 0;
>> weak_alias(dummy_file, __stdin_used);
>> weak_alias(dummy_file, __stdout_used);
>> weak_alias(dummy_file, __stderr_used);
>>
>> weak_alias(old, new) is defined as: extern __typeof(old) new
>> __attribute__((weak, alias(#old)))
>>
>> This generates the following object file:
>> mspencer at mspencer-vm:~/Projects/test$ objdump -st
>> ../musl/src/stdio/__stdio_exit.o
>>
>> ../musl/src/stdio/__stdio_exit.o: file format elf64-x86-64
>>
>> SYMBOL TABLE:
>> 0000000000000000 l df *ABS* 0000000000000000 src/stdio/__stdio_exit.c
>> 0000000000000044 l F .text 0000000000000049 close_file
>> 0000000000000000 l O .rodata 0000000000000008 dummy_file
>> 0000000000000000 l d .text 0000000000000000 .text
>> 0000000000000000 l d .data 0000000000000000 .data
>> 0000000000000000 l d .bss 0000000000000000 .bss
>> 0000000000000000 l d .rodata 0000000000000000 .rodata
>> 0000000000000000 l d .note.GNU-stack 0000000000000000 .note.GNU-stack
>> 0000000000000000 w O .rodata 0000000000000008 __stderr_used
>> 0000000000000000 w O .rodata 0000000000000008 __stdin_used
>> 0000000000000000 g F .text 0000000000000044 __stdio_exit
>> 0000000000000000 w O .rodata 0000000000000008 __stdout_used
>> 0000000000000000 *UND* 0000000000000000 __libc
>> 0000000000000000 *UND* 0000000000000000 __lock
>> 0000000000000000 *UND* 0000000000000000 __lockfile
>>
>> Contents of section .text:
>> 0000 53833d00 00000000 740abf00 000000e8 S.=.....t.......
>> 0010 00000000 488b1d00 000000eb 0c4889df ....H........H..
>> 0020 e81f0000 00488b5b 704885db 75ef488b .....H.[pH..u.H.
>> 0030 3d000000 00e80a00 0000488b 3d000000 =.........H.=...
>> 0040 005beb00 534889fb 4885db74 3e83bb8c .[..SH..H..t>...
>> 0050 00000000 78084889 dfe80000 0000488b ....x.H.......H.
>> 0060 4328483b 4338760a 4889df31 f631d2ff C(H;C8v.H..1.1..
>> 0070 5348488b 7308482b 7310730f 488b4350 SHH.s.H+s.s.H.CP
>> 0080 4889dfba 01000000 5bffe05b c3 H.......[..[.
>> Contents of section .rodata:
>> 0000 00000000 00000000
>>
>> Note that __stdout_used is the last symbol in the .rodata section.
>> This means that the reader assigns the data (16 bytes of 0) to
>> __stdout_used. Because dummy_file and the other __stdx_used symbols
>> come before it, they end up in the right place in the final file.
>>
>> This works great until another object file provides a definition of
>> __stdout_used. The weak definition of it gets totally removed, meaning
>> so does the content for the other __stdx_used symbols.
>>
>> I fixed this by adding weak_alias(dummy_file,
>> __zinurfilestealinurdata); to __stdio_exit.c which allocated the 16
>> bytes to __zinurfilestealinurdata.
>>
>> Another way to fix this it to, in the reader, assign all the data to
>> the non-weak symbol (dummy_file in this case) when multiple symbols
>> share the same location. However, this fails to work if you have a
>> weak symbol pointing in to the middle of a non weak symbol's data. In
>> this case we actually need to move the data over to the non-weak
>> symbol (or create an anonymous local symbol to hold the data).
>> However, this only needs to happen in specific cases.
>>
>> - Michael Spencer
>
More information about the llvm-dev
mailing list