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. > >

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. Index: ELF/Writer.cpp =================================================================== --- ELF/Writer.cpp (revision 290066) +++

>Not quite sure what you mean by "on linker side" - but I guess you mean using linker features like comdats etc, rather than DWARF parsing/reassembly/etc. I mean that it probably not a good idea for external library. I feel it is much more convinent to do such proccessing in a linker. Linker do and knows much more about things like sections that are ICFed, eliminated, about COMDATs

Just in case, a little update for this thread: There was a talk about "Protecting the code: Control Flow Enforcement Technology" during the recent llvm-dev meeting (https://llvm.org/devmtg/2018-04/talks.html#Talk_17). It was mentioned that some support is already implemented in LLVM. I did not have chance to look close on it though. Whole feature requires linker side support,

On 26 May 2015, at 20:13, Rui Ueyama <ruiu at google.com> wrote: > > I sent a patch to llvm-commits. You can see the code at http://reviews.llvm.org/D10036. Thanks! Why does the link not actually go where the text of it would imply, and instead bounce via some random (malicious?) third party? Do you have some malware infecting your mail client? David

On Sat, Dec 16, 2017 at 11:40 AM George Rimar <grimar at accesssoftek.com> wrote: > Or following workflow: > > Split dwarf is used to make linker to proccess less, like relocations, > right ? > Partly, though the main motivation as far as I know, was to have to provide fewer bytes to the linker at all. That's why something like Apple's scheme (leave the debug info in

> On Dec 13, 2016, at 11:51 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 11:37 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Dec 13, 2016, at 11:30 AM, Rui Ueyama <ruiu at google.com <mailto:ruiu at google.com>> wrote: >> >> On Tue, Dec 13, 2016 at 11:23 AM, Mehdi

On Tue, Dec 13, 2016 at 12:01 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 13, 2016, at 11:51 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 11:37 AM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> >> On Dec 13, 2016, at 11:30 AM, Rui Ueyama <ruiu at google.com> wrote: >> >> On Tue, Dec

----- Original Message ----- > From: "Sean Silva via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Rui Ueyama" <ruiu at google.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, December 13, 2016 9:59:37 PM > Subject: Re: [llvm-dev] LLD status update and performance chart > On Tue, Dec 13, 2016 at 12:08 PM, Rui

On Tue, Dec 13, 2016 at 9:15 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > ------------------------------ > > *From: *"Sean Silva via llvm-dev" <llvm-dev at lists.llvm.org> > *To: *"Rui Ueyama" <ruiu at google.com> > *Cc: *"llvm-dev" <llvm-dev at lists.llvm.org> > *Sent: *Tuesday, December 13, 2016 9:59:37 PM >

On Tue, Dec 13, 2016 at 12:08 PM, Rui Ueyama <ruiu at google.com> wrote: > On Tue, Dec 13, 2016 at 12:01 PM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> >> On Dec 13, 2016, at 11:51 AM, Rui Ueyama <ruiu at google.com> wrote: >> >> On Tue, Dec 13, 2016 at 11:37 AM, Mehdi Amini <mehdi.amini at apple.com> >> wrote: >>

I've run a new scan of LLD's architecture and it appears to be getting cleaner! There are still some upward dependencies however: - core depends on Reader and Writer - passes depend on Reader and Writer - ReaderWriter/PECOFF/ReaderCOFF.cpp depends on Driver.h The updated architecture can be seen here: http://www.c2lang.org/docs/lld_architecture_20140710.png On Tue, Jun 3, 2014 at 3:07

On Tue, Jan 24, 2017 at 11:29 AM, Rui Ueyama <ruiu at google.com> wrote: > Well, maybe, we should just change the Linux kernel instead of tweaking > our tokenizer too hard. > This is silly. Writing a simple and maintainable lexer is not hard (look e.g. at https://reviews.llvm.org/D10817). There are some complicated context-sensitive cases in linker scripts that break our approach

> On Dec 13, 2016, at 11:30 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 11:23 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Dec 13, 2016, at 11:08 AM, Rui Ueyama <ruiu at google.com <mailto:ruiu at google.com>> wrote: >> >> On Tue, Dec 13, 2016 at 11:02 AM, Mehdi

Slowdown by "[ELF] - Early continue in InputSectionBase<ELFT>::relocate(). NFC.?" looks wierd for me. I do not see any reasons for any impact on perfomance by this change. Good news is that since it was NFC it can easily be reverted. But I think slowdown in results is unrelative with that change and reverting will not give us 2-3% boost back. Best regards, George.

We are modeling target specific functionally using references, Doesn't your idea defeat the purpose of the atom model? Atoms are mostly target neutral and yaml/native format represents just an atom. Having a derived class for atoms will have a impact on the testing method with lld IMO. We could continue to model using references in my opinion and add some meta data information in the atom

On Tue, Dec 13, 2016 at 11:37 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 13, 2016, at 11:30 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 11:23 AM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> >> On Dec 13, 2016, at 11:08 AM, Rui Ueyama <ruiu at google.com> wrote: >> >> On Tue, Dec

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

On Mon, Oct 6, 2014 at 5:00 PM, Nick Kledzik <kledzik at apple.com> wrote: > On Oct 6, 2014, at 3:44 PM, Rui Ueyama <ruiu at google.com> wrote: > > Looks like most people in this thread support using LLVM style in LLD. I > also had an offline discussion and many people wanted to have one coding > style in all LLVM projects. So I'm convinced that we should do that.

Not all input files have to be able to represented in YAML/Native format. There are many unrealistic use cases there. No one wants to write an executable file in Native because there's no operating system that can run that file. So is YAML. So is the combination of .so file and Native/YAML unless we have an operating system whose loader is able to loads a YAML .so file. We might want to write