[PATCH] D41928: [ELF] Fix SysV hash tables with --no-rosegment

Rafael Avila de Espindola via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 10 19:44:56 PST 2018


Shoaib Meenai via Phabricator <reviews at reviews.llvm.org> writes:

> smeenai created this revision.
> smeenai added reviewers: espindola, grimar, ruiu.
> Herald added a subscriber: emaste.
>
> When setting up the chain, we copy over the bucket's previous symbol
> index, assuming that this index will be 0 (STN_UNDEF) for an unused
> bucket (marking the end of the chain). When linking with --no-rosegment,
> however, unused buckets will in fact contain the padding value, and so
> the hash table will end up containing invalid chains. Explicitly
> zero-initialize the buckets to fix this problem. Also explicitly
> zero-initialize the chain entry for STN_UNDEF; I don't think this is
> actually necessary, but it doesn't hurt, and should make the hash table
> identical both with and without --no-rosegment.
>
>
> Repository:
>   rLLD LLVM Linker
>
> https://reviews.llvm.org/D41928
>
> Files:
>   ELF/SyntheticSections.cpp
>   test/ELF/sysv-hash-no-rosegment.s
>
>
> Index: test/ELF/sysv-hash-no-rosegment.s
> ===================================================================
> --- /dev/null
> +++ test/ELF/sysv-hash-no-rosegment.s
> @@ -0,0 +1,13 @@
> +# REQUIRES: x86
> +# RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %s -o %t.o
> +# RUN: ld.lld -shared --no-rosegment -o %t %t.o
> +# RUN: llvm-readobj -hash-table %t | FileCheck %s
> +
> +# CHECK:      HashTable {
> +# CHECK-NEXT:   Num Buckets: 2
> +# CHECK-NEXT:   Num Chains: 2
> +# CHECK-NEXT:   Buckets: [1, 0]
> +# CHECK-NEXT:   Chains: [0, 0]
> +# CHECK-NEXT: }
> +
> +callq undef at PLT
> Index: ELF/SyntheticSections.cpp
> ===================================================================
> --- ELF/SyntheticSections.cpp
> +++ ELF/SyntheticSections.cpp
> @@ -1843,7 +1843,9 @@
>    write32(P++, NumSymbols); // nchain
>  
>    uint32_t *Buckets = P;
> +  memset(Buckets, STN_UNDEF, NumSymbols * 4);

I would just use 0 in here. Otherwise I get the impression that this
writes 4 *NumSymbols 32 values.

LGTM with that.

Thanks,
Rafael


More information about the llvm-commits mailing list