On Thu, Mar 12, 2009 at 02:02:36PM +0100, Joel Porquet wrote: > > 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:
Don't know then. Look at compiler-generated assembly instead of disassembly; that often helps. > 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)... That statement about uclibc strikes me as bizarre. I tested it with glibc, naturally. GLIBC has a much more reliable TLS implementation than uclibc's in-progress one. > >> 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. You can't. > 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? This is a *module* relocation. In local dynamic the module is always the current DSO; it does not need a symbol. -- Daniel Jacobowitz CodeSourcery
