elf | 易学教程

understanding the __libc_init_array

阅读更多关于 understanding the __libc_init_array

问题 I viewed the source code of __libc_init_array from http://newlib.sourcearchive.com/documentation/1.18.0/init_8c-source.html . But I don't quite understand what this function does. I know that these symbols /* These magic symbols are provided by the linker. */ extern void (*__preinit_array_start []) (void) __attribute__((weak)); extern void (*__preinit_array_end []) (void) __attribute__((weak)); extern void (*__init_array_start []) (void) __attribute__((weak)); extern void (*__init_array_end [

understanding the __libc_init_array

阅读更多关于 understanding the __libc_init_array

What does a compiled C++ class look like?

阅读更多关于 What does a compiled C++ class look like?

问题 With some background in assemble instructions and C programs, I can visualize how a compiled function would look like, but it's funny I have never so carefully thought about how a compiled C++ class would look like. bash$ cat class.cpp #include<iostream> class Base { int i; float f; }; bash$ g++ -c class.cpp I ran: bash$objdump -d class.o bash$readelf -a class.o but what I get is hard for me to understand. Could somebody please explain me or suggest some good starting points. 回答1: The classes

Remove file paths from TEXT directives in go binaries

阅读更多关于 Remove file paths from TEXT directives in go binaries

问题 I want to remove all path information like /Users/myuser/dev/go/src/fooapi/spikes/mongoapi.go from the executable that I created with go build . I'm compiling the code like this: CGO_ENABLED=0 go build -v -a -ldflags="-w -s" -o ./fooapi spikes/mongoapi.go Some part of the example assembly from the go build command above: $ go tool objdump ./fooapi . . TEXT main.init(SB) /Users/myuser/dev/go/src/api/spikes/mongoapi.go mongoapi.go:60 0x12768c0 65488b0c25a0080000 GS MOVQ GS:0x8a0, CX mongoapi.go

How can I make GCC compile the .text section as writable in an ELF binary?

阅读更多关于 How can I make GCC compile the .text section as writable in an ELF binary?

问题 I would like to be able to dynamically change the executable code within a library I am using. Essentially, I would like to dynamically NOP out certain functions if they are not needed. However, the .text section of the library I am using is not-writable (as is the case for most programs). I have the source code of the library and so would like to use GCC to compile it as writable. Is there a way to do this? 回答1: In the general sense, mprotect is the perferred choice (on POSIX conforming

How do you get the start and end addresses of a custom ELF section?

阅读更多关于 How do you get the start and end addresses of a custom ELF section?

问题 I'm working in C on Linux. I've seen the usage of of the gcc __section__ attribute (especially in the Linux kernel) to collect data (usually function pointers) into custom ELF sections. How is the "stuff" that gets put in those custom sections retrieved and used? 回答1: As long as the section name results in a valid C variable name, gcc ( ld , rather) generates two magic variables: __start_SECTION and __stop_SECTION . Those can be used to retrieve the start and end addresses of a section, like

What does exactly the warning mean about hidden symbol being referenced by DSO?

阅读更多关于 What does exactly the warning mean about hidden symbol being referenced by DSO?

问题 I have a problem linking some shared library with g++. It gives me a warning like: hidden symbol XXX in YYY is referenced by DSO /usr/lib/... I've read some related questions about particular problems, but I want to understand it in a whole - what does this warning mean and what is a cause: What is DSO? What is a hidden symbol? How can it be referenced, if it's hidden? 回答1: What is a DSO? A DSO is a Dynamic Shared Object , or less formally a shared library. What is a hidden symbol? A hidden

(笔记)Ubuntu下安装arm-linux-gcc-4.4.3.tar.gz (交叉编译环境)

阅读更多关于 (笔记)Ubuntu下安装arm-linux-gcc-4.4.3.tar.gz (交叉编译环境)

参考了前人的成果，结合自己实践,arm-linux-gcc-4.4.3.tar.gz的下载地址为： http://ishare.iask.sina.com.cn/f/13836544.html?from=like 本人所用系统是Ubuntu12.04，但只要是Ubuntu应该都可以安照此步骤安装。 1.解压文件解压 tar zxvf arm-linux-gcc-4.4.3.tar.gz -C/（直接解压后就可以，-C/会让解压的文件自动放在根目录下指定路径，不用管）下载arm-linux-gcc-4.4.3.tgz到任意的目录下，进入这个文件夹 sudo tar xvzf arm-linux-gcc-4.4.3.tgz –C / 注意:C后面有个空格（不需要）,并且C是大写的（必须）,它是英文单词“Change”的第一个字母,在此是改变目录的意思。执行该命令,将把arm-linux-gcc 安装到/opt/Friendlyarm/toolschain/4.4.3 目录。 2.建立目录 sudo mkdir /usr/local/arm 3.复制文件 sudo cp -r /opt/FriendlyARM/toolschain/4.4.3 /usr/local/arm 5.添加环境变量网上很多修改环境变量的方法，很杂。有 redhat上面的,fedora。下面一共三种方法

Why do we need -rdynamic option in gcc? [duplicate]

阅读更多关于 Why do we need -rdynamic option in gcc? [duplicate]

问题 This question already has answers here : What exactly does `-rdynamic` do and when exactly is it needed? (3 answers) Closed last year . By default all symbols are exported to dynamic table, so why would we use -rdynamic flag? Even if we hide some symbols via attributes/ -fvisibility=hidden - -rdynamic doesn't change result, it doesn't unhide previously hidden symbols. So what's the point in it? 回答1: Symbols are only exported by default from shared libraries. -rdynamic tells linker to do the

what function set “program_invocation_name” ? and when?

阅读更多关于 what function set “program_invocation_name” ? and when?

问题 Here is a bit of information I got about program_invocation_name : This value contains the name that was used to invoke the calling program. This value is automatically initialized. This value is global variable. ( So at the first sight, I thought it was in <.bss> or <.data> . But it was in stack memory region. That's weird... ) Here is debugger view of program_invocation_name : pwndbg> x/s program_invocation_name 0xbffff302: "/tmp/my_program" Problem) I followed the execution flow from the