LeafLabs Garden

A place to share, learn, and grow...

1. 

   JL2010
   Member

   I'm currently using a hacked up build system to build libmaple and target an STM32F1xx medium density chip. All of this works great on my Macbook but I recently made the switch to an Ubuntu 64-bit desktop. After installing the ia32-libs, I was able to run the tool chain binaries downloaded from the Unix Tool Chain set-up guide.

   However, when calling the linker [LD], it throws this error:

   arm-none-eabi-g++: selected multilib 'thumb2' not installed

   I'm not exactly sure what to make of it. I know what some are going to tell me: "But there's now support for the STM32F value line! Just check out the latest on github!" - well... I'm kind of neck deep in a project now and I can't make the switch as of now. If I were starting fresh, then yes definitely. Either way, I'm not sure if it's a problem with my modified build system (which works flawlessly on my Mac) or if it's because I'm trying to run these 32-bit compiler binaries in a 64-bit environment.

   Any help would be appreciated! Thank you.

   Posted 3 years ago #
2. 

   JL2010
   Member

   Scratch that. I downloaded the tool chain again and replaced the entire tool chain directory with the new one. It works! Must be an issue with the tool chain that was checked in to our repository...

   HOWEVER! Question #2:

   The output from my Mac:

   text: 22440 data: 2296 bss: 168 dec: 24904

   On my linux machine:

   text: 28928 data: 2296 bss: 168 dec: 31392

   Any ideas why there's such a code size difference? They are being built using the same build process with the same flags...

   Posted 3 years ago #
3. 

   gbulmer
   Moderator

   JL2010 - The size difference could be caused by several sources:
   1. Different version of the compiler generate different code - I did notice a gcc 'size' regression message a few months ago.
   2. There is something different in the build process for the libraries, and they are the cause of differences.
   3. A flag is interpreted differently between two versions of the compiler - for example, IIRC 4.7 uses 'Whole program linking', which may make the difference.
   4. The way the size is reported is misleading, and it is not so big a difference.

   How critical is the difference?

   You could check 1. by comparing the object files generated for your program (before linking) by the two compilers.

   diff will tell you if they files are different. If they are the same, it is not 1.

   If they are different, it may account for all the difference or only a small part, i.e. the explanation is 1 plus some other causes.

   When the object files are different, it would then be easier to compare them using objdump (which is documented in binutils). objdump will disassemble object files into a readable assembler source files.
   diff will identify differences between the assembler source, and something like 'grep' or 'grep -v' will let you trim out non-code stuff to see the code differences. With such a large difference, 6,488Bytes, it should be clear if there is a lot of extra lines in one file of assembler source.

   If this doesn't explain the difference, try diff and objdump on the whole program.

   (Full disclosure: I am not a member of LeafLabs staff.)

   Posted 3 years ago #

RSS feed for this topic

Reply

You must log in to post.