BFD bug in msp430-elf-gcc 4.9.3 (stock and TI source release 3_04_05_00)

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

BFD bug in msp430-elf-gcc 4.9.3 (stock and TI source release 3_04_05_00)

Zvika Meiseles
Hi,

I've encountered another BFD problem, similar to the one reported by Eric a
few months back (2015-03-25 13:43:23).
I am currently using GCC 4.9.3 and binutils 2.25.1 on a gentoo machine
(which include the fix by Alan Modra), and I'm getting the following error:

  /usr/libexec/gcc/msp430-elf/ld: BFD (Gentoo 2.25.1 p1.0) 2.25.1 internal
error, aborting at
/var/tmp/portage/cross-msp430-elf/binutils-2.25.1/work/binutils-2.25.1/bfd/elf-eh-frame.c
line 1732 in _bfd_elf_write_section_eh_frame

Here is the code snippet:

    /* 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.  */
    sec_size = sec->size;
    if (sec_info->count != 0
        && sec_info->entry[sec_info->count - 1].size == 4)
      sec_size -= 4;
    if ((sec_size % ptr_size) != 0)
      abort (); */* this is line 1732 */*

I've narrowed it down to an [.eh_frame] in one of the object files, which
has a size of 74 (0x4a) while ptr_size is 4.

Here is the complete output of objdump:

  $ msp430-elf-objdump -h /tmp/1.o

  /tmp/1.o:     file format elf32-msp430

  Sections:
  Idx Name          Size      VMA       LMA       File off  Algn
    0 .text         00000000  00000000  00000000  00000034  2**0
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
    1 .data         00000000  00000000  00000000  00000034  2**0
                    CONTENTS, ALLOC, LOAD, DATA
    2 .bss          00000000  00000000  00000000  00000034  2**0
                    ALLOC
    3 .text.startup.main 00000026  00000000  00000000  00000034  2**1
                    CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
*    4 .eh_frame     0000004a  00000000  00000000  0000005a  2**1*
*                    CONTENTS, ALLOC, LOAD, RELOC, DATA*
    5 .comment      0000002b  00000000  00000000  000000a4  2**0
                    CONTENTS, READONLY
    6 .MSP430.attributes 00000017  00000000  00000000  000000cf  2**0
                    CONTENTS, READONLY

I've tried replacing both msp43-elf-g++ and msp430-elf-ld with ones I built
from source obtained from TI's site (
http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/exports/msp430-gcc-source.tar.bz2)
but received the same results.

HAs anyone else encountered this problem?
Is the problem in the linker or compiler:
Should LD be able to handle this eh_frame?
Or should GCC have created an eh_frame with correct (i.e. aligned) size ?

Thank you very much for your help,

------------------------------------------------------------------------------

_______________________________________________
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.3 (stock and TI source release 3_04_05_00)

nick clifton
Hi Zvika,

> I've encountered another BFD problem, similar to the one reported by Eric a
> few months back (2015-03-25 13:43:23).

>    /usr/libexec/gcc/msp430-elf/ld: BFD (Gentoo 2.25.1 p1.0) 2.25.1 internal
> error, aborting at
> /var/tmp/portage/cross-msp430-elf/binutils-2.25.1/work/binutils-2.25.1/bfd/elf-eh-frame.c
> line 1732 in _bfd_elf_write_section_eh_frame

> I've narrowed it down to an [.eh_frame] in one of the object files, which
> has a size of 74 (0x4a) while ptr_size is 4.

Please could you try the patch found in this email (and copied here for
ease of access):

   https://www.sourceware.org/ml/binutils/2015-07/msg00319.html

The issue is the the MSP430 has two different sizes for its pointers,
depending upon whether large mode has been enabled or not, but the BFD
library was assuming that pointers were always 4 bytes long...


Cheers
   Nick

diff --git a/bfd/elf32-msp430.c b/bfd/elf32-msp430.c
index 9e69791..83bb9ce 100644
--- a/bfd/elf32-msp430.c
+++ b/bfd/elf32-msp430.c
@@ -2532,6 +2532,27 @@ msp430_elf_is_target_special_symbol (bfd *abfd,
asymbol *sym)
    return _bfd_elf_is_local_label_name (abfd, sym->name);
  }

+static bfd_boolean
+uses_large_model (bfd *abfd)
+{
+  obj_attribute * attr;
+
+  if (abfd->flags & BFD_LINKER_CREATED)
+    return FALSE;
+
+  attr = elf_known_obj_attributes_proc (abfd);
+  if (attr == NULL)
+    return FALSE;
+
+  return attr[OFBA_MSPABI_Tag_Code_Model].i == 2;
+}
+
+static unsigned int
+elf32_msp430_eh_frame_address_size (bfd *abfd, asection *sec
ATTRIBUTE_UNUSED)
+{
+  return uses_large_model (abfd) ? 4 : 2;
+}
+
  /* This is gross.  The MSP430 EABI says that (sec 11.5):

       "An implementation may choose to use Rel or Rela
@@ -2563,6 +2584,7 @@ msp430_elf_is_target_special_symbol (bfd *abfd,
asymbol *sym)
  #undef  elf_backend_obj_attrs_arg_type
  #define elf_backend_obj_attrs_arg_type elf32_msp430_obj_attrs_arg_type
  #define bfd_elf32_bfd_merge_private_bfd_data
elf32_msp430_merge_private_bfd_data
+#define elf_backend_eh_frame_address_size
elf32_msp430_eh_frame_address_size

  #define ELF_ARCH bfd_arch_msp430
  #define ELF_MACHINE_CODE EM_MSP430



------------------------------------------------------------------------------
_______________________________________________
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.3 (stock and TI source release 3_04_05_00)

Zvika Meiseles
Hi Nick,

Please could you try the patch found in this email (and copied here for

> ease of access):
>
>   https://www.sourceware.org/ml/binutils/2015-07/msg00319.html
>
> The issue is the the MSP430 has two different sizes for its pointers,
> depending upon whether large mode has been enabled or not, but the BFD
> library was assuming that pointers were always 4 bytes long...
>
>
> Cheers
>   Nick
>
Thank you!
I've applied the patch to the stock binutils and it works now!
I'll try the TI/RH sources next.
I hope this gets into the next release and picked up by Gentoo soon :-)

Cheers,
  Zvika

------------------------------------------------------------------------------

_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users