除了安全编译选项问题, 还有性能编译选项问题; 请build-SIG一起考虑下;
请openEuler编译默认ELF使用2M对齐 openEuler X86编译默认是4K对齐, AMR64是64K对齐; 这两种对齐方式都会导致透明大页特性开启的时候, 无法有效使用透明大页; 因此需要将openEuler编译对齐为2M对齐;
From: Hexiaowen (Hex, EulerOS) [mailto:hexiaowen@huawei.com] Sent: Tuesday, November 16, 2021 10:11 AM To: Chenxi Mao chenxi.mao@suse.com; dev@openeuler.org Subject: [Dev] 答复: 关于欧拉操作系统gcc_secure包问题的讨论
很感谢你的参与，我尝试答复下这个问题，有不合理的地方，希望可以一起改进：
我是SUSE的毛晨曦，目前正在从事基于欧拉的发行版的开发和调研工作。 在开发的过程当中，关于GCC_secure的相关问题，想请教一下社区的开发者和维护者。后续我想会在GCC_secure这个包上面做一些开发维护工作。
Ø Gcc_secure这个软件产生的背景是，需要对所有gcc编译的软件添加安全编译选项，
Ø 最开始的方案是选择修改rpm CFLAGS等编译选项，但发现无法覆盖所有，特别是没有makefile，直接使用脚本或其他方式构建的软件。
Ø Gcc_secure的方案很粗暴，但有效，也在尝试改进方案。
根据我对于GCC _secure包的理解，GCC_secure包主要完成了下面几项工作： 1. 在gcc_secure包中增加了部分安全相关的编译参数，如pic/pie/fsprotect等，目的是增强整个openEuler的安全性 2. 增加了fsigned-char参数，为了保证arm64和X86的平台可移植性。 3. 在gcc_secure中定义了一个exclude名单，这个名单是在project config中进行定义的，里面包含了大约几十个包
Ø 这里的描述准确，恰恰是gcc_secure的功能，
Ø 关于gcc_secure的实现，有一些不太了解的地方想请开发者、维护者帮我理清一下。
1. gcc_exclude的这个名单，是否是因为一些已知问题，才将这些软件包放在exclude的名单中？后续时候会根据版本演进，逐渐将这些包也使用gcc_secure的方式进行编译，如果开发者或维护者已经有相关计划或规划，烦请分享一下相关计划，后续可以共同解决这个问题，使得编译一致化。
Ø Exclude名单是在日常处理时，发现的不能使用gcc_secure，或只能使用某一个或几个安全编译选项， 这个早期的方案现在看来导致整个系统的构建极其混乱，需要整改。
2. 在gcc_secure中增加fsigned-char使得ARM64的行为与X86一致，是否可以从源代码的层面解决会更加彻底一些，最终将fsigned-char从gcc_secure中移除。这方面我已经做了一些初步的工作，已经提交到社区。如果获得批准，后续我也会继续完善这方面工作。
Ø 非常赞成你的观点，源码层面的问题，就应该由开发者在源码层面闭环掉，而不应该让整个编译系统兜底。
几个PR我会检视合入， 再次感谢你的热心。
发件人: Chenxi Mao [mailto:chenxi.mao@suse.com] 发送时间: 2021年11月15日 17:31 收件人: dev@openeuler.orgmailto:dev@openeuler.org 抄送: Chenxi Mao <chenxi.mao@suse.commailto:chenxi.mao@suse.com> 主题: [Dev] 关于欧拉操作系统gcc_secure包问题的讨论
Hi 各位尊敬的开发者和维护者： 您好，
我是SUSE的毛晨曦，目前正在从事基于欧拉的发行版的开发和调研工作。 在开发的过程当中，关于GCC_secure的相关问题，想请教一下社区的开发者和维护者。后续我想会在GCC_secure这个包上面做一些开发维护工作。 根据我对于GCC _secure包的理解，GCC_secure包主要完成了下面几项工作： 1. 在gcc_secure包中增加了部分安全相关的编译参数，如pic/pie/fsprotect等，目的是增强整个openEuler的安全性 2. 增加了fsigned-char参数，为了保证arm64和X86的平台可移植性。 3. 在gcc_secure中定义了一个exclude名单，这个名单是在project config中进行定义的，里面包含了大约几十个包 关于gcc_secure的实现，有一些不太了解的地方想请开发者、维护者帮我理清一下。 1. gcc_exclude的这个名单，是否是因为一些已知问题，才将这些软件包放在exclude的名单中？后续时候会根据版本演进，逐渐将这些包也使用gcc_secure的方式进行编译，如果开发者或维护者已经有相关计划或规划，烦请分享一下相关计划，后续可以共同解决这个问题，使得编译一致化。 2. 在gcc_secure中增加fsigned-char使得ARM64的行为与X86一致，是否可以从源代码的层面解决会更加彻底一些，最终将fsigned-char从gcc_secure中移除。这方面我已经做了一些初步的工作，已经提交到社区。如果获得批准，后续我也会继续完善这方面工作。 初步提交的PR如下： https://gitee.com/src-openeuler/libstoragemgmt/pulls/12 https://gitee.com/src-openeuler/fcoe-utils/pulls/12
烦请社区维护者审阅 相关问题在gitee上的地址： https://gitee.com/src-openeuler/obs_meta/issues/I4FDFP https://gitee.com/src-openeuler/gcc_secure/issues/I4F7UV?from=project-issue
Chenxi