Now how did you run that?
As simple as..../run_canon_fw.sh EOSM2,firmware="boot=0" -d debugmsg -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb
...
CTRL-C
(gdb) set $pc = 0xff222b64
(gdb) continue
Is that two ways of looking at the same thing?
Yes.
Before and after memory allocation?
No.
Ok--so what are we looking at here?
Besides standard C malloc (aka user_mem in DryOS), and a similar allocator named AllocateMemory (
sys_mem - nope, that's a third one), which both live in a tiny space of about 12MB (the gray bar at the left - 13MB on most models), for the memory-hungry stuff, Canon code uses a bunch of hardcoded regions (which may change according to operating modes). The graph shows these regions (top: scaled to show their real size, bottom: scaled so you can read the text).
Some of these regions are managed by allocators (shoot_malloc, srm_malloc), but it's not very clear which and when. It's one thing in photo mode and another in LiveView. Consider modes like video recording, raw developing, direct print (anyone uses it?) or wifi operation, and it starts to get really complicated. The safest way is to rely on these allocators when a large amount of memory is needed, and free it as soon as you no longer need it (otherwise you may not be able to change between some of the above modes). That's why the memory backend avoids shoot/srm allocators until it has no other choice. That's also the explanation for the second way to trigger ERR70 described
in the stack trace PR.
In some cases, there are memory areas that are never used by Canon code (they are marked as full-height gray bars). We can double-check whether these are really unused (by making sure nobody writes to them while operating the camera in all possible modes we can think of), and if they are really free, we can take them. Caveat: they might be using stuff that's not listed in this log (as parts of that log are also hardcoded, so there's nothing to make sure what's in the log actually matches reality - they could have printed any numbers). On 60D, a region identified as free in this graph was later found to be actually used by Canon code (see the RscMgr PR, where we ran into trouble because of that). So, take this graph with a grain of salt.
For ML, we only need about 512K to load autoexec.bin (compare that to 128MB or even 64 for the 1000D). The other stuff (modules, work memory, whatever) are allocated dynamically, which is less troublesome, as the memory backend figures out which allocators to use, and lets you configure additional ones. But the initial code (autoexec.bin) has to be loaded statically, at some predefined address (unless you relocate it).
Of course, we can move everything to modules and end up with a very small static binary. It's a little more difficult than copy/paste though. Or you can try to compile as Thumb (good luck figuring it out).
Or, we can disable some features. You can even comment out features.h, CONFIG_RAW_* and fix up whatever gives compilation errors - that way, you'll get just the menu with a few debug items inside. It's best to do that anyway, and enable features one by one - otherwise you may end up with lots of possibly broken features (as it's really hard to test every single thing - I used to do that manually years ago), and if it's not something really widely used, you get a bug report after some months or years (even if the feature is not working at all).
Exercise: draw a similar memory map for DryOS (the first ~13 MB), based on the info from
this post. Find out where the minimal ML is loaded (draw the map before and after). Find out the memory pool used by AllocateMemory. Find out where it's initialized (hint: check QEMU source). Patch it.
After finishing this, you will have both the Hello World working and a very good understanding of how the memory is organized.
