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.su
> 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?
Will
