Device-os: "Dynalib location not correct"

[larseggert]

Bug Report

As I add code to my project, linking starts to fail with

arm-none-eabi/bin/ld: Dynalib location not correct
arm-none-eabi/bin/ld: Dynalib location not same as exported location

The .text of a smaller project has an LMA of 0x000d4018, whereas a larger project has an LMA of 0x000d4020, which apparently causes user.ld to balk at the output.

Anyone know why this is happening and what to do about it? Here is a diff of the two .lst files:

Sections:
 Idx Name          Size      VMA       LMA       File off  Algn
   0 .module_info  00000018  000d4000  000d4000  00004000  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
-  1 .text         000194f0  000d4020  000d4020  00004020  2**4
+  1 .text         00006928  000d4018  000d4018  00004018  2**3

Expected Behavior

Link my growing project.

Observed Behavior

Link step fails with

arm-none-eabi/bin/ld: Dynalib location not correct
arm-none-eabi/bin/ld: Dynalib location not same as exported location

Steps to Reproduce

This is with DeviceOS v1.2.1 and po-util, using this toolchain:

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.3.1 20160307 (release) [ARM/embedded-5-branch revision 234589]

git clone --recurse-submodules https://github.com/NTAP/quant.git
cd quant/particle/
po argon build

Test App

See quant/particle/firmware/main.cp.

References

There is a discussion here, but no resolution.

[avtolstoy]

Thanks for submitting the issue!

I've managed to reproduce it and quickly tried manually forcing the location of the user-part dynalib at the correct location, however that didn't seem to help.

We'll be looking into the reasons more closely and will update this issue with the findings.

[larseggert]

Not sure is this is related or not, but I tried enabling LTO in the hopes of getting the size down to where the link step still worked.

However, that results in different linker errors:

/var/folders/2l/mj2rsdx10t93p5wsl2z45zl00019yg/T//ccW357uj.ltrans9.ltrans.o: In function `spark::JSONWriter::printf(char const*, ...)':
/Users/lars/.po-util/src/particle/firmware/modules/argon/user-part/src/spark_wiring_json.cpp:490: undefined reference to `vsnprintf'
/Users/lars/.po-util/src/particle/firmware/modules/argon/user-part/src/spark_wiring_json.cpp:495: undefined reference to `vsnprintf'
/var/folders/2l/mj2rsdx10t93p5wsl2z45zl00019yg/T//ccW357uj.ltrans11.ltrans.o: In function `Print::printf_impl(bool, char const*, ...) [clone .constprop.85]':
/Users/lars/.po-util/src/particle/firmware/modules/argon/user-part/src/spark_wiring_print.cpp:262: undefined reference to `vsnprintf'
/Users/lars/.po-util/src/particle/firmware/modules/argon/user-part/src/spark_wiring_print.cpp:273: undefined reference to `vsnprintf'
collect2: error: ld returned 1 exit status
make[1]: *** [../../../build/module.mk:235: /Users/lars/Documents/Code/quant/particle/bin/particle-argon.elf] Error 1

[larseggert]

@avtolstoy would you happen to have any ETA for a fix? I'm kinda dead in the water at a moment if I can't link.

[larseggert]

Any updates? I am beginning to wonder if it is time to ditch the platform.

[avtolstoy]

@larseggert Thanks for bumping the issue. We are currently in the process of refactoring the linker files for all the platforms, so I may suggest following this PR and trying out the branch to see if it resolves the issue for you.

Alternatively, as a temporary workaround I may suggest moving the dynalib into a separate section in the linker file by applying the following patch to your local DeviceOS repository:

diff --git a/modules/shared/nRF52840/user.ld b/modules/shared/nRF52840/user.ld
index 876c2c439..bbe4457f1 100644
--- a/modules/shared/nRF52840/user.ld
+++ b/modules/shared/nRF52840/user.ld
@@ -7,16 +7,16 @@ SECTIONS
     INCLUDE module_start.ld
     INCLUDE module_info.ld

-    .text :
+    .dynalib :
     {
-        expected_dynalib_start = ORIGIN (APP_FLASH) + 24 ;
+        expected_dynalib_start = ORIGIN(APP_FLASH) + 24 ;
         link_dynalib_start = .;
         KEEP(*(*.user_part_module))
         link_dynalib_end = . ;
-        link_length_start = .;
-        KEEP(*(*.user_part_length))
-        link_length_end = .;
+    } > APP_FLASH AT> APP_FLASH

+    .text :
+    {
         . = ALIGN(4);

         link_code_location = .;

[larseggert]

Neither the fix/linker_file nor the feature/part1_sram branch worked, but your patch above did.

[sviraaj]

The patch worked for me too. But any idea why this is happening? The location counter ('.') just before .text section seems to be 0x000d4018 and just after the section seems to be 0x000d4020 as @larseggert mentioned. Just curious as to how this happens without any section attributes or ALIGN statements? Thanks for the WAR.

[avtolstoy]

@sviraaj Most likely this is a GCC/ld bug, however we haven't verified with the newer toolchain versions.