1) I was following the "stubs tutorial"...
....
Do you write own, custom scripts that parse entire disassembly file and look for the occurrence of a label in line N and push command in line N+1 or are there some established scripts that help with stub searching?
Most of the time looking for strings is a good way to have a looks in the right direction (or code segment), usually can be done by searching inside decompiled files if using dissasemble.pl script or by looking for xrefs in IDA.
check-stubs.py can also be useful when porting
firmware update.
that Memory functions, but they are easy, still curious how did you identify that "create" function
Also using QEMU for
some tricks (.idc file of function called during emulation and code blocks copied from ROM to RAM), helped me a lot to have more functions marked inside the disassembly or to retrieve the RAM address instead of the ROM address for a specific stub.
IDA will replace and display calls to RAM version of functions automatically if code segments are loaded into the project; the exact function can be found inside the disassembly without using them, but having RAM address instead come in handy when we need to easly patch them.
2) I assume that stub searching is easier if you have an older camera with stubs identified: I assume that large % the low-level API stays unchanged from version to version, and one could look e.g for a similar sequence of commands or sth like that. Am I making sense here?
Definitely useful to have a reference camera which use same DIGIC generation, it makes looking for stubs much easier because much of the code is shared and usually unchanged between them.
But because most of the code is shared or evolved during years, also comparing disassembly from older cameras can reveal the same or similar code structure to compare with: If I remember correctly I also double checked using a disassembly from 50D (Digic IV) when working on 77D and others (Digic VII).
Unfortunately comparing too much older cameras with a more recent one, ie. 5DC with 50D or even 40D (only 1 generation newer) won't help much... while disassembling 5DC, a lot of stubs looks like 50% smaller or completely different from newer cameras... also error messages (ie. looking for error code pattern from "finding stubs") looks like are handled in a different way, a lot of strings missing... making things harder...
3) the stubs.S files for other cameras have around 50-100 stubs that are identified. I am surprised that this number is actually so low. There way more functions mentioned in the string files for the ROM i downloaded.
Some older camera have unused stubs which were commented because they were replaced by standard library instead of canon's version, or because some stubs required by some specific feature are not necessary anymore due to some refactor of ML code.
Obviously having lesser stubs to find makes porting much easier for us.
The ML code is not able to operate merely on these 50-100 functions right? How is that so? does this: "THUMB_FN(0xE04E706A, call) /* many functions called by name (lv_start, lv_stop etc) */" open the door to call everything else?
A much better answer to last question need to be provided by main devs or someone which saw how ML code evolved during years.
