[Compiler] EABI compilation mode

Hi,

In Developer Studio, while starting a new project, most of you have already saw that project allow multiple compiler possibilities:

  • ADS: which is an old compiler that has been always supported by Open AT. ADS was only available from ARM Limited but it is no more commercially available. Open AT still support ADS to remain compatible with legacy platform, but Sierra Wireless has no intention to maintain it in the futur. In addition this compiler doesn’t support the EABI library format.
  • RVDS: It is the latest compiler available from ARM Limited. Firmwares and Open AT libraries are compiled with it, as it offers the most interresting performances for code size reduction and code execution speed. In addition RVDS support the EABI library format. So, it is recommanded for further project.
  • GCC ARM Elf: Old compiler generation that was included in the early age of Open AT. Open AT still support GCC ARM Elf, but we have no intention to maintain it. Remaining libraries that are still compiled with this compiler will be also compiled with RVDS or GCC ARM EABI (if not already done), or some of them won’t be maintained and disapear from next SDK.
  • GCC ARM EABI: Latest compilation mode that was recently added to Open AT. The interrest of this compiler is that it is compatible with RVDS EABI library format. GCC ARM EABI is part of the recommended compiler for further project.

But what is the EABI compilation mode?
Libraries compiled in EABI mode are interoperable. RVDS or GCC libraries that are compiled in EABI mode are compatible and can be used in the same project to build an end application.
Sierra Wireless plan to deliver all their next generation of libraries based on EABI compilation mode to ease interroperability and compatibility.
Then, any project relying on EABI compiler (RVDS or GCC) could support a libraries from any third party without knowing which compiler was used originally, preventing interworking issues.

Which compiler is the best?
From our experience, RVDS remain the most powerfull compiler in code size reduction and code speed execution. Anyway, GCC performances are reasonably good.
RVDS is not free of charge and available from ARM directly or their reseller, while GCC is already included with Developer Studio.
Sierra Wireless intends to deliver RVDS EABI library in order to let you benefits from their maximum of performances. Then, these libraries could be used in any projects relying on GCC EABI or RVDS.

Hi,

It is a very good idea to change to EABI compilation mode, but not all the libraries are compiled (e.g. C-GPS-OPUS-III) in EABI mode and therefor I’m unable to use the RVDS compiler or GCC ARM EABI.

Can I get a EABI compiled version of C-GPS plugin? or when it will be available for download?

Dear Shekib,

Not all libraries could be delivered in EABI format. C-GPS is one of them.
C-GPS library will remain in Elf format within the Open AT Framework 2.3x.

For new projects, it is currently recommended to use XM0110 GPS module with its Location library.
Location library is available in EABI format.

Christophe

Is it possible to use Keil MDK compiler in DS? It is also owned by ARM company. Our company is working with MDK on other project so it would be great if we could use it in Dev Studio also.

Best Regards,
Ivan

https://forum.sierrawireless.com/t/fw-7-45-suffers-lag-in-gprs-edge-streaming/5179/7

Several things have to be verified…
1* Is this compiler able to produce ARM EABI code (as GCC or RVDS do)? If not, then it’s over, since you won’t be able to link your code against Open AT libraries (built for ARM EABI).
2* Then, the easy way would be that this MDK compiler uses options syntax similar to other ARM ones. If this is the case, you could give a try to customize - for example - ARM RVDS installation paths (in Windows > Preferences > Developer Studio > Tools Path > RVDS), and various compiler options to try to get it compile and link against our libs.
3* And if not (I mean if the options syntax is really completely different), I’m afraid that someone need to do some java and Eclipse code to develop a DS add-on able to integrate this particular toolchain. That’s the moment to remind that DS code is opened, and that it’s possible to develop (and even maybe contribute) add-ons: forum.sierrawireless.com/viewto … 108&t=5727 :wink:

Note that Keil (an ARM company) do already have an Eclipse-based IDE: arm.com/products/tools/softw … /index.php - so, if necessary, it migh be possible to base something on that…

arm tools comparison: http://www.keil.com/arm/rvcomparison.asp

MDK is EABI compatible

I will try configure DS as daav recomended in point 2.

awneil, you are referencing ARM Development Studio. There is a chance (even I don’t bet on it) that this version of compiler is more similar to MDK than RVDS so maybe info from this Eclipse plugin would be valuable.

Hello world project compilation and GDB debugging with Keil MDK worked like a charm! :smiley:

For further ref - steps that worked for me (thank you daav):

  1. Setup Tools Path (Window->Preferences->Developer Studio->Tools paths->RealView Development Suite preferences)
    RVCT40BIN: C:\Keil\ARM\BIN40
    RVCT40INC: C:\Keil\ARM\RV31\INC
    RVCT40LIB: C:\Keil\ARM\RV31\LIB

  2. Add Windows System Environment Variable ARMLIB -> C:\Keil\ARM\RV31\LIB (+restart Dev Studio)
    Without this step I had wrong path during linking process. I have ADS1.2 toolchain installed which set ARMLIB variable to ADS linker. I’m not sure why DS used path from System Environment Variable instead configured path (from step 1.)

  3. Project Properties->C/C++ Build->Settings->ToolSettings->RVDS C/C++ Linker->Linker options : unmark Elf format checkbox (I didn’t try with Elf so I’m not sure is this make any difference but I wanted EABI).

Good news!
Sure this will be helpful for other users.

Actually, DS exports environment variables with the exact names mentioned in the preferences pages (e.g. RVCT40LIB, etc…)
Note that if ARMLIB variable is required by your compiler, maybe it is closer to ADS configuration system (cf. ADS preference page in DS, where you can configure ARMLIB & other variables…)
Last option, instead of modifying your OS environment, you can configure DS/CDT to make it export environment variables at build time: cf Window > Preferences > C/C++ > Build > Environment. You can even overwrite these global settings at project level in each project properties.

Another question regarding this subject (using Keil MDK as a toolchain).

Setup: SL6087 module on development board
Dev Studio Build Version 2.1.1.201201180944-R8656
SL Module FW 7.47

I have some problems during GDB session. My test project contains following files:
src\generated.c
src\hello_world.c
src\SubFolderTest\SecondFile.c
src\SubFolderTest\SecondFile.h (marked as “Exclude resource from build”)

Compile/link Debug project and then Debug As Open AT Target application.

After I pause debug session I am able to place breakpoints inside hello_world.c file and debug as expected (step, continue,…). Problem is when I try to place breakpoint inside SecondFile.c. GDB says "No line 9 in file “…\src\SubFolderTest\SecondFile.c”. I can manually place breakpoint on that place but with following command: break “…\src\SubFolderTest/SecondFile.c”:9. Notice “/” before SecondFile.c.

Other observations:

  • When debugging and step from hello_world.c into function located in SecondFile.c everything works (SecondFile.c is being open and I can continue to stepping inside it but placing breakpoints directly in SecondFile.c still doesn’t work).
  • Same test with EABI GCC toolchain works.
  • When move SecondFile.h to inc\SecondFile.h, Refresh project, recompile and retry debugging then I am able to place breakpoints in both .c files (Keil toolchain).
  • GDB console shows following lines after starting debug session:
    warning: Loadable segment “APP_DATA” outside of ELF segments
    warning: Loadable segment “APP_BSS” outside of ELF segments
    warning: Loadable segment “APP_UNINIT” outside of ELF segments
    Can’t send signals to this remote system. SIGEMT not sent.
    warning: RMT ERROR : failed to get remote thread list.

Does anyone have a suggestion what can be source of problem based on this “blurry” info that I gave?

More info on subject

Test Scenario 1: SecondFile.h placed inside src\SubFolderTest
Test Scenario 2: SecondFile.h placed inside inc

Test Scenarios Info:

  • both with MDK Keil toolchain
  • both successfuly downloaded and debug with breakpoints located inside hello_world.c file
  • Test Scenario 1 - placing breakpoints inside SecondFile.h doesn’t work
  • Test Scenario 2 - placing breakpoints inside SecondFile.h works ok

Command maint info psymtabs SecondFile.c executed from GDB Console returns different result in above test scenarios.

Test Scenario 1

maint info psymtabs SecondFile.c
{ objfile C:/workspace/TestA/[Target]RVDS_Debug/TestA.axf
((struct objfile *) 01CD1570)
{ psymtab …\src\SubFolderTest\SecondFile.c
((struct partial_symtab ) 01D0E170)
readin yes
fullname (null)
text addresses 0x0 – 0x0
globals (none)
statics (
(struct partial_symbol **) 01CDA978 @ 2)
dependencies (none)
}
{ psymtab …\src\SubFolderTest/SecondFile.c
((struct partial_symtab *) 01D0E0F8)
readin no
fullname (null)
text addresses 0x0 – 0x0
globals (none)
statics (none)
dependencies {
psymtab …\src\SubFolderTest\SecondFile.c ((struct partial_symtab *) 01D0E088)
}
}
{ psymtab …\src\SubFolderTest\SecondFile.c
((struct partial_symtab ) 01D0E088)
readin yes
fullname (null)
text addresses 0x260200 – 0x260212
globals (
(struct partial_symbol *) 01D09BD8 @ 1)
statics (
(struct partial_symbol **) 01CDA974 @ 1)
dependencies (none)
}
}

maint info symtabs SecondFile.c
{ objfile C:/workspace/TestA/[Target]RVDS_Debug/TestA.axf
((struct objfile *) 01CD1570)
{ symtab …\src\SubFolderTest\SecondFile.c ((struct symtab *) 01D107A0)
dirname C:\workspace\TestA[Target]RVDS_Debug
fullname (null)
blockvector ((struct blockvector *) 01D10718) (primary)
linetable ((struct linetable *) 00000000)
debugformat DWARF 2
}
{ symtab …\src\SubFolderTest/SecondFile.c ((struct symtab *) 01D103D0)
dirname C:\workspace\TestA[Target]RVDS_Debug
fullname (null)
blockvector ((struct blockvector *) 01D10718)
linetable ((struct linetable *) 01D10730)
debugformat unknown
}
{ symtab …\src\SubFolderTest\SecondFile.c ((struct symtab *) 01D10300)
dirname C:\workspace\TestA[Target]RVDS_Debug
fullname (null)
blockvector ((struct blockvector *) 01D102F0) (primary)
linetable ((struct linetable *) 00000000)
debugformat DWARF 2
}
}

Test Scenario 2

maint info psymtabs SecondFile.c
{ objfile C:/workspace/TestA/[Target]RVDS_Debug/TestA.axf
((struct objfile *) 01C81570)
{ psymtab …\src\SubFolderTest\SecondFile.c
((struct partial_symtab ) 01CBE170)
readin no
fullname (null)
text addresses 0x0 – 0x0
globals (none)
statics (
(struct partial_symbol **) 01C8A978 @ 2)
dependencies (none)
}
{ psymtab …\src\SubFolderTest\SecondFile.c
((struct partial_symtab *) 01CBE0F8)
readin no
fullname (null)
text addresses 0x0 – 0x0
globals (none)
statics (none)
dependencies {
psymtab …\src\SubFolderTest\SecondFile.c ((struct partial_symtab *) 01CBE088)
}
}
{ psymtab …\src\SubFolderTest\SecondFile.c
((struct partial_symtab ) 01CBE088)
readin no
fullname (null)
text addresses 0x260200 – 0x260212
globals (
(struct partial_symbol *) 01CB9BD8 @ 1)
statics (
(struct partial_symbol **) 01C8A974 @ 1)
dependencies (none)
}
}

maint info symtabs SecondFile.c
(doesn’t return anything)