[U-Boot] [RFC/PATCH] tools: New 'spl-stackusage' script

[Siarhei Siamashka]

On Mon, 02 Feb 2015 14:15:33 +0100
"Andreas Bießmann" <andreas.devel at googlemail.com> wrote:

> Dear Siarhei Siamashka,

Hi Andreas,

Thanks for your feedback.

> On 02/01/2015 12:47 AM, Siarhei Siamashka wrote:
> > This is a script, which tries to provide a pessimistic estimate
> > of the stack usage in the SPL binary.
> > 
> > A more detailed description about how it works and some example
> > pictures are available in an earlier e-mail:
> >     http://lists.denx.de/pipermail/u-boot/2015-January/201713.html
> > 
> > In fact, I have done nothing with it since that old status update
> > and the code is still very much just at the proof of concept
> > stage and can be only treated as a somewhat working prototype.
> > It only supports 32-bit ARM so far.
> > 
> > An example of trying it:
> > 
> > 1. First compile u-boot for some ARM board. For example:
> > 
> >    make CROSS_COMPILE=arm-none-linux-gnueabi- Cubieboard_defconfig
> >    make CROSS_COMPILE=arm-none-linux-gnueabi- -j8
> 
> unfortunately out-of-tree build is not directly supported with this
> script. I mean some environment (CROSS_COMPILE) is re-used/required by
> the script but others not (O). It would be fine to just replace the make
> in cmdline with this tool to run it.

I'm not so sure that replacing make is a very good idea because that's
outside of the scope of this script. The script only needs the 'spl'
directory with the SPL binary itself and also the *.su files generated
by GCC.

The CROSS_COMPILE environment variable is only used to find the
arm variant of the objdump tool. This variable is even only used as
a fallback method, because the script contains the list of possible arm
toolchain triplets and probes them. In many cases it can be run even
without the CROSS_COMPILE variable defined.

> > 2. Run the script:
> > 
> >    tools/spl-stackusage/spl-stackusage
> > 
> > 3. Look at the (slightly reformatted) output:
> > 
> >    Execution path with maximized stack usage (3152 bytes):
> >       entry > _main > board_init_f > board_init_r > spl_mmc_load_image >
> >       mmc_init > mmc_startup > mmc_switch.isra.1 > mmc_send_status >
> >       printf > puts > console_puts ? mmc_bread > mmc_set_blocklen >
> >       mmc_send_cmd ? sunxi_mmc_getcd > gpio_get_value >
> >       axp_gpio_get_value > axp209_read > i2c_read ? twsi_i2c_read >
> >       i2c_begin > twsi_wait > udelay > __udelay
> > 
> >    The '>' symbols indicate normal calls. The '?' symbols
> >    indicate a suspected indirect call. Now we can see that the
> >    'console_puts ? mmc_bread' indirect call does not make any sense.
> >    So we can run the script again, now indicating that a call
> >    from 'console_puts' to 'mmc_bread' is impossible:
> > 
> > 4. Run the script again as:
> > 
> >    tools/spl-stackusage/spl-stackusage \
> >        remove_arrow[console_puts,mmc_bread]
> 
> Unfortunately dynamic stack allocation is not considered.

The use of dynamic stack size is at least detected and the script
refuses to work. I wanted to get some feedback before deciding
how to best handle it.

> So adding FAT to SPL will result in an empty list here. I only get 'dynamic stack size
> in get_cluster'. I think the most important thing is to always print out
> the summary and the caller stack, mark the dynamic parts of the stack
> and mention that there is some more required.

Thanks for the suggestion. For now you can just find the relevant .su
file and edit it fake some some arbitrary stack usage estimate there.

> Some interface to declare the maximum amount of dynamic stack usage for
> a specific symbol by command line would be really great. So one can
> guess the relevant parts and calculate the maximum size.

Yes. Or alternatively it is perhaps possible to just fix the FAT code
and use malloc instead of dynamic allocations on stack.

The large buffers in .bss in the FAT code is already responsible for
the .bss section placement in DRAM. And these dynamic allocations on
stack are yet another wacky thing in this code.

> Another point ... I really appreciate your efforts to bring this tool
> in. So don't get me wrong, but ... why ruby?

That's because I know ruby, but don't know python at the moment.

Why I have picked ruby over python some years ago is another story.
But I don't want to start a programming language holy war here :)

> A while ago some guys started to introduce python for some complex
> scripts, before that u-boot only had shell scripts.
> I personally think one interpreter in u-boot world is enough. I'm
> curious how others think about that.

If python is a requirement, then I will have to learn it first. Which
is fair enough. But this requirement first needs to be explicitly
communicated by somebody.

-- 
Best regards,
Siarhei Siamashka