On Wed, Mar 11, 2009 at 11:03:10AM +0100, Joel Porquet wrote: > By default, the chosen tls model is "initial-exec", which causes one > relocation for "b" (R_MIPS_TLS_TPREL32). If I specify "local-exec", > the behavior is as expected, I get no relocation at all. But whenever > I choose a dynamic model ("local-dynamic" or "global-dynamic"), I > still get a "R_MIPS_TLS_TPREL32" which is not a dynamic relocation. > Why this?
No particular reason, it's just how GCC behaves. I consider it a bug, though minor. > 5ffe0424: 3c034003 lui v1,0x4003 > 5ffe0428: 00621821 addu v1,v1,v0 > 5ffe042c: 8c625760 lw v0,22368(v1) > The suspicious instruction is "lui v1,0x4003". I don't understand > where does "0x4003" comes from... Check what symbol is at, or near, 0x40030000 + 22368. It's probably the GOT plus a constant bias. > This time, it seems gcc expects "__get_tls_addr" to return the > DTP+0x8000. Indeed the access to variable "b" is done with "lw > v0,-32768(v1)" and 32768==0x8000. Are you sure both of those code sequences are calling __tls_get_addr? If so, compare the arguments they passed. > Last question, is there a difference between DSO and PIE objects other > than the INTERP entry in the program header? Yes. Symbol preemption is allowed for DSOs but not for PIEs or normal executables. That explains the different choice of model. -- Daniel Jacobowitz CodeSourcery