I'm building for aarch64 and hitting:
/usr/local/google/home/sleffler/camkes-aarch64-rootserver/kernel/include/arch/arm/arch/64/mode/kernel/vspace.h:55:36: error: ‘mode_reserved_region’ causes a section type conflict with ‘avail_p_regs’ 55 | static const region_t BOOT_RODATA *mode_reserved_region = NULL; ... /usr/local/google/home/sleffler/camkes-aarch64-rootserver/build/kernel/gen_headers/plat/machine/devices_gen.h:67:37: note: ‘avail_p_regs’ was declared here 67 | static const p_region_t BOOT_RODATA avail_p_regs[] = {
Looking at the commit history I see this commit:
https://github.com/seL4/seL4/commit/680ce96b590295c1d49db6a2a34f77ac22e8475a
followed by this commit:
https://github.com/seL4/seL4/commit/8a87015a7c289f8bc2b5799d61e7c91482ad1cb2
I'm using gcc 11.2 from arm's prebuilt toolchain repo:
https://developer.arm.com/tools-and-software/open-source-software/developer-...
Removing the clang band-aid fixes things. My source tree is "tracking" upstream but not directly based off it. Have I missed a change that resolves this? Is the 11.2 release just not being used yet (assuming it's a change in gcc?
-Sam
Sam,
/usr/local/google/home/sleffler/camkes-aarch64-rootserver/kernel/include/arch/arm/arch/64/mode/kernel/vspace.h:55:36: error: ‘mode_reserved_region’ causes a section type conflict with ‘avail_p_regs’ 55 | static const region_t BOOT_RODATA *mode_reserved_region = NULL; ... /usr/local/google/home/sleffler/camkes-aarch64-rootserver/build/kernel/gen_headers/plat/machine/devices_gen.h:67:37: note: ‘avail_p_regs’ was declared here 67 | static const p_region_t BOOT_RODATA avail_p_regs[] = {
Looking at the commit history I see this commit: https://github.com/seL4/seL4/commit/680ce96b590295c1d49db6a2a34f77ac22e8475a followed by this commit: https://github.com/seL4/seL4/commit/8a87015a7c289f8bc2b5799d61e7c91482ad1cb2 I'm using gcc 11.2 from arm's prebuilt toolchain repo: https://developer.arm.com/tools-and-software/open-source-software/developer-... Removing the clang band-aid fixes things.
I have some dark blurry memories about this "mode_reserved_region" and trying to hide this away in AARCH32, as it was only needed there. Makes we wonder if that might be the best way to continue - do not define or reference "mode_reserved_region" at all unless MODE_RESERVED is greater 0 there. But I can't rember why we kept it the way it is, might have been for verification. The that left us with the C parser used there, that does not support empty arrays.
Axel
On Mon, Aug 1, 2022 at 2:53 PM Axel Heider axelheider@gmx.de wrote:
Sam,
/usr/local/google/home/sleffler/camkes-aarch64-rootserver/kernel/include/arch/arm/arch/64/mode/kernel/vspace.h:55:36:
error: ‘mode_reserved_region’ causes a section type conflict with ‘avail_p_regs’ 55 | static const region_t BOOT_RODATA *mode_reserved_region = NULL; ...
/usr/local/google/home/sleffler/camkes-aarch64-rootserver/build/kernel/gen_headers/plat/machine/devices_gen.h:67:37:
note: ‘avail_p_regs’ was declared here 67 | static const p_region_t BOOT_RODATA avail_p_regs[] = {
Looking at the commit history I see this commit:
https://github.com/seL4/seL4/commit/680ce96b590295c1d49db6a2a34f77ac22e8475a
followed by this commit:
https://github.com/seL4/seL4/commit/8a87015a7c289f8bc2b5799d61e7c91482ad1cb2
I'm using gcc 11.2 from arm's prebuilt toolchain repo:
https://developer.arm.com/tools-and-software/open-source-software/developer-...
Removing the clang band-aid fixes things.
I have some dark blurry memories about this "mode_reserved_region" and trying to hide this away in AARCH32, as it was only needed there. Makes we wonder if that might be the best way to continue - do not define or reference "mode_reserved_region" at all unless MODE_RESERVED is greater 0 there. But I can't rember why we kept it the way it is, might have been for verification. The that left us with the C parser used there, that does not support empty arrays.
The commit msg says it's #ifdef'd clang to avoid impacting verification. But w/ the 11.2 gcc toolchain it doesn't compile as-is so my question is whether I'm missing some other change that addresses this or if I'm at the bleeding edge toolchain and we need a narrower #ifdef or similar. I can always keep a local change but at some point I'll want to sync w upstream and have to deal with this.
Guess I need to pull a clean checkout and see whether it compiles w/ gcc 11.2.
-Sam
A clean upstream checkout fails to build w/ gcc 11.2 because of the section mismatch.
On Mon, Aug 1, 2022 at 3:57 PM Sam Leffler sleffler@google.com wrote:
On Mon, Aug 1, 2022 at 2:53 PM Axel Heider axelheider@gmx.de wrote:
Sam,
/usr/local/google/home/sleffler/camkes-aarch64-rootserver/kernel/include/arch/arm/arch/64/mode/kernel/vspace.h:55:36:
error: ‘mode_reserved_region’ causes a section type conflict with ‘avail_p_regs’ 55 | static const region_t BOOT_RODATA *mode_reserved_region = NULL; ...
/usr/local/google/home/sleffler/camkes-aarch64-rootserver/build/kernel/gen_headers/plat/machine/devices_gen.h:67:37:
note: ‘avail_p_regs’ was declared here 67 | static const p_region_t BOOT_RODATA avail_p_regs[] = {
Looking at the commit history I see this commit:
https://github.com/seL4/seL4/commit/680ce96b590295c1d49db6a2a34f77ac22e8475a
followed by this commit:
https://github.com/seL4/seL4/commit/8a87015a7c289f8bc2b5799d61e7c91482ad1cb2
I'm using gcc 11.2 from arm's prebuilt toolchain repo:
https://developer.arm.com/tools-and-software/open-source-software/developer-...
Removing the clang band-aid fixes things.
I have some dark blurry memories about this "mode_reserved_region" and trying to hide this away in AARCH32, as it was only needed there. Makes we wonder if that might be the best way to continue - do not define or reference "mode_reserved_region" at all unless MODE_RESERVED is greater 0 there. But I can't rember why we kept it the way it is, might have been for verification. The that left us with the C parser used there, that does not support empty arrays.
The commit msg says it's #ifdef'd clang to avoid impacting verification. But w/ the 11.2 gcc toolchain it doesn't compile as-is so my question is whether I'm missing some other change that addresses this or if I'm at the bleeding edge toolchain and we need a narrower #ifdef or similar. I can always keep a local change but at some point I'll want to sync w upstream and have to deal with this.
Guess I need to pull a clean checkout and see whether it compiles w/ gcc 11.2.
-Sam
On Wed, Aug 3, 2022 at 4:57 AM Sam Leffler via Devel devel@sel4.systems wrote:
A clean upstream checkout fails to build w/ gcc 11.2 because of the section mismatch.
The commit msg says it's #ifdef'd clang to avoid impacting verification. But w/ the 11.2 gcc toolchain it doesn't compile as-is so my question is whether I'm missing some other change that addresses this or if I'm at the bleeding edge toolchain and we need a narrower #ifdef or similar. I can always keep a local change but at some point I'll want to sync w upstream and have to deal with this.
Guess I need to pull a clean checkout and see whether it compiles w/ gcc 11.2.
Thanks for bringing this up, there isn't any existing patch for this yet as you are the first to report the compiler error.
-Sam
Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems
-
Axel Heider -
Kent Mcleod -
Sam Leffler