[cooker] Re: Why ICF and GC-sections are enabled ?
Worth to mention is that -ffunction-sections -fdata-sections were good in times where LTO was not available. wt., 24 wrz 2019, 23:49 użytkownik Tomasz Gajc napisał: > Hi, > > our linkers (ld.bfd, ld.lld) by default uses ICF and gc-sections > > > https://github.com/OpenMandrivaAssociation/llvm/blob/3e06cf7671e8abed54b1f48c9689810d3cbf59f3/lld-default-settings.patch#L32 > > > https://github.com/OpenMandrivaAssociation/llvm/blob/3e06cf7671e8abed54b1f48c9689810d3cbf59f3/lld-default-settings.patch#L61 > > 1. gc-sections > This works only when -ffunction-sections is passed during compilation, and > its GCC specific. > Makes no sense to enable LD --gc-sections when our default %optflags does > not emit -ffunction-sections -fdata-sections > > 2. ICF > Same as above, without -ffunction-sections -fdata-sections in optflags it > make no sense > > 3. Unsafe ? > We are the only ones who enabled ICF and gc-section in gold and LLD. I > really wonder if these uncommon options gives any advantage these days. > > WDYT ? >
[cooker] Why ICF and GC-sections are enabled ?
Hi, our linkers (ld.bfd, ld.lld) by default uses ICF and gc-sections https://github.com/OpenMandrivaAssociation/llvm/blob/3e06cf7671e8abed54b1f48c9689810d3cbf59f3/lld-default-settings.patch#L32 https://github.com/OpenMandrivaAssociation/llvm/blob/3e06cf7671e8abed54b1f48c9689810d3cbf59f3/lld-default-settings.patch#L61 1. gc-sections This works only when -ffunction-sections is passed during compilation, and its GCC specific. Makes no sense to enable LD --gc-sections when our default %optflags does not emit -ffunction-sections -fdata-sections 2. ICF Same as above, without -ffunction-sections -fdata-sections in optflags it make no sense 3. Unsafe ? We are the only ones who enabled ICF and gc-section in gold and LLD. I really wonder if these uncommon options gives any advantage these days. WDYT ?
Re: [cooker] RPM why not use internal beecrypt ?
On Tue, Sep 24, 2019 at 5:27 PM Tomasz Gajc wrote: > > Hi, > > why our RPM uses external crypto engine which is set to OpenSSL ? > Isn't this a overkill ? > https://github.com/OpenMandrivaAssociation/rpm/blob/e8e8006f608eee038c4acb7484943f50e439/rpm.spec#L555 > > I'd like to suggest ti use RPM's internal beecrypt as a crypto engine. WDYT ? No. BeeCrypt is completely unmaintained these days. And RPM does not bundle beecrypt either. You still need to ship the library. We use OpenSSL because it's currently the fastest and best maintained crypto backend. I explicitly picked it because of that. In the future, we may switch to the newer gcrypt backend, but for now, we're using OpenSSL. NSS is a ridiculous pain to deal with these days with constant ABI/API breaks, so it's not a reasonable option for RPM. -- 真実はいつも一つ！/ Always, there's only one truth! -- Cooker mailing-list https://www.openmandriva.org/lists
[cooker] RPM why not use internal beecrypt ?
Hi, why our RPM uses external crypto engine which is set to OpenSSL ? Isn't this a overkill ? https://github.com/OpenMandrivaAssociation/rpm/blob/e8e8006f608eee038c4acb7484943f50e439/rpm.spec#L555 I'd like to suggest ti use RPM's internal beecrypt as a crypto engine. WDYT ?
Re: [cooker] Hello, just a test
Hello esteemed colleagues, Testing Reply. On 9/24/19 8:25 AM, Raphaël Jadot wrote: Cheers, -- Raphaël J. -- Cooker mailing-list https://www.openmandriva.org/lists -- Ben Bullard ben79 OpenMandriva-QA Team -- Cooker mailing-list https://www.openmandriva.org/lists
[cooker] Hello, just a test
Cheers,, -- Raphaël J. -- Cooker mailing-list https://www.openmandriva.org/lists
[cooker] Hello, just a test
Cheers, -- Raphaël J. -- Cooker mailing-list https://www.openmandriva.org/lists
Re: [cooker] Use Thin LTO
Any news on this? Have you discussed that idea? czw., 22 sie 2019, 02:12 użytkownik Colin Close napisał: > Hi Tomek, > > This looks quite interesting as although ThinLto reults in some slower > executables this slight disadvantage is balanced out by significant > improvements in build time and memory consumption. With the prospect of > further optimisation in later releases it could be worthwhile choice > assuming there are no unseen gotcha's. > > Best, > > Colin > > > > On Tuesday, 20 August 2019 14:46:07 BST Tomasz Gajc wrote: > > > Hi, > > > > > > what do you think to start to use by default -flto=thin ? > > > We may benefit from using thiner LTO objects. > > > > > > More info can be found here: > > > https://clang.llvm.org/docs/ThinLTO.html > > > http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html > > > > > > > >
[cooker] Kernel compiled with LLVM/clang
Hi, I've spent some time to get our kernel compiled with LLVM/clang-9.0.0 It's not tested at all. Feel free to try it. Some observations: -O3 in clang works differently so it catches some error when compiling APPLESMC module, so I've disabled it. objtool makefile needed a patch to skip user CFLAGS redefinition. Saa716x patch needs to be disabled as it generated some warnings which was quite suspicious. VirtualBox module for disabled because using some GCC specific pragmas. Iirc FreeBSD got some patches to build Vbox with clang. I had to use LLVM tools like ar, objcopy, nm etc. LLD generates lots of warnings due to enabled ICF and gc-secrions together. https://abf.openmandriva.org/build_lists/610456
