Re: Glibc 2.12 issue
On Thu, Sep 2, 2010 at 1:41 AM, alexander.kanevs...@nokia.com wrote: On 01/09/2010 15:24, ext Loïc Minier loic.min...@linaro.org wrote: On Tue, Aug 31, 2010, Michael Hope wrote: The solution is to add -fno-stack-protector to the libgcc build options and rebuild the compiler. I've heard (but can't track down the link) that the ARM libgcc unwind functions must be built this way in any case. See http://svn.debian.org/wsvn/gcccvs/branches/sid/gcc-4.5/debian/patches/gcc-def ault-ssp.diff for how Debian does this. How can we fix this in the upstream sources? Should glibc or libgcc detect this erroneous state? Probably glibc, as this error appeared in 2.12, and not reproducible with the same gcc and flags with glibc 2.11. There's a few questions here: 1. What in libanl has caused the new call to gnu_Unwind_Backtrace? Fixing this will remove the immediate problem 2. Does the backtrace work with -fstack-protector? 3. Should libgcc be built without -fstack-protector? (3) is interesting as libgcc is such a fundamental library that it really shouldn't have dependencies on anything else. What's the opinion of people on the list? -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Glibc 2.12 issue
I agree. It's also inappropriate for something as low level as libgcc to have dependencies on other libraries such as libssp. We'll propose a patch adding '-fno-stack-protector' to the gcc list and see how it goes. -- Michael On Thu, Sep 2, 2010 at 9:23 AM, Mark Mitchell m...@codesourcery.com wrote: On 9/1/2010 2:10 PM, Michael Hope wrote: 3. Should libgcc be built without -fstack-protector? To put it more strongly, I believe that libgcc should not be built with -fstack-protector. I don't think there's any reason to expect that all code in libgcc would continue to work with stack-protection checks inserted (e.g., low-level primitives for thread safety or exception-handling, where chaos may ensue if a fault occurs in the midst of the stack-protection code). Furthermore, those checks will increase overhead for all users of the library. And, if libgcc has dependencies on other shared libraries, that could potentially break binary compatibility across Linux distributions. If someone wants to build libgcc with -fstack-protector, that would require an assessment of all code in libgcc to make sure that is safe. libgcc is emphatically not application code. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Glibc 2.12 issue
Hi Chung-Lin. Could you please take care of this upstream? The short story is that many distributions, including Fedora and Ubuntu, build GCC with the stack protector turned on by default. This is both inappropriate for and could interfere with libgcc. We'd like to ensure the stack protector is turned off by adding -fno-stack-protector to the libgcc build rules. I've created LP: #628526 to track this. See the link below for how Ubuntu does it. I'd like the change in Linaro GCC 4.4 and 4.5. -- Michael On Thu, Sep 2, 2010 at 9:53 AM, Michael Hope michael.h...@linaro.org wrote: I agree. It's also inappropriate for something as low level as libgcc to have dependencies on other libraries such as libssp. We'll propose a patch adding '-fno-stack-protector' to the gcc list and see how it goes. -- Michael On Thu, Sep 2, 2010 at 9:23 AM, Mark Mitchell m...@codesourcery.com wrote: On 9/1/2010 2:10 PM, Michael Hope wrote: 3. Should libgcc be built without -fstack-protector? To put it more strongly, I believe that libgcc should not be built with -fstack-protector. I don't think there's any reason to expect that all code in libgcc would continue to work with stack-protection checks inserted (e.g., low-level primitives for thread safety or exception-handling, where chaos may ensue if a fault occurs in the midst of the stack-protection code). Furthermore, those checks will increase overhead for all users of the library. And, if libgcc has dependencies on other shared libraries, that could potentially break binary compatibility across Linux distributions. If someone wants to build libgcc with -fstack-protector, that would require an assessment of all code in libgcc to make sure that is safe. libgcc is emphatically not application code. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Glibc 2.12 issue
Hi Alexander. I've looked into the problem and the linker error is caused by a mix of stack protector options between libgcc and the C library. GCC includes a feature called the stack smashing protector which detects writing past the end of a stack based object. It's quite nice as it gives decent protection against buffer overruns which are the most common type of security vulnerability. The implementation is straight forward: when compiled with -fstack-protector, any function with a stack-based character array will have extra stack checking code inserted into the prologue and epilogue. The prologue allocates a canary value at the top of stack and fills it in with the value of '__stack_chk_guard' provided by libssp. The epilogue checks this value and calls `__stack_chk_fail` if it has been changed. The stack protector can interfere with some code and isn't applicable in others. The problem here is caused by a stack up of things: * glibc knows about -fstack-protector and turns it on and off for different functions and libraries * gcc knows about -fstack-protector and includes libssp if required * glibc knows about libgcc and statically links against it to ensure availability * Meego seems to turn on -fstack-protector by default (as does Ubuntu) This results in the libgcc function '_gcc_Unwind_Backtrace' being built with the stack protector and the glibc library 'libanl' without. At static link time GCC sees that the stack protector is off and skips linking against libssp, causing the missing symbol error. The solution is to add -fno-stack-protector to the libgcc build options and rebuild the compiler. I've heard (but can't track down the link) that the ARM libgcc unwind functions must be built this way in any case. See http://svn.debian.org/wsvn/gcccvs/branches/sid/gcc-4.5/debian/patches/gcc-default-ssp.diff for how Debian does this. Hope that helps, -- Michael On Fri, Aug 27, 2010 at 9:06 PM, alexander.kanevs...@nokia.com wrote: Hi Michael. I've created for you account in MeeGo OBS (build system that we use in MeeGo is OpenSuSE build system) login: michaelh password: wog-feg-da Web client url: https://build.meego.com API url: https://api.meego.com The build log that had problem with glibc 2.12 + gcc 4.5 you can find here: https://build.meego.com/package/live_build_log?arch=armv7elpackage=glibcpr oject=home%3Akad%3Abranches%3ATrunk%3ATestingrepository=standard Might be you have some idea what went wrong, as our toolchain people were not able to find why combination of latest gcc plus glibc 2.11.x works, but not gcc 4.5 + glibc 2.12.0 :( This log is from my home project inside OBS, where stuff is already a bit outdated. I'll ask Jan-Simon from Linux Fundation to point to right place where latest builds are present, so you can experiment with them. -- Best regards, Alexander Kanevskiy. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
