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
