On Mon, Jan 20, 2020 at 1:28 PM Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > On Tue, Jan 07, 2020 at 04:04:33PM -0500, William Tambe wrote: > > On Tue, Jan 7, 2020 at 3:32 PM J Decker <d3ck0r@xxxxxxxxx> wrote: > > > > > > I do think having a the reason why you would want to do this instead of 'how can I do this' might help... (something of an X-Y problem) > > > > I agree; I have added the reason to my previous email: > > Such that in the above example the address of myfunc that is used to > > initialize myglobal get computed at run-time instead of at compile > > time. > > > > The question is what actual problem are you facing with the way it's > done now. Do you have some special environment you need to run in where > the normal support code to make this work doesn't exist? In my environment I do not have a dynamic linker; hence the reason I am looking for a solution where GCC will generate the initialization instruction for the global variable just like it would do it for a local variable. > > In a normal system, even though the assembler output for your file looks > like myglobal is being initialized at compile time, it actually gets > initialized at run-time, by the dynamic linker (ld-linux.so) that's part > of glibc (or whatever libc you use). Only the offset from the base > address of the program is calculated and initialized at compile (or > really link) time. I do not have a dynamic linker in my environment. Shouldn't it be possible for PIE executable to run without the need of a dynamic linker ? > > That's assuming you're generating a PIE executable. If you aren't, it > will be initialized by the static linker at link time, and there's no > apparent reason why you would want to postpone it to run-time since the > address can't change. PIE gets generated by default; I need for it to be done at run-time such that the correct address of myfunc() get computed; currently the address computed at compile-time is not the correct address if the executable is not loaded at its TEXT_START_ADDR.
