Skip to content
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

Compilation fixes for GCC 5.4.x #1159

Merged
merged 5 commits into from Nov 29, 2016

Conversation

@sergeuz
Copy link
Member

commented Nov 6, 2016

Closes #1085 and #1054. Tested with GCC 5.4.1, 5.3.1 and 4.9.3


Doneness:

  • Contributor has signed CLA
  • Problem and Solution clearly stated
  • Code peer reviewed
  • API tests compiled
  • Run unit/integration/application tests on device
  • Add documentation
  • Add to CHANGELOG.md after merging (add links to docs and issues)

Enhancements

@sergeuz sergeuz added this to the 0.7.x milestone Nov 6, 2016

@sergeuz sergeuz referenced this pull request Nov 12, 2016
2 of 2 tasks complete
@@ -3,7 +3,7 @@ MEMORY
APP_FLASH (rx) : ORIGIN = 0x08020000, LENGTH = 256K

/* todo - SRAM must start also at an offset after what has been reserved for system-module 1 */
SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 384
SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 1K

This comment has been minimized.

Copy link
@m-mcgowan

m-mcgowan Nov 24, 2016

Contributor

That's quite a large increase - also I would expect system part 2 RAM to also be extended. Could you please investigate why the size change is required - what new symbols are included - I suspect we may be pulling in unnecessary parts.

This comment has been minimized.

Copy link
@sergeuz

sergeuz Nov 24, 2016

Author Member

Sure, I'll check that. Actually, SRAM usage increased by only 300 bytes if I remember correctly, I just put "1K" to have a little more space than necessary.

This comment has been minimized.

Copy link
@m-mcgowan

m-mcgowan Nov 24, 2016

Contributor

we can't really increase the space since the system part2 RAM starts immediately afterwards so there will be a collision. Best to figure out what's consuming the extra room and try to remove it. If we anticipate a need to increase the part1 ram, then it has to be done over 2 releases - first move the floor for part2, then move the ceiling for part1.

This comment has been minimized.

Copy link
@sergeuz

sergeuz Nov 25, 2016

Author Member

oh, so in case of Photon I can extend part1's SRAM region only up to 0x20000300 address (see system_part1_module_ram_end), which gives 768 bytes? This is still enough to get this branch compiled with gcc 5.4.1 as is -- just want to ensure this PR results in correct firmware until I investigate what causes increase in static memory usage.

@sergeuz sergeuz force-pushed the feature/build_fixes branch from b3625e5 to 7341b45 Nov 25, 2016

@sergeuz

This comment has been minimized.

Copy link
Member Author

commented Nov 25, 2016

Couple of notes on this PR:

Size of the SRAM region for system-part1 on Photon has been increased to 768 bytes (maximum size possible in current configuration) – this is due to the newlib bundled with ARM GCC 5.4.x which is now using global C locale data for such functions as strtol(), isspace(), etc.:

GCC 5.4.1:

long _DEFUN(strtol, (s, ptr, base), _CONST char *__restrict s _AND char **__restrict ptr _AND int base) {
    return _strtol_l (_REENT, s, ptr, base, __get_current_locale ());
}

GCC 5.3.1:

long _DEFUN(strtol, (s, ptr, base), _CONST char *__restrict s _AND char **__restrict ptr _AND int base) {
    return _strtol_r (_REENT, s, ptr, base);
}

It would be good to investigate how to exclude locale data from the build entirely (can't be done via feature macros at first glance), or at least have it allocated only in one of the firmware parts.

Also, this PR defines _POSIX_C_SOURCE macro globally in build/module.mk makefile, effectively excluding GNU and BSD extensions for libc from the global namespace. This may break compilation of user code that depends on those extensions.

@technobly technobly merged commit cf6789a into develop Nov 29, 2016

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@technobly technobly deleted the feature/build_fixes branch Nov 29, 2016

@technobly technobly modified the milestones: 0.7.x, 0.6.1 Nov 29, 2016

@jhodapp

This comment has been minimized.

Copy link

commented Nov 30, 2016

Thanks for the fix, will definitely give this a try soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.