relocation

Problems with static local variables with relocatable code

霸气de小男生 提交于 2019-12-12 16:16:08
问题 I am building a project which has relocatable code on bare metal. It is a Cortex M3 embedded application. I do not have a dynamic linker and have implemented all the relocations in my startup code. Mostly it is working but my local static variables appear to be incorrectly located. Their address is offset by the amount that my executable is offset in memory - ie I compile my code as if it is loaded at memory location 0 but I actually load it in memory located at 0x8000. The static local

What's the purpose of copy relocation?

大兔子大兔子 提交于 2019-12-10 09:41:44
问题 BACKGROUND: If an executable file has a external data reference, which is defined in a shared object, the compiler will use copy relocation and place a copy in its .bss section. Copy relocation is detailed in this site: http://www.shrubbery.net/solaris9ab/SUNWdev/LLM/p22.html#CHAPTER4-84604 However, my question is: Is it possible to implement it through GOT, just like the external data reference in shared object? The executable can indirectly accesses this external code through its GOT entry,

How is it that main function is always loaded at the same address whereas variables have different address most of the time?

て烟熏妆下的殇ゞ 提交于 2019-12-07 09:17:59
问题 I wrote this small program today and I was blown away by the results. Here is the program int main(int argc, char **argv) { int a; printf("\n\tMain is located at: %p and the variable a is located at address: %p",main,&a); return 0; } on my machine the main function is always loaded at address "0x80483d4" and the address of the variable keeps on varying How does this happen? I read in operating systems that as a part of virtualization scheme the OS keeps relocating the address of instructions.

What's the purpose of copy relocation?

一个人想着一个人 提交于 2019-12-06 02:56:12
BACKGROUND: If an executable file has a external data reference, which is defined in a shared object, the compiler will use copy relocation and place a copy in its .bss section. Copy relocation is detailed in this site: http://www.shrubbery.net/solaris9ab/SUNWdev/LLM/p22.html#CHAPTER4-84604 However, my question is: Is it possible to implement it through GOT, just like the external data reference in shared object? The executable can indirectly accesses this external code through its GOT entry, and this GOT entry can be stuffed with the real address of this symbol in run-time. I don't know why

How is it that main function is always loaded at the same address whereas variables have different address most of the time?

假装没事ソ 提交于 2019-12-05 17:39:59
I wrote this small program today and I was blown away by the results. Here is the program int main(int argc, char **argv) { int a; printf("\n\tMain is located at: %p and the variable a is located at address: %p",main,&a); return 0; } on my machine the main function is always loaded at address "0x80483d4" and the address of the variable keeps on varying How does this happen? I read in operating systems that as a part of virtualization scheme the OS keeps relocating the address of instructions. So why is it that everytime I run this program that main is loaded at the same address? thanks in

Recompiling with -fPIC

蓝咒 提交于 2019-12-05 01:23:06
问题 I have MPICH 3.0.4 installed on my machine (Ubuntu 12.04). I am trying to install a library called Qthreads which I have worked with and successfully installed before (except with the MPICH2 package installed). The configuration works fine: ./configure --prefix=/usr/local/qthreads --enable-multinode --with-multinode-runtime=mpi --with-portals4=/usr/local/portals4 --with-hwloc=/usr/local/hwloc : ... ... ... System Characteristics: Target Style: unix Multi-node: yes, mpi Topology API: hwloc

Resolve relative relocations in partial link

こ雲淡風輕ζ 提交于 2019-12-04 03:58:31
问题 I've noticed that using -r to do a partial link doesn't actually resolve any relocations, it seems, even if they could be resolved via relative addressing. For example, consider f.o and g.o , with f.o containing f() which calls g() within g.o . Before linking, the disassembly and relocations are as expected. After partial linking to a new file h.o (via ld -r -o h.o f.o g.o ), however, there is still a relocation for the call to g() , even though in theory it could have been resolved with a

Dynamic relocation of code section

天涯浪子 提交于 2019-12-04 00:59:04
Just out of curiosity I wonder if it is possible to relocate a piece of code during the execution of a program. For instance, I have a function and this function should be replaced in memory each time after it has been executed. One idea that came up our mind is to use self-modifying code to do that. According to some online resources, self-modifying code can be executed on Linux, but still I am not sure if such a dynamic relocation is possible. Has anyone experience with that? Yes dynamic relocation is definitely possible. However, you have to make sure that the code is completely self

Cmake: Exporting subproject targets to main project

瘦欲@ 提交于 2019-12-03 14:29:32
I currently have a project called LIBS with a structure like this: ├── Lib1 │ ├── CMakeLists.txt │ ├── lib1-class.cpp │ └── lib1-class.h ├── lib2 │ └── CMakeLists.txt │ ├── lib2-class.cpp │ ├── lib2-class.h ├── cmake │ └── LIBSConfig.cmake.in ├── CMakeLists.txt in the main cmake file, I have: install( TARGETS lib1 lib2 DESTINATION ${PROJECT_DIRNAME_lib} EXPORT ${PROJECT_NAME}Exports ) install( EXPORT ${PROJECT_NAME}Exports DESTINATION ${PROJECT_DIRNAME_lib} ) as I want to export these in a package that is discoverable by find_package(). My problem is that I generate lib1 and lib2 in their

How are PE Base Relocations build up?

丶灬走出姿态 提交于 2019-12-03 10:39:01
问题 I'm currently having trouble understanding how PE Base Relocations are build up. I understand there can be more then one relocation, I understand also why and how this is done, but I just don't understand it programmatically: Which of the following is true (IMAGE_BASE_RELOCATION in WinNT.h)? // Base relocation #1 DWORD VirtualAddress; DWORD SizeOfBlock; // size of current relocation WORD TypeOffset[1]; // Base relocation #2 DWORD VirtualAddress; DWORD SizeOfBlock; // size of current