On Mon, 02 Feb 2015 14:15:33 +0100 "Andreas Bießmann" andreas.devel@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:
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.
Run the script:
tools/spl-stackusage/spl-stackusage
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:
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.