This is the mail archive of the
mailing list for the glibc project.
Re: stack-protector configure test and MIPS64
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 21 May 2012 13:43:52 -0700 (PDT)
- Subject: Re: stack-protector configure test and MIPS64
- References: <Pine.LNX.firstname.lastname@example.org>
I don't like having any machine-dependent stuff in this test (by
whatever means) if we can avoid it.
The main reason I made it such an exact match was paranoia about the
overall fragility of the test. (But I still can't really think of a
better style of test for this.)
It's might be fine to accept random undefined symbols and just treat
presence of foobar in that list as the only sanity check.
Better paranoia would be to do a sanity-check test that compiles the
same code with -fstack-protector explicitly and verifies that
__stack_chk_fail is in the list of undefined symbols. Only if that
passes would we then do the test with the default flags and consider
presence/absence of a __stack_chk_fail reference to tell us anything.
That would catch e.g. a compiler configured to emit some different
call than the one we're expecting.
I'm of two minds as to whether the sanity-check test failing should be
a hard configure failure or just cause it to skip the test for