I assume most function calls are within the .dso. Therefore I'd like all function calls to just use 0xE8. Where the function call is resolved by the linker to not be within the same .dso, I'd like the linker to generate a small stub. That stub will use GOT, yes. But the majority of function calls will be within the .dso and be cheaply position independent without either GOT or TEXTREL. Data accesses I would assume are almost never cross-.dso. The rare ones would be source-annotated with some sort of "import", and the compiler would generate less efficient but PIC code for them. Unannotated data access would, well, PIC would probably still necessitate something "inefficient", maybe the same for intra-.dso as inter-.dso. Does that make sense? Interposition is not a goal (for me and I think most people, but granted of ELF.) This is basically the Win32/NT model and seems pretty good. Win32/NT furthermore doesn't really have PIC, so what I say about data access is different there. And the linker generated stubs are probably different. I'll repeat myself: one model for function calls: just a direct position indepedent non-interposible 0xE8, linker generated stubs for the ones that are cross .dso data: possibly annotated, and not direct I'm actually fairly ignorant of x86 addressing modes and exactly the PIC codegen model, so I don't know if annotating data accesses would help much. Data accesses "have to" be annotated on NT, but that isn't entirely relevant, because Cygwin gets around it somehow, and the resulting intra-.dso accesses aren't PIC anyway. Given they have to be indirect somehow even for intra-.dso use to avoid TEXTREL, not sure intra vs. inter can be optimized much. But definitely function calls can be.. Thanks, - Jay ---------------------------------------- > To: jay.krell@xxxxxxxxxxx > CC: gcc-help@xxxxxxxxxxx > Subject: Re: ideal visibility setting? > From: iant@xxxxxxxxxx > Date: Thu, 20 May 2010 09:34:55 -0700 > > Jay K writes: > >> Ian, I don't have to use -fPIC and go through GOT/PLT, in case my code will end up in a .so? >> Well, it looks like you can do that -- omit -fPIC -- but then you get TEXTREL, not good. >> >> >> You know, x86 already has the ip-relative 0xE8 opcode. >> I'd like to just use that, directly to the function, have the linker generate a stub if it ends up imported (using GOT/PLT). >> But still whatever more complicated stuff is needed to reference data without TEXTREL. > > That approach does not permit symbol interpositioning, which is a key > goal of ELF. If you don't want to permit symbol interpositioning, you > can avoid the PLT if you with -fPIC, but link with -Bsymbolic. > > That will still wind up using the GOT for global/static variables, but > I don't see how you can avoid that in position independent code. > There is no PC relative load instruction for 32-bit x86. As far as I > can see you must either use a GOT or get a TEXTREL tag. > > Ian
