[Mspgcc-users] BFD bug in msp430-elf-gcc 4.9.1 (TI source release 3_02_03_00)

[Eric]

Hi folks-

I have one of those bugs from hell that comes and goes without any discernable pattern
to its cause, so I'm looking for assistance as to where I should start for troubleshooting.

I am writing an alternative Arduino port for the MSP430 architecture using msp430-elf-gcc,
currently using the 4.9.1 release from TI - built from source on a Fedora 19 64-bit laptop.
Source obtained via http://www.ti.com/tool/msp430-gcc-opensource

I have a few C++ classes in the "core" folder which collect and manage CPU speed-related
matters, and I've found that on occasion doing seemingly innocuous operations on these
classes causes the following error on link:

/opt/local/msp430-elf-gcc/lib/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld: BFD (GNU Binutils) 2.24.51.20140505 internal error, aborting at ../../bfd/elf-eh-frame.c line 1726 in _bfd_elf_write_section_eh_frame

/opt/local/msp430-elf-gcc/lib/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld: Please report this bug.

collect2: error: ld returned 1 exit status

Looking at the binutils source, this is failing at:

/* We don't align the section to its section alignment since the
runtime library only expects all CIE/FDE records aligned at
the pointer size. _bfd_elf_discard_section_eh_frame should
have padded CIE/FDE records to multiple of pointer size with
size_of_output_cie_fde. */
if ((sec->size % ptr_size) != 0)
abort ();


So a section is getting generated with improperly alignment I'm guessing? Is there any
tool I could use to ascertain this - I know the compiler is building all the .o files,
and it's just bombing on linking, so can msp430-elf-objdump be used to somehow spot the
"odd-sized section"?

I would provide more detail but the source is a bit large and the bug rather ... random (yet
repeatable), so I'm mostly looking for expert advice on how I can dig deeper and hopefully
spot the bug myself.


FYI- Command used to build the .o files (example for main.cpp):

/opt/local/msp430-elf-gcc/bin/msp430-elf-g++ -c -g -Os -ffunction-sections -fdata-sections -Wall -fpermissive -mmcu=msp430f5529 -DF_CPU_DEFAULT=16000000L -msmall -DARDUINO=10601 -DENERGIA=10601 -DARDUINO_MSP430_LPMSP430F5529 -DARDUINO_ARCH_MSP430 -DMSP430_MEMORY_small -I/home/ebrundic/Documents/Arduino/hardware/spirilis/msp430/cores/msp430 -I/home/ebrundic/Documents/Arduino/hardware/spirilis/msp430/variants/launchpad_f5529 /home/ebrundic/Documents/Arduino/hardware/spirilis/msp430/cores/msp430/main.cpp -o /tmp/build3887189002897295326.tmp/main.cpp.o


Command used to link everything (core API objects get bundled up into "core.a" beforehand,
then the "sketch" .o linked with it):

/opt/local/msp430-elf-gcc/bin/msp430-elf-g++ -Os -Wl,--gc-sections -minrt -mmcu=msp430f5529 -o /tmp/build3887189002897295326.tmp/f5529_skunk1.cpp.elf -u main /tmp/build3887189002897295326.tmp/f5529_skunk1.cpp.o /tmp/build3887189002897295326.tmp/core.a -L/tmp/build3887189002897295326.tmp -T msp430f5529.ld -lm


GCC version (msp430-elf-gcc -v):
Using built-in specs.
COLLECT_GCC=msp430-elf-gcc
COLLECT_LTO_WRAPPER=/opt/local/msp430-elf-gcc/libexec/gcc/msp430-elf/4.9.1/lto-wrapper
Target: msp430-elf
Configured with: ../configure --prefix=/opt/local/msp430-elf-gcc --target=msp430-elf --enable-languages=c,c++ --disable-nls
Thread model: single
gcc version 4.9.1 20140707 (prerelease (msp430-14r1-167)) (GNUPro 14r1) (Based on: GCC 4.8 GDB 7.7 Binutils 2.24 Newlib 2.1) (GCC)

LD version (msp430-elf-ld -v):
GNU ld (GNU Binutils) 2.24.51.20140505



Thanks!

[Nicholas Clifton]

Hi Eric,

Post by Eric
I have one of those bugs from hell that comes and goes without any discernable pattern
to its cause, so I'm looking for assistance as to where I should start for troubleshooting.

If the bug is reproducible with a given set of object files and linker
command line, then you could open a binutils bug report here:

https://sourceware.org/bugzilla/

Also, it would be worth downloading and building a linker from the
current mainline FSF binutils sources. That linker should be backwards
compatible with the one from the TI release, and it may, possibly,
contain a bug fix which solves the problem.

Post by Eric
msp430-elf/bin/ld: BFD (GNU Binutils) 2.24.51.20140505 internal error, aborting at ../../bfd/elf-eh-frame.c line 1726 in _bfd_elf_write_section_eh_frame
/* We don't align the section to its section alignment since the
runtime library only expects all CIE/FDE records aligned at
the pointer size. _bfd_elf_discard_section_eh_frame should
have padded CIE/FDE records to multiple of pointer size with
size_of_output_cie_fde. */
if ((sec->size % ptr_size) != 0)
abort ();
So a section is getting generated with improperly alignment I'm guessing?

Yes, that would appear to be the case.

Post by Eric
Is there any
tool I could use to ascertain this - I know the compiler is building all the .o files,
and it's just bombing on linking, so can msp430-elf-objdump be used to somehow spot the
"odd-sized section"?

Yes:

msp430-elf-objdump -h foo.o

should show you all the sections in foo.o. You could also use readelf
to perform the same task, as in:

msp430-elf-readelf -S foo.o

Post by Eric
I would provide more detail but the source is a bit large and the bug rather ... random (yet
repeatable), so I'm mostly looking for expert advice on how I can dig deeper and hopefully
spot the bug myself.

I would suggest that you add a printf before the abort that prints out
the name of the section (sec->name) and the size, and just to be
paranoid, the value of ptr_size. That will help narrow down which
section(s) is causing the problem.

I also see that in the current mainline sources have this patch:

2014-11-11 Alan Modra <***@gmail.com>

* elf-eh-frame.c (_bfd_elf_write_section_eh_frame): Adjust section
size check to account for possible zero terminator.

which may well address the problem that you have encountered. Details
of the patch can be found here:

https://www.sourceware.org/ml/binutils/2014-11/msg00090.html

Cheers
Nick