romlogs vs modules

reyalp

12532

« on: 04 / March / 2013, 00:21:32 »

Advertisements

Right now, romlogs are much less useful for debugging code in modules, since we don't know where they were loaded.

Some ideas:

1) Add an option to log module loads + address to a file. Could potentially hit filehandle issues, would not help with random romlogs form users who didn't have the option on. Shouldn't be on by default because of performance and filehandle issues

2) Log camera log. Would get lost if the module was loaded a long time before the crash, requires finding _LogPrintf for all the cameras. Leaves CHDK messages in camera flash.

3) Hook exception handlers and log module info at crash time. Logging to file could be problematic depending what crashed. Camera log might work. Hooking exception handlers on all cameras could be a lot of work (but could be useful for other things)

4) Option to build modules into binary at a fixed address. Like logging loads to file, this would not be useful for regular autobuild user bug reports.

Logged

Don't forget what the H stands for.

philmoz

3154

Re: romlogs vs modules

« Reply #1 on: 04 / March / 2013, 02:57:31 »

Quote from: reyalp on 04 / March / 2013, 00:21:32

Right now, romlogs are much less useful for debugging code in modules, since we don't know where they were loaded.

Some ideas:

1) Add an option to log module loads + address to a file. Could potentially hit filehandle issues, would not help with random romlogs form users who didn't have the option on. Shouldn't be on by default because of performance and filehandle issues

2) Log camera log. Would get lost if the module was loaded a long time before the crash, requires finding _LogPrintf for all the cameras. Leaves CHDK messages in camera flash.

3) Hook exception handlers and log module info at crash time. Logging to file could be problematic depending what crashed. Camera log might work. Hooking exception handlers on all cameras could be a lot of work (but could be useful for other things)

4) Option to build modules into binary at a fixed address. Like logging loads to file, this would not be useful for regular autobuild user bug reports.

I'm working on some changes for the module handling that includes:
- logging load and unload of modules to a file (with load address). Menu options to enable/disable and delete the log file.
- make modules auto-loading when first used, and unloaded when not needed (controlled by the module itself). This replaces code like:
if (module_load())
libmodule->somefunction();
with:
libmodule->somefunction();

The second change means that the module could be compiled into the core CHDK and only the module 'library' pointer needs to be modified. The rest of the code will work without change. This would still need some changes to the makefiles to support compiling the module into the core.

Note: building a module into the core CHDK may not help debugging a problem, if the problem arises from the load/unload timing - which I've hit quite a lot of recently

Phil.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)

reyalp

12532

Re: romlogs vs modules

« Reply #2 on: 27 / April / 2013, 17:57:39 »

A note, if you have original ELF and the start address, you should be able to get the dis-assembly at the correct location by using

arm-elf-objdump -d -r -x --adjust-vma=<start address> mod.elf > mod.dumpobj

Logged

Don't forget what the H stands for.