Jordan Crouse wrote:
I need a community vote. There is an lingering stack protect issue in LinuxBIOS, and it hits us when we port new platforms. The problem is that not all of the lines in the various Config.lb files that compile code also include the $(CPU_OPT) variable that we use to pass in the -fno-stack-protector from buildrom.
So I offer these two possible solutions. One is a patch to buildrom that changes how we pass in the -fno-stack-protect flag (thanks to Marc for the patch). The other is a patch to LinuxBIOS itself to fix the actual problem and pass $(CPU_OPT) where appropriate in the mainboard Config.lb files.
So I leave it to the community - which solution do we prefer? One one hand, the buildrom solution only affects targets when built by buildrom, so abuild and other tools aren't affected, though it glosses over the real problem.
On the other hand, any tools who may find CPU_OPT useful for their own uses will hit this too, but it is far more likely to break things.
Thoughts?
I'll be brutally honest: I don't like either one. The buildrom patch, as you've said, only affects buildrom, so it still leaves the issue of manually building (an easy fix, but nonetheless an annoying one) and also abuild. IMO, the best test will be when we can do abuild on stock ubuntu with a fresh checkout.
The linuxbios patch only fixes cache-as-ram based boards, but is much more promising IMO. If we can extend that into ROMCC without breaking anything fragile, it'll be good. But there's always the if ;)
BTW, I'm happy to say I've finally gotten rid of ubuntu on both my main machines, and am much happier with opensuse, until something breaks. I do still have one machine left that I can test any patches you want to throw out with.
-Corey