Bug 218206 - boot2 fails to compile with xtoolchain-amd64-gcc 6.3.0: negative space left
Summary: boot2 fails to compile with xtoolchain-amd64-gcc 6.3.0: negative space left
Status: Closed DUPLICATE of bug 213137
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-29 09:32 UTC by Enji Cooper
Modified: 2017-09-01 00:45 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Enji Cooper freebsd_committer 2017-03-29 09:32:45 UTC
BOOT2SIZE might need to be increased (or some creative work be done to reduce used space) to accommodate gcc 6.3.0 being able to compile boot2. From https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/207/console :

04:30:03 kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1
04:30:03 client: fmt=bin size=1984 text=0 data=0 bss=0 entry=0
04:30:03 output: fmt=bin size=2214 text=200 data=2014 org=0 entry=0
04:30:03 --- boot2 ---
04:30:03 --- all_subdir_usr.bin ---
04:30:03 --- tbl.o ---
04:30:03 /usr/local/bin/x86_64-unknown-freebsd11.0-gcc -isystem /workspace/obj/workspace/src/tmp/usr/include -L/workspace/obj/workspace/src/tmp/usr/lib -B/workspace/obj/workspace/src/tmp/usr/lib --sysroot=/workspace/obj/workspace/src/tmp -B/usr/local/x86_64-freebsd/bin/  -O2 -pipe   -DHAVE_CONFIG_H  -I/workspace/src/lib/libopenbsd/ -g -MD  -MF.depend.tbl.o -MTtbl.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-error=address -Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare -Wno-error=cast-align -Wno-error=clobbered -Wno-error=enum-compare -Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses -Wno-error=strict-aliasing -Wno-error=uninitialized -Wno-error=unused-but-set-variable -Wno-error=unused-function -Wno-error=unused-value -Wno-error=strict-overflow -Wno-error=misleading-indentation -Wno-error=nonnull-compare -Wno-error=--- all_subdir_gnu ---
04:30:03 --- B ---
04:30:03 --- all_subdir_usr.bin ---
04:30:03 shift-negative-value -Wno-error=tautological-compare -Wno-error=unused-const-variable     -c /workspace/src/contrib/mdocml/tbl.c -o tbl.o
04:30:03 --- all_subdir_sys ---
04:30:03 -1044 bytes available
04:30:03 *** [boot2] Error code 1
Comment 1 Warner Losh freebsd_committer 2017-03-29 18:13:05 UTC
BOOT2SIZE is invariant and cannot be changed. It shall be 7.5k and no larger since boot2 is installed into a slot that's 7.5k in size. We might be able to do creative things to mine a few bytes from boot1, but even that's a crap shoot.

But -1044 bytes free is an epic fail on gcc 6.3's part. Someone will need to see if there's a magic combination of options that can reduce the size, or it will be unsupported. That's the harsh reality of living in 7.5k: either it fits, or it's broken. gcc 4.2.1 has +204 bytes free today. Even the bloat-generating clang has 100 bytes free.
Comment 2 Warner Losh freebsd_committer 2017-03-29 18:13:37 UTC
What's the space available before my changes of the past week?
Comment 3 Warner Losh freebsd_committer 2017-03-29 18:33:12 UTC
The latest sources are only -544 bytes free.
Comment 4 Toomas Soome freebsd_committer 2017-03-29 18:50:14 UTC
(In reply to Warner Losh from comment #3)

My guess is that at first the resulting object files should be analyzed and compared.

One possible way to safe few bytes is about the question, should boot2 include both ufs1 and ufs2 reader and how much we win from ufs2 only; and even more importantly, as the ufs2 does leave more space for boot block, how much time and energy we should invest for 7.5k code:)
Comment 5 Warner Losh freebsd_committer 2017-03-29 19:32:33 UTC
And having a boot2.ufs1 and boot2.ufs2 wouldn't help either, since that only saves 200 bytes...
Comment 6 Warner Losh freebsd_committer 2017-03-29 19:34:11 UTC
(In reply to Toomas Soome from comment #4)

Gcc 6.3 is being pathologically stupid in its defaults. I'd rather see us say that compiler isn't supported that do much work here. However, an hour with compiler options likely will suffice to bring the generated code down.
Comment 7 Toomas Soome freebsd_committer 2017-03-29 20:03:37 UTC
(In reply to Warner Losh from comment #6)

at the end of the day, the question is about who is the interested party;)
Comment 8 Ryan Libby freebsd_committer 2017-09-01 00:45:56 UTC

*** This bug has been marked as a duplicate of bug 213137 ***