This is the mail archive of the
mailing list for the GCC project.
Re: stack-protection vs alloca vs dwarf2
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 17 Apr 2014 09:19:18 +0200
- Subject: Re: stack-protection vs alloca vs dwarf2
- Authentication-results: sourceware.org; auth=none
- References: <201404170303 dot s3H335mQ015761 at greed dot delorie dot com>
> While debugging some gdb-related FAILs, I discovered that gcc's
> -fstack-check option effectively calls alloca() to adjust the stack
Note that the subject is misleading, -fstack-check is stack checking and not
stack protection, which is -fstack-protector.
> However, it doesn't mark the stack adjustment as FRAME_RELATED even
> when it's setting up the local variables for the function.
> In the case of rx-elf, for this testcase, the CFA for the function is
> defined in terms of the stack pointer - and thus is incorrect after
> the alloca call.
That's the bug, any function using alloca must use the frame pointer as CFA.
> My question is: who's fault is this? Should alloca() tell the debug
> stuff that the stack pointer has changed? Should it tell it to not
> use $sp at all? Should the debug stuff "just know" that $sp isn't a
> valid choice for the CFA?
Presumably the rx back-end and more precisely TARGET_FRAME_POINTER_REQUIRED,
which needs to return true if cfun->calls_alloca.