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

[christos%astron.com@localhost (Christos Zoulas)]

In article <16690.1550005102%splode.eterna.com.au@localhost>,
matthew green  <mrg%eterna.com.au@localhost> wrote:
>Joerg Sonnenberger writes:
>> On Tue, Feb 12, 2019 at 10:16:58AM +0000, matthew green wrote:
>> > Module Name:	src
>> > Committed By:	mrg
>> > Date:		Tue Feb 12 10:16:58 UTC 2019
>> > 
>> > Modified Files:
>> > 	src/usr.bin/crunch/crunchgen: crunchgen.c
>> > 
>> > Log Message:
>> > hack alert time:
>> > 
>> > on sparc and sparc64, don't remove .eh_frame section.  it leads
>> > to failure as something is referenced, and objcopy ends up
>> > emitting a broken binary that can't be run -- it attempts to
>> > load at va=0, beyond having missing referenced data.
>> > 
>> > also, on sparc64 also don't remove .note.netbsd.mcmodel.
>> > 
>> > the former should be revised when we can avoid it.
>> 
>> 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.

christos