objdump segfaults when dumping library with sources (arm-elf / arm-none-eabi)

[Nick Clifton]

Hi Michael,

> First of all I am quite new to compiling binutils, etc. myself and I
> don't know if this is a compiler problem, generating wrong debugging
> information, or a binutils problem disassembling wrong.

Well first thank you for reporting this problem.  Secondly even if it 
does turn out to be a compiler problem, objdump should not be seg-faulting.

> My main problem is then objdump segfaults when dumping library files.

Which version of the binutils are you using ?  If you do not have the 
latest release (2.21) or (even better) the mainline development code, 
then it may be that this a bug that has already been fixed.

> In my case it was easily reproducible when executing "arm-elf-objdump -S
> libc.a".

The best way to solve this problem is to file a bug report with the 
binutils bugzilla system:

   http://sourceware.org/bugzilla

If you include a test case that can reproduce the problem, that will 
really help.


> The function get_map_sym_type() in "opcodes/arm-dis.c" was called
> with a disassemble info containing 4 sym_tabs, while n was 24.
> This results in an array out of bound access which may segfault.

This sounds like the underlying cause is some bogus debug info in the 
file.

> When I added validation of the input parameters the segfault was
> gone (and disassembly for this opcode seems to be skipped).

>   {
>     /* If the symbol is in a different section, ignore it.  */
> +  if (n>= info->symtab_size)
> +    return FALSE;
>     if (info->section != NULL&&  info->section != info->symtab[n]->section)

This seems OK, although I would have put the new code before the 
comment, not after it.

> After that I was able to dump the same library but the
> disassembly was missing.

OK - to go any further though we are really going to need a test case. 
And ideally a bug report in which to keep track of the work done in 
solving the problem.

Cheers
   Nick