2009/3/16 Daniel Jacobowitz d...@false.org:
On Mon, Mar 16, 2009 at 06:19:01PM +0100, Joel Porquet wrote:
2009/3/12 Daniel Jacobowitz d...@false.org:
On Thu, Mar 12, 2009 at 02:02:36PM +0100, Joel Porquet wrote:
Check what symbol is at, or near, 0x4003 + 22368. It's probably
the GOT
On Tue, Mar 17, 2009 at 10:26:05AM +0100, Joel Porquet wrote:
I don't understand how the runtime loader could know that! As far as I
know, the tls model is not embedded in reloc information.
Sure it is. I suggest you go back to Ulrich Drepper's TLS paper
for more information about the
2009/3/17 Daniel Jacobowitz d...@false.org:
On Tue, Mar 17, 2009 at 10:26:05AM +0100, Joel Porquet wrote:
I don't understand how the runtime loader could know that! As far as I
know, the tls model is not embedded in reloc information.
Sure it is. I suggest you go back to Ulrich Drepper's TLS
On Tue, Mar 17, 2009 at 04:03:45PM +0100, Joel Porquet wrote:
2009/3/17 Daniel Jacobowitz d...@false.org:
On Tue, Mar 17, 2009 at 10:26:05AM +0100, Joel Porquet wrote:
I don't understand how the runtime loader could know that! As far as I
know, the tls model is not embedded in reloc
2009/3/17 Daniel Jacobowitz d...@false.org:
On Tue, Mar 17, 2009 at 04:03:45PM +0100, Joel Porquet wrote:
2009/3/17 Daniel Jacobowitz d...@false.org:
On Tue, Mar 17, 2009 at 10:26:05AM +0100, Joel Porquet wrote:
I don't understand how the runtime loader could know that! As far as I
know,
On Tue, Mar 17, 2009 at 04:21:18PM +0100, Joel Porquet wrote:
Problem is how can you find the symbol referenced by the relocation
when the symbol index is null??
Then, should we consider that a null symbol index means that the
module relocation is the DSO itself?
Yes, that's what I said.
2009/3/12 Daniel Jacobowitz d...@false.org:
On Thu, Mar 12, 2009 at 02:02:36PM +0100, Joel Porquet wrote:
Check what symbol is at, or near, 0x4003 + 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
On Mon, Mar 16, 2009 at 06:19:01PM +0100, Joel Porquet wrote:
2009/3/12 Daniel Jacobowitz d...@false.org:
On Thu, Mar 12, 2009 at 02:02:36PM +0100, Joel Porquet wrote:
Check what symbol is at, or near, 0x4003 + 22368. It's probably
the GOT plus a constant bias.
It seems there is
Check what symbol is at, or near, 0x4003 + 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 0x34
On Thu, Mar 12, 2009 at 02:02:36PM +0100, Joel Porquet wrote:
Check what symbol is at, or near, 0x4003 + 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
Dear GCC-list and Daniel,
Lately, I continued working on TLS for mips and a few things bother me.
Firstly, it seems the -ftls-model option for gcc is not completely
respected when compiling Position-Independent Executable (-fpie).
Here is a sample of code for app.c:
__thread int a = 0;
extern
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
2008/11/21 Daniel Jacobowitz [EMAIL PROTECTED]:
No, there's nothing wrong with this. You can even use multiple models
in the same executable for the same symbol. The linker will take care
of everything necessary.
For instance, the executable's TLS block is at a fixed offset from the
DTV
On Mon, Nov 24, 2008 at 03:27:55PM +0100, Joel Porquet wrote:
And the related reloc symbols are:
5ffe14b0 0026 R_MIPS_TLS_DTPMOD
5ffe14b8 0026 R_MIPS_TLS_DTPMOD
Still, is R_MIPS_TLS_DTPMOD a correct symbol ?
In the document you wrote about NPTL for mips
2008/11/20 Daniel Jacobowitz [EMAIL PROTECTED]:
On Thu, Nov 20, 2008 at 05:28:16PM +0100, Joel Porquet wrote:
Gcc is using local-exec tls model instead of global-dynamic. The
option -fpie is supposed to act as -fpic though (dixit the manual).
Here is the first problem...
Could you explain
This is one of the reasons that the generated code can only be used
in executables.
Okay, I abdicate on this point.
Nevertheless, how could i have a coherent compilation concerning the
TLS management, if my executable needs dynamically libraries ? Aren't
the exec and dynamic models completely
On Fri, Nov 21, 2008 at 06:51:26PM +0100, Joel Porquet wrote:
Nevertheless, how could i have a coherent compilation concerning the
TLS management, if my executable needs dynamically libraries ? Aren't
the exec and dynamic models completely incompatible in the same
whole (eg one executable and
17 matches
Mail list logo
