>> Maybe I misunderstood your original question. Yes, you're calling the >> payload's main() from your loader, and that's OK because your loader >> has already started up through the crt startup code. But I thought >> you >> were trying to link the payload binary so that it could also serve as >> an executable that could be launched by itself rather than via the >> loader. To do that, you need the startup code in the crt*.o files, >> and >> that code will call your payload's main(). > > Yes, I understand. > But what does *not* work is exactly "calling the payload's main() from > the loader". On the other hand, starting the payload directly *does* > work. Your original question was why you couldn't dlopen the PIE binary, and I explained that the TLS model was wrong. We were then talking about building your payload as a real shared library (i.e., with -shared instead of -pie), so that you could dlopen it from your loader. But in order to also be able to launch that as a standalone executable, you need startup code, and that's what I was talking about (theoretically). When you use your launcher, it will just call main, but when you try to run it standalone, it needs to begin execution at _start in order to initialize everything before calling main. Case (a): Build as -pie. - Can launch as standalone. - Cannot dlopen from separate launcher. Case (b): Build as -shared. - Can dlopen from separate launcher. - Need to develop PIC startup code in order to launch as standalone (might work in theory, but no current support). -cary
