[llvm-bugs] [Bug 45746] LLD sometimes nondeterministically swaps _end and _edata in the string table

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=45746

Fangrui Song <i at maskray.me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #5 from Fangrui Song <i at maskray.me> ---
See https://reviews.llvm.org/D79222

I am not sure we want to make this change. I believe lld's current behavior is
consistent with GNU ld and gold.

```
% clang -fuse-ld=bfd a.c -lX11 -o a && readelf -W --dyn-syms a
...
     3: 0000000000404028     0 NOTYPE  GLOBAL DEFAULT   21 _edata
     4: 0000000000404030     0 NOTYPE  GLOBAL DEFAULT   22 _end
```

GNU ld's internal linker script includes:

`  _edata = .; PROVIDE (edata = .);`

So `_edata` is always available (in .symtab). It will end up in .dynsym if it
can preempt `_edata` in a shared object (libX11.so.6) or is exported via other
mechanisms.

lld's current behavior matches GNU ld w.r.t. .dynsym, but the .symtab entry is
optional.

It may be useful to understand why libX11.so.6 exports `_edata` and `_end`.
References within `libX11.so.6` will get bound to `_edata` and `_end` defined
in the main executable (preempted), which may be non-intuitive to many users.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200615/bf05a7bc/attachment.html>