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/17 Daniel Jacobowitz :
> On Tue, Mar 17, 2009 at 04:03:45PM +0100, Joel Porquet wrote:
>> 2009/3/17 Daniel Jacobowitz :
>> > 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
On Tue, Mar 17, 2009 at 04:03:45PM +0100, Joel Porquet wrote:
> 2009/3/17 Daniel Jacobowitz :
> > 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.
2009/3/17 Daniel Jacobowitz :
> 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
>
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 relocat
2009/3/16 Daniel Jacobowitz :
> On Mon, Mar 16, 2009 at 06:19:01PM +0100, Joel Porquet wrote:
>> 2009/3/12 Daniel Jacobowitz :
>> > 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 const
On Mon, Mar 16, 2009 at 06:19:01PM +0100, Joel Porquet wrote:
> 2009/3/12 Daniel Jacobowitz :
> > 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 i
2009/3/12 Daniel Jacobowitz :
> 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
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
> 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 0x5ffe
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 mod
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;
ext
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
> (http://www
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
>
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
> 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 11:19:32AM +0100, Joel Porquet wrote:
> I agree that wether the code is pic or not and the tls model are quite
> independent.
> According to the manual, the default policy for TLS is affected by the
> pic model though:
>
> -ftls-model=model
> ...
> The default wit
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
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 the problem with this? The choice of local-exec v
Hi,
I'm trying to compile a Position Independent Executable with a TLS but
gcc doesn't generate the expected code (at least, what i expect).
Here's an example:
__thread int test_loc;
void func()
{
test_loc = 2;
}
I compile the object with:
CFLAGS=-nostdinc -nostdlib -fno-builtin \
20 matches
Mail list logo
