Android二进制工具objdump/readelf不能打印出function@plt的解决

Android二进制工具objdump/readelf不能打印出function@plt的原因和补丁. 查找原因时, google到的一点资料.

有人解决了后, Google的工程师也火急火燎地让上传补丁. :)

objdump not printing "function@plt" symbols when processing arm or mips object, but does for x86.

As one would expect of a modern toolchain targeting a shared library system, the ndk toolchain creates executables in which calls to external library functions are implemented with a call to a helper in the .plt section, which redirects to the address in the global offset table where the runtime linker will eventually place the address of the target function.

If I compile a simple hello-world executable with the ndk targeting both x86 and arm, then objdump the x86 version, I get something like this (trimmed a lot for brevity):

$ i686-android-linux-objdump -d obj/local/x86/hello

Disassembly of section .plt:
0804827c <puts@plt>:
 804827c:        ff 25 58 95 04 08            jmp    *0x8049558
 8048282:        68 00 00 00 00               push   $0x0
 8048287:        e9 e0 ff ff ff               jmp    804826c <puts@plt-0x10>

Disassembly of section .text:
080483c0 <main>:
 80483de:        e8 99 fe ff ff               call   804827c <puts@plt>

But, for the arm version:

$arm-linux-androideabi-objdump -d obj/local/armeabi/hello

Disassembly of section .plt:
000084f8 <.plt>:
    8524:        e28fc600         add        ip, pc, #0        ; 0x0
    8528:        e28cca02         add        ip, ip, #8192        ; 0x2000
    852c:        e5bcf7a4         ldr        pc, [ip, #1956]!

0008590 <main>:
    8590:        b510              push        {r4, lr}
    8592:        4803              ldr        r0, [pc, #12]        (85a0 <main+0x10>)
    8594:        4478              add        r0, pc
    8596:        f7ff efc6         blx        8524 <_start-0x3c>

As you can see, there is no "puts@plt" synthetic symbol created, and the invocation within the program code is left as a negative address in relation to the first known symbol.  Needless to say, this makes making sense of dumps very complicated - extremely so if looking at a stripped executable where the dynamic link symbols of the library functions used may be the only major clues as to what you are looking at.

So I would like to figure out why this useful feature of displaying the names of library functions called via the plt works for x86, and not for arm.  I know that the necessary information to create these synthetic symbols does exist in the file, because I wrote a program which pattern matches the opcodes of the .plt, figures out the target address then searches for a dynamic symbol and at that address and prints out the corresponding stringtab name with a section suffix in
the way I assme objdump/BFD is doing for x86:

$ printplt obj/local/armeabi/hello

decoding plt...
0x0000850c:  __cxa_begin_cleanup@plt
0x00008518:  memcpy@plt
0x00008524:  puts@plt
0x00008530:  abort@plt
0x0000853c:  __libc_init@plt
0x00008548:  __cxa_type_match@plt
0x00008554:  __gnu_Unwind_Find_exidx@plt

So my question is, why is this not working with the arm objdump?  (it does not seem to work for mips either)

- Is there metadata missing from the arm object which is key to objdump / BFD deciding to try to do this?
- Is the feature just not implemented for arm?
- Is it implemented, but not available in the prebuilt toolchain due to omission of a compile-time option?
- Is it failing because the instructions used in the .plt are not of the form expected?

Unfortunately, I have not yet been able to figure out where these synthetic symbols are created in the binutils source; there's not a lot to search on since the "@plt" is presumably named from the section rather than being a static string, so it seems finding the code would require developing a degree of understanding of the codebase.

If possible, I'd like to find the area where binutils could be patched to enable this for arm, as it's a capability I would really like to have when debugging projects (and poking around on the device in general).  If I can't figure out how to put it into objdump, I guess I could clean up and share my plt parsing program, but it would be a lot nicer to have the names in the disassembled output (and putting them in after the fact with sed seems a bit roundabout).

 

Managed to solve my problem - objdump now displays thefunction@pltnames is the disassembly of both the .plt and program code which calls them.

Patch follows... I suppose it's time to figure out how to use gerrit.
Which version of binutils would it be appropriate to submit against? I tried this on 2.21 but see there are lots in the git package.  Or should it go upstream to someone else and only then back into android?

--- bfd/elf32-arm-orig.c        2012-06-27 16:12:27.000000000 -0400
+++ bfd/elf32-arm.c        2012-06-27 16:31:05.000000000 -0400
@@ -13898,6 +13898,21 @@
 #define elf_backend_obj_attrs_order        elf32_arm_obj_attrs_order
 #define elf_backend_obj_attrs_handle_unknown
elf32_arm_obj_attrs_handle_unknown

+/* Changes to enable decoding of function@plt symbols for android */
+#undef  elf_backend_plt_sym_val
+#define elf_backend_plt_sym_val                elf32_arm_android_plt_sym_val
+
+/* Return address for Ith PLT stub in section PLT, for relocation REL
+   or (bfd_vma) -1 if it should not be included.  */
+
+static bfd_vma
+elf32_arm_android_plt_sym_val (bfd_vma i, const asection *plt,
+                               const arelent *rel ATTRIBUTE_UNUSED)
+{
+  return plt->vma + 4 * (
+    ARRAY_SIZE(elf32_arm_plt0_entry) +
+    ARRAY_SIZE(elf32_arm_plt_entry) * i);
+}
 #include "elf32-target.h"

 /* VxWorks Targets.  */

 

Thank you for figuring out the fix!   Please submit it to AOSP toolchain repo

repo init -u https://android.googlesource.com/toolchain/manifest.git

repo sync

 

You may google for how to submit patch to AOSP, but in short. 

cd binutils

repo start yourbranchname .

Apply changes to binutils/binutils-2.19 and ideally also in binutils/binutils-2.21

git commit -a  # write commit message

repo upload .  # then add reviewer

Your upload will appear in https://android-review.googlesource.com for review. 

Looking forward to see it soon.