similar to: [lld] Treat .openbsd.randomdata as read-only

LGTM On Mon, Dec 19, 2016 at 1:48 PM, Mark Kettenis via llvm-dev < llvm-dev at lists.llvm.org> wrote: > It is the intention that .openbsd.randomdata sections are made > read-only after initialization. The native (ld.bfd based) OpenBSD > toolchain accomplishes this by including .openbsd.randomdata into the > PT_GNU_RELRO segment. The diff below makes ldd do the same. > >

On Tue, Mar 14, 2017 at 12:07 PM, Mark Kettenis <mark.kettenis at xs4all.nl> wrote: > > Date: Tue, 14 Mar 2017 11:39:22 -0700 > > From: Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> > > > > Hi all, > > > > LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for production > > use at least for x86-64 (and probably for AArch64 and

>> From: Rui Ueyama <ruiu at google.com> >> Date: Mon, 19 Dec 2016 20:08:59 -0600 >> >> LGTM > >Great. I don't have commit access, so it would be great if you could >commit this change for me. > >Just realized that that I should have sent this to llvm-commits >instead. Apologies for that. > >I have some further fixes. Is Phabricator

We are proud to a announce another alpha release of Samba 4, alpha 14, codenamed "randomdata". What's new in Samba 4 alpha14 ============================= Samba 4 is the ambitious next version of the Samba suite that is being developed in parallel to the stable 3.x series. The main emphasis in this branch is support for the Active Directory logon protocols used by Windows 2000 and

Hi, This is a proposal to add an option to lld that forces .dynamic sections to be read-only. The .dynamic section is almost read-only except for the DT_DEBUG entry which requires the dynamic linker to modify a word. MIPS has long since had a solution to this using the DT_MIPS_RLD_MAP entry to give a pointer to another section which is writable. It would be nice to have this functionality on

On OpenBSD we still use the "classic" SunOS 4 shared library versioning scheme where the major and minor number are part of the library name (and recorded in DT_NEEDED entries). For example the shared libc on the OpenBSD-current is named libc.so.89.2. With this scheme, linker has to pick the pick the library with the highest major and minor (within the highest major version); the

Your understanding is correct. It saves a small number of physical pages. It's strictly better even if it's only a little bit better. On Tue, May 16, 2017, 5:14 PM Rui Ueyama <ruiu at google.com> wrote: > Hi Jake, > > Thank you for sending this to llvm-dev! > > If I understand correctly, your motivation to add an option to make > .dynamic sections read-only is to

Hi Mark, If we have to do this, or LLD doesn't work on OpenBSD, I think we need to do this. But can I ask one question? I wonder why OpenBSD systems don't have symbolic links unlike the other Unix-like systems in the first place. On Mon, Dec 19, 2016 at 2:27 PM, Mark Kettenis via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On OpenBSD we still use the "classic"

The motivation is not only memory savings but also security: can-never-be-written is strictly better than RELRO in all cases. The biggest win is when .dynamic is the sole reason for having a writable segment at all. The distinction is fairly small for exploitability, but not negligible. LLD already has several command-line options that are not supported by or are different from ld or gold, so

Hi all, LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for production use at least for x86-64 (and probably for AArch64 and MIPS). I believe you've heard a few good news about the linker -- it just works <http://lld.llvm.org/#features> and is very fast <http://lld.llvm.org/#performance>, clean, compact and supported by the active community. I don't think I need to

On Fri, Aug 30, 2019 at 4:54 AM Fāng-ruì Sòng <maskray at google.com> wrote: > > > Old: R RX RW(RELRO) RW > > > New: R(R+RELRO) RX RW; R includes the traditional R part and the > > > RELRO part > > > Runtime (before relocation resolving): RW RX RW > > > Runtime (after relocation resolving): R RX RW > > > > > I actually see two

Hi Shankar, I almost implement ELFRelocationReader but still not completely sure that this is a right direction. Suppose somebody wants to override creation of the `ELFReference` object from the `Elf_Rela` or `Elf_Rel` record. Let's consider two implementations A and B: A: ===== 1. Factor out `ELFReference` creation from `createDefinedAtomAndAssignRelocations` into a couple of virtual

On 26 July 2018 at 18:05, Ed Maste <emaste at freebsd.org> wrote: > On 26 July 2018 at 11:08, Peter Smith <peter.smith at linaro.org> wrote: >> On 26 July 2018 at 15:52, Ed Maste <emaste at freebsd.org> wrote: >>> On 27 February 2018 at 09:06, Ed Maste <emaste at freebsd.org> wrote: >>>> >>>> A number of companies are shipping

Hi, Thanks for the explanation. If I understand you properly you suggest to move relocation parsing to the class with the following interface. Right? Who will be user of this class? If it is still only ELFFile class, what benefits will we get from separation of this logic? template <class ELFT> class ELFRelocationReader { public: ELFRelocationReader(.....); // Returns all created

Hi Shankar, On Tue, Feb 12, 2013 at 10:46 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Author: shankare > Date: Tue Feb 12 12:46:53 2013 > New Revision: 174990 > > URL: http://llvm.org/viewvc/llvm-project?rev=174990&view=rev [...] > ELFDefinedAtom<ELFT> *createDefinedAtomAndAssignRelocations( > StringRef symbolName, StringRef

Hi, There are more than one MIPS relocations which need GOT entry creation. Let's consider two of them R_MIPS_GOT16 and R_MIPS_CALL16 [1]. R_MIPS_GOT16 is applicable to local and external symbols and performs a different calculation in each cases [2]. R_MIPS_CALL16 is applicable to external symbols only and a linker should show an error if it finds R_MIPS_CALL16 with a local target. Now LLD

Rafael, here is a repro.tar to look at: https://reviews.llvm.org/F3100177 The attached foo.diff adds a print which shows the issue. ``` NAME: sleep SYMINDEX: 2 NAME: sched_yield SYMINDEX: 1 NAME: __libc_start_main SYMINDEX: 0 ``` `readelf --relocs` Shows that we create : ... 000000255110 002900000007 R_X86_64_JUMP_SLO 0000000000254410 __xstat at GLIBC_2.2.5 + 0 000000255118 001e00000007

On Thu, Aug 29, 2019 at 3:10 AM Fāng-ruì Sòng <maskray at google.com> wrote: > Hello Vic, > > To make sure I understand the proposal correctly, do you propose: > > Old: R RX RW(RELRO) RW > New: R(R+RELRO) RX RW; R includes the traditional R part and the > RELRO part > Runtime (before relocation resolving): RW RX RW > Runtime (after relocation resolving): R RX

I've recently implemented profile guided section layout in llvm + lld using the Call-Chain Clustering (C³) heuristic from https://research.fb.com/wp-content/uploads/2017/01/cgo2017-hfsort-final1.pdf . In the programs I've tested it on I've gotten from 0% to 5% performance improvement over standard PGO with zero cases of slowdowns and up to 15% reduction in ITLB misses. There are

I've been working on supporting ARM/Thumb interworking thunks in LLD and have encountered a limitation that I think it is worth bringing up in a wider context. This is all LLD specific, apologies if I've abused llvm-dev here. TL;DR summary: - Thunks in lld may not work if they are added to InputSections that have already been scanned. - There is a short term fix, but in the longer term I