Summary: | boot2 fails to compile with xtoolchain-amd64-gcc 6.3.0: negative space left | ||
---|---|---|---|
Product: | Base System | Reporter: | Enji Cooper <ngie> |
Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> |
Status: | Closed DUPLICATE | ||
Severity: | Affects Some People | CC: | cem, emaste, imp, lwhsu, rlibby, tsoome |
Priority: | --- | ||
Version: | CURRENT | ||
Hardware: | Any | ||
OS: | Any |
Description
Enji Cooper
2017-03-29 09:32:45 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. What's the space available before my changes of the past week? The latest sources are only -544 bytes free. (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:) And having a boot2.ufs1 and boot2.ufs2 wouldn't help either, since that only saves 200 bytes... (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. (In reply to Warner Losh from comment #6) at the end of the day, the question is about who is the interested party;) *** This bug has been marked as a duplicate of bug 213137 *** |