elf

Set the heap start address in C program?

由 微笑、不失礼 提交于 2020-06-12 04:44:28
问题 Is there a way to set the heap start address in GCC compiled C program in linux? In x86_64 system,my test program sets the heap address to 4 byte referenced address ( less than FFFFFFFF). I want to set this to 8 byte referenced address for some testing ( > FFFFFFFF). Does GCC provide any way to set the heap start address? 回答1: You can do this a bit indirectly using sbrk() : #include <stdio.h> #include <stdlib.h> #include <unistd.h> int main(void) { sbrk(0xFFFFFFFF); printf("%p\n", malloc(1));

Can i execute code that resides in data segment (ELF binary)?

由 百般思念 提交于 2020-05-25 08:28:28
问题 In the way to understanding binaries (Virtual memory layout, execution...etc), I've written a C code that declares a global string which contains bytes of an executable code, then i overwrote the return address from the main() function to that executable code using a simple trick by declaring a pointer ( PTR ) in main() which is a local area of memory reserved on the stack 2 WORDS far away from the return address from the main() , so all i do is assigning the address of the return address to

Can i execute code that resides in data segment (ELF binary)?

由 耗尽温柔 提交于 2020-05-25 08:27:09
问题 In the way to understanding binaries (Virtual memory layout, execution...etc), I've written a C code that declares a global string which contains bytes of an executable code, then i overwrote the return address from the main() function to that executable code using a simple trick by declaring a pointer ( PTR ) in main() which is a local area of memory reserved on the stack 2 WORDS far away from the return address from the main() , so all i do is assigning the address of the return address to

Is -fPIC for shared libraries ONLY?

由 时间秒杀一切 提交于 2020-05-11 17:01:25
问题 I know -fPIC is necessary for shared libraries and know why. However, I am not clear on the question: Should -fPIC never be used during building an executable or a static library? 回答1: Should -fPIC never be used during building an executable or a static library? Never is a strong word, and the statement above is false. Code built with -fPIC is (slightly) less optimal, so why would you want to put it into anything other than a shared library? Let's start with a static library, which has an

ELF: linking: Why do I get undefined references in .so files

由 回眸只為那壹抹淺笑 提交于 2020-05-10 04:42:48
问题 I'm trying to build a program against wxWidgets, and I get a linker error. I'd like to really understand what it means. The error is: /usr/lib/libwx_baseu-2.8.so: undefined reference to `std::ctype<char>::_M_widen_init() const@GLIBCXX_3.4.11' What I don't understand is why the error is at libwx_baseu-2.8.so . I thought that .so files had all its symbols resolved, contrary to .o files that still need linking. When I ldd the .so , I get can resolve all its linked libraries, so there is no

ELF: linking: Why do I get undefined references in .so files

由 心不动则不痛 提交于 2020-05-10 04:42:04
问题 I'm trying to build a program against wxWidgets, and I get a linker error. I'd like to really understand what it means. The error is: /usr/lib/libwx_baseu-2.8.so: undefined reference to `std::ctype<char>::_M_widen_init() const@GLIBCXX_3.4.11' What I don't understand is why the error is at libwx_baseu-2.8.so . I thought that .so files had all its symbols resolved, contrary to .o files that still need linking. When I ldd the .so , I get can resolve all its linked libraries, so there is no

Difference between .dynamic .dynsym and .dynstr in an ELF executable

由 我的梦境 提交于 2020-05-07 15:34:46
问题 My preliminary knowledge is that: .dynamic contains libraries that the executable needs to load .dynsym contains external symbols such as setsockopt@GLIBC_2.0 .dynstr contains strings of function requirements Overall, I am a bit confused as to how these sections work together to create a binary - specifically .dynsym and .dynstr . So my question is two-fold. Are my statements above correct? If so, how do these three sections work together to create a binary? 回答1: Are my statements above

Difference between .dynamic .dynsym and .dynstr in an ELF executable

由 我与影子孤独终老i 提交于 2020-05-07 15:33:59
问题 My preliminary knowledge is that: .dynamic contains libraries that the executable needs to load .dynsym contains external symbols such as setsockopt@GLIBC_2.0 .dynstr contains strings of function requirements Overall, I am a bit confused as to how these sections work together to create a binary - specifically .dynsym and .dynstr . So my question is two-fold. Are my statements above correct? If so, how do these three sections work together to create a binary? 回答1: Are my statements above

Linux内核分析作业第七周

由 岁酱吖の 提交于 2020-03-28 22:32:45
一、 预处理、编译、链接 gcc hello.c -o hello. gcc编译源代码生成最终可执行的二进制程序，GCC后台隐含执行了四个阶段步骤。 预处理 → 编译 → 汇编 → 链接 预处理：编译器将C源代码中包含的头文件编译进来和执行宏替换等工作。 gcc -E hello.c -o hello.i 　　编译：gcc首先要检查代码的规范性、是否有语法错误等，以确定代码的实际要做的工作，在检查无误后，gcc把代码翻译成汇编语言。 gcc –S hello.i –o hello.s-S：该选项只进行编译而不进行汇编，生成汇编代码。 　　汇编：把编译阶段生成的 .s文件 转成二进制目标代码. gcc –c hello.s –o hello.o 　　链接:将编译输出 .o文件 链接成最终的可执行文件。 gcc hello.o –o hello 　　运行：若链接没有-o指明，则生成可执行文件默认为 a.out ./hello 二、可执行文件 　 　1、在windows环境下，只要双击一个.exe的文件就可以执行一个程序，这个以.exe结尾的文件就是一个可执行文件。在andriod系统下，一个.apk的文件就是一个可执行文件，在linux系统下，可执行文件在linux环境下并没有什么特殊的后缀标记，只是在生成该文件时，它的属性设置了可执行（就是‘x’），那么他就是属于可执行文件。 　　2

How to extend a ELF binary

由 两盒软妹~` 提交于 2020-03-28 03:56:53
问题 I am writing a small instrumentation tool. I must insert the instrumentation routine within the binary file. A good approach should be to insert those routines in a separate code segment and a separate data segment, could you explain how to accomplish this? Furthemore how can I modify the size of the code segment in the original file? Best, 回答1: I must insert the instrumentation routine within the binary file. A good approach should be to insert those routines in a separate code segment and a
订阅 elf