Skip to content

pass on asm flags for uVision project #10424

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

Closed
wants to merge 1 commit into from

Conversation

studavekar
Copy link
Contributor

Description

This should fix Keil uVision + armc6 build failure issue #10423 with PR #10390 .

Currently, asm flags are not passed on Uvision exporter

self.flags['asm'].append("--cpu=%s" % asm_cpu)

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@bridadan @SenRamakri @kjbracey-arm

Release Notes

@ciarmcom ciarmcom requested review from bridadan, kjbracey, SenRamakri and a team April 16, 2019 23:00
@ciarmcom
Copy link
Member

@studavekar, thank you for your changes.
@bridadan @SenRamakri @kjbracey-arm @ARMmbed/mbed-os-tools @ARMmbed/mbed-os-maintainers please review.

@0xc0170
Copy link
Contributor

0xc0170 commented Apr 17, 2019

Was this tested with few diff targets and projects? I recall some issues with asm + flags in uvision (length issue or similar).

Aborted CI build (was triggered automatically), we need CI time for 5.12.2 jobs today.

@mbed-ci
Copy link

mbed-ci commented Apr 17, 2019

Test run: FAILED

Summary: 6 of 7 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_build-IAR
  • jenkins-ci/mbed-os-ci_mbed2-build-ARM
  • jenkins-ci/mbed-os-ci_mbed2-build-GCC_ARM
  • jenkins-ci/mbed-os-ci_build-GCC_ARM
  • jenkins-ci/mbed-os-ci_build-ARM
  • jenkins-ci/mbed-os-ci_mbed2-build-IAR

@0xc0170
Copy link
Contributor

0xc0170 commented Apr 17, 2019

Was this tested with few diff targets and projects? I recall some issues with asm + flags in uvision (length issue or similar).

I've checked only ARMC5 , please check also ARMCC6 if this is the case.

For ARMC5, we add common to asm flags - this could be problematic. If you check asm command line options and armcc , they differ. --gnu for instance is only armcc flag, not asm. I would not copy common to asm in this case (or remove from common flags that are not common for asm/armcc).

@studavekar
Copy link
Contributor Author

Was this tested with few diff targets and projects? I recall some issues with asm + flags in uvision (length issue or similar).

CI should catch it.

For ARMC5, we add common to asm flags - this could be problematic.

I currently don't see common flag added to asm flags, i am looking at flags['asm']

@0xc0170
Copy link
Contributor

0xc0170 commented Apr 18, 2019

ARMC6 seems not to do it, but ARMC5 yes

ARMC5:
https://github.com/ARMmbed/mbed-os/blob/master/tools/toolchains/arm.py#L102

ARMC6:
https://github.com/ARMmbed/mbed-os/blob/master/tools/toolchains/arm.py#L600

Thus I don't think ARCM5 will work (not all common flags are for asm).

@studavekar
Copy link
Contributor Author

studavekar commented Apr 18, 2019

@0xc0170 self.asm and self.flags['asm'] are not same we are using only self.flags['asm'] . However, we may not need this change as @bridadan was working on updating the uVIsion template to handle no fpu case.

@adbridge
Copy link
Contributor

@studavekar what is the status of this PR ? Is it actually still needed ?

@bridadan
Copy link
Contributor

bridadan commented Apr 25, 2019

@studavekar I've been looking at this a bit more. There are quite a few flags that are being duplicated in uvision (not 100% sure if this duplication is already present on the master branch as well, need to look more). I'm still looking into this, just taking longer than I was hoping. @kjbracey-arm is also looking at this a bit in #10390

@adbridge
Copy link
Contributor

@kjbracey-arm is this related to some of your own going work? If so would you be able to pick this up also ?

@studavekar
Copy link
Contributor Author

closing this PR, due to lack of progress on PR and won't be able to allocate time for this. Feel free to reopen.

@studavekar studavekar closed this Jun 26, 2019
@jeromecoutant
Copy link
Collaborator

Hi

Feel free to reopen.

@0xc0170 could you re-open this one ?
We are currently working on the new STM32WL target which is a M4 without FPU.
Without this patch I couldn't compile with Keil, so it seems a mandatory patch.

@MarceloSalazar

@kjbracey
Copy link
Contributor

Hmm, I missed this at the time. Not that familiar with exporters, or the Python relating to them, but appears conceptually valid. There have been other similar issues with exporters not passing on assembly flags.

@kjbracey
Copy link
Contributor

Oh, one concern I vaguely recall is getting the information passed at a "high enough" level. Rather than just passing all the flags in the command line under "misc flags", the exporters want to set higher-level XML options, like "core type" - so extract and translate the known options. This wouldn't be doing that.

(The one time I looked at this was #11225 for setting the language standard)

@0xc0170
Copy link
Contributor

0xc0170 commented Dec 18, 2020

As old tools were frozen, exporters as well. I would close this as won't fix.

cc @ARMmbed/mbed-os-tools

@jeromecoutant
Copy link
Collaborator

I can't agree...

@0xc0170
Copy link
Contributor

0xc0170 commented Dec 18, 2020

Let @ARMmbed/mbed-os-tools to review

@@ -175,7 +175,7 @@ def format_flags(self):
'--cpreproc --cpreproc_opts=-D__ASSERT_MSG,' +
",".join("-D{}".format(s) for s in
self.toolchain.get_symbols(for_asm=True)))
flags['asm_flags'] = asm_flag_string
flags['asm_flags'] = "{} {}".format(" ".join(self.toolchain.flags['asm']), asm_flag_string)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that this change is in the uVision project generator it shouldn't affect the behaviour in the online build service. Meaning we shouldn't have to create another "tools-release" for the online compiler. However, as we've had this PR open since April 2019, let's wait a few more days for @Patater to return before we decide if we're going to accept it. We will need to evaluate if this actually does affect Mbed Studio or the online build service.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Patater can you please make a decision on this?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NB: This is mandatory for the on going STM32WL target which is a M4 without FPU.
Without this patch I couldn't compile with Keil IDE. Even if export is no more mandatory for ARM, it still very appreciated from customers.
Thx

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Mbed Online IDE actually can export things, so it would affect the Online IDE.

Sorry, we can't risk breaking the online tooling right now. That's why the tools are frozen. Exporter support is important and we should work to support it from the CMake-based build system instead of merging this risky PR.

ludoch-stm pushed a commit to ludoch-stm/mbed-os that referenced this pull request Jan 8, 2021
@jeromecoutant
Copy link
Collaborator

Hi
Any update ?
Thx

@ciarmcom ciarmcom added the stale Stale Pull Request label Jan 20, 2021
@ciarmcom
Copy link
Member

This pull request has automatically been marked as stale because it has had no recent activity. @studavekar, please carry out any necessary work to get the changes merged. Thank you for your contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.