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

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
> arm-elf-ld crashed while linking a project compiled with GCC 4.0.1.
...
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

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

Shaun Jackman
On 7/29/05, Nick Clifton <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

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

Shaun Jackman
In reply to this post by Nick Clifton
Hello Nick,

On 7/29/05, Nick Clifton <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Nick Clifton
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



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;
  }
 
Reply | Threaded
Open this post in threaded view
|

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

Shaun Jackman
On 7/31/05, Nick Clifton <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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


Reply | Threaded
Open this post in threaded view
|

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

Nick Clifton
In reply to this post by Shaun Jackman
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
Reply | Threaded
Open this post in threaded view
|

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

Paul Brook
In reply to this post by Nick Clifton
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
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

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

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

        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.


patch.ar_unrecord (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

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

Shaun Jackman
In reply to this post by Nick Clifton
On 8/2/05, Nick Clifton <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Shaun Jackman
In reply to this post by Nick Clifton
On 8/8/05, Nick Clifton <[hidden email]> 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

bfd-pr1147.diff (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Nick Clifton
In reply to this post by Shaun Jackman
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
Reply | Threaded
Open this post in threaded view
|

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

Nick Clifton
In reply to this post by Shaun Jackman
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
Reply | Threaded
Open this post in threaded view
|

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