1.5 development planning thread

We could reduce core size by more than 1kB if we could find a way to exclude unneeded language strings (such as GPS strings on GPS-less cams).

edit (no need to bump the thread, just a note to myself):

A special module could be created to make on-the-fly 'cache hack' experiments possible (such as: modify constant in ROM, logging access to arbitrary routines, etc.), with Lua scripting interface. An HP timer could be used to re-apply the hacks (this method is still not 100% reliable, but should be good enough for research purposes).

I'm putting this here only because I'm not sure if the subject deserves an own thread.

Newer DryOS firmwares have a function that can scan a memory heap for corruption (of course the chance of detecting something is not very high as only areas surrounding the malloc'd blocks are checked). The function that checks the malloc heap can be identified by the "refusing to print malloc information" string. The lower level function can be used for other heaps, such as the system heap. I have written identification for the higher level function (malloc), but not yet for the lower level one.

Now, the question: if having something like this in CHDK is considered useful, what kind of interface should it have? The code I have is only called when displaying the CHDK memory information dialog. But I figured it might be useful to make this information available to scripts. But, how?My other concern is that we have no equivalent for suba (the allocator we're using).Note: this fw function is not something that should be continuously called because lower level semaphores likely prevent the allocator from working for the time of scan.

Now, the question: if having something like this in CHDK is considered useful, what kind of interface should it have? The code I have is only called when displaying the CHDK memory information dialog. But I figured it might be useful to make this information available to scripts. But, how?My other concern is that we have no equivalent for suba (the allocator we're using).

This definitely seems like it would be useful for debugging. Even if it's restricted to the canon malloc heap, that could catch a lot of cases. Many ports have enough canon heap to use it for CHDK.

Are there other canon heaps we would want to check? UI memory? Anything else?

For the now, we could have a script function like check_heap_corruption

If we add more heaps later we could use names like get_meminfo, or raw pointers (or allow both).

Quote

Note: this fw function is not something that should be continuously called because lower level semaphores likely prevent the allocator from working for the time of scan.

Assuming it just blocks any allocations until it's done, a define to call it every Nth spytask or kbd_task iteration might be useful. Not on by default but as something you can turn on for test builds. I guess we should also check how long it keeps things locked for.

I have created an updated, generic version of the E32 fix patch.I'm not sure if this is something that should be in the official source, mainly because it comes with an 8 byte penalty even when not enabled (the 8 bytes are added due to a required stub, DisableISDriveError).

I have done some experiments and considered adding support for conditional stubs, something like this:CNHSTUB(DisableISDriveError, 0xffe19918, OPT_DISABLE_CAM_ERROR)where OPT_DISABLE_CAM_ERROR has the value of 0 or 1, depending on the same named define in buildconf.inc. This line would be emitted by the sigfinder.The current patch, however, only uses normal NHSTUBs.

Can someone explain the meaning of N and H in NHSTUB? N probably means 'named', but I have no clue about H...

I have created an updated, generic version of the E32 fix patch.I'm not sure if this is something that should be in the official source, mainly because it comes with an 8 byte penalty even when not enabled (the 8 bytes are added due to a required stub, DisableISDriveError).

I wouldn't worry about that, or about making the stub conditional. If it were a few hundred, maybe.

Quote

Can someone explain the meaning of N and H in NHSTUB? N probably means 'named', but I have no clue about H...

AFAIK H is for "hard". Before the philmoz "new" sigfinder, stubs_entry2.S wasn't parsed, finsig just generated weak NSTUB, and if they were wrong, you overrode them with NHSTUB. This had a size penalty, because the weak ones are still there.

I wouldn't worry about that, or about making the stub conditional. If it were a few hundred, maybe.

OK, in that case I'll check in this feature in a few days - it will make creating those "special" builds easier (there are not a lot of those requests, but one had to work on it each occasion).

Quote

AFAIK H is for "hard". Before the philmoz "new" sigfinder, stubs_entry2.S wasn't parsed, finsig just generated weak NSTUB, and if they were wrong, you overrode them with NHSTUB. This had a size penalty, because the weak ones are still there.

I see, thanks. It was confusing for me because NHSTUBs are weak references currently.

A related question: would it be a good idea to put NHSTUB(special_function, NULL_SUB) in stubs_entry.S when special_function is not found?For example, the previously mentioned (heap corruption check) function does not exist in a number of DryOS firmwares. I can't use a weak, empty function as a replacement because it may override the NHSTUB (I've experienced this while working on the e32 patch).I could of course put a #define in a number of platform_camera.h files, but I'd prefer to avoid that.