OSDev.org

Hi,

I have been converting the few things I implemented for my OS from assembly to C++ and everything works except one thing I can't figure out how to work around. As you all know, if I don't use "-fwhole-program" I will get a bunch of unused functions because g++ assumes that the program may be a library and needs to export functions, so the small functions that got inlined will have an unused base function just laying around.

On one hand I can start my code with a random named function like "loader" or something but I can't use "-fwhole-program" because it will assume all my code as unused and erases it all so I get an empty binary.
On the the other hand I can call my start function main and "-fwhole-program" works wonderfully as it is supposed to but at the beginning of the binary (2nd instruction right after sub rsp) either I get a "call qword 0x9" and it breaks the stack (which can be fixed by inline asm "add $8, %rsp") or I get a "lea rax,[rel 0xb]" "call rax" if I use "-mcmodel=large" like I want to and an infinite loop will begin, calling that call itself until rsp is negative and canonical address exception happens. Is there a way to tell g++ to not put a useless code breaking call at the start of the "main" function?


Cheers,
Luís

1: Make sure you are using a cross-compiler.
2: Emit relocations, symbols and debugging information, and use objdump to check where the call qword [0x9] was supposed to point.

If neither reveals a potential solution, post the minimal set of sources and command line instructions (using the cross-compiler from #1) that reproduces the problem.

Thanks, I have a 64 bit pe cross but I'll try to make a x86_64-pc-elf64 one and see how it goes. Cygwin is not compiling binutils anymore I have no idea why so I'm gonna try a virtual machine linux and see how it goes. That call is to adress 9 not adress in memory [9] and yes it's pointing to the correct address which is the the instruction right after that call which makes that call pretty useless. Anyway I'll try a new cross compiler and see if that new one doesn't screw things. Btw I suppose there is no such thing as x86_64-pc-binary right? Would be nice to drop the objcopy to convert to binary format to get a stripped version of the file.

x86_64-pc-elf does the trick. I guess my old cross compiler wasn't good enough. Thanks again Combuster