objdump

问题 I am building an embedded application comprised of several code modules and a static library. Some global variables are explicitly placed in dedicated memory sections (i.e, not the default .data section). The processor memory architecture is 4 banks, creating a contiguous physical memory space. In my application, only the 1st bank is reserved for code and the other 3 banks are reserved for the explicitly allocated globals and a small stack. The problem is that the code section (.text) now

问题 I am using objdump to analyze a shared object's memory usage. Along with the .data and .rodata sections I see a .data.rel.ro section. Anyone know what this used for? 回答1: I found the answer here: gcc, the GNU linker, and the glibc dynamic linker cooperate to implement an idea called read-only relocations, or relro. This permits the linker to designate a part of an executable or (more commonly) a shared library as being read-only after dynamic relocations have been applied. This may be used

问题 I have a bit of strange question. If I use objdump -d for disassembling an ARM binary it can resolve the function (system library) names of branch instructions e.g.: 8404: e581e000 str lr, [r1] 8408: e59f0028 ldr r0, [pc, #40] ; 8438 <address_of_message1> 840c: ebffffc1 bl 8318 <printf@plt> 8410: e59f0028 ldr r0, [pc, #40] ; 8440 <address_of_scan_pattern> 8414: e59f1028 ldr r1, [pc, #40] ; 8444 <address_of_read> 8418: ebffffc4 bl 8330 <scanf@plt> 841c: e59f0018 ldr r0, [pc, #24] ; 843c

问题 During one of my (FWIW, ARM) debugging sessions I noticed the source-interleaved disassembly output from GDB and objdump -S differ in an interesting way: objdump seems hop through individual/group of instructions and display the source line from which those instructions were generated (instruction order). GDB disassembly, on the other hand, seems to hop through source lines, and lists all assembly instructions generated from that source line (source order). For an -O0 code, output from both

问题 I'm currently practicing some RE w/ GDB and am having issues simply stopping the run/start on the first/second instruction. I am new to GDB/RE and have a limited knowledge of some of GDB's inner workings. So far when I open the program I have done: (gdb) set disassembly-flavor intel (gdb) file /path/to/binary (gdb) info file Symbols from "/path/to/binary". Local exec file: `/path/to/binary', file type elf32-i386. Entry point: 0x8048450 . . . (gdb) b *0x8048450 (gdb) start Temporary breakpoint

问题 Everytime I do an objdump -d I always see the asm code with batches of nop instructions (instructions that do nothing) For example take this same program: #include <stdio.h> #include <math.h> int main() { printf("Hello World!\n"); printf("cos: %f\n", cos(1)); return 1; } The objdump for exampe has 2 nops at the end of the entry point 0000000000400450 <_start>: 400450: 31 ed xor %ebp,%ebp 400452: 49 89 d1 mov %rdx,%r9 400455: 5e pop %rsi 400456: 48 89 e2 mov %rsp,%rdx 400459: 48 83 e4 f0 and

问题 I have nodejs script that throws Error: Process finished with exit code 139 (interrupted by signal 11: SIGSEGV) After I included var SegfaultHandler = require('segfault-handler'); SegfaultHandler.registerHandler("crash.log"); // With no argument, SegfaultHandler will generate a generic log file name I got this stack trace: PID 2645 received SIGSEGV for address: 0x0 0 segfault-handler.node 0x00000001034ae1c8 _ZL16segfault_handleriP9__siginfoPv + 280 1 libsystem_platform.dylib

问题 Similarly to How do I disassemble raw x86 code?, but then for the MIPS architecture: how do I disassemble raw MIPS code with objdump ? I want to check the instructions in a vmlinux image, but to do so I now have to: : > x.c mipsel-linux-gnu-gcc -c -o x.o x.c mipsel-linux-gnu-objcopy --add-section raw=vmlinux x.o mipsel-linux-gnu-objcopy --remove-section .comment x.o mipsel-linux-gnu-objdump -D x.o | less Is there an easier way to do it? I've tried the below to no avail: mipsel-linux-gnu

问题 Example: $ objdump Logger.cpp.o -t 00000000 g F .text 00000000 .hidden __sti___10_Logger_cpp_0b2ae32b 回答1: It means that the visibility of the symbol is hidden: https://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html Reasons for changing the visibility of symbols include: Less risk of symbol collision. Smaller binaries. Reduced start-up time because the dynamic linker does not need to process as many symbols. Opportunities

问题 I have a C++ object file that contains instantiations of some C++ template functions. The object file in question instantiates the same function for a few different combinations of template parameters. I'm trying to debug a problem and would like to look at the disassembly of a specific instantiation of the template function (that is, I know the template parameters for the function that I want to examine). I would typically do this using objdump to disassemble the object file, but it (at