How can we disable the syntax checking of linker files

[lucvansteenkist]

Starting from MCUXpresso 11.0 a feature is added to do syntax highlighting in linker files and map files.

Although this feature is nice, it generates incorrect errors.

Example:

.flash : ALIGN(4)
{
      KEEP(*(.Timer));
      . = ALIGN(0x100);
      *board*                (.text* .rodata* .constdata*)

      *\libcommon.a:*   (.text*)                                 /* include all required object files from library libcommon.a */

} > m_flash

The syntax checker gives the following error at the colon in the line *\libcommon.a:*

      no viable alternative at input :

The build succeeds with correct output files but according to the IDE the project was not built. (Red indication on project and linker file)

The more annoying side effect is that the J-LINK debugger does not want to start. 

Resulting messagebox is:

      MCUXpresso IDE: Error

      Unable to perfor operation: project build failed!

SO, question is..

How can we disable this syntax checking.

Thanks

Luc

[Emiel1984]

Unfortunately the issue returned again the morning after.
Because my colleagues where able to debug with the same code without the change I asked them to show how they did start a debug session of the project. We figured out that if they performed the same method as I did, they did get the same error.

The difference was that I always :
'right click project name'->Debug as->Segger J link probes (we all have a j-link pro)
Where my colleagues always pressed the blue 'bug' icon.

But the error remains to exist in the 'Problems' window.

This file is exactly the same as it already was in the SDK_2.x_K32W061 (SDK version 2.6.4).

@lpcxpresso_supp Can this be fixed in the next update of mcuxpresso ? 

[Emiel1984]

Difficult to believe that I did run into this same issue with the latest released mcuxpresso.
Seems it isn't solved 2 years later. Have to thank @ErichStyger it solved the issue for me.

Path in mcuxpresso:
mcuxpresso->Window->Preferences->General->Editors>File Associations-> 'FileType *.ld'  -> 'Text Editor' ->Default

After this I was still required to 'delete' the already created error in 'Problems' tab. But I was able to debug again.
I did also find it strange that if use a linker file located in an SDK, the issue will not appear at all.
The issue only appeared after copying it into my own project.

@lpcxpresso_supp  maybe it would be nice the the default editor for NXP tools in general is an text editor until the moment it would not trigger these false errors that block you from debugging. This issue created a lot of weird\amazed faces in my office..

[lpcxpresso_supp]

As Con Verse highlights, there are several ways to disable the use of the linker script editor. Once this is done, then if necessary, go to the "Problems" view to delete the (potentially incorrect) errors the editor has previously flagged for you.

But please could you supply the actual linker script(s) that are triggering your issues for us to look?

Regards,

MCUXpresso IDE Support

[johnadriaan]

Thank you for releasing the latest version of MCUXpresso IDE v11.1.0 [Build 3209] [2019-12-12]

It resolves many other issues I've had, and I accept that you haven't had a chance to address the above issues. Unfortunately, I'm reporting one more legal gcc ld syntax that your (new) parser doesn't cope with:

In the MEMORY { ... } command, everyone seems to provide a list of attributes for every entry (for example, the (!rx) below):

    SRAM   (!rx) : ORIGIN = 0x20000000,  LENGTH = 128K

However, these attributes are not only optional, they're invalid most of the times people provide them. These are only used by the linker if a SECTION is specified without explicitly providing which MEMORY region to use. It looks at the attributes, and picks a matching region that has acceptable attributes.

In other words, unless you want the linker to automatically pick a memory region, you shouldn't specify any attributes for it! People seem to use these attributes to document what can be done with these memory regions: peripheral regions are usually given (rw) (can read or write here!), while secondary RAM is given (rwx) (can read, write or execute here!).

While the idea is true, that is not what the above means: specifying (rw) for a peripheral region would allow the linker to allocate normal variables to those areas! As such, I specify attributes for MEMORY regions rarely - but your parser seems to require them.

For the following lines, I get either of the two errors shown below, depending on how confused it got from the previous entries:

    SRAM  (!rx) : ORIGIN = 0x20000000,  LENGTH = 128K

    AIPS1       : ORIGIN = 0x40000000,  LENGTH = 1M           /* ARM IP Bus 1 */

    AIPS2       : ORIGIN = 0x40100000,  LENGTH = 1M           /* ARM IP Bus 2 */

• mismatched input ':' expecting '('
• missing ')' at ':'

[lpcxpresso_supp]

Thank you. We'll address this last finding as well.

Greetings,
MCUXpresso IDE Support

[johnadriaan]

Another legal gcc ld syntax that your parser doesn't cope with:

Inside a linker script you can define variable names, and they have very loose restrictions - far looser than C variables. In fact, you can even surround the variable names with quotes, and use spaces. So:

    "Flash Size" = 0x8000;

Now, I don't go that far - but since variables are unusual in linker scripts I make sure I surround them in quotes, to distinguish them from compiler-defined variables:

    "_Flash_Size" = 0x8000;

    .

    .

    FLASH (rx)   : ORIGIN = 0x60000000,  LENGTH = "_FLASH_Size" /* Script variable */

While gcc uses these fine, again, your parser errors out on them, with either:

• missing EOF at "_Flash_Size" or
• no viable alternative at "_Flash_Size"

[lpcxpresso_supp]

Thank you for your feedback. We'll investigate adding support for quotes in symbols like this for a future IDE release.

Regards,

MCUXpresso IDE Support

[johnadriaan]

I too am having trouble with this (MCUXpresso IDE v11.0.1 [Build 2563] [2019-09-01]).

GCC completes the link: there is no problem with the linker script according to gcc's ld.

My main problem is the following INCLUDE statement: INCLUDE ARM/ARM.ld

I get two errors:

* A NullPointerException occured. This indicates a missing value converter or a bug in its implementation.

* no viable alternative at input '/'

Adding ARM to the -L search path (which I DON'T want to do) and removing the subdirectory from the line fixes the second error - the Exception remains.

Putting quotes around the path and filename (not required by the syntax) removes the first error, but replaces it with:

* Included file does not exist!

Again, gcc has no problem with any of the above solutions: only your parser does, and I cannot find a workaround

[lucvansteenkist]

Attache is a ZIP file with the linker scripts of two projects

In example1 I don't see how to solve the issue.

I am loading the required functions out of the libraries in a specific section.

The linker itself works and does exactly what I expect.

In example2 we can solve the issues by not including other files but embedding everything in one linker file.

Thanks for looking at the issue,

Luc

[converse]

Syntax coloring only affects the editor - it does not affect the build, so (while annoying) it will not cause any build problems.

I don't know of any convenient way to switch off just the syntax coloring for a single tool. In fact switch it off is difficult. Options are:

• you can change default file association in Eclipse preferences (General -> Editors -> File associations)
• you can open a file with the text editor via the contextual menu on the file "Open with -> text editor". Eclipse will remember your choice, and will use the text editor the next time you'll open this file.
• To disable syntax highlighting EVERYWHERE: 
  1. Select Window->Preferences->C/C++->Scalability->Disable syntax coloring in editor
  2. Set Window->Preferences->C/C++->Scalability->"Enter scalability mode when the number of lines in the file is more than" to something low (e.g. 10)
  3. Close the file and reopen it.

[lucvansteenkist]

The syntax coloring is not the issue, it is the syntax checking of the linker scripts.

Not all features of the linker script syntax are correctly interpreted.

See the screenshots below / attached.

Although the project build fine (no compile / link errors) the debugger does not want to start because of the so-called but non-existing build errors.

[ErichStyger]

To disable the syntax checking, I have found following simple solution:

Change the editor to be used with Open with:

This will use the normal text editor for it.

Other *.ld files are not affected.

To change it globaly, go to workspace preferences and change the default for all *.ld files:

I hope this helps,

Erich