Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP]: Investigation to get PX4 compile on ARM GCC 9 #13448

Closed
wants to merge 1 commit into from

Conversation

dagar
Copy link
Member

@dagar dagar commented Nov 12, 2019

Describe problem solved by this pull request
We are using GCC 9 for the posix build for quite some time and ARM released newer versions for the ARM GCC for a long time already as well. But there are certain corners that prevent us from using ARM GCC 9 for our daily work and release builds.

Describe your solution
I started investigating and listing the problems that make it not build on ARM GCC 9.2.

  • NuttX only ccompiles with this fix: sched/wdog: fix signature for wdentry_t NuttX#52
    I rebased it on our latest NuttX version here: https://github.com/MaEtUgR/NuttX/tree/arm-gcc-9 and included the submodule update for testing.
    Solved with the NuttX pr.
  • The task_main_trampoline/main_loop_helper void to int return value casting fail. They can be declared static int in the header and int in the declaration
    Solved with this pr
  • UAVCAN produces some deprecated warnings because of the BitMask copy constructor
    Unsolved, I just removed the library
  • timing tests use abs on uint64_t timestamps which is not supported by the math library we use. We can either support uint64_t or switch to int (done in this draft) or look at why abs is necessary at all.
    Unsolved, this is not a proper fix
  • Some unit test that is still in the sitl tests uses fishy array assignments and the compiler complained it can't check the boundaries.
    Unsolved, I added a compiler flag to ignore it which is not a solution.
  • In our flashparams implementation a casted 4 byte pointer iterates over a packed struct to overwrite it with 0xFFs which the compiler doesn't like.
    Unsolved, I added a compiler flag to ignore it which is not a solution.
  • All binary output including io overflows end of region flash for every single section. This is probably due to warning: creating a segment to contain the file and program headers outside of any MEMORY region. Maybe the additional "default" section has to be disabled or placed in the linker file (thanks for input by @dinomani).
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld.gold: warning: creating a segment to contain the file and program headers outside of any MEMORY region
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld.gold: error: section .text overflows end of region flash
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld.gold: error: section .init_section overflows end of region flash
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld.gold: error: address 0x82e9bd4 is not within region flash
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld.gold: error: section __param overflows end of region flash
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld.gold: error: section .ARM.extab overflows end of region flash
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld.gold: error: section .ARM.exidx overflows end of region flash
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld.gold: error: section .data overflows end of region flash

Additional context
#12814

FYI @dagar @bkueng @julianoes

@dagar
Copy link
Member Author

dagar commented Nov 12, 2019

Here's another oddity. Runtime memory differences.

nsh> free
              total       used       free    largest
Umem:       231024     173872      57152      51328   <-- master
Umem:       226992     175024      51968      48784   <-- PR

@stale
Copy link

stale bot commented Feb 10, 2020

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

@TSC21
Copy link
Member

TSC21 commented Apr 4, 2020

This seems to be superseded by #14159. Closing

@TSC21 TSC21 closed this Apr 4, 2020
@julianoes julianoes deleted the pr-arm-gcc-9 branch April 5, 2020 07:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants