Discussion - STM port & GCC Runtime Library Exception about micropython HOT 12 CLOSED

What is the resulting binary size using libgcc?

from micropython.

The size difference is about 1K. I'm not sure if this is libgcc or a combination of using gcc (instead of ld) and libgcc.

from micropython.

Well, 1k is probably because the __aeabi_d2f etc functions are now implemented!

If we can use libgcc, that's nice. But then if the board is used in a commercial product, would they have to use a different library? Since it's a standard C library, it would be easy to swap in/out.

from micropython.

libgcc is not the standard C library, it's the compiler library for cases where implementing compiled code with inlined code would create too large a file. For example, in the above case converting a float to a double and vice versa might produces way too large of a binary if this code was placed inline, so these are provided as a function in libgcc.a. So in essence this is part of the compiled product rather than a gnu library such as the c library.

That's my understanding of it. If anyone else thinks otherwise, please feel free to comment.

So, since the gcc compiler can be made to make commercial products and libgcc.a is just a compile time library then I would say it can be used commercially as well.

from micropython.

As a side effect of linking to libgcc.a, it seems the libgcc.a library that comes with arm-none-eabi is a bit incompatible with the compile flags in stm. As I linked to more functions in libgcc.a (as a result of building a slimmed down c library)

I had to change -mabi=aapcs-linux to -mabi=aapcs and -mfloat-abi=hard to -mfloat-abi=softfp

I have still some more coding to do to get a minimal c library printf function working before I can build a binary that I can test. I should know more about the implications of changing these flag then.

from micropython.

It looks like it is possible to link to libgcc.a with the stm port of micropython without affecting the mit license. Gcc contains a runtime library library exception.

Yep, that's how runtime-level stuff works. Linux doesn't want to force you to run only FOSS software, or disallow to run commercial software. GCC doesn't want to force you do develop/compile only opensource software, and neither Glibc wants to force open-source license on your software. There's good background reason for that: all those things implement basic runtime environment, there're lot of other implementation of it. So, Linux/GCC/Glibc in the first approximation don't provide any new value, they implement just baseline. It makes no sense to cause hurdles when using them with commercial software - if they do, commercial stuff will just stay on commercial OSes/compilers/runtime libs, FOSS (and GNU in particular) will gain nothing, lose big user base.

It's different with application-level libs. Say, GNU readline when was released represented great advance in state of art of command-line interface (heck, now people got so used to completion that think they can name commands with it in mind (#17)), and was licensed under GPL, so if people wanted to benefit from capabilities it offers, they should benefit GNU project in return.

So, no worries that libgcc indeed works like FAQ described - there's solid logic behind FOSS licenses (unlike some commercial licenses which have funny holes and patches in their logic).

from micropython.

that comes with arm-none-eabi

Which exactly gcc build do you use? (download url/version)

I had to change -mabi=aapcs-linux to -mabi=aapcs and -mfloat-abi=hard to -mfloat-abi=softfp

-mfloat-abi=softfp change is potentially non-optimal. We don't have extra ticks in mere 120MHz to pass floats via non-float registers and move them back to FPU, which softfp likely means (but you should check that).

from micropython.

well figured out what was going on.

Aparently, the libgcc.a that comes with the arm-none-eabi from launchpad.net is a multi lib - in other words there are quite a few variations of libgcc.a available. From the command line type

arm-none-eabi-gcc -print-multi-lib

this will output what flags will trigger which libgcc.a to use. From this information the linker flags should be

-march=armv7e-m -mthumb -mfloat=hard -mfpu=fpv4-sp-d16

also these linker flags should match the gcc flags.

Now the correct libgcc.a is linked in and everything (so far) seems to be working

from micropython.

+1

I'm using __aeabi_uldivmod, __aeabi_llsr and __aeabi_llsl in str() implement (#81), it would really helpful if using libgcc.a.

from micropython.

.

from micropython.

Running arm-none-eabi-gcc -print-multi-lib gives me:

.;
thumb/arm7tdmi-s;@mthumb@mcpu=arm7tdmi-s
thumb/cortex-m0;@mthumb@mcpu=cortex-m0
thumb/cortex-m3;@mthumb@mcpu=cortex-m3
thumb/cortex-m4;@mthumb@mcpu=cortex-m4
thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16;@mthumb@mcpu=cortex-m4@mfloat-abi=hard@mfpu=fpv4-sp-d16

This last line seems to match exactly what's in stm/Makefile. @hagenkaye why use the march=armv7e-m flag?

from micropython.

I guess it depends on how the compiler was built. I'm using gcc 4.7.1 downloaded from-

https://launchpad.net/gcc-arm-embedded

the output from -print-multi-lib is different.

from micropython.