| Message ID | 20200512033948.3507-1-jandryuk@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Fixups for fcf-protection | expand |
On 12.05.20 05:39, Jason Andryuk wrote: > Two patches to fix building with a cf-protection toolchain. The first > handles the case where the compiler fails to run with "error: > ‘-mindirect-branch’ and ‘-fcf-protection’ are not compatible". > > The second fixes a runtime error that prevented Xen booting in legacy > mode. That might be better than just disabling fcf-protection as well (which was done in Ubuntu lacking a better solution). Not sure it was already hit but that additional .note section breaks the build of the emulator as generated headers become gigantic: https://git.launchpad.net/ubuntu/+source/xen/tree/debian/patches/1001-strip-note-gnu-property.patch?h=ubuntu/focal -Stefan > > I still haven't figured out exactly what is wrong with rombios and/or > ipxe. > > Jason Andryuk (2): > xen/x86: Disable fcf-protection when necessary to build > x86/boot: Drop .note.gnu.properties in build32.lds > > xen/arch/x86/arch.mk | 11 ++++++++++- > xen/arch/x86/boot/build32.lds | 5 +++++ > 2 files changed, 15 insertions(+), 1 deletion(-) >
On 12/05/2020 08:17, Stefan Bader wrote: > On 12.05.20 05:39, Jason Andryuk wrote: >> Two patches to fix building with a cf-protection toolchain. The first >> handles the case where the compiler fails to run with "error: >> ‘-mindirect-branch’ and ‘-fcf-protection’ are not compatible". >> >> The second fixes a runtime error that prevented Xen booting in legacy >> mode. > That might be better than just disabling fcf-protection as well (which was done > in Ubuntu lacking a better solution). It is a GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 Fixed for 10, and 9.4 > > Not sure it was already hit but that additional .note section breaks the build > of the emulator as generated headers become gigantic: > > https://git.launchpad.net/ubuntu/+source/xen/tree/debian/patches/1001-strip-note-gnu-property.patch?h=ubuntu/focal 4.6G of notes?!? That is surely a toolchain bug. ~Andrew
On 12.05.20 20:47, Andrew Cooper wrote: > On 12/05/2020 08:17, Stefan Bader wrote: >> On 12.05.20 05:39, Jason Andryuk wrote: >>> Two patches to fix building with a cf-protection toolchain. The first >>> handles the case where the compiler fails to run with "error: >>> ‘-mindirect-branch’ and ‘-fcf-protection’ are not compatible". >>> >>> The second fixes a runtime error that prevented Xen booting in legacy >>> mode. >> That might be better than just disabling fcf-protection as well (which was done >> in Ubuntu lacking a better solution). > > It is a GCC bug > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 > > Fixed for 10, and 9.4 Ah, thanks. And yes, should have reported sooner but, as always, one runs into those things while in a hurry, with not enough time. We were glad to have something that did work somehow. > >> >> Not sure it was already hit but that additional .note section breaks the build >> of the emulator as generated headers become gigantic: >> >> https://git.launchpad.net/ubuntu/+source/xen/tree/debian/patches/1001-strip-note-gnu-property.patch?h=ubuntu/focal > > 4.6G of notes?!? That is surely a toolchain bug. No, sorry if that was unclear. The .notes themselves are just about some Kb or so per object file. Problem is that each object file gets converted into a hex array header file. And this does multiply the resulting header file sizes. So the .h files generated are 4.6G in size. And there were a couple of those, all included into one .c file. Which ended in the compiler running out of memory on a 32GB system. > > ~Andrew >
On 13.05.2020 07:41, Stefan Bader wrote: > On 12.05.20 20:47, Andrew Cooper wrote: >> On 12/05/2020 08:17, Stefan Bader wrote: >>> Not sure it was already hit but that additional .note section breaks the build >>> of the emulator as generated headers become gigantic: >>> >>> https://git.launchpad.net/ubuntu/+source/xen/tree/debian/patches/1001-strip-note-gnu-property.patch?h=ubuntu/focal >> >> 4.6G of notes?!? That is surely a toolchain bug. > > No, sorry if that was unclear. The .notes themselves are just about some Kb or > so per object file. Problem is that each object file gets converted into a hex > array header file. And this does multiply the resulting header file sizes. > So the .h files generated are 4.6G in size. And there were a couple of those, > all included into one .c file. Which ended in the compiler running out of memory > on a 32GB system. But as per the link above it's still 3Mb notes per object, which still seems insane. Jan