armlink is unaware of Mbed configuration options

[Patater]

Description of defect

armlink is unaware of any Mbed configuration defines. The scatterfiles are pre-processed, but without any Mbed configuration defines set.

1. The preprocessor is invoked like so, for K64F for example. Notice no -D options passed or responsefile given: armclang -E --target=arm-arm-none-eabi -x c -mcpu=cortex-m4 -IBUILD/tests/K64F/ARMC6/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/device/TOOLCHAIN_ARM_STD
2. The linker is invoked like so: armlink --via ./BUILD/tests/K64F/ARMC6/./TESTS/mbed_hal/stack_size_unification/.link_options.txt. The .link_options.txt file does have some -D options, but no MBED_CONF_* -D options.

This means the desired behavior expressed within the config system isn't available in linker scripts (scatterfiles) when using Arm Compiler 6.

Discovered when working on #13452

Target(s) affected by this defect ?

Probably all that are buildable with Arm Compiler 6

Toolchain(s) (name and version) displaying this defect ?

Arm Compiler 6

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.2.1

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli

How is this defect reproduced ?

Attempt to set any Mbed configuration option the tools don't have special logic to handle. Observe that the MBED_CONF_* macro is not available in the scatterfile.

[ciarmcom]

@Patater thank you for raising this issue.Please take a look at the following comments:

We cannot automatically identify a release based on the version of Mbed OS that you have provided.
Please provide either a single valid sha of the form #abcde12 or #3b8265d70af32261311a06e423ca33434d8d80de
or a single valid release tag of the form mbed-os-x.y.z .
E.g. '#13452' has not been matched as a valid tag or sha.
NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered.
Please update the issue header with the missing information, the issue will not be mirroredto our internal defect tracking system or investigated until this has been fully resolved.

[0xc0170]

Good find. Is this related to what we found out and reported to ARMCLang team: using , as macro delimeter, causing an issue when something like this is passed MACRO_1=0x0,0x01 ? I can link it to this issue if they are (It was previously linked to CMake issue we found).
It would explain why we haven't seen it with the old tools (or maybe we did, therefore it was not enabled, I don't know).

[adbridge]

@Patater Neither of these : mbed-os-99.99.99, #13452 are valid mbed-os versions or shas and will stop this issue from being mirrored. Please provide the requested information.

[Patater]

Good find. Is this related to what we found out and reported to ARMCLang team: using , as macro delimeter, causing an issue when something like this is passed MACRO_1=0x0,0x01?.

No, the problem here is that we aren't even making an attempt to pass on the MBED_CONF_* options to the linker.

[kjbracey]

You can just add #include "mbed_config.h" to the scatter file to get the options. I'm not sure if the ARM build is inconsistent with the GNU build here.