Summary: | gcc; x v.s. x-vanilla yields broken software | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Blu3 <david+gentoo.org> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | f5d8fd51ed1e804c9e8d0357e8614e0493b06e96, hardened |
Priority: | High | ||
Version: | 2005.0 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Blu3
2005-05-03 01:48:09 UTC
Could you try gcc-3.4.4-r1 and let us know if you still have issues? w.r.t. using gdb on code built with the hardened compiler, this is a known limitation of gdb in that it cannot debug PIEs. See the hardened faq http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#hardeneddebug (I haven't tried gdb-6.4 yet to see if this has changed). w.r.t. segfaults - each segfault has to be dealt with on a case-by-case basis. This is frequently due to ssp, which we know doesn't work perfectly with some C++ at least. Realistically we're not likely to fix such problems, and the workaround is to switch off ssp for the relevant applications: CFLAGS="-fno-stack-protector" emerge foo is a workaround for users. w.r.t. the 'test.c' program - well that works fine. All observed output is as expected. If this were to segfault there would be something to worry about. I see little point in doing much with a bug that says, like this one, "hardened gcc breaks lots of stuff". re your comment. #1, this is nice. back when i asked the questions about this and when i filed the bug, nobody could come up with an answer or even come close to an explanation. #2, this isn't c++, it's basic C. it is also -O2 not -O3 as is referenced by the hardened FAQ. #3, the test.c was a ref. program showing some differences. #4, it's easy to denigrate bug reports half a year later after everyone has figured things out. why do people refuse to post bug reports and gripe about the rudeness of those who reply like this. literally, at that point in time, hardened gcc was breaking a bunch of packages and nobody knew how to solve it. if someone did know, they didn't feel like sharing. as time went on, both gcc and packages got fixed. gcc no longer emitted broken code on some of those packages and some of those packages got inherently flawed code fixed. Mark, joe and hardened gcc are living happily together now as are the other 17 packages i had problems with. thank you for checking. gcc since that version has been better and i currently have 3.4.4-r1 installed. Reopening... To mark fixed. Thanks for your response. (In reply to comment #3) > #1, this is nice. back when i asked the questions about this and when i filed > the bug, nobody could come up with an answer or even come close to an > explanation. I suspect this bug got lost in the fog, probably because it didn't identify a specific problem when initially raised (it just referred to other bugs that were already marked invalid). It would be better to ask general questions like the ones posed here on the hardened mailing list (i.e. "how do I debug programs built with the hardened compiler?", "Lots of stuff segfaults when built with the hardened compiler - help!"). Re bug #88203 (joe) - you marked that bug RESOLVED/INVALID which implies the bug was not a bug in the first place, so we won't have looked at that further. Similarly with bug #91259. In future, if a package fails when built with the hardened compiler, re-assign the bug to the hardened team rather than just closing it. In order to find problems with the hardened compiler, we need to know which packages fail with it and where. Closing all the related bugs and raising just one that says "gcc is broken!" doesn't help us to narrow down the problem; we're a very small team and can't watch everything on bugzilla. > #2, this isn't c++, it's basic C. it is also -O2 not -O3 as is referenced by > the hardened FAQ. As far as this bug is concerned, you didn't identify a specific failure. You've also put two completely separate issues together. It appears you posted test.c in relation to debugging PIEs, but that's not clear from this bug. This bug says 'gcc is broken' yet the test code you supplied works fine, so there's nothing much to be done. > #3, the test.c was a ref. program showing some differences. But to what purpose, since it doesn't fail? It would have been better to have continued the "unable to debug" problem on bug #91259 where you initially raised it. > #4, it's easy to denigrate bug reports half a year later after everyone has > figured things out. why do people refuse to post bug reports and gripe about > the rudeness of those who reply like this. Calm down please. What seems to have happend here is that you asked the original questions in ways that fell under our radar. I posted about the PIE debug issue to the forums in January 2005 (http://forums.gentoo.org/viewforum-f-8.html), and the hardened team were capable of answering that issue well before then, because I got that answer from them when I started. > > literally, at that point in time, hardened gcc was breaking a bunch of packages > and nobody knew how to solve it. if someone did know, they didn't feel like > sharing. as time went on, both gcc and packages got fixed. gcc no longer > emitted broken code on some of those packages and some of those packages got > inherently flawed code fixed. If anything got fixed, it was most likely to have been due to upstream development (either GCC, ssp or package authors) rather than anything we did. I can assure you there is no conspiracy trying to keep things secret from you. > Mark, joe and hardened gcc are living happily together now as are the other 17 > packages i had problems with. thank you for checking. gcc since that version > has been better and i currently have 3.4.4-r1 installed. 17 packages! How can we be expected to investigate something if you don't tell us you have such problems. It would have been much better to have listed these 17 packages on your bug report, along with details about how they failed. |