bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gold/20114] Partial relro support for s390x gold


From: krebbel at linux dot ibm.com
Subject: [Bug gold/20114] Partial relro support for s390x gold
Date: Tue, 30 Apr 2019 07:13:55 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=20114

--- Comment #9 from Andreas Krebbel <krebbel at linux dot ibm.com> ---
(In reply to maamountki from comment #7)
> Thinking of replacing the new layout with this one
> 
>       +----------------------------------+
>       |.got[0]: DYNAMIC                  |   <--- _GLOBAL_OFFSET_TABLE_ .got
>       +----------------------------------+
>       |                                  |   <--- non-plt GOT entries
>       |                                  |
>       |                                  |
>       +----------------------------------+
>       |.got.plt[0]: link_map parm        |   <--- DT_PLTGOT .gotplt
>       |.got.plt[1]: &_dl_runtime_resolve |
>       |                                  |
>       |                                  |
>       +----------------------------------+
>       |                                  |   <--- PLT GOT entries
>       |                                  |
>       |                                  |
>       |                                  |
>       +----------------------------------+
> 
> However ld and gold layouts will not be on the same track and the code will
> not be as simple as the current patch, What do you think?

Would this really solve the linker script problem?

I also considered this variant but it is some disadvantages:

- Our PLT first entry accesses the link_map parm and the dl_runtime_resolve
entries via _GLOBAL_OFFSET_TABLE_. Fixing this probably would require adding
another symbol to replace _GLOBAL_OFFSET_TABLE_ which can be used in the
initial PLT entry.

- prelink currently adjusts DT_PLTGOT[0]. The value then will be read by ld.so
via _GLOBAL_OFFSET_TABLE_[0]. Having DT_PLTGOT != _GLOBAL_OFFSET_TABLE_ would
require to have two copies of that value and keep them in sync somehow and/or
change prelink. However, I'm not sure prelink is still a concern anymore?!

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]