gcc. windows dev kit, binary size & the whole ordeal (discussion here)

Hacki

358
SX100

Re: gcc. windows dev kit, binary size & the whole ordeal (discussion here)

« Reply #20 on: 27 / October / 2008, 12:05:51 »

Advertisements

I just ran batch-zip-complete and uploaded it to mighty-hoernsche.de so you guys can test if everything works as it should with the new compiler:

Index of /chdk/dev/new_gcc

I doubt there will be any problem, but a little testing doesnt hurt.

Logged

reyalp

12109

Re: gcc. windows dev kit, binary size & the whole ordeal (discussion here)

« Reply #21 on: 28 / October / 2008, 03:07:54 »

ARM Information Center

I'd say .ltorg should be an acceptable solution, it's already used in quite a few places.

Logged

Don't forget what the H stands for.

whim

2013
A495/590/620/630 ixus70/115/220/230/300/870 S95

Re: gcc. windows dev kit, binary size & the whole ordeal (discussion here)

« Reply #22 on: 28 / October / 2008, 05:39:59 »

@hacki

new builds run fine here on my cams; adding ".ltorg\n" to boot.c in both SX100 builds for trunk 545
seems to be compatible with the old toolchain as well (compiles without warnings)

BTW how did you arrive at proper location for the ".ltorg\n" ? I understand (i think

) that it should
always be last in a function, but how did you determine in which function to add it ?

wim

« Last Edit: 28 / October / 2008, 05:43:01 by whim »

Logged

*Wikia FAQ *GCC Compiler Shell for Windows

Hacki

358
SX100

Re: gcc. windows dev kit, binary size & the whole ordeal (discussion here)

« Reply #23 on: 28 / October / 2008, 05:49:57 »

Quote

/tmp/ccsXyUYU.s:201: Error: invalid literal constant: pool needs to be closer

So, i guess it could have worked if i put it in line 202, but i figured it looks cleaner at the end of the function.. somehow..

-> No idea of ASM, was more like 'try and error programming'

Logged

reyalp

12109

Re: gcc. windows dev kit, binary size & the whole ordeal (discussion here)

« Reply #24 on: 28 / October / 2008, 23:31:01 »

Background:
Arm instructions are fixed length 32 bits. Because of this, a single arm instruction cannot include an arbitrary 32 bit constant. Instead, it can only use small constants, or small constants that are shifted. Unlike, say x86 you can't just do

Code: [Select]

mov R0, 1234567890because there's no way to encode both the mov and the number in a single instruction.

What arm does instead is put the constants in memory, and load them with a regular load instruction. But wait: load needs an address... which is also a 32 bit number!
The solution arm uses is:
1) use the PC register (program counter, i.e. the current instruction) and a small constant (encoded in the load instruction) as the address.
2) store the constants close to the code that uses them.

With lots of inline asm, it appears that you need to give GCC a hint as to where it can put the pool of constants.

edit:
committed fix -> moved .ltorg.

« Last Edit: 30 / October / 2008, 01:58:03 by reyalp »

Logged

Don't forget what the H stands for.

reyalp

12109

Re: gcc. windows dev kit, binary size & the whole ordeal (discussion here)

« Reply #25 on: 15 / November / 2008, 18:33:07 »

Some more GCC related stuff:

gcc3 supports -march=armv5te which is the architecture of the arm946e-s chip used on CHDK cams. This allows us to use instructions such as strd and probably results in smaller/faster code.

However, using gcc 4 built according to User:Geekmug/Compiling CHDK under Windows - CHDK Wiki both -mcpu=arm946e-s and -march=armv5te fail to link due to some conflict between hard and soft float. -mtune works, but does not allow the use of armv5te specific instructions.

I'm a bit lost when it comes to configuring gcc, so I'm not sure what the correct way to deal with this is.

Logged

Don't forget what the H stands for.

reyalp

12109

Re: gcc. windows dev kit, binary size & the whole ordeal (discussion here)

« Reply #26 on: 16 / November / 2008, 00:50:39 »

small update: if you configure gcc with --with-arch=armv5te (rather than --with-cpu=arm9) it appears to avoid the hard/soft float problem, and still allow you to use the armv5te instructions.

I don't really understand why this is the case, but all known CHDK cams use this arch, so it should be OK. We could probably use with-cpu=arm946e-s (didn't try it, I'm tired of compiling gcc) but targeting armv5te should be good enough.

FWIW the error I get with arm9 is a bunch of things like

Quote

.../arm-elf/bin/ld: ERROR: /home/reed/chdk/arm-elf/lib/gcc/arm-elf/4.3.2/thumb/interwork/libgcc.a(_fixunssfsi.o) uses hardware FP, whereas main.elf uses software FP

edit:
except that my camera crashes right after boot with this build

« Last Edit: 16 / November / 2008, 02:14:29 by reyalp »

Logged

Don't forget what the H stands for.

whim

2013
A495/590/620/630 ixus70/115/220/230/300/870 S95

Re: gcc. windows dev kit, binary size & the whole ordeal (discussion here)

« Reply #27 on: 17 / November / 2008, 10:26:23 »

@reyalp

Re: CFLAGS+=-mcpu=arm946e-s

FYI: i accidentally discovered that GCC 4.3.2 ('normal Geekmug setup', --with-cpu=arm9)
while barfing on trunk 575,does properly (well... with syntax warnings) compile trunk 544.
meaning, the linker produces none of the soft/hard float warnings ...
i then worked my way forwards in the builds, and found that 568 (= last before ixus 80 additions)
still builds OK with 'arm946' flag, while 570 behaves (or rather un-behaves) like 575 ...
the '568 / mcpu=arm946e-s binaries run fine on my A620

another info tidbit: on another machine, where i recently installed cygwin a la Geekmug,
i used a more recent binutils (2.19) I checked '568 on that system, building was identical, that is,
no errors, but the resulting binaries brick my A620 (battery removal required). I then checked '544
and it also bricked the cam ...

my conclusions so far:

1) don't use binutils 2.19

2) the hard/soft float linker error is most likely caused by new code and/or modifications
after trunk 568 and with/before trunk 570.

not sure if this is any help to you, but i thought you'd like to know ...

wim

edit: checked 569 too --> behaves identical to 570, so the 'offending' code must have been introduced @ 569
edit2: same behaviour on ixus70_sd1000 as on A620

« Last Edit: 17 / November / 2008, 12:42:57 by whim »

Logged

*Wikia FAQ *GCC Compiler Shell for Windows

chr

138
IXUS 82 IS

Re: gcc. windows dev kit, binary size & the whole ordeal (discussion here)

« Reply #28 on: 17 / November / 2008, 16:21:58 »

Quote from: whim on 17 / November / 2008, 10:26:23

1) don't use binutils 2.19

Agreed.

I just downgraded to 2.18 and the binaries now boot on my sd1100. It works until I switch to rec mode: crash.
With my cute ROMLOG feature I found out, it crashed with "instruction fetch abort" in get_batt_average()

I disabled "show batt" while in play mode, rec mode works, no crash. Not tested much if something else crashes.

Recompiled w/o thumb mode: "show batt" works !

Quote

2) the hard/soft float linker error is most likely caused by new code and/or modifications
after trunk 568 and with/before trunk 570.

Disagreed.

I think, gcc selects the wrong FP format. It must match libgcc and chdk.

configure gcc --with-cpu=arm9 makes libgcc FPA float format
but compiling chdk with -mcpu=arm946e-s chdk is VFP -> link errors.

Meanwhile I tried both, VFP and FPA. That compiles and links w/o errors, but cam crashes in (or around) get_batt_average() if using thumb code.

Mh, downgrade gcc, too

Logged

whim

2013
A495/590/620/630 ixus70/115/220/230/300/870 S95

Re: gcc. windows dev kit, binary size & the whole ordeal (discussion here)

« Reply #29 on: 17 / November / 2008, 16:32:14 »

hi chr !

Quote

Disagreed.

I think, gcc selects the wrong FP format. It must match libgcc and chdk.

... but why (with the same setup and switches) would gcc select the right setup on trunk 568 ,
while producing the FP related errors on 569+ ?

wim

Logged

*Wikia FAQ *GCC Compiler Shell for Windows