On Fri, Feb 17, 2017 at 06:58:02PM +1300, Michael Cree wrote: > On Thu, Feb 16, 2017 at 09:19:09PM -0600, Bob Tracy wrote: > > On Thu, Feb 16, 2017 at 08:23:05AM +1300, Michael Cree wrote: > > > I've got bigger fish to fry at the moment. In particular a > > > binutils/glibc bug that is causing segfaults in the dynamic symbol > > > resolver. Try this: write a simple "Hello world" program in C. > > > Compile with "-Wl,-z,now" linker option which causes the dynamic > > > loader to resolve all symbols at program invocation, rather than > > > resolving symbols when first used. If compiled with a recent > > > toolchain it segfaults [2]. > > > (...) > > > > > > [2] Toolchain gcc 4:6.1.1-1, binutils 2.27-8 produces a working > > > executable, but toolchains later than gcc 4:6.2.1-1, binutils > > > 2.27.90.20170124-2 are known to be bad. > > > > Verified the broken behavior for a kernel.org kernel version 4.9.0 with > > gcc 6.3.0 20170205 (Debian 6.3.0-6) and binutils 2.27.90.20170205. This > > is *nasty*. > > I don't understand. The toolchain bug is for executables built to run > in userspace, not for the kernel. What's the broken behaviour you are > seeing with the kernel?
None whatsoever with the kernel. You spoke of a commit that needed to be backed out prior to building a kernel, but it wasn't clear from context what package that commit was against, and I ASSumed it was against the kernel tree without bothering to check. I went back and checked your earlier message, and I *think* the proper context was a warning not to try building a kernel with the broken tool chain. My kernel, built with the broken tool chain, seems to be working properly as best I can tell. Sorry for the confusion. --Bob
