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

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

[Michael Trensch]

Hi,

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.

My main problem is then objdump segfaults when dumping library files. I
reproduced this behavior with the Yagarto toolchain and it also happens
there. I first remarked it when dumping my own ARM libraries and thought
that it's my libraries. So I tried it with the compiler / newlib
delivered libraries and saw the same effect. It never crashed so far on
a full-build application in an .elf file.

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

The last output (before segfault) written was:

---
00000000 <__libc_fini_array>:
extern void _fini (void);

/* Run all the cleanup routines.  */
void
__libc_fini_array (void)
{
   0:
---

I am not very familiar with gdb but I was able to track down the location where it happened.
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.

When I added validation of the input parameters the segfault was gone (and disassembly for this opcode seems to be skipped).
---
diff -aurN binutils-2.21/opcodes/arm-dis.c binutils-2.21-netx/opcodes/arm-dis.c
--- binutils-2.21/opcodes/arm-dis.c	2010-09-27 09:47:04.000000000 +0000
+++ binutils-2.21-netx/opcodes/arm-dis.c	2011-07-22 11:00:55.000000000 +0000
@@ -4500,6 +4500,8 @@
 		  enum map_type *map_type)
 {
   /* 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)
     return FALSE;
---

After that I was able to dump the same library but the disassembly was missing.
---
00000000 <__libc_fini_array>:
extern void _fini (void);

/* Run all the cleanup routines.  */
void
__libc_fini_array (void)
{
   0:	e92d4070 	.word	0xe92d4070
...
---

I know that this only cures the symptoms but not the cause. I did not look deeper into the symbol parsing happening before (deep ELF Format knowledge would be needed I assume). Probably someone with a deeper knowledge of the source / parsing can find the real issue with this information.


Does anyone already know about this issue? Is there any workaround for this?


Regards,
Michael

Re: 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

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

[Michael Trensch]

On 29.07.2011 16:33, Nick Clifton wrote:
>> 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.
Sorry that I forgot to add the version I was using. Just my lazyness.

I was trying the original 2.21 release which segfaulted.

Now i've tried the latest snapshot (2.21.53) which seems not being
affected by this problem. I've diffed the sources and saw that much of
the disassembling code (especially the functions calling
get_map_sym_type()) has been re-arranged, probably fixing this problem.

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

I will see if I can provide a reliable way to reproduce it, as it seems
to depend on the library I dump. Maybe I can build a simple C File that
produces and object containing this type of debugging symbol that fails.

>> disassembly was missing.
> After that I was able to dump the same library but the
>
> 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.
>
I will see what I can provide, when I am back at work.

Regards,
Michael