[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200611221925.GA31090@pi3.com.pl>
Date: Fri, 12 Jun 2020 00:19:25 +0200
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Subject: Re: RE: ISRA optimized functions
Hi,
On Thu, Jun 11, 2020 at 11:33:45PM +0200, Mikhail Morfikov wrote:
> On 11/06/2020 23:14, Mikhail Morfikov wrote:
> > On 11/06/2020 22:34, Adam Zabrocki wrote:
> >>
> >> Sure, however, from the logs below it looks like you've compiled Linux kernel
> >> using -O2 flag.
> >>
> >
> > Yes, but in both cases this flag was used, and in the case of gcc9 it looks like
> > it doesn't matter (because LKRG works well), and in the case of gcc10 it does
> > (since it has the problem with the function). So the question here is why? All I
> > did was using update-alternatives to configure the gcc/g++/cpp links, and nothing
> > else have changed in my system. So why does it work with the kernel built with
> > gcc9 and it doesn't work with kernel built with gcc10?
> >
This is question for GCC developers not for LKRG.
>
> I just checked, and the flags aren't used in the kernel build process:
>
> $ make ARCH="x86_64" -j3 bindeb-pkg
> sh ./scripts/package/mkdebian
> dpkg-buildpackage -r"fakeroot -u" -a$(cat debian/arch) -b -nc -uc
> dpkg-buildpackage: info: source package linux-5.7.2-amd64
> dpkg-buildpackage: info: source version 5.7.2-amd64-8
> dpkg-buildpackage: info: source distribution sid
> dpkg-buildpackage: info: source changed by Mikhail Morfikov <mmorfikov@...il.com>
> dpkg-buildpackage: info: host architecture amd64
> dpkg-source --before-build .
> debian/rules build
> dpkg-buildflags --status
> dpkg-buildflags: status: environment variable DEB_BUILD_OPTIONS=parallel=4
> dpkg-buildflags: status: environment variable DEB_HOST_ARCH=amd64
> dpkg-buildflags: status: vendor is Debian
> dpkg-buildflags: status: future features: lfs=no
> dpkg-buildflags: status: hardening features: bindnow=no format=yes fortify=yes pie=yes relro=yes stackprotector=yes stackprotectorstrong=yes
> dpkg-buildflags: status: qa features: bug=no canary=no
> dpkg-buildflags: status: reproducible features: fixdebugpath=yes fixfilepath=no timeless=yes
> dpkg-buildflags: status: sanitize features: address=no leak=no thread=no undefined=no
> dpkg-buildflags: status: CFLAGS [user]: -g -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong -Wformat -Werror=format-security
> dpkg-buildflags: status: CPPFLAGS [vendor]: -Wdate-time -D_FORTIFY_SOURCE=2
> dpkg-buildflags: status: CXXFLAGS [user]: -g -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong -Wformat -Werror=format-security
> dpkg-buildflags: status: FCFLAGS [user]: -g -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong
> dpkg-buildflags: status: FFLAGS [user]: -g -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong
> dpkg-buildflags: status: GCJFLAGS [user]: -g -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong
> dpkg-buildflags: status: LDFLAGS [vendor]: -Wl,-z,relro
> dpkg-buildflags: status: OBJCFLAGS [user]: -g -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong -Wformat -Werror=format-security
> dpkg-buildflags: status: OBJCXXFLAGS [user]: -g -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong -Wformat -Werror=format-security
> make KERNELRELEASE=5.7.2-amd64 ARCH=x86_64 KBUILD_BUILD_VERSION=8 -f ./Makefile
> DESCEND objtool
> CALL scripts/atomic/check-atomics.sh
> CALL scripts/checksyscalls.sh
> CHK include/generated/compile.h
> UPD include/generated/compile.h
> CC init/version.o
> AR init/built-in.a
> GEN .version
> CHK include/generated/compile.h
> LD vmlinux.o
> MODPOST vmlinux.o
> MODINFO modules.builtin.modinfo
> GEN modules.builtin
> LD .tmp_vmlinux.kallsyms1
> KSYM .tmp_vmlinux.kallsyms1.o
> LD .tmp_vmlinux.kallsyms2
> KSYM .tmp_vmlinux.kallsyms2.o
> LD vmlinux
> SORTTAB vmlinux
> SYSMAP System.map
> MODPOST 0 modules
> CC arch/x86/boot/version.o
> VOFFSET arch/x86/boot/compressed/../voffset.h
> OBJCOPY arch/x86/boot/compressed/vmlinux.bin
> RELOCS arch/x86/boot/compressed/vmlinux.relocs
> CC arch/x86/boot/compressed/kaslr.o
> XZKERN arch/x86/boot/compressed/vmlinux.bin.xz
> CC arch/x86/boot/compressed/misc.o
> MKPIGGY arch/x86/boot/compressed/piggy.S
> AS arch/x86/boot/compressed/piggy.o
> LD arch/x86/boot/compressed/vmlinux
> ZOFFSET arch/x86/boot/zoffset.h
> OBJCOPY arch/x86/boot/vmlinux.bin
> AS arch/x86/boot/header.o
> LD arch/x86/boot/setup.elf
> OBJCOPY arch/x86/boot/setup.bin
> BUILD arch/x86/boot/bzImage
> Setup is 14396 bytes (padded to 14848 bytes).
> System is 10336 kB
> CRC 514b895b
> Kernel: arch/x86/boot/bzImage is ready (#9)
> fakeroot -u debian/rules binary
> make KERNELRELEASE=5.7.2-amd64 ARCH=x86_64 KBUILD_BUILD_VERSION=8 -f ./Makefile intdeb-pkg
> sh ./scripts/package/builddeb
> DEPMOD 5.7.2-amd64
> dpkg-deb: building package 'linux-headers-5.7.2-amd64' in '../linux-headers-5.7.2-amd64_5.7.2-amd64-8_amd64.deb'.
> INSTALL debian/linux-libc-dev/usr/include
> dpkg-deb: building package 'linux-libc-dev' in '../linux-libc-dev_5.7.2-amd64-8_amd64.deb'.
> dpkg-deb: building package 'linux-image-5.7.2-amd64' in '../linux-image-5.7.2-amd64_5.7.2-amd64-8_amd64.deb'.
> dpkg-genbuildinfo --build=binary
> dpkg-genchanges --build=binary >../linux-5.7.2-amd64_5.7.2-amd64-8_amd64.changes
> dpkg-genchanges: info: binary-only upload (no source code included)
> dpkg-source --after-build .
> dpkg-buildpackage: info: binary-only upload (no source included)
>
> Here I stripped the -02 (via ~/.config/dpkg/buildflags.conf) and as you can see
> the kernel wasn't recompiled, so the flags weren't taken into consideration,
> and probably it uses the default set of flags which all debian systems use. So
> still what could be wrong with the gcc10 compared to gcc9?
>
I would need to do manual investigation how your build process looks and works.
However, I don't think it makes any sense.
You can read more about CONSTPROP here:
https://www.cs.yale.edu/homes/wilke-pierre/jar18/doc/html/Constprop.html
And people are having issues with that:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61393
https://stackoverflow.com/questions/14796686/what-does-the-gcc-function-suffix-constprop-mean
It is normal that such optimizations are applied, e.g.:
$ uname -r
5.7.0-g3
$ cat /proc/kallsyms |grep constprop|wc -l
919
$ uname -r
4.18.0-80.11.2.el8_0.centos.plus.x86_64
$ cat /proc/kallsyms |grep constprop|wc -l
325
However, which function would be affected by such optimization purely
depends on the kernel configuration.
I need to discuss and research more in details if adding such non-standard
kernel configuration / compilation support makes sense from LKRG perspective.
Nevertheless, current LKRG is going to work fine in your system with all
functionalities.
Thanks,
Adam
--
pi3 (pi3ki31ny) - pi3 (at) itsec pl
http://pi3.com.pl
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
