fix(bw): build fails for some radios when using GCC 13 or later

[philmoz]

The extra buffer added in #5716 plus the additional RAM used by #5717 overflows for some radios.

This PR reduces the 'bin_allocator' memory used to fit.

[philmoz]

Hmm. The nightly build worked; but my local builds fail for GX12 - not enough room in the CCM region.

[pfeerick]

Yeah, the merged commit immediately after those two PRs also compiled successfully, so maybe it is a compiler difference and/or different build flags.

…

On Mon, Dec 23, 2024 at 2:08 PM philmoz ***@***.***> wrote: Hmm. The nightly build worked; but my local builds fail for GX12 - not enough room in the CCM region. — Reply to this email directly, view it on GitHub <#5731 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ66KKLYVLGTFS375ZVY2T2G6EELAVCNFSM6AAAAABUBIROLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJYHA3DQNRTGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[philmoz]

GCC13 & 14 blow out the BSS area by 320 bytes ????

[pfeerick]

Did you have a look at the firmware-size report from the last main build to see how it compares to your build with the exact same flags? (hint: it's part of the tests done for each radio so search that for "Built target firmware-size")... as if you are using the same build flags with a clean build, I don't think there is any other real explanation other than some build environment variation...

…

On Mon, Dec 23, 2024 at 3:01 PM philmoz ***@***.***> wrote: GCC13 & 14 blow out the BSS area by 320 bytes ???? — Reply to this email directly, view it on GitHub <#5731 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ66KK226ADJZU5OLXQC7T2G6KJJAVCNFSM6AAAAABUBIROLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJYHEYTENZYGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[philmoz]

If I build with GCC 10 it works; but 13 & 14 fail.

[pfeerick]

Ouch... clearly something is being treated differently in later GCC versions. Just bumped #5263 as it will be bringing the GCC version used up to 13... and surprise, surprise... guess which radio it failed on (first?)... So clearly this will be needed... but would be nice to know what is going on with that extra usage! Wanna go with this for now, and I'll rebase 5263 again to see if all the radios will pass?

…

On Mon, Dec 23, 2024 at 3:13 PM philmoz ***@***.***> wrote: If I build with GCC 10 it works; but 13 & 14 fail. — Reply to this email directly, view it on GitHub <#5731 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ66KKPAJ6KIFVSWUOBEE32G6LWBAVCNFSM6AAAAABUBIROLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJYHEZDENZWGM> . You are receiving this because you commented.Message ID: ***@***.***>

[philmoz]

GCC 13 also fails for me on XLiteS and X9D+2019 - flash size too big.
Extra code added in recent PR's.

[pfeerick]

That nearly justifies my recent thoughts that we should consider taking main to RC for 2.11, then we can more immediately jump to H7 (and GCC 13) mayhem and chaos for 2.12. Can you rebase the lua53 branch again and see how it copes?

…

On Mon, Dec 23, 2024 at 3:27 PM philmoz ***@***.***> wrote: GCC 13 also fails for me on XLiteS and X9D+2019 - flash size too big. — Reply to this email directly, view it on GitHub <#5731 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ66KKLT6ODX3DFJPSD7NT2G6NLDAVCNFSM6AAAAABUBIROLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJYHEZTIOJRGI> . You are receiving this because you commented.Message ID: ***@***.***>

[gagarinlg]

2.11 should have H7, or we have to insert a 2.12

[gagarinlg]

And, I wanted to set a fixed GCC version a couple of months ago, to avoid this type of issues.
@philmoz maybe you can diff the .map files from different compiler versions and check where the difference comes from

[philmoz]

With GCC 13 there is an additional 312 byte buffer called '__sf' and a bunch of functions stating with the same string.
No idea what this is for.

[3djc]

And, I wanted to set a fixed GCC version a couple of months ago, to avoid this type of issues.

Thats what we have been doing for Otx for similar reasons

[philmoz]

Should now work with GCC 13 or 14.

I've added a custom __assert_func which should fix the FLASH size issue with XLites and X9D+2019.

GX12 still needs the reduced memory in the bin_allocator (due to the inclusion of the __sf array).

[philmoz]

Moved the changes to the toolchain_update PR #5263 since it is GCC version issues.

[pfeerick]

And, I wanted to set a fixed GCC version a couple of months ago, to avoid this type of issues.

Thats what we have been doing for Otx for similar reasons

Exactly... which is why only documented and formally "supported" compiler version for EdgeTX has been the one from https://developer.arm.com/-/media/Files/downloads/gnu-rm/10-2020q4. Hopefully this will be the only nasty remaining in the transition to GCC 13.x ... we'll find out soon!