BFD bug in msp430-elf-gcc 4.9.1 (TI source release 3_02_03_00)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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!

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: BFD bug in msp430-elf-gcc 4.9.1 (TI source release 3_02_03_00)

nick clifton
Hi 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.

> 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

> 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?

Yes, that would appear to be the case.

> 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

> 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  <[hidden email]>

        * 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


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users