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: Jeff Law <law at redhat dot com>
- To: 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>
- Cc: "Joey dot Ye at arm dot com" <Joey dot Ye at arm dot com>, Niklas DAHLQUIST <niklas dot dahlquist at st 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, 30 Nov 2018 17:15:14 -0700
- Subject: Re: [PATCH] Added information about inline assembler in stack calculations (.su files)
- References: <firstname.lastname@example.org>
On 11/26/18 7:02 AM, Torbjorn SVENSSON wrote:
> Attached is a small patch that, in case of inline assembler code,
> indicates that the function stack usage is uncertain due to inline
> The test suite are using "nop" as an assembler instruction on all
> targets, is this acceptable or is there a better way to test this?
> Patch has been tested on gcc-arm-none-eabi-7-2018-q2-update for both
> arm-none-eabi and x86_64-linux-gnu and SVN head (r266454) for
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
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.