This one is hard to fix - branch instructions in ARM code cannot go "too far" (they are limited to +/- 32MB around the address of the branch instruction). Normally, the compiler takes care of this (e.g. by using long jumps or inserting veneers - intermediate jumps), but here we are patching existing binary code in the firmware, to jump to our code instead.
I couldn't find an easy fix for this one; while a long jump can be implemented, it may require patching 2 instructions for one function. It's doable though, and other cameras will benefit from this (60D, which has the same problem in some experimental branches, and maybe some newer models too).
On 1300D I'm afraid we can't just use the workaround for 60D (where we load ML at a different address in order to be able to patch things), so a proper fix will be required in order to get some useful debug logs.
I'll try, but the solution is not straightforward.
Previously covered in replies #120 and #239.
Edit: confirmed the dm-spy-experiments branch is not working, even with minimal logging options (dm_spy_extra* commented out).
Need to use a long jump for patching DebugMsg. It started to work - to some extent - with this:
int err = patch_instruction(DebugMsg_addr, MEM(DebugMsg_addr), FAR_CALL_INSTR, "dm-spy: log all DebugMsg calls");
err |= patch_instruction(DebugMsg_addr + 4, MEM(DebugMsg_addr + 4), &my_DebugMsg, "dm-spy: log all DebugMsg calls");
The semaphore error appears to come from beep() - somebody's calling that before beep_init. Disabled beeps, it went further.
When trying to save the log, it fails with:
[dm-spy] captured 128kB of messages
[NotifyBox] Pretty-printing... (128kB)
[ CtrlSrv:fe49c7fc ] (83:02) DlgShootOlc.c LOCAL_DIALOG_REFRESH
qemu: fatal: Trying to execute code outside RAM or ROM at 0x87274218
That was because I've patched two instructions from DebugMsg, to implement the long call, but when uninstalling the logging hook, I should have "unpatched" both instructions. Rookie mistake.
Now, the hard part - clean up the code and commit it 
Still need to find a general solution for patching arbitrary functions in Canon code (i.e. to implement long jump support in the patch manager).
The firmware is located at the end, and ends at 0xFFFFFFFF
What happens if you try to jump over 0xFFFFFFFF (relative), do the address wrap into 0xxxxxxx ram ? (or do we get an exception, possibly yes ?)
But if we dont get an exception - we could steal the first useable location in ram and make patch_instruction/gdb call this ram
function (using a single branch relative instruction). Then we could let this function analyze the lr and jump to the correct
location based on the lr value. This also requires that patch_instructions/gdb make a table of pc/lr's and where to jump to / jump back to
