new branch - CHDK : Elf Edition - Developers wanted - page 28 - General Discussion and Assistance

msl

1280
A720 IS, SX220 HS 1.01a

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #270 on: 29 / April / 2012, 05:47:51 »

Advertisements

Quote from: reyalp on 28 / April / 2012, 22:20:34

I wouldn't want this in core CHDK code, but a lua script ...

Quote from: stefantalpalaru on 28 / April / 2012, 18:41:49

Please provide a way to convert CCHDK.CFG settings to CCHDK2.CFG . If an automated in-camera conversion is too hard, an external tool will do. Thanks.

Here is a script (multilingual German/English) for saving/writing configuration data: http://trac.assembla.com/chdkde/browser/trunk/CHDK/SCRIPTS/USER/conf_rw.lua

This script was designed for the non module version. You can rewrite the script. Or you convert the IDs in the saved file.

Here are the IDs which are stored with the script:

old CHDKversion: http://trac.assembla.com/chdk/browser/branches/release-1_0/core/conf.c#L156
Module CHDK version: http://trac.assembla.com/chdk/browser/trunk/core/conf.c#L129

msl

Logged

CHDK-DE: CHDK-DE links

stefantalpalaru

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #271 on: 04 / May / 2012, 09:57:00 »

Quote from: reyalp on 28 / April / 2012, 22:20:34

Is resetting your settings once for a major release really a big deal ?

The strongest point of CHDK is its high configurability. I probably changed just 10% of the 200+ options during the time I've been using it but having to do it all from scratch is still a big deal.

msl, thanks for the script. It works without modifications for the core options. I don't see how it should be modified to set module options. conf_setValue() seems decoupled from config_restore().

Logged

srsa_4c

4451

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #272 on: 03 / January / 2014, 11:42:06 »

People who try to compile custom modules with newer gcc may encounter an error message similar to

Code: [Select]

In file .o/mymodule.elf:
elf2flt unknown segment 1 for name: 'some_function_name'
make[1]: *** [mymodule.flt] Error 6

In my case the trouble was caused by gcc's
-freorder-functions
option which is enabled with higher levels of optimization.
This makes gcc group functions according to their usage frequency, and can result in additional code sections named
.text.unlikely .text.hot
which elf2flt can't handle. Note that the following check in tools/elf2flt/elfflt.c is true for every section name starting with ".text":
(strncmp(name, ".text", 5) == 0)
Fixing this won't solve the above issue though.

Adding
-fno-reorder-functions
to CFLAGS in modules/Makefile appears to solve the issue.

Logged

philmoz

3445

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #273 on: 03 / January / 2014, 16:59:23 »

Quote from: srsa_4c on 03 / January / 2014, 11:42:06

People who try to compile custom modules with newer gcc may encounter an error message similar to

Code: [Select]
In file .o/mymodule.elf: elf2flt unknown segment 1 for name: 'some_function_name' make[1]: *** [mymodule.flt] Error 6In my case the trouble was caused by gcc's
-freorder-functions
option which is enabled with higher levels of optimization.
This makes gcc group functions according to their usage frequency, and can result in additional code sections named
.text.unlikely .text.hot
which elf2flt can't handle. Note that the following check in tools/elf2flt/elfflt.c is true for every section name starting with ".text":
(strncmp(name, ".text", 5) == 0)
Fixing this won't solve the above issue though.

Adding
-fno-reorder-functions
to CFLAGS in modules/Makefile appears to solve the issue.

What version of GCC are you seeing this in?

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)
g7x2 (1.01a, 1.01b, 1.10b)

srsa_4c

4451

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #274 on: 03 / January / 2014, 18:49:32 »

Quote from: philmoz on 03 / January / 2014, 16:59:23

What version of GCC are you seeing this in?

I'm currently using a self-compiled gcc 4.6.4 toolchain (linux, 32bit). The issue does not happen on gcc 4.4.3, and it definitely didn't happen on the 4.5.1 or 4.5.3 toolchain I was using earlier. The module I'm experimenting with uses http://code.google.com/p/miniz . I have attached a few dumps (I have enabled/added some debugging code in elfflt.c and the makefile).

gccissue.7z (233.59 kB - downloaded 11 times.)

Logged

philmoz

3445

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #275 on: 03 / January / 2014, 19:16:09 »

Quote from: srsa_4c on 03 / January / 2014, 18:49:32

Quote from: philmoz on 03 / January / 2014, 16:59:23
What version of GCC are you seeing this in?
I'm currently using a self-compiled gcc 4.6.4 toolchain (linux, 32bit). The issue does not happen on gcc 4.4.3, and it definitely didn't happen on the 4.5.1 or 4.5.3 toolchain I was using earlier. The module I'm experimenting with uses http://code.google.com/p/miniz . I have attached a few dumps (I have enabled/added some debugging code in elfflt.c and the makefile).

Haven't come across this with 4.6.1 or 4.6.2; but if could be related to the complexity of the code.
Can you post the module source?

Also you can get the extra text segments output to the *.elf.dump files by adding them to the makefile rule - e.g.
$(OBJDUMP) -j .text -j .text.unlikely -j .text.hot -j .rodata.str1.1 -j .data -j .bss -z -d -r -f -h .o/$*.elf >.o/$*.elf.dump

Phil.

Logged

srsa_4c

4451

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #276 on: 03 / January / 2014, 20:22:03 »

Quote from: philmoz on 03 / January / 2014, 19:16:09

Haven't come across this with 4.6.1 or 4.6.2; but if could be related to the complexity of the code.
Can you post the module source?

Attached. Not incredibly useful ATM.

Quote

Also you can get the extra text segments output to the *.elf.dump files by adding them to the makefile rule - e.g.
$(OBJDUMP) -j .text -j .text.unlikely -j .text.hot -j .rodata.str1.1 -j .data -j .bss -z -d -r -f -h .o/$*.elf >.o/$*.elf.dump

Thx.

ziptest_140104wip.7z (44.89 kB - downloaded 12 times.)

Logged

philmoz

3445

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #277 on: 04 / January / 2014, 02:00:25 »

Quote from: srsa_4c on 03 / January / 2014, 20:22:03

Quote from: philmoz on 03 / January / 2014, 19:16:09
Haven't come across this with 4.6.1 or 4.6.2; but if could be related to the complexity of the code.
Can you post the module source?
Attached. Not incredibly useful ATM.

Quote
Also you can get the extra text segments output to the *.elf.dump files by adding them to the makefile rule - e.g.
$(OBJDUMP) -j .text -j .text.unlikely -j .text.hot -j .rodata.str1.1 -j .data -j .bss -z -d -r -f -h .o/$*.elf >.o/$*.elf.dump
Thx.

GCC 4.6.2 has the same problem as 4.6.4.

Adding -fno-reorder-functions to the modules/Makefile seems the best option at this stage, fixing the elf2flt.c code would take a while.
From what I can see 4.6.2 generates smaller code with -fno-reorder-functions so it's not a very good optimisation.

Phil.

Logged

waterwingz

12132

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #278 on: 18 / October / 2014, 11:48:13 »

This recent thread got me thinking about FLT modules again : New Mandelbrot generator released

Rereading this thread, I see that the original vision for loadable modules was somewhat larger that what was finally implemented (for a whole bunch of good reasons). So I can't help but wonder if we should create a set of "hooks" that would allow CHDK to accept a platform independent user created module that could be distributed independent of the CHDK build. By this I mean something like a script file except compiled to ARM code and much more tightly integrated into CHDK.

Some ideas :

create a new "empty" task in boot.c that does nothing until given a pointer to code in the user created module
add a hook of some sort to the menu system that recognizes a loaded user module and displays its menu structs
give the user module the ability to be loaded at startup and run in the background (outside of <ALT> mode)
allocate a generic block of memory to be available to the user module for persistent data. Save and restore it just like any other config data

Does this give us much over just using scripts or just creating a custom build by editing the core CHDK code? I think so. It allows creation of some nice custom highly integrated features that might only be of interest to a small group that doesn't have to go into the trunk and be maintained there.

Logged

Ported : A1200 SD940 G10 Powershot N G16

srsa_4c

4451

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #279 on: 18 / October / 2014, 12:42:05 »

Quote from: waterwingz on 18 / October / 2014, 11:48:13

So I can't help but wonder if we should create a set of "hooks" that would allow CHDK to accept a platform independent user created module that could be distributed independent of the CHDK build.

I had a somewhat related idea a while ago: http://chdk.setepontos.com/index.php?topic=8151.msg100537#msg100537

Quote

Some ideas :
(...)
allocate a generic block of memory to be available to the user module for persistent data. Save and restore it just like any other config data

I also had an idea called "clipboard" (module loaded on demand, maintaining data as long as needed), although my idea did not include saving the data as config data. Since I couldn't come up with a sensible use case, I abandoned the idea.

Quote

Does this give us much over just using scripts or just creating a custom build by editing the core CHDK code? I think so. It allows creation of some nice custom highly integrated features that might only be of interest to a small group that doesn't have to go into the trunk and be maintained there.

Logged