On 11/30/2017 09:40 AM, Thomas Preudhomme wrote:
> Hi,
>
> Effective target fstack_protector fails to return an error for
> newlib-based target (such as arm-none-eabi targets) which does not
> support stack protector. This is due to the test being too simplist for
> stack protection code to be generated by GCC: it does not contain a
> local buffer and does not read unknown input.
>
> This commit adds a small local buffer with a copy of the filename to
> trigger stack protector code to be generated. The filename is used
> instead of the full path so as to ensure the size will fit in the local
> buffer.
>
> ChangeLog entry is as follows:
>
> *** gcc/testsuite/ChangeLog ***
>
> 2017-11-28 Thomas Preud'homme <thomas.preudho...@arm.com>
>
> * lib/target-supports.exp (check_effective_target_fstack_protector):
> Copy filename in local buffer to trigger stack protection.
>
> Testing: Ran gcc.dg/pr38616 on arm-none-eabi and arm-linux-gnueabihf,
> the former is now UNSUPPORTED while the latter continues to PASS.
>
> Is this ok for stage3?
OK.
jeff
