gcc10 vs vxworks - page 2 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 [2]   Go Down

gcc10 vs vxworks

  • 18 Replies
  • 4851 Views
*

Online philmoz

  • *****
  • 3450
    • Photos
Re: gcc10 vs vxworks
« Reply #10 on: 22 / March / 2021, 21:45:26 »
Advertisements
Quote from: reyalp on 22 / March / 2021, 21:10:20
Definitely getting cache coherency vibes.


That would explain the weirdness - seems to be related to the LR state rather than memcpy/memset.


Not sure why push {r4,lr} / pop {r4, lr} behaves differently to push {lr} / pop {lr}


Quick fix would be to add '-fno-tree-loop-distribute-patterns' to CFLAGS (probably only for VxWorks and GCC 10) to make GCC 10 behave like 9.


Fixing the boot() code in all the affected ports would be more work and hard to test.

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)
*

Offline reyalp

  • ******
  • 14126
Re: gcc10 vs vxworks
« Reply #11 on: 22 / March / 2021, 22:38:14 »
Quote from: philmoz on 22 / March / 2021, 21:45:26
That would explain the weirdness - seems to be related to the LR state rather than memcpy/memset.
It definitely feels like something like that, but I don't see an obvious how. loader/main.c disables and flushes (and the Canon OS does the same before loading diskboot, IIRC) so the enable should be OK. Disabling without cleaning and draining write buffer seems sketchy.

What I wanted to find by blinking was whether the problem happens in memcpy, or somewhere later. I'll try that with inline code.

Quote
Fixing the boot() code in all the affected ports would be more work and hard to test.
Yeah, I'm definitely not inclined to change the ports without understanding the root cause.

Quote
Quick fix would be to add '-fno-tree-loop-distribute-patterns' to CFLAGS (probably only for VxWorks and GCC 10) to make GCC 10 behave like 9.
I think this is worthwhile, but I'd be inclined to disable it for platform files (maybe files compiled as ARM). Some early dryos cams like a720 have similar loops, and the optimization should be safe (and save tiny bit of size) outside of boot code.

edit:
With gcc10
putting x_blink(10) after the cache disable (second bit of inline asm) blinks indefinitely.

Adding dcache_clean_all() before the cache disable blinks 10 times and boots normally.
Drain write buffer alone doesn't.

Idea: The LR of stuff called when the cache is enabled can still be in flight after cache is disabled, and overwrites some later LR pushed onto the stack. Whether the earlier boot code pushes one word or two affects what it ends up clobbering. Thing I don't like about this is the memset touches a lot a lot of memory, which seems like it should evict anything pushed at the start of the call.
« Last Edit: 22 / March / 2021, 23:25:29 by reyalp »
Logged
Don't forget what the H stands for.
*

Online philmoz

  • *****
  • 3450
    • Photos
Re: gcc10 vs vxworks
« Reply #12 on: 22 / March / 2021, 23:01:14 »
Quote from: reyalp on 22 / March / 2021, 22:38:14
What I wanted to find by blinking was whether the problem happens in memcpy, or somewhere later. I'll try that with inline code.


I suspect it happens later and is related to the value in LR - it appears that h_usrKernelInit 'returns' to this location by popping the value into PC.


Adding the code below to platform/makefile_sub.inc limits the change to just the files in platfom/cam/sub for VxWorks cams using GCC10.
I'll commit this unless you have any other suggestions.
Code: [Select]

# Disable GCC 10 optimisation for VxWorks that prevents build from booting on some cameras.
ifeq ($(PLATFORMOS),vxworks)
    ifeq ($(GCC_VERSION_MAJOR),10)
        CFLAGS+=-fno-tree-loop-distribute-patterns
    endif
endif
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)
*

Offline reyalp

  • ******
  • 14126
Re: gcc10 vs vxworks
« Reply #13 on: 22 / March / 2021, 23:28:48 »
Quote from: philmoz on 22 / March / 2021, 23:01:14
I'll commit this unless you have any other suggestions.
Code: [Select]

# Disable GCC 10 optimisation for VxWorks that prevents build from booting on some cameras.
ifeq ($(PLATFORMOS),vxworks)
    ifeq ($(GCC_VERSION_MAJOR),10)
        CFLAGS+=-fno-tree-loop-distribute-patterns
    endif
endif
I'd suggest enabling it for all OSes, since the underlying problem is not vxworks specific. Some dryos cams have very similar loops in boot.c.
Logged
Don't forget what the H stands for.
*

Online philmoz

  • *****
  • 3450
    • Photos
Re: gcc10 vs vxworks
« Reply #14 on: 23 / March / 2021, 01:09:35 »
I've checked in the fix to disable the optimisation in GCC 10.


@whim - can you try version 5795 on your affected cameras with GCC 10.

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)
*

Offline whim

  • ******
  • 2046
  • A495/590/620/630 ixus70/115/220/230/300/870 S95
Re: gcc10 vs vxworks
« Reply #15 on: 23 / March / 2021, 03:54:04 »
@philmoz

Confirmed running on ixus70-101b.
Compiled under 64 bit linux, gcc 10.2, r5797.

Will test more later today (real life ...)

thanks !

wim
Logged
*

Offline Caefix

  • *****
  • 948
  • Sorry, busy deleting test shots...
Re: gcc10 vs vxworks
« Reply #16 on: 23 / March / 2021, 12:26:11 »
Ixusizoom_sd30 & Ix900 are booting fine now.... 8)
Quote from: reyalp on 22 / March / 2021, 23:28:48
I'd suggest enabling it for all OSes, since the underlying problem is not vxworks specific. Some dryos cams have very similar loops in boot.c.
Which other cams could/should be compared?
Logged
All lifetime is a loan from eternity.
*

Offline reyalp

  • ******
  • 14126
Re: gcc10 vs vxworks
« Reply #17 on: 23 / March / 2021, 12:40:54 »
Quote from: Caefix on 23 / March / 2021, 12:26:11
Ixusizoom_sd30 & Ix900 are booting fine now.... 8)
Quote from: reyalp on 22 / March / 2021, 23:28:48
I'd suggest enabling it for all OSes, since the underlying problem is not vxworks specific. Some dryos cams have very similar loops in boot.c.
Which other cams could/should be compared?
Many early dryos cams like a720, ixus80 have a similar loop in boot.c. But they don't disable cache after the loop, so they might not have been affected.

I don't think there's a need to test a bunch of cams for this, the change philmoz made will prevent this specific thing from happening. If there are other gcc10 problems, they will be something else...
Logged
Don't forget what the H stands for.
*

Offline whim

  • ******
  • 2046
  • A495/590/620/630 ixus70/115/220/230/300/870 S95
Re: gcc10 vs vxworks
« Reply #18 on: 23 / March / 2021, 17:51:56 »

@philmoz

Hi,

As promised, some more tests, this time on Windows.
Like in previous post used trunk r5795, compiled for ixus70_sd1000-101b
1. Baseline OPT_ setting for these tests: everything OFF, except PTP and WARNINGS
2. as in baseline, but with FIRMWARE_PC24_CALL turned on
3. as in baseline, but with DEBUGGING turned on

Result: All 3 compiled and ran fine.

I then looked a little further into binaries created by gcc 493/541/831/931/1021
compiled with/without the '-fno-tree-loop-distribute-patterns', and sizes were
equal, except in those from gcc 10.(option commented out = 24 bytes smaller)

Reading the docs (gcc.pdf) for each compiler about '-ftree-loop-distribute-patterns':

1. gcc 493 : no mention of the option (when used silently ignores it)
2. gcc 5, 8 and 9 docs say it is automatically activated for optimization level -O3
3. gcc 10 docs are ambivalent, the required optimization level is mentioned once as
       -O2, and later on as -O3 ...

If they forgot to change the second occurrence, that would explain the behaviour
we see, because 'our' opt.level is -Os, which, according to the same doc
'enables all -O2 optimizations except those that often increase code size:'
followed by 6 options not including ours.
At least now we can easily test against future gcc 10.x versions, if it is a bugin GCC they'll surely find and fix it, there must be loads of embedded arm running with size optimization ;)

BTW, other vxworks cams now work too on r5797 - A620 , A630(A620 not sure if it was affected)

wim
Logged
Pages: 1 [2]   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal