From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-help-return-54735-listarch-gcc-help=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 30654 invoked by alias); 29 Jan 2014 19:50:48 -0000
Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-help.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-help@gcc.gnu.org>
Sender: gcc-help-owner@gcc.gnu.org
Received: (qmail 30645 invoked by uid 89); 29 Jan 2014 19:50:47 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.2
X-HELO: fep45.mx.upcmail.net
Received: from fep45.mx.upcmail.net (HELO fep45.mx.upcmail.net) (62.179.121.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Jan 2014 19:50:46 +0000
Received: from edge01.upcmail.net ([192.168.13.236])          by viepfeppe45-int.chello.at          (InterMail vM.8.01.05.11 201-2260-151-128-20120928) with ESMTP          id <20140129195043.JJPF8330.viepfeppe45-int.chello.at@edge01.upcmail.net>          for <gcc-help@gcc.gnu.org>; Wed, 29 Jan 2014 20:50:43 +0100
Received: from noppl-pc ([80.108.207.49])	by edge01.upcmail.net with edge	id Kvqh1n00u14UsaQ01vqjWP; Wed, 29 Jan 2014 20:50:43 +0100
X-SourceIP: 80.108.207.49
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: gcc-help@gcc.gnu.org
Subject: Re: ColdFire and Thread-Local Storage
References: <52E7D186.4030108@embedded-brains.de> <CAKOQZ8yGOWKD3d7waw0f7ucaStHENQ16X=EMntnKBsG45JpG3w@mail.gmail.com> <52E8B2FE.5040102@embedded-brains.de>
Date: Wed, 29 Jan 2014 19:50:00 -0000
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Norbert Lange" <lange@chello.at>
Message-ID: <op.xagr2oy8sf9m9j@noppl-pc>
In-Reply-To: <52E8B2FE.5040102@embedded-brains.de>
User-Agent: Opera Mail/12.16 (Win32)
X-IsSubscribed: yes
X-SW-Source: 2014-01/txt/msg00120.txt.bz2

Hello,

its been some time since I looked at the TLS conventions and I only done  
this on ARM.
But I would strongly advise you to implement the function in asm, on ARM  
you arent allowed to change any register except the one you return and I  
would bet its the same on other architectures.

Norbert

Am 29.01.2014, 08:51 Uhr, schrieb Sebastian Huber  
<sebastian.huber@embedded-brains.de>:

> On 2014-01-28 20:15, Ian Lance Taylor wrote:
>> On Tue, Jan 28, 2014 at 7:49 AM, Sebastian Huber
>> <sebastian.huber@embedded-brains.de> wrote:
>>>
>>> it seems GCC uses this ColdFire TLS ABI:
>>>
>>> https://lists.debian.org/debian-68k/2007/11/msg00071.html
>>>
>>> Here we have a function
>>>
>>> void *__m68k_read_tp(void)
>>>
>>> which must return the thread pointer in register a0.
>>>
>>> I have to implement this function.  Is there a way to instruct GCC to  
>>> return
>>> the value in register a0 instead of d0 or do I have to use assembler to
>>> implement this function?
>>
>> I believe that on m68k GNU/Linux a function that returns a pointer
>> will normally return the value in a0.
>>
>> Ian
>>
>
> The function
>
> void *__m68k_read_tp(void)
> {
>    const Thread_Control *executing = _Thread_Get_executing();
>
>    return (char *) executing->Start.tls_area +
>      _TLS_Get_thread_control_block_area_size((uintptr_t) _TLS_Alignment)
>      + 0x7000;
> }
>
> translates to
>
> __m68k_read_tp:
>          move.l #_TLS_Alignment,%d0
>          moveq #8,%d1
>          move.l _Per_CPU_Information+18,%a0
>          cmp.l %d0,%d1
>          jls .L2
>          moveq #8,%d0
> .L2:
>          add.l #28672,%d0
>          add.l 194(%a0),%d0
>          rts
>
> I use now:
>
> void __m68k_read_tp(void)
> {
>    const Thread_Control *executing = _Thread_Get_executing();
>    void *tp = (char *) executing->Start.tls_area +
>      _TLS_Get_thread_control_block_area_size((uintptr_t) _TLS_Alignment)
>      + 0x7000;
>
>    __asm__ volatile (
>      "move.l %0, %%a0"
>      :
>      : "d" (tp)
>    );
> }