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

Reply via email to