This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Added information about inline assembler in stack calculations (.su files)
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Niklas DAHLQUIST <niklas dot dahlquist at st dot com>
- Cc: Jeff Law <law at redhat dot com>, Torbjorn SVENSSON <torbjorn dot svensson at st dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "Joey dot Ye at arm dot com" <Joey dot Ye at arm dot com>, Samuel HULTGREN <samuel dot hultgren at st dot com>, Christophe LYON <christophe dot lyon at st dot com>, Christophe MONAT <christophe dot monat at st dot com>
- Date: Fri, 7 Dec 2018 17:35:26 -0600
- Subject: Re: [PATCH] Added information about inline assembler in stack calculations (.su files)
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com>
On Fri, Dec 07, 2018 at 07:51:35AM +0000, Niklas DAHLQUIST wrote:
> On 12/1/18 1:15 AM, Jeff Law wrote:
> > One could argue that allocating stack space inside an ASM is a really
> > bad idea. Consider things like dwarf debugging and unwind tables. If
> > you're allocating stack inside an ASM that stuff is going to be totally
> > wrong.
> > So I think my question before moving forward with something like this is
> > whether or not it makes sense at all to bother dumping data for a
> > scenario that we'd probably suggest developers avoid to begin with.
> The purpose of the patch is to notify when the reported stack usage might be
> incorrect. Even if it's bad practice to alter stack in asm, there are
> use cases
> in the embedded world that makes sense. A notable common use case is
> task switch using ARM "naked" attribute and inline asm, which reports "0
> which gives a faulty stack usage. We have considered the other option to
> report a warning for these cases, but that alternative hasn't appealed
> to us.
Would that work well? Only warn for naked functions? It would work
better for all users that do *not* mess with the stack in their asm ;-)