arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Shaun Jackman]

arm-elf-ld crashed while linking a project compiled with GCC 4.0.1.

$ arm-elf-gcc ...
collect2: ld terminated with signal 11 [Segmentation fault], core dumped

It's a fairly large project and I haven't been able to boil it down to
a small test case yet, but here's the offending line and the
backtrace. I hope it's useful.

Please cc me in your reply. Cheers,
Shaun

$ gdb /usr/local/arm-elf/bin/ld core.21836
...
#0  0x0807784f in elf32_arm_compare_mapping (a=0x2ad0e788, b=0x2ad0e788)
    at ../../bfd/elf32-arm.c:5536
5536      return ((const elf32_arm_section_map *) a)->vma
(gdb) p ((const elf32_arm_section_map *) a)
$1 = (const struct elf32_elf_section_map *) 0x2ad0e788
(gdb) p *((const elf32_arm_section_map *) a)
Cannot access memory at address 0x2ad0e788
(gdb) bt
#0  0x0807784f in elf32_arm_compare_mapping (a=0x2ad0e788, b=0x2ad0e788)
    at ../../bfd/elf32-arm.c:5536
#1  0x0097d6a4 in _quicksort () from /lib/tls/libc.so.6
#2  0x0097dc40 in qsort () from /lib/tls/libc.so.6
#3  0x0807789a in elf32_arm_write_section (output_bfd=0x8900290,
    sec=0x8a40424, contents=0x8c5fb78 "empty\n�\021\002")
    at ../../bfd/elf32-arm.c:5562
#4  0x0808bf6b in elf_link_input_bfd (finfo=0xbff324f0, input_bfd=0x89cd050)
    at ../../bfd/elflink.c:7356
#5  0x0808e64b in bfd_elf_final_link (abfd=0x8900290, info=0x80d9220)
    at ../../bfd/elflink.c:8163
#6  0x08059dea in ldwrite () at ../../ld/ldwrite.c:554
#7  0x08057848 in main (argc=1, argv=0xbff32644) at ../../ld/ldmain.c:467

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Shaun Jackman]

I replaced ld 2.16.1 with ld 2.15 (only ld, not all of binutils) and
it does not crash in this case.

Please cc me in your reply. Cheers,
Shaun

On 7/28/05, Shaun Jackman <sjackman@gmail.com> wrote:
> arm-elf-ld crashed while linking a project compiled with GCC 4.0.1.
...

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Nick Clifton]

Hi Shaun,

> I replaced ld 2.16.1 with ld 2.15 (only ld, not all of binutils) and
> it does not crash in this case.

Not surprising since the mapping symbol ordering code was not in 2.15.

> It's a fairly large project and I haven't been able to boil it down to
> a small test case yet, but here's the offending line and the
> backtrace. I hope it's useful.

Sorry - I had a quick look at the code, but it appears to be good.  So 
we really are going to need a test case that can reproduce the problem.

Either that or maybe you could do some debugging for us ?  It looks like 
bad data is being placed into the section's map array or else the 
section has never had its target specific data pointer initialised 
correctly.  Can you find out the answers to these questions:

   * Which section is being processed when the seg fault occurs ?
   * What is the value for elf32_arm_section_data() for that section ?
   * Was the map for this section ever bfd_zalloc()ed by 
elf32_arm_new_section_hook() or bfd_realloc()ed by 
elf32_arm_output_symbol_hook() ?
   * Are their other values in the map array, and if so are they valid ? 
  (ie could something else be stomping on this, correctly allocated and 
initialised, memory).

Cheers
   Nick

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Shaun Jackman]

On 7/29/05, Nick Clifton <nickc@redhat.com> wrote:
> Sorry - I had a quick look at the code, but it appears to be good.  So
> we really are going to need a test case that can reproduce the problem.

> Either that or maybe you could do some debugging for us ?  It looks like
> bad data is being placed into the section's map array or else the
> section has never had its target specific data pointer initialised
> correctly.  Can you find out the answers to these questions:

Here's the debugging results. I hope it's useful.

>    * Which section is being processed when the seg fault occurs ?

.data

(gdb) p *sec
$10 = {name = 0x9099f9f ".data", id = 995, index = 0, next = 0x90a1b30,
  flags = 291, user_set_vma = 1, linker_mark = 1, linker_has_input = 0,
  gc_mark = 0, segment_mark = 0, sec_info_type = 0, use_rela_p = 1,
  has_tls_reloc = 0, has_gp_reloc = 0, need_finalize_relax = 0,
  reloc_done = 0, vma = 0, lma = 0, size = 6, rawsize = 0,
  output_offset = 7176, output_section = 0x8e29060, alignment_power = 0,
  relocation = 0x0, orelocation = 0x0, reloc_count = 0, filepos = 52,
  rel_filepos = 0, line_filepos = 0, userdata = 0x0, contents = 0x0,
  lineno = 0x0, lineno_count = 0, entsize = 0, kept_section = 0x0,
  moving_line_filepos = 0, target_index = 0, used_by_bfd = 0x9099fdc,
  constructor_chain = 0x0, owner = 0x905f050, symbol = 0x9099fa8,
  symbol_ptr_ptr = 0x90a1b14, link_order_head = 0x0, link_order_tail = 0x0}


>    * What is the value for elf32_arm_section_data() for that section ?

(gdb) p *(struct _arm_elf_section_data *)sec->used_by_bfd
$11 = {elf = {this_hdr = {sh_name = 27, sh_type = 1, sh_flags = 3,
      sh_addr = 0, sh_size = 6, sh_entsize = 0, sh_link = 0, sh_info = 0,
      sh_offset = 52, sh_addralign = 1, bfd_section = 0x90a1a8c,
      contents = 0x0}, rel_hdr = {sh_name = 0, sh_type = 0, sh_flags = 0,
      sh_addr = 0, sh_size = 0, sh_entsize = 0, sh_link = 0, sh_info = 0,
      sh_offset = 0, sh_addralign = 0, bfd_section = 0x0, contents = 0x0},
    rel_hdr2 = 0x0, rel_count = 0, rel_count2 = 0, this_idx = 0, rel_idx = 0,
    rel_idx2 = 0, dynindx = 0, linked_to = 0x0, rel_hashes = 0x0,
    relocs = 0x0, local_dynrel = 0x0, sreloc = 0x0, group = {name = 0x0,
      id = 0x0}, sec_group = 0x0, next_in_group = 0x0, sec_info = 0x0},
  mapcount = 151410616, map = 0x9065808}

>    * Was the map for this section ever bfd_zalloc()ed by
> elf32_arm_new_section_hook()

I don't know about this particular map that's causing the crash, but
elf32_arm_new_section_hook is called for the .data section many times.
This is the first occurence.

(gdb) p *sec
$15 = {name = 0x8dc12b9 ".data", id = 17, index = 1, next = 0x0, flags = 0,
...
(gdb) bt
#0  elf32_arm_new_section_hook (abfd=0x8db8900, sec=0x8dc2fd8)
    at ../../bfd/elf32-arm.c:5522
#1  0x08068ea5 in bfd_section_init (abfd=0x8db8900, newsect=0x8dc2fd8)
    at ../../bfd/section.c:699
#2  0x0807ac82 in _bfd_elf_make_section_from_shdr (abfd=0x8db8900,
    hdr=0x8dc1170, name=0x8dc12b9 ".data") at ../../bfd/elf.c:692
...

> or bfd_realloc()ed by elf32_arm_output_symbol_hook() ?

No, bfd_realloc() is never called.

>    * Are their other values in the map array, and if so are they valid ?
>   (ie could something else be stomping on this, correctly allocated and
> initialised, memory).

(gdb) p *map
$7 = {vma = 0, type = 22 '\026'}
(gdb) p mapcount
$8 = 151410616

I noticed that mapcount varies from run to run. I'd guess that this is
not supposed to happen.

Hope this helps! Cheers,
Shaun

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Nick Clifton]

Hi Shaun,

>>   * What is the value for elf32_arm_section_data() for that section ?
> (gdb) p *(struct _arm_elf_section_data *)sec->used_by_bfd

Actually could you get the value of the "sec->used_by_bfd" field ?  What 
I would like to know is if this value was ever allocated by a call to 
bfd_zalloc() in elf32_arm_new_section_hook() or if the used_by_bfd field 
  is in fact just a rubbish pointer.

>>   * Are their other values in the map array, and if so are they valid ?
>>  (ie could something else be stomping on this, correctly allocated and
>>   initialised, memory).

> (gdb) p *map
> $7 = {vma = 0, type = 22 '\026'}

Hmm - the type field is supposed to be the second character of a mapping 
symbol's name.  I would expect this to either be an printable ASCII 
value or 0.  22 looks very suspicious to me.

Would it be possible for you to place a conditional breakpoint on this 
line in bfd/elf32_arm.c, (line 6549 in the sources I have):

   map[mapcount - 1].type = name[1];

and then find out the full name of the symbol whose name[1] is 22 ?  (Or 
if there is no such symbol).

> (gdb) p mapcount
> $8 = 151410616

This looks highly suspicious to me.  I seriously doubt if you have that 
many symbols in the .data section.

I think that the elf32_section_map_data array for this particular .data 
section is corrupt.  Either because the used_by_bfd pointer was never 
allocated in elf32_arm_new_section_hook() or because it was corrupted by 
  elf32_arm_output_symbol_hook().  (Although you say that the 
bfd_realloc there was never called which sounds very suspicious as well. 
  That would mean that there are no mapping symbols associated with this 
.data section and so the mapcount ought to be 0).

So - some more questions for you:

   To which bfd is this corrupt .data section attached ?  (ie what is 
the value of input_bfd->filename for the input_bfd that it being 
processed in elf_link_input_bfd() that called elf32_arm_write_section() 
when the seg fault happens).

   How many times is the function _bfd_elf_new_section_hook() called and 
is that more than the number of times that elf32_arm_new_section_hook() 
is called ?  (If so then the problem is that _bfd_elf_new_section_hook() 
creates an elf_section_data structure and not an arm_elf_section_data 
structure).

Cheers
   Nick

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Shaun Jackman]

Hello Nick,

On 7/29/05, Nick Clifton <nickc@redhat.com> wrote:
> Sorry - I had a quick look at the code, but it appears to be good.  So
> we really are going to need a test case that can reproduce the problem.

Good news! I found the test case that reproduces my bug. It involves objcopy:

$ echo 'int main() { return 0; }' > main.c
$ echo empty > empty
$ arm-elf-objcopy -Ibinary -Oelf32-littlearm empty empty.o
$ arm-elf-gcc main.c empty.o
collect2: ld terminated with signal 11 [Segmentation fault]
/usr/local/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: warning:
unknown architecture of input file `empty.o' is incompatible with arm
output

Cheers,
Shaun

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

Hi Shaun,

> Good news! I found the test case that reproduces my bug. It involves objcopy:

And ignoring a rather important warning message from the linker:

> unknown architecture of input file `empty.o' is incompatible with arm
> output

But nevertheless the linker should not seg fault, so I have created a 
patch to fix the problem.

Could you do me a couple of favours please ?

   1. Could you try out the attached patch and make sure that it works 
for you with your original test case.

   2. Please could you create a bugzilla entry for this so that we have 
somewhere to record this bug, how to reproduce it and how it was fixed.

Cheers
   Nick



[-- Attachment #2: arm-mapping.patch --]
[-- Type: text/plain, Size: 8090 bytes --]

Index: bfd/elf32-arm.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-arm.c,v
retrieving revision 1.49
diff -c -3 -p -r1.49 elf32-arm.c
*** bfd/elf32-arm.c	8 Jul 2005 06:19:58 -0000	1.49
--- bfd/elf32-arm.c	31 Jul 2005 18:47:13 -0000
*************** typedef struct elf32_elf_section_map
*** 1515,1529 ****
  }
  elf32_arm_section_map;
  
! struct _arm_elf_section_data
  {
    struct bfd_elf_section_data elf;
!   int mapcount;
    elf32_arm_section_map *map;
! };
  
  #define elf32_arm_section_data(sec) \
!   ((struct _arm_elf_section_data *) elf_section_data (sec))
  
  /* The size of the thread control block.  */
  #define TCB_SIZE	8
--- 1515,1530 ----
  }
  elf32_arm_section_map;
  
! typedef struct _arm_elf_section_data
  {
    struct bfd_elf_section_data elf;
!   unsigned int mapcount;
    elf32_arm_section_map *map;
! }
! _arm_elf_section_data;
  
  #define elf32_arm_section_data(sec) \
!   ((_arm_elf_section_data *) elf_section_data (sec))
  
  /* The size of the thread control block.  */
  #define TCB_SIZE	8
*************** elf32_arm_merge_private_bfd_data (bfd * 
*** 4400,4406 ****
  
    /* Check to see if the input BFD actually contains any sections.  If
       not, its flags may not have been initialised either, but it
!      cannot actually cause any incompatibility.  Do not short-circuit
       dynamic objects; their section list may be emptied by
      elf_link_add_object_symbols.
  
--- 4401,4407 ----
  
    /* Check to see if the input BFD actually contains any sections.  If
       not, its flags may not have been initialised either, but it
!      cannot actually cause any incompatiblity.  Do not short-circuit
       dynamic objects; their section list may be emptied by
      elf_link_add_object_symbols.
  
*************** elf32_arm_section_from_shdr (bfd *abfd,
*** 6511,6516 ****
--- 6512,6582 ----
    return TRUE;
  }
  
+ /* A structure used to record a list of sections, independently
+    of the next and prev fields in the asection structure.  */
+ typedef struct section_list
+ {
+   asection * sec;
+   struct section_list * next;
+   struct section_list * prev;
+ }
+ section_list;
+ 
+ /* Unfortunately we need to keep a list of sections for which
+    an _arm_elf_section_data structure has been allocated.  This
+    is because it is possible for functions like elf32_arm_write_section
+    to be called on a section which has had an elf_data_structure
+    allocated for it (and so the used_by_bfd field is valid) but
+    for which the ARM extended version of this structure - the
+    _arm_elf_section_data structure - has not been allocated.  */
+ static section_list * sections_with_arm_elf_section_data = NULL;
+ 
+ static void
+ record_section_with_arm_elf_section_data (bfd * abfd, asection * sec)
+ {
+   struct section_list * entry;
+ 
+   entry = bfd_alloc (abfd, sizeof (* entry));
+   if (entry == NULL)
+     return;
+   entry->sec = sec;
+   entry->next = sections_with_arm_elf_section_data;
+   entry->prev = NULL;
+   if (entry->next != NULL)
+     entry->next->prev = entry;
+   sections_with_arm_elf_section_data = entry;
+ }
+ 
+ static _arm_elf_section_data *
+ get_arm_elf_section_data (asection * sec)
+ {
+   struct section_list * entry;
+ 
+   for (entry = sections_with_arm_elf_section_data; entry; entry = entry->next)
+     if (entry->sec == sec)
+       return elf32_arm_section_data (sec);
+   return NULL;
+ }
+ 
+ static void
+ remove_section_with_arm_elf_section_data (asection * sec)
+ {
+   struct section_list * entry;
+ 
+   for (entry = sections_with_arm_elf_section_data; entry; entry = entry->next)
+     if (entry->sec == sec)
+       {
+ 	if (entry->prev != NULL)
+ 	  entry->prev->next = entry->next;
+ 	if (entry->next != NULL)
+ 	  entry->next->prev = entry->prev;
+ 	if (entry == sections_with_arm_elf_section_data)
+ 	  sections_with_arm_elf_section_data = entry->next;
+ 	free (entry);
+ 	break;
+       }
+ }
+ 
  /* Called for each symbol.  Builds a section map based on mapping symbols.
     Does not alter any of the symbols.  */
  
*************** elf32_arm_output_symbol_hook (struct bfd
*** 6523,6528 ****
--- 6589,6596 ----
  {
    int mapcount;
    elf32_arm_section_map *map;
+   elf32_arm_section_map *newmap;
+   _arm_elf_section_data *arm_data;
    struct elf32_arm_link_hash_table *globals;
  
    /* Only do this on final link.  */
*************** elf32_arm_output_symbol_hook (struct bfd
*** 6538,6562 ****
    if (! bfd_is_arm_mapping_symbol_name (name))
      return TRUE;
  
!   mapcount = ++(elf32_arm_section_data (input_sec)->mapcount);
!   map = elf32_arm_section_data (input_sec)->map;
    /* TODO: This may be inefficient, but we probably don't usually have many
       mapping symbols per section.  */
!   map = bfd_realloc (map, mapcount * sizeof (elf32_arm_section_map));
!   elf32_arm_section_data (input_sec)->map = map;
  
-   map[mapcount - 1].vma = elfsym->st_value;
-   map[mapcount - 1].type = name[1];
    return TRUE;
  }
  
- 
  /* Allocate target specific section data.  */
  
  static bfd_boolean
  elf32_arm_new_section_hook (bfd *abfd, asection *sec)
  {
!   struct _arm_elf_section_data *sdata;
    bfd_size_type amt = sizeof (*sdata);
  
    sdata = bfd_zalloc (abfd, amt);
--- 6606,6640 ----
    if (! bfd_is_arm_mapping_symbol_name (name))
      return TRUE;
  
!   /* If this section has not been allocated an _arm_elf_section_data
!      structure then we cannot record anything.  */
!   arm_data = get_arm_elf_section_data (input_sec);
!   if (arm_data == NULL)
!     return TRUE;
! 
!   mapcount = arm_data->mapcount + 1;
!   map = arm_data->map;
    /* TODO: This may be inefficient, but we probably don't usually have many
       mapping symbols per section.  */
!   newmap = bfd_realloc (map, mapcount * sizeof (* map));
!   if (newmap != NULL)
!     {
!       arm_data->map = newmap;
!       arm_data->mapcount = mapcount;
! 
!       map[mapcount - 1].vma = elfsym->st_value;
!       map[mapcount - 1].type = name[1];
!     }
  
    return TRUE;
  }
  
  /* Allocate target specific section data.  */
  
  static bfd_boolean
  elf32_arm_new_section_hook (bfd *abfd, asection *sec)
  {
!   _arm_elf_section_data *sdata;
    bfd_size_type amt = sizeof (*sdata);
  
    sdata = bfd_zalloc (abfd, amt);
*************** elf32_arm_new_section_hook (bfd *abfd, a
*** 6564,6569 ****
--- 6642,6649 ----
      return FALSE;
    sec->used_by_bfd = sdata;
  
+   record_section_with_arm_elf_section_data (abfd, sec);
+ 
    return _bfd_elf_new_section_hook (abfd, sec);
  }
  
*************** elf32_arm_write_section (bfd *output_bfd
*** 6586,6591 ****
--- 6666,6672 ----
  			 bfd_byte *contents)
  {
    int mapcount;
+   _arm_elf_section_data *arm_data;
    elf32_arm_section_map *map;
    bfd_vma ptr;
    bfd_vma end;
*************** elf32_arm_write_section (bfd *output_bfd
*** 6593,6606 ****
    bfd_byte tmp;
    int i;
  
!   mapcount = elf32_arm_section_data (sec)->mapcount;
!   map = elf32_arm_section_data (sec)->map;
  
    if (mapcount == 0)
      return FALSE;
  
!   qsort (map, mapcount, sizeof (elf32_arm_section_map),
! 	 elf32_arm_compare_mapping);
  
    offset = sec->output_section->vma + sec->output_offset;
    ptr = map[0].vma - offset;
--- 6674,6692 ----
    bfd_byte tmp;
    int i;
  
!   /* If this section has not been allocated an _arm_elf_section_data
!      structure then we cannot record anything.  */
!   arm_data = get_arm_elf_section_data (sec);
!   if (arm_data == NULL)
!     return FALSE;
! 
!   mapcount = arm_data->mapcount;
!   map = arm_data->map;
  
    if (mapcount == 0)
      return FALSE;
  
!   qsort (map, mapcount, sizeof (* map), elf32_arm_compare_mapping);
  
    offset = sec->output_section->vma + sec->output_offset;
    ptr = map[0].vma - offset;
*************** elf32_arm_write_section (bfd *output_bfd
*** 6644,6650 ****
--- 6730,6741 ----
  	}
        ptr = end;
      }
+ 
    free (map);
+   arm_data->mapcount = 0;
+   arm_data->map = NULL;
+   remove_section_with_arm_elf_section_data (sec);
+ 
    return FALSE;
  }
  

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Shaun Jackman]

On 7/31/05, Nick Clifton <nickc@redhat.com> wrote:
> > Good news! I found the test case that reproduces my bug. It involves objcopy:
> 
> And ignoring a rather important warning message from the linker:

Indeed; my apologies for the extra trouble this caused. I've been
using objcopy to include a binary blob in an executable for some time.
It worked nicely for years, and then about a year ago it started
generating a warning. Since it still worked though, I'd learned to
simply ignore the warning. I didn't attribute this crash to the same
warning I've been ignoring for so long.

$ arm-elf-gcc -c hello.c
$ echo data > data
$ arm-elf-objcopy -Ibinary -Oelf32-littlearm data data.o
$ arm-elf-gcc hello.o data.o
/usr/local/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: warning:
unknown architecture of input file `data.o' is incompatible with arm
output
$ file hello.o data.o
hello.o: ELF 32-bit LSB relocatable, ARM, version 1 (ARM), not stripped
data.o:  ELF 32-bit LSB relocatable, no machine, version 1 (ARM), not stripped

It looks like the warning is caused by the machine field of the object
file created by objcopy being set to 'no machine' instead of 'ARM'.
Can I pass an option to objcopy to change the machine field? Or
perhaps the machine field should default to 'ARM'.

> > unknown architecture of input file `empty.o' is incompatible with arm
> > output
> 
> But nevertheless the linker should not seg fault, so I have created a
> patch to fix the problem.
> 
> Could you do me a couple of favours please ?
> 
>    1. Could you try out the attached patch and make sure that it works
> for you with your original test case.

It does! Thank you very much.

>    2. Please could you create a bugzilla entry for this so that we have
> somewhere to record this bug, how to reproduce it and how it was fixed.

http://sourceware.org/bugzilla/show_bug.cgi?id=1147

Thanks, Nick! Cheers,
Shaun

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Nick Clifton]

Hi Shaun,

>>    2. Please could you create a bugzilla entry for this so that we have
>> somewhere to record this bug, how to reproduce it and how it was fixed.
> 
> http://sourceware.org/bugzilla/show_bug.cgi?id=1147

Thanks - I have added the patch to this PR and then closed it as FIXED. 
  I have also checked in the patch.

Cheers
   Nick

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Paul Brook]

On Tuesday 02 August 2005 09:25, Nick Clifton wrote:
> Hi Shaun,
>
> >>    2. Please could you create a bugzilla entry for this so that we have
> >> somewhere to record this bug, how to reproduce it and how it was fixed.
> >
> > http://sourceware.org/bugzilla/show_bug.cgi?id=1147
>
> Thanks - I have added the patch to this PR and then closed it as FIXED.
>   I have also checked in the patch.

This has broken arm-unknown-eabi-ar.

What appears to be happening is that ar.c:open_inarch is calling 
bfd_openr/bfd_check_format which indirectly calls 
record_section_with_arm_elf_section_data

It then calls bfd_close, which frees the memory allocated for 
sections_with_arm_elf_section_data without calling 
unrecord_section_with_arm_elf_section_data.
This then segfaults on a later call torecord_section_with_arm_elf_section_data 
because sections_with_arm_elf_section_data point to memory that no longer 
exists.

This occurred when building libstdc++.

To reproduce:

$ rm -f libtest.a
$ arm-unknown-eabi-ar cru libtest.s test1.o
Segmentation fault

You can fetch test1.o from https://nowt.dyndns.org/test1.o.bz2

Paul

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Nick Clifton]

Hi Paul,

> This has broken arm-unknown-eabi-ar.

I have reopened PR 1147 and placed a second patch there - please could 
you try it out and let me know if you have any problems with it.

Cheers
   Nick

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Paul Brook]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

On Sunday 07 August 2005 10:20, Nick Clifton wrote:
> Hi Paul,
>
> > This has broken arm-unknown-eabi-ar.
>
> I have reopened PR 1147 and placed a second patch there - please could
> you try it out and let me know if you have any problems with it.

Nearly. A couple of bugs: You were only defining bfd_elf32_close_and_cleanup 
for the symbian configuration, and and 
unrecord_section_with_arm_elf_section_data was trying to free() memory not 
allocated with malloc.

Updated patch attached.
Ok?

Paul

2005-08-07  Nick Clifton  <nickc@redhat.com>
	Paul Brook  <paul@codesourcery.com>

	PR 1147
	* elf32-arm.c (bfd_elf32_close_and_cleanup): Define.
	(elf32_arm_close_and_cleanup): New function - walk over the
	sections in the bfd that is being closed removing them from the
	list of recorded sections.
	(unrecord_section_via_map_over_sections): New helper function.
	(unrecord_section_with_arm_elf_section_data): Remove call to free.

	* elfxx-target.h (bfd_elfNN_close_and_cleanup): Only define if not
	already defined by the target.


[-- Attachment #2: patch.ar_unrecord --]
[-- Type: text/x-diff, Size: 2331 bytes --]

Index: bfd/elf32-arm.c
===================================================================
RCS file: /var/cvsroot/src-cvs/src/bfd/elf32-arm.c,v
retrieving revision 1.50
diff -u -p -r1.50 elf32-arm.c
--- bfd/elf32-arm.c	2 Aug 2005 08:17:45 -0000	1.50
+++ bfd/elf32-arm.c	7 Aug 2005 11:27:13 -0000
@@ -6572,7 +6572,6 @@ unrecord_section_with_arm_elf_section_da
 	  entry->next->prev = entry->prev;
 	if (entry == sections_with_arm_elf_section_data)
 	  sections_with_arm_elf_section_data = entry->next;
-	free (entry);
 	break;
       }
 }
@@ -6739,6 +6738,22 @@ elf32_arm_write_section (bfd *output_bfd
   return FALSE;
 }
 
+static void
+unrecord_section_via_map_over_sections (bfd * abfd ATTRIBUTE_UNUSED,
+					asection * sec,
+					void * ignore ATTRIBUTE_UNUSED)
+{
+  unrecord_section_with_arm_elf_section_data (sec);
+}
+
+static bfd_boolean
+elf32_arm_close_and_cleanup (bfd * abfd)
+{
+  bfd_map_over_sections (abfd, unrecord_section_via_map_over_sections, NULL);
+
+  return _bfd_elf_close_and_cleanup (abfd);
+}
+
 /* Display STT_ARM_TFUNC symbols as functions.  */
 
 static void
@@ -6897,6 +6912,7 @@ const struct elf_size_info elf32_arm_siz
 #define bfd_elf32_find_inliner_info	        elf32_arm_find_inliner_info
 #define bfd_elf32_new_section_hook		elf32_arm_new_section_hook
 #define bfd_elf32_bfd_is_target_special_symbol	elf32_arm_is_target_special_symbol
+#define bfd_elf32_close_and_cleanup elf32_arm_close_and_cleanup
 
 #define elf_backend_get_symbol_type             elf32_arm_get_symbol_type
 #define elf_backend_gc_mark_hook                elf32_arm_gc_mark_hook
Index: bfd/elfxx-target.h
===================================================================
RCS file: /var/cvsroot/src-cvs/src/bfd/elfxx-target.h,v
retrieving revision 1.88
diff -u -p -r1.88 elfxx-target.h
--- bfd/elfxx-target.h	29 Jul 2005 02:46:04 -0000	1.88
+++ bfd/elfxx-target.h	7 Aug 2005 10:27:18 -0000
@@ -26,7 +26,9 @@
    There are two such structures here:  one for big-endian machines and
    one for little-endian machines.   */
 
+#ifndef bfd_elfNN_close_and_cleanup
 #define	bfd_elfNN_close_and_cleanup _bfd_elf_close_and_cleanup
+#endif
 #define bfd_elfNN_bfd_free_cached_info _bfd_generic_bfd_free_cached_info
 #ifndef bfd_elfNN_get_section_contents
 #define bfd_elfNN_get_section_contents _bfd_generic_get_section_contents

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Nick Clifton]

Hi Paul,

> Nearly. A couple of bugs: You were only defining bfd_elf32_close_and_cleanup 
> for the symbian configuration, 

Oops!

> and unrecord_section_with_arm_elf_section_data was trying to free() memory not 
> allocated with malloc.
> 
> Updated patch attached.
> Ok?

Yes, but I decided that removing the call to free() in unrecorded... is 
not quite right.  We would just be leaking memory that way.  Well, 
actually we probably won't be since the memory will be freed when the 
bfd is released, but this assumes that the bfd is released in a timely 
fashion.  I prefer to have explicit malloc()s and free()s so that we 
know when the memory is supposed to be valid.

So with that one small change I have checked our combined patch in, and 
I'll close the PR again.

Cheers
   Nick

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Shaun Jackman]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]

On 8/8/05, Nick Clifton <nickc@redhat.com> wrote:
...
> So with that one small change I have checked our combined patch in, and
> I'll close the PR again.

Any chance there's a release of binutils 2.16.2 planned that fixes
PR-1147 [1]? For posterity, I've attached the combined patch that
fixed this bug.

Thanks!
Shaun

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=1147

[-- Attachment #2: bfd-pr1147.diff --]
[-- Type: text/x-patch, Size: 7867 bytes --]

Index: bfd/elf32-arm.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-arm.c,v
retrieving revision 1.49
retrieving revision 1.51
diff -u -r1.49 -r1.51
--- bfd/elf32-arm.c	8 Jul 2005 06:19:58 -0000	1.49
+++ bfd/elf32-arm.c	8 Aug 2005 11:06:16 -0000	1.51
@@ -1515,15 +1515,16 @@
 }
 elf32_arm_section_map;
 
-struct _arm_elf_section_data
+typedef struct _arm_elf_section_data
 {
   struct bfd_elf_section_data elf;
-  int mapcount;
+  unsigned int mapcount;
   elf32_arm_section_map *map;
-};
+}
+_arm_elf_section_data;
 
 #define elf32_arm_section_data(sec) \
-  ((struct _arm_elf_section_data *) elf_section_data (sec))
+  ((_arm_elf_section_data *) elf_section_data (sec))
 
 /* The size of the thread control block.  */
 #define TCB_SIZE	8
@@ -4400,7 +4401,7 @@
 
   /* Check to see if the input BFD actually contains any sections.  If
      not, its flags may not have been initialised either, but it
-     cannot actually cause any incompatibility.  Do not short-circuit
+     cannot actually cause any incompatiblity.  Do not short-circuit
      dynamic objects; their section list may be emptied by
     elf_link_add_object_symbols.
 
@@ -6511,6 +6512,71 @@
   return TRUE;
 }
 
+/* A structure used to record a list of sections, independently
+   of the next and prev fields in the asection structure.  */
+typedef struct section_list
+{
+  asection * sec;
+  struct section_list * next;
+  struct section_list * prev;
+}
+section_list;
+
+/* Unfortunately we need to keep a list of sections for which
+   an _arm_elf_section_data structure has been allocated.  This
+   is because it is possible for functions like elf32_arm_write_section
+   to be called on a section which has had an elf_data_structure
+   allocated for it (and so the used_by_bfd field is valid) but
+   for which the ARM extended version of this structure - the
+   _arm_elf_section_data structure - has not been allocated.  */
+static section_list * sections_with_arm_elf_section_data = NULL;
+
+static void
+record_section_with_arm_elf_section_data (asection * sec)
+{
+  struct section_list * entry;
+
+  entry = bfd_malloc (sizeof (* entry));
+  if (entry == NULL)
+    return;
+  entry->sec = sec;
+  entry->next = sections_with_arm_elf_section_data;
+  entry->prev = NULL;
+  if (entry->next != NULL)
+    entry->next->prev = entry;
+  sections_with_arm_elf_section_data = entry;
+}
+
+static _arm_elf_section_data *
+get_arm_elf_section_data (asection * sec)
+{
+  struct section_list * entry;
+
+  for (entry = sections_with_arm_elf_section_data; entry; entry = entry->next)
+    if (entry->sec == sec)
+      return elf32_arm_section_data (sec);
+  return NULL;
+}
+
+static void
+unrecord_section_with_arm_elf_section_data (asection * sec)
+{
+  struct section_list * entry;
+
+  for (entry = sections_with_arm_elf_section_data; entry; entry = entry->next)
+    if (entry->sec == sec)
+      {
+	if (entry->prev != NULL)
+	  entry->prev->next = entry->next;
+	if (entry->next != NULL)
+	  entry->next->prev = entry->prev;
+	if (entry == sections_with_arm_elf_section_data)
+	  sections_with_arm_elf_section_data = entry->next;
+	free (entry);
+	break;
+      }
+}
+
 /* Called for each symbol.  Builds a section map based on mapping symbols.
    Does not alter any of the symbols.  */
 
@@ -6523,6 +6589,8 @@
 {
   int mapcount;
   elf32_arm_section_map *map;
+  elf32_arm_section_map *newmap;
+  _arm_elf_section_data *arm_data;
   struct elf32_arm_link_hash_table *globals;
 
   /* Only do this on final link.  */
@@ -6538,25 +6606,35 @@
   if (! bfd_is_arm_mapping_symbol_name (name))
     return TRUE;
 
-  mapcount = ++(elf32_arm_section_data (input_sec)->mapcount);
-  map = elf32_arm_section_data (input_sec)->map;
+  /* If this section has not been allocated an _arm_elf_section_data
+     structure then we cannot record anything.  */
+  arm_data = get_arm_elf_section_data (input_sec);
+  if (arm_data == NULL)
+    return TRUE;
+
+  mapcount = arm_data->mapcount + 1;
+  map = arm_data->map;
   /* TODO: This may be inefficient, but we probably don't usually have many
      mapping symbols per section.  */
-  map = bfd_realloc (map, mapcount * sizeof (elf32_arm_section_map));
-  elf32_arm_section_data (input_sec)->map = map;
+  newmap = bfd_realloc (map, mapcount * sizeof (* map));
+  if (newmap != NULL)
+    {
+      arm_data->map = newmap;
+      arm_data->mapcount = mapcount;
+
+      map[mapcount - 1].vma = elfsym->st_value;
+      map[mapcount - 1].type = name[1];
+    }
 
-  map[mapcount - 1].vma = elfsym->st_value;
-  map[mapcount - 1].type = name[1];
   return TRUE;
 }
 
-
 /* Allocate target specific section data.  */
 
 static bfd_boolean
 elf32_arm_new_section_hook (bfd *abfd, asection *sec)
 {
-  struct _arm_elf_section_data *sdata;
+  _arm_elf_section_data *sdata;
   bfd_size_type amt = sizeof (*sdata);
 
   sdata = bfd_zalloc (abfd, amt);
@@ -6564,6 +6642,8 @@
     return FALSE;
   sec->used_by_bfd = sdata;
 
+  record_section_with_arm_elf_section_data (sec);
+
   return _bfd_elf_new_section_hook (abfd, sec);
 }
 
@@ -6586,6 +6666,7 @@
 			 bfd_byte *contents)
 {
   int mapcount;
+  _arm_elf_section_data *arm_data;
   elf32_arm_section_map *map;
   bfd_vma ptr;
   bfd_vma end;
@@ -6593,14 +6674,19 @@
   bfd_byte tmp;
   int i;
 
-  mapcount = elf32_arm_section_data (sec)->mapcount;
-  map = elf32_arm_section_data (sec)->map;
+  /* If this section has not been allocated an _arm_elf_section_data
+     structure then we cannot record anything.  */
+  arm_data = get_arm_elf_section_data (sec);
+  if (arm_data == NULL)
+    return FALSE;
+
+  mapcount = arm_data->mapcount;
+  map = arm_data->map;
 
   if (mapcount == 0)
     return FALSE;
 
-  qsort (map, mapcount, sizeof (elf32_arm_section_map),
-	 elf32_arm_compare_mapping);
+  qsort (map, mapcount, sizeof (* map), elf32_arm_compare_mapping);
 
   offset = sec->output_section->vma + sec->output_offset;
   ptr = map[0].vma - offset;
@@ -6644,10 +6730,31 @@
 	}
       ptr = end;
     }
+
   free (map);
+  arm_data->mapcount = 0;
+  arm_data->map = NULL;
+  unrecord_section_with_arm_elf_section_data (sec);
+
   return FALSE;
 }
 
+static void
+unrecord_section_via_map_over_sections (bfd * abfd ATTRIBUTE_UNUSED,
+					asection * sec,
+					void * ignore ATTRIBUTE_UNUSED)
+{
+  unrecord_section_with_arm_elf_section_data (sec);
+}
+
+static bfd_boolean
+elf32_arm_close_and_cleanup (bfd * abfd)
+{
+  bfd_map_over_sections (abfd, unrecord_section_via_map_over_sections, NULL);
+
+  return _bfd_elf_close_and_cleanup (abfd);
+}
+
 /* Display STT_ARM_TFUNC symbols as functions.  */
 
 static void
@@ -6806,6 +6913,7 @@
 #define bfd_elf32_find_inliner_info	        elf32_arm_find_inliner_info
 #define bfd_elf32_new_section_hook		elf32_arm_new_section_hook
 #define bfd_elf32_bfd_is_target_special_symbol	elf32_arm_is_target_special_symbol
+#define bfd_elf32_close_and_cleanup             elf32_arm_close_and_cleanup
 
 #define elf_backend_get_symbol_type             elf32_arm_get_symbol_type
 #define elf_backend_gc_mark_hook                elf32_arm_gc_mark_hook
Index: bfd/elfxx-target.h
===================================================================
RCS file: /cvs/src/src/bfd/elfxx-target.h,v
retrieving revision 1.88
retrieving revision 1.89
diff -u -r1.88 -r1.89
--- bfd/elfxx-target.h	29 Jul 2005 02:46:04 -0000	1.88
+++ bfd/elfxx-target.h	8 Aug 2005 11:06:16 -0000	1.89
@@ -26,7 +26,9 @@
    There are two such structures here:  one for big-endian machines and
    one for little-endian machines.   */
 
+#ifndef bfd_elfNN_close_and_cleanup
 #define	bfd_elfNN_close_and_cleanup _bfd_elf_close_and_cleanup
+#endif
 #define bfd_elfNN_bfd_free_cached_info _bfd_generic_bfd_free_cached_info
 #ifndef bfd_elfNN_get_section_contents
 #define bfd_elfNN_get_section_contents _bfd_generic_get_section_contents

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Nick Clifton]

Hi Shaun,

> Any chance there's a release of binutils 2.16.2 planned that fixes
> PR-1147 [1]? For posterity, I've attached the combined patch that
> fixed this bug.

I think that Dan is planning on starting a 2.17 release soon, in which 
case there will be no need for a 2.16.2 release.

Is this right Dan ?

Cheers
   Nick

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Daniel Jacobowitz]

On Thu, Mar 09, 2006 at 05:09:34PM +0000, Nick Clifton wrote:
> Hi Shaun,
> 
> >Any chance there's a release of binutils 2.16.2 planned that fixes
> >PR-1147 [1]? For posterity, I've attached the combined patch that
> >fixed this bug.
> 
> I think that Dan is planning on starting a 2.17 release soon, in which 
> case there will be no need for a 2.16.2 release.
> 
> Is this right Dan ?

I'm tentatively planning to.  However, I'm swamped right now; it may
be a little while longer.

-- 
Daniel Jacobowitz
CodeSourcery

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Nick Clifton]

Hi Shaun,

> hello.o: ELF 32-bit LSB relocatable, ARM, version 1 (ARM), not stripped
> data.o:  ELF 32-bit LSB relocatable, no machine, version 1 (ARM), not stripped
> 
> It looks like the warning is caused by the machine field of the object
> file created by objcopy being set to 'no machine' instead of 'ARM'.
> Can I pass an option to objcopy to change the machine field? 

   --alt-machine-code 40

> Or perhaps the machine field should default to 'ARM'.

Debatable.  Since the input file is "binary" it is presumably not 
actually ARM code at all, but something else.  (If it was ARM code it 
would have been created by the assembler and already have the machine 
field set to EM_ARM).

Cheers
   Nick

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Shaun Jackman]

On 8/2/05, Nick Clifton <nickc@redhat.com> wrote:
> > It looks like the warning is caused by the machine field of the object
> > file created by objcopy being set to 'no machine' instead of 'ARM'.
> > Can I pass an option to objcopy to change the machine field?
>
>    --alt-machine-code 40

$ arm-elf-objcopy -Ibinary -Oelf32-littlearm image.bin image.bin.o
--alt-machine-code=40
arm-elf-objcopy: unknown alternate machine code, ignored

What's the correct value for the `ARM' machine code?

Thanks,
Shaun

Re: arm-elf-ld 2.16.1 crash at bfd/elf32-arm.c:5536

[Nick Clifton]

Hi Shaun,

>>>It looks like the warning is caused by the machine field of the object
>>>file created by objcopy being set to 'no machine' instead of 'ARM'.
>>>Can I pass an option to objcopy to change the machine field?
>>
>>   --alt-machine-code 40
> 
> 
> $ arm-elf-objcopy -Ibinary -Oelf32-littlearm image.bin image.bin.o
> --alt-machine-code=40
> arm-elf-objcopy: unknown alternate machine code, ignored
> 
> What's the correct value for the `ARM' machine code?

Ah - this was the subject of a recent thread:

http://sources.redhat.com/ml/binutils/2006-02/msg00219.html

The patch from this thread has been checked in, so if you obtain the 
latest sources from the CVS repository and build a new objcopy you 
should be able to install the new machine code value using the command 
you described above.

Cheers
   Nick