> Check what symbol is at, or near, 0x40030000 + 22368. It's probably
> the GOT plus a constant bias.
It seems there is nothing at this address. Here is the program header:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x5ffe0034 0x5ffe0034 0x000c0 0x000c0 R E 0x4
INTERP 0x0000f4 0x5ffe00f4 0x5ffe00f4 0x00013 0x00013 R 0x1
[Requesting program interpreter: /usr/lib/libc.so.1]
LOAD 0x000000 0x5ffe0000 0x5ffe0000 0x00488 0x00488 R E 0x1000
LOAD 0x000488 0x5ffe1488 0x5ffe1488 0x0002c 0x0002c RW 0x1000
DYNAMIC 0x000120 0x5ffe0120 0x5ffe0120 0x002e6 0x002e6 R 0x4
TLS 0x000488 0x5ffe1488 0x5ffe1488 0x00004 0x00004 R 0x4
And no symbol is near the given address. All are around 0x5ffe...
>> 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.
My mistake, you're certainly right on this one. When relocating symbol
DTPREL in the runtime-loader, we return offset - 0x8000 (as PowerPC
does), so with the "global-dynamic" model, tls_get_addr will return
the exact address of tls variable.
By the way, how did you test the code of TLS for mips? I mean, uclibc
seems the more advanced lib for mips, and although this lib seems to
have the necessary code to manage tls once it is "installed", the ldso
doesn't contain any code for handling TLS (relocation, tls allocation,
etc)...
>> 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.
But this is only a property, isn't it? I was meaning, how can you
differenciate them at loading time, when you "analyse" the elf file.
Finally, I observed another strange thing with the local-dynamic
model. It concerns the reloc symbols.
Here is the rel.dyn with local-dynamic:
Relocation section '.rel.dyn' at offset 0x3d0 contains 2 entries:
Offset Info Type Sym.Value Sym. Name
00000000 00000000 R_MIPS_NONE
5ffe1470 00000026 R_MIPS_TLS_DTPMOD
And the same with global-dynamic:
Relocation section '.rel.dyn' at offset 0x3d0 contains 3 entries:
Offset Info Type Sym.Value Sym. Name
00000000 00000000 R_MIPS_NONE
5ffe1470 00000926 R_MIPS_TLS_DTPMOD 00000000 a
5ffe1474 00000927 R_MIPS_TLS_DTPREL 00000000 a
As you surely know, ELF_R_SYM() macro performs (val>>8) which gives
the symbol index in order to retrieve the name of the symbol. This
name then allows to look up the symbol. Unfortunately, in the case of
local-dynamic, ELF_R_SYM will return 0 which is not correct (the same
for global-dynamic will return 9): we can see by the way that readelf
is not able to get the symbol name. What do you think about this?
Regards,
Joel
