This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How do values get into the %gs:0x0 location?


Hi Amittai,

Have you looked the function _dl_allocate_tls (it is from glibc, but
it is compiled to the dynamic linker) ? It not only allocates, but
fills the tls.

And you are right, the content of $gs:0x0 is the same address of
$gs:0x0. The applications makes an indirect access to the TLS static
block using this pointer (if you compile with the option
-mno-tls-direct-seg-refs all the access to TLS data are made this
way).

Eduardo

On Mon, Aug 24, 2009 at 8:59 AM, Amittai Aviram<amittai.aviram@yale.edu> wrote:
> Thanks! ?It looks as if Linux places the address of %gs:0x0 into the
> location %gs:0x0, and I think the glibc routine __libc_setup_tls does this
> rather than the system call (which is called "set_thread_area"), though I
> still haven't found where exactly this happens.
>
> Best wishes,
> Amittai
>
> Amittai Aviram
> Graduate Student in Computer Science
> Yale University
> 646 483 2639
> amittai.aviram@yale.edu
> http://www.amittai.com
>
> On Aug 24, 2009, at 9:02 AM, Carlos O'Donell wrote:
>
>> On Sun, Aug 23, 2009 at 8:24 PM, Amittai Aviram<amittai.aviram@yale.edu>
>> wrote:
>>>
>>> I have searched through a representation of the object code that I had
>>> gotten with objdump -D, and there are many, many instances of moving the
>>> value from %gs:0x0 to a register, as above -- and some instances of
>>> moving a
>>> value from a register to some location at a nonzero offset from %gs, such
>>> as
>>> %gs:0xc -- but not a single instruction in the whole object code dump
>>> that
>>> moves a value into %gs:0x0. ?Does anybody have any idea how this works?
>>> ?It's important to me right now, because I'm debugging a virtual
>>> execution
>>> environment (a sort of lightweight virtual OS) with a code translator,
>>> and
>>> it's failing on the printing of floating-point numbers. ?It looks as if
>>> the
>>> value is remaining 0 at my virtual %gs:0x0, whereas it should be a number
>>> that serves as an address a few instructions later. ?Thanks!
>>
>> The kernel might set this value after the process is cloned. See
>> CLONE_SETTLS in the kernel for your architecture.
>>
>> I don't know how x86 does this, but on hppa we call a kernel helper
>> routine (like a lightweight syscall) to set the thread register to
>> point at the TLS data in memory.
>>
>> Cheers,
>> Carlos.
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]