elf

What is __libc_start_main and _start?

由 让人想犯罪 __ 提交于 2021-02-18 16:58:08
问题 From the past few days I have been trying to understand what happens behind the curtain when we execute a C program. However even after reading numerous posts I cannot find a detailed and accurate explanation for the same. Can someone please help me out ? 回答1: You would usually find special names like this for specific uses when compiling and linking programs. Typically, something like _start would be the actual entry point for an executable, it will be located in some object file or library

PE文件格式和ELF文件格式（下）----ELF文件

由 故事扮演 提交于 2021-02-18 12:54:21
1 简介 可执行链接格式（Executable and Linking Format）最初是由UNIX 系统实验室（UNIX System Laboratories，USL）开发并发布的，作为应用程序二进制接口（Application Binary Interface，ABI ）的一部分。工具接口标准（Tool Interface Standards，TIS）委员会将还在发展的ELF 标准选作为一种可移植的目标文件格式，可以在32 位Intel 体系结构上的很多操作系统中使用[1, 2] 。 ELF 标准的目的是为软件开发人员提供一组二进制接口定义，这些接口可以延伸到多种操作环境，从而减少重新编码、重新编译程序的需要。接口的内容包括目标模块格式、可执行文件格式以及调试记录信息与格式等。 TIS 给出的Portable Formats Specification 1.1 版本中主要针对三种不同类型的目标文件作了规定，并规定了程序加载与动态链接相关过程细节，给出了标准ANSI C 和libc例程必须提供的符号[1] 。在该组织随后发布的 Executable and Linking Format(ELF) Specification 1.2 版本中则分如下三个部分，主要的不同点是对与操作系统相关的部分进行了重新组织： 2 相关标准 2.1 System V ABI System V

Delayed Symbol Resolving

由 喜欢而已 提交于 2021-02-11 15:02:31
问题 I am working on some diagnostic tools to help locate memory issues on an embedded ARM platform. Due to memory constraints, I can't load all symbols for all libraries on the unit itself. What information do I need to save to be able to resolve symbols later on a different machine? The machine where I will resolve the symbols is an x86 machine that has a cross toolchain and gdb with all the symbol packages needed. What would I use to resolve the symbols in a batch from this information I've

Swig Perl: wrong ELF class

由 孤者浪人 提交于 2021-02-11 12:36:31
问题 I am trying to build a Perl module out of a CXX module using Swig. There are multiple guides related to this: The generic Swig tutorial with a Perl section The Swig and C++ guide The Swig and Perl5 guide I'm new to Swig and not very familiar with C(++), but I've been able to compile my module following the tutorial in 1: I created an interface file: %module my_module %{ #include "case.h" #include "case.h" #include "lexindex.h" #include "intlist.h" #include "weight.h" #include "invindex.h"

Violating the one definition rule by simply linking dynamically

由 生来就可爱ヽ(ⅴ＜●) 提交于 2021-02-11 08:09:14
问题 Question: Are dynamically linked C++ programs on ELF platforms always on the brink of producing undefined behavior by violating the one definition rule? More specific: By simply writing a shared library exposing one function #include <string> int __attribute__((visibility("default"))) combined_length(const char *s, const char *t) { const std::string t1(t); const std::string u(s + t1); return u.length(); } and compiling it with GCC 7.3.0 via $ g++ -Wall -g -fPIC -shared \ -fvisibility=hidden

Violating the one definition rule by simply linking dynamically

由 孤者浪人 提交于 2021-02-11 08:08:04
问题 Question: Are dynamically linked C++ programs on ELF platforms always on the brink of producing undefined behavior by violating the one definition rule? More specific: By simply writing a shared library exposing one function #include <string> int __attribute__((visibility("default"))) combined_length(const char *s, const char *t) { const std::string t1(t); const std::string u(s + t1); return u.length(); } and compiling it with GCC 7.3.0 via $ g++ -Wall -g -fPIC -shared \ -fvisibility=hidden

Violating the one definition rule by simply linking dynamically

由 痞子三分冷 提交于 2021-02-11 08:07:37
问题 Question: Are dynamically linked C++ programs on ELF platforms always on the brink of producing undefined behavior by violating the one definition rule? More specific: By simply writing a shared library exposing one function #include <string> int __attribute__((visibility("default"))) combined_length(const char *s, const char *t) { const std::string t1(t); const std::string u(s + t1); return u.length(); } and compiling it with GCC 7.3.0 via $ g++ -Wall -g -fPIC -shared \ -fvisibility=hidden

Violating the one definition rule by simply linking dynamically

由 孤人 提交于 2021-02-11 08:07:28
问题 Question: Are dynamically linked C++ programs on ELF platforms always on the brink of producing undefined behavior by violating the one definition rule? More specific: By simply writing a shared library exposing one function #include <string> int __attribute__((visibility("default"))) combined_length(const char *s, const char *t) { const std::string t1(t); const std::string u(s + t1); return u.length(); } and compiling it with GCC 7.3.0 via $ g++ -Wall -g -fPIC -shared \ -fvisibility=hidden

Violating the one definition rule by simply linking dynamically

由 不打扰是莪最后的温柔 提交于 2021-02-11 08:06:55
问题 Question: Are dynamically linked C++ programs on ELF platforms always on the brink of producing undefined behavior by violating the one definition rule? More specific: By simply writing a shared library exposing one function #include <string> int __attribute__((visibility("default"))) combined_length(const char *s, const char *t) { const std::string t1(t); const std::string u(s + t1); return u.length(); } and compiling it with GCC 7.3.0 via $ g++ -Wall -g -fPIC -shared \ -fvisibility=hidden

ELF read/write in other process memory

由 蓝咒 提交于 2021-02-08 11:50:30
问题 Is there an equivalent of ReadProcessMemory windows function for reading (or writing) in another process memory ? I have tried to preload a shared library, i have also tried to debug (ptrace, peek and poke memory). It seems to work, but i am wondering if there is not a simplest way... 回答1: Is there an equivalent of ReadProcessMemory Yes: man ptrace ( PTRACE_PEEKDATA , etc.) The ptrace interface is generic to UNIX, and has nothing to do with ELF (i.e. it also works on systems that use COFF ,
订阅 elf