Parse ARM unwind tables

I wrote this patch a while ago to dump unwind info from Android system
libraries. It proved useful for that, but I never got around to thinking about
upstreaming it. The bulk of the code is originally from libunwind, but I
modified it to convert into our CFI records. It doesn't produce pretty symbol
files, but it seems to work. It's also severely lacking in unit tests.

[jimb]

Wow, awesome.

I haven't read it too carefully, but the way this is structured seems like it
will be hard to test. The same code both parses the data and builds the
StackFrameEntry. If those tasks could be separated, perhaps by having the parser
drive a builder class that matched the ARM table's semantics (analogous to
dwarf2reader::CallFrameInfo::Handler), and then plugging in a builder that took
care of relating ARM's world view to Breakpad's (analogous to
google_breakpad::DwarfCFIToModule), then it seems like testing would be much
easier.

[jimb]

Do we need to bring this into like with the Google C++ Style Guide? Or can we
treat it as "imported code"?

[Vasily]

On 2012/10/05 17:11:29, Ted Mielczarek wrote:
Hello.
I am trying to implement the usage of .ARM.ex* in Valgrind. At first, I tried to
run "dump_syms" (on x86) on binary for ARM with this section. Unfortunately, I
received Segmentation fault. Could I kindly ask you what was the number of
revision at SVN which you used to generate these patches? I tried r 1064 and
1065. My program is very simple and attached here some information.

Any ideas are welcome.
Thank you in advance.

_________________
!Source code!
__________________

#include <stdio.h>
#include <stdlib.h>

char* p;

void ddd  ( void ) { p[-1] += 'z'; }
void ccc  ( void ) { ddd(); }
void bbb  ( void ) { ccc(); }
void aaa  ( void ) { bbb(); }

void zzzzzzz  ( void ) { p = malloc(10); }
void yyy  ( void ) { zzzzzzz(); }
void xxx  ( void ) { yyy(); }
void www  ( void ) { xxx(); }

int main ( void ) {
        www();
        aaa();
        return 0;
}
___________________
!CMake file!
___________________

cmake_minimum_required (VERSION 2.6)

set (PROJECT experiments)

set (BIN_DIR /bin) # Не используется пока

project (${PROJECT})

set (SOURCES
        experiments.c)

#set (CMAKE_C_FLAGS "-O1 -march=armv7-a -g -funwind-tables")
set (CMAKE_C_FLAGS "-O1 -funwind-tables -march=armv7-a")
#add_definitions (-g -O1 -funwind-tables)

add_executable (${PROJECT} ${SOURCES})
__________________________________
! We have .ARM.ex* indeed!
__________________________________

-sh-4.1# readelf -u ./experiments

Unwind table index '.ARM.exidx' at offset 0x9b4 contains 11 entries:

0x8788 <_start>: 0x1 [cantunwind]

0x883c <ddd>: 0x80b0b0b0
  Compact model 0
  0xb0      finish
  0xb0      finish
  0xb0      finish

0x8858 <ccc>: @0x8954
  Compact model 1
  0xb1 0x08 pop {r3}
  0x84 0x00 pop {r14}
  0xb0      finish
  0xb0      finish

0x8864 <bbb>: @0x8960
  Compact model 1
  0xb1 0x08 pop {r3}
  0x84 0x00 pop {r14}
  0xb0      finish
  0xb0      finish

0x8870 <aaa>: @0x896c
  Compact model 1
  0xb1 0x08 pop {r3}
  0x84 0x00 pop {r14}
  0xb0      finish
  0xb0      finish

0x887c <zzzzzzz>: @0x8978
  Compact model 1
  0xb1 0x08 pop {r3}
  0x84 0x00 pop {r14}
  0xb0      finish
  0xb0      finish

0x8898 <yyy>: @0x8984
  Compact model 1
  0xb1 0x08 pop {r3}
  0x84 0x00 pop {r14}
  0xb0      finish
  0xb0      finish

0x88a4 <xxx>: @0x8990
  Compact model 1
  0xb1 0x08 pop {r3}
  0x84 0x00 pop {r14}
  0xb0      finish
  0xb0      finish

0x88b0 <www>: @0x899c
  Compact model 1
  0xb1 0x08 pop {r3}
  0x84 0x00 pop {r14}
  0xb0      finish
  0xb0      finish

0x88bc <main>: @0x89a8
  Compact model 1
  0xb1 0x08 pop {r3}
  0x84 0x00 pop {r14}
  0xb0      finish
  0xb0      finish

0x88d0 <__libc_csu_init>: 0x1 [cantunwind]
__________________________________________
!Using gdb to obtain backtrace!
__________________________________________

golubev@golubev-System-Product-Name:~/work/valgrind_project/google-breakpad$ gdb
../google-breakpad_bin/bin/dump_syms
GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from
/home/golubev/work/valgrind_project/google-breakpad_bin/bin/dump_syms...done.
(gdb) run ../google-breakpad_bin/experiments >
../google-breakpad_bin/experiments.sym
Starting program:
/home/golubev/work/valgrind_project/google-breakpad_bin/bin/dump_syms
../google-breakpad_bin/experiments > ../google-breakpad_bin/experiments.sym

Program received signal SIGSEGV, Segmentation fault.
arm_exidx_extract (entry=0x7ffff7ff79c4, buf=0x7fffffffd750 "\260\260\260") at
src/common/linux/arm_ex_tables.cc:331
331	      data = extbl_data[0];
(gdb) l
326	      buf[nbuf++] = data;
327	    }
328	  else
329	    {
330	      uint32_t *extbl_data = reinterpret_cast<uint32_t*>(prel31_to_addr
(&entry->data));
331	      data = extbl_data[0];
332	      unsigned int n_table_words = 0;
333	      if (data & ARM_EXIDX_COMPACT)
334		{
335		  int pers = (data >> 24) & 0x0f;
(gdb) backtrace
#0  arm_exidx_extract (entry=0x7ffff7ff79c4, buf=0x7fffffffd750 "\260\260\260")
at src/common/linux/arm_ex_tables.cc:331
#1  0x000000000041f2b6 in decode_arm_exidx (section=<optimized out>,
size=<optimized out>, module=0x7fffffffdda0, mapped_address=0x7ffff7ff7000
"\177ELF\001\001\001", load_address=32768)
    at src/common/linux/arm_ex_tables.cc:406
#2  0x00000000004259ad in LoadARMexidx<google_breakpad::ElfClass32>
(loading_addr=32768, module=0x7fffffffdda0, header=0x7ffff7ff7000,
section=<optimized out>) at src/common/linux/dump_symbols.cc:348
#3  (anonymous namespace)::LoadSymbols<google_breakpad::ElfClass32>
(obj_file=..., big_endian=false, elf_header=0x7ffff7ff7000,
read_gnu_debug_link=false, info=0x7fffffffde70, module=0x7fffffffdda0)
    at src/common/linux/dump_symbols.cc:619
#4  0x00000000004267e5 in (anonymous
namespace)::WriteSymbolFileElfClass<google_breakpad::ElfClass32>
(elf_header=0x7ffff7ff7000, obj_filename=..., debug_dir=..., cfi=true,
sym_stream=...)
    at src/common/linux/dump_symbols.cc:778
#5  0x0000000000426f48 in google_breakpad::WriteSymbolFile (obj_file=...,
debug_dir=..., cfi=true, sym_stream=...) at src/common/linux/dump_symbols.cc:868
#6  0x00000000004042e4 in main (argc=<optimized out>, argv=<optimized out>) at
src/tools/linux/dump_syms/dump_syms.cc:70

[Ted Mielczarek]

It sounds like there's something wrong with the parsing here. I don't have
intricate knowledge of the parser, I just borrowed the code from libunwind. I
don't have time to debug this at the moment. If you'd like to read the
documentation on the unwind table format it's documented here:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf

Just for reference, what compiler (and version of the compiler) are you using?

[Vasily]

I used gcc-4.5.3 for building the binary. I compiled my example inside the
environment of the device using OBS.
I will try to look precisely at the parser. But could you tell me how you
obtained these patches? Using the revision 1064 at SVN or some others?

Thanks

[Ted Mielczarek]

On 2012/10/19 04:42:06, Vasily wrote:
> I used gcc-4.5.3 for building the binary. I compiled my example inside the
> environment of the device using OBS.
> I will try to look precisely at the parser. But could you tell me how you
> obtained these patches? Using the revision 1064 at SVN or some others?

I originally wrote the patch against a much older revision, but I rebased it to
work with latest trunk right before I posted it here. I just tried running it on
an ARM binary I had locally and it crashes the same way, so it looks like either
I broke something in the update or the code wasn't quite right in the first
place.

[Vasily]

On 2012/10/19 10:47:12, Ted Mielczarek wrote:
> On 2012/10/19 04:42:06, Vasily wrote:
> > I used gcc-4.5.3 for building the binary. I compiled my example inside the
> > environment of the device using OBS.
> > I will try to look precisely at the parser. But could you tell me how you
> > obtained these patches? Using the revision 1064 at SVN or some others?
> 
> I originally wrote the patch against a much older revision, but I rebased it
to
> work with latest trunk right before I posted it here. I just tried running it
on
> an ARM binary I had locally and it crashes the same way, so it looks like
either
> I broke something in the update or the code wasn't quite right in the first
> place.

As far as I understand, the problem arises when we deal with the third case from
this table:

/* An ARM unwind entry consists of a prel31 offset to the start of a
     function followed by 31bits of data: 
       * if set to 0x1: the function cannot be unwound (EXIDX_CANTUNWIND)
       * if bit 31 is one: this is a table entry itself (ARM_EXIDX_COMPACT)
       * if bit 31 is zero: this is a prel31 offset of the start of the
         table entry for this function  */
 
Could I kindly ask you to send me some link where the format of prel31 is
described? For example, I use "readelf -x .ARM.exidx" and "readelf -x
.ARM.extab" on the binary with two simple functions. How can I use this info to
calculate the address of .ARM.extab entry from the information in .ARM.exidx
row? It is not simple offset or smth else, in my opinion.

Thank you in advance

[Vasily]

Hi
I think that I solved the problem of SegFault on ARM binaries without debug
info. Now dump_syms works fine on them. But I can't test stackwalk because there
is a problem with obtaining a dump on ARM. I compiled standard code (from wiki)
but it fails with message "

ExceptionHandler::GenerateDump waitpid failed:No child processes
Dump path: /tmp/11bdb39f-8040-ecf6-39453d42-624afa96.dmp
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

". 

Can somebody help me with this problem?

[Ted Mielczarek]

This is Vasily's updated version of my patch from
http://code.google.com/p/google-breakpad/issues/detail?id=503.

I found a bug in the handling of ARM_EXIDX_CMD_VFP_POP, we needed to use <= to
properly handle the input values. I get pretty sensible stacks when I use this
code to dump Android system libraries. I've also found that modern readelf has a
-u option to dump these tables, so it's handy for sanity checking the work here.
Sorry for letting this sit for so long, I just didn't have the time (or the
need) to look at it. I think we want to use this in Firefox, so I'll probably
work on cleaning it up and getting it into a landable state.