• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 769 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430-GCC-OPENSOURCE: Binary executables build from source, are about 5x larger than the pre-built executables

jonahugh
Intellectual 415 points
Part Number: MSP430-GCC-OPENSOURCE
Other Parts Discussed in Thread: MSP430-FLASHER

I downloaded, and have been using msp430-gcc-8.3.0.16_linux64 software tools, which seem to have been functioning correctly so far, except for the fact that whenever I tries to enable --tui (text user interface) gdb mode, gdb crashed with:

[ No Source Available ]Segmentation fault (core dumped)

Since I could not figure out why this was happening, I decided to build the whole set of tools from source.

I struck a few snags along the way, and decided to separate the configure steps for: binutils, gcc and gdb by stripping out the unecessary parts of README-build.sh script into build-binutils.sh, build-gcc.sh and build-gdb.sh, respectively.

Whilst doing this, I also tweaked a few parameters, particularly for the gdb build, as follows:

#configure_args_gdb=$(echo --disable-{binutils,gas,ld,gprof,etc} --without-{mpfr,lzma} --with-python=no)
configure_args_gdb=$(echo --without-{mpfr,lzma} --with-python=yes --enable-targets=all --enable-tui --with-curses )

because I noticed that tui and python were not previously enabled, and I wanted them both.

binutils and gcc seemed to build OK.

I found that I had to install python-dev onto my system, because I kept running into an error stating that there was an issue with python 2.7.

I finally managed to get gdb to build and I briefly tested to make sure that tui mode was working, which it appeared to be, since it no longer crashed.

Owing to the fact that I had added the necessary support files to the original build and also to make sure that all the necessary components were in the new build, I did a directory comparison, and immediately noticed that a directory called lib64, did not appear in the new build (BTW, I had added the library file, libmsp430.so to this directory, since it was needed by msp430-flasher).

Anyhow, I just started checking through, to make sure that all the components were there in the new build, when I noticed that all of the executables in the install/bin directory, appear to be about 5 times larger than the original pre-built ones.

I have done one or two cursory checks, by running a few of the newly built executables, with --version and -h options, just to see if they are basically alive or dead, and seem to be behaving normally.

Could anyone perhaps suggest why this may have happened please?

I have attached the three modified configure scripts, for reference.

Thanks in advance.

Jonathan Roberts

binutils-gcc-gdb-sh.zip

  • 0
    Guru 25185 points

    When you say that they are five times as large do you mean the code size as reported by size or the file size as reported by "ls -l"?

    If the latter then I suspect that those executables have been stripped of their symbol information while the files you built have not.

  • 0
    Expert 2410 points

    Hi Jonathan,

    Jonathan Roberts14 said:

    Whilst doing this, I also tweaked a few parameters, particularly for the gdb build, as follows:

    #configure_args_gdb=$(echo --disable-{binutils,gas,ld,gprof,etc} --without-{mpfr,lzma} --with-python=no)
    configure_args_gdb=$(echo --without-{mpfr,lzma} --with-python=yes --enable-targets=all --enable-tui --with-curses )

    because I noticed that tui and python were not previously enabled, and I wanted them both.

    Since we need the binaries to be portable and work on a variety of system configurations, some features have to be disabled.

    python, mpfr, lzma aren't available on clean installs of some Linux distributions or macOS.

    However, we are planning to ship an additional "msp430-elf-gdb-py" binary in the next release series (next year) which will have python support enabled.

    Regarding "tui", I'll investigate whether we can enable this by default or if it needs to be built into a separate binary to maintain portability.

    Jonathan Roberts14 said:

    Owing to the fact that I had added the necessary support files to the original build and also to make sure that all the necessary components were in the new build, I did a directory comparison, and immediately noticed that a directory called lib64, did not appear in the new build (BTW, I had added the library file, libmsp430.so to this directory, since it was needed by msp430-flasher).

    lib64 doesn't contain much, just some 64-bit libraries for the host, the toolchain might still work fine even if this is missing on 64-bit systems.

    However I would expect it to be created if you are building on a 64-bit system. Are you using 64-bit Linux or 32-bit?

    Jonathan Roberts14 said:

    Anyhow, I just started checking through, to make sure that all the components were there in the new build, when I noticed that all of the executables in the install/bin directory, appear to be about 5 times larger than the original pre-built ones.

    I have done one or two cursory checks, by running a few of the newly built executables, with --version and -h options, just to see if they are basically alive or dead, and seem to be behaving normally.

    Could anyone perhaps suggest why this may have happened please?

    David is correct in his previous post. We strip debug information from the target libraries, and other symbols from executable files.

    This won't affect too much in practice. If you are debugging library code it is not really useful to have debug information unless you also have the source.

    Since you built the toolchain from scratch and you may find it useful to retain the debug information, it's up to you.

    You can strip the debug information from the libraries by running a command such as below (msp430-elf-strip will fail on native libraries and executables, but you can ignore that).

    for f in $(find ${install_dir} -type f); do
    msp430-elf-strip --strip-debug $f &> /dev/null
done

    Regards,

  • 0 in reply to David Schultz
    Intellectual 415 points

    binary-sizes.zipHi David,

    David Schultz36 said:
    When you say that they are five times as large do you mean the code size as reported by size or the file size as reported by "ls -l"?

    The actual executables are about 5 times larger. Please see the two attached text files, which contain the output from ls -l on each respective directory.

    I see that there is another response from another member/colleague and will read that now.

    Thank you for your help.

    Best Regards,

    Jonathan

  • 0 in reply to Jozef_Lawrynowicz
    Intellectual 415 points

    Hi Jozef,

    Thank you very much for your detailed response.

    I attached size comparisons of the bin directories for the prebuilt and compiled versions, and would be interested to hear your comments about the significant difference please.

    Since they are much larger, they would of course occupy a significant amount more laptop memory.

    I would really like to understand, as to whether or not there is anything grossly wrong with these executables.

    I will run a test, as you have suggested and let you know what happens.

    Thanks and Regards,

    Jonathan

  • 0 in reply to jonahugh
    Expert 2410 points

    Hi Jonathan,

    There shouldn't be anything wrong with the executables. Try the following strip commands that we use during packaging of the toolchain. They should get your sizes in line with what is prebuilt. If there's still a big gap, I'll take another look.

    # Strip binaries
msp430_strip="${install_dir}/bin/msp430-elf-strip"
for f in $(find ${install_dir}/bin -type f); do
  if [ -x "$f" ] && [ -f "$f" ]; then
    strip --strip-unneeded $f &> /dev/null
  fi
done
for f in $(find ${install_dir}/libexec/gcc/msp430-elf/*/ -type f); do
  if [ -x "$f" ] && [ -f "$f" ]; then
    strip --strip-unneeded $f &> /dev/null
  fi
done
for f in $(find ${install_dir} -type f); do
    $msp430_strip --strip-debug $f &> /dev/null
strip -S ${install_dir}/lib/libmsp430-elf-sim.a &> /dev/null

    Regards,

  • 0 in reply to Jozef_Lawrynowicz
    Intellectual 415 points

    Hi Jozef,

    Thank you very much for your excellent and quick response.

    I will follow your suggestion and let you know the outcome later, since I have some other things to attend to now, which will probably be tomorrow, your time (guessing you are in the UK, I am in NZ).

    I really appreciate your help.

    Best Regards,

    Jonathan

  • 0 in reply to jonahugh
    Expert 2410 points

    No problem, happy to help. Yes, I am based in the UK.

    Regards,

  • 0 in reply to Jozef_Lawrynowicz
    Intellectual 415 points

    Hi Jozef,

    After running the strip script which you sent me, there was a huge reduction in the size of the executables, however, I notice that they are still larger than your pre-built ones.

    Provided they all work correctly, I will be quite happy.

    For your reference, however, I have attached the sizes for, stripped, compiled and pre-built executables.

    Thanks a lot for your help.

    Best Regards,

    Jonathanstripped-compiled-prebuilt-sizes.zip

**Attention** This is a public forum