> >> 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.
