re: CVS commit: src/usr.bin/crunch/crunchgen

[matthew green <mrg%eterna.com.au@localhost>]

> >> The real bug is the reverted varasm.c change. GCC creates the .eh_frame
> >> section with the wrong permissions.
> >
> >yes - putting your varasm.c back fixes the crtbegin.o
> >build, but it breaks the libstdc++ one:
> >
> >In file included from
> >/usr/src4/external/gpl3/gcc/dist/libstdc++-v3/src/c++98/pool_allocator.cc:31:0:
> >/usr/src4/external/gpl3/gcc/dist/libstdc++-v3/include/ext/pool_allocator.h:210:5: error: only zero initializers are allowed in section
> >     __pool_alloc<_Tp>::_S_force_new;
> >     ^~~~~~~~~~~~~~~~~
> >i'm not sure how to solve this -- we apparently want both
> >behaviours with GCC 7.  uwe@ suggested an explicit asm()
> >or .S file for the crtbegin issue.
> 
> Isn't this used only to deal with "GLIBCXX_FORCE_NEW"? And "NEW" is a
> misnomer since this thing started more than 10 years ago, and it still
> bites: https://www.zerotier.com/blog/2017-05-05-theleak.shtml
> 
> Well, regardless of what the right permissions of .eh_frame are,
> we could just nuke the code and default to the "new" behavior...
> We can then put back the varasm.c change...
> This of course needs to be evaluated carefully.

FWIW, there are several files that have problem with the
varasm.c change applied.

  https://www.netbsd.org/~mrg/gcc7-no-varasm-change-vs-libstdc++.txt

all these fail:

    compile  libstdc++-v3/bitmap_allocator.o
    compile  libstdc++-v3/pool_allocator.o
    compile  libstdc++-v3/mt_allocator.o
    compile  libstdc++-v3/locale-inst.o
    compile  libstdc++-v3/string-inst.o
    compile  libstdc++-v3/wlocale-inst.o
    compile  libstdc++-v3/wstring-inst.o

christos, can you be more detailed in what exactly you think we
can delete or so?  it's not just stuff related to the
GLIBCXX_FORCE_NEW variable AFAICT.


.mrg.