This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC][AArch64] function prologue analyzer in linux kernel

On 01/16/2016 01:56 AM, Will Deacon wrote:
On Wed, Jan 13, 2016 at 05:13:29PM +0900, AKASHI Takahiro wrote:
On 01/13/2016 03:04 AM, Will Deacon wrote:
On Tue, Jan 12, 2016 at 03:11:29PM +0900, AKASHI Takahiro wrote:
On 01/09/2016 12:53 AM, Will Deacon wrote:
I still don't understand why you can't use fstack-usage. Can you please
tell me why that doesn't work? Am I missing something?

I don't know how gcc calculates the usage here, but I guess it would be more
robust than my analyzer.

The issues, that come up to my mind, are
- -fstack-usage generates a separate output file, *.su and so we have to
   manage them to be incorporated in the kernel binary.

That doesn't sound too bad to me. How much data are we talking about here?

   This implies that (common) kernel makefiles might have to be a bit changed.
- more worse, what if kernel module case? We will have no way to let the kernel
   know the stack usage without adding an extra step at loading.

We can easily add a new __init section to modules, which is a table
representing the module functions and their stack sizes (like we do
for other things like alternatives). We'd just then need to slurp this
information at load time and throw it into an rbtree or something.

I found another issue.
Let's think about 'dynamic storage' case like:
$ cat stack.c
extern long fooX(long a);
extern long fooY(long b[]);

long foo1(long a) {

	if (a > 1) {
		long b[a];  <== Here

		return a + fooY(b);
	} else {
		return a + fooX(a);

Then, -fstack-usage returns 48 for foo1():
$ aarch64-linux-gnu-gcc -fno-omit-frame-pointer -fstack-usage main.c stack.c \
       -pg -O2 -fasynchronous-unwind-tables
$ cat
stack.c:4:6:foo1	48	dynamic

This indicates that foo1() may use 48 bytes or more depending on a condition.
But in my case (ftrace-based stack tracer), I always expect 32 whether we're
backtracing from fooY() or from fooX() because my stack tracer estimates:
        (stack pointer) = (callee's frame pointer) + (callee's stack usage)
(in my previous e-mail, '-(minus)' was wrong.)

where (callee's stack usage) is, as I described in my previous e-mail, a size of
memory which is initially allocated on a stack in a function prologue, and should not
contain a size of dynamically allocate area.

According to who? What's the use in reporting only the prologue size?

Me :)
(I'm afraid that my wording, "stack usage", might confuse you.)

My arm64-specifc check_patch() expects this in order to estimate caller's correct stack
pointer address from a callee's frame pointer, which does not contain any of callee's
dynamically (so probably after a prologue) allocated variables.
Please take a close look at my patch #5[1].


-Takahiro AKASHI


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]