public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ro at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/47631] New: Support native TLS on Tru64 UNIX
Date: Mon, 07 Feb 2011 12:54:00 -0000	[thread overview]
Message-ID: <bug-47631-4@http.gcc.gnu.org/bugzilla/> (raw)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47631

           Summary: Support native TLS on Tru64 UNIX
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ro@gcc.gnu.org
                CC: rth@gcc.gnu.org
              Host: alpha-dec-osf5.1b
            Target: alpha-dec-osf5.1b
             Build: alpha-dec-osf5.1b


I've just noticed that Tru64 UNIX does have native support for TLS, obviously
already in V4.0.  The details are described in the Object File and Symbol Table
Format Specification:

http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/SUPPDOCS/OBJSPEC/TITLE.HTM

especially 

3.3.9        Thread Local Storage (TLS) Data
4.3.3.7      TLS Relocations
4.3.4.26     R_TLS_LITERAL
4.3.4.27     R_TLS_HIGH
4.3.4.28     R_TLS_LOW
8.3.5        Finding Thread Local Storage (TLS) Symbols
13.3.5       TLS Symbols

Compiling th example in 4.3.4.26

__declspec(thread) long foo;
main(){
foo = 2;
}

with cc -S, I get

        .set noat
        .set noreorder
        .tlscomm foo 8
        .rdata
$$1:
        .extern __tlsoffset 8
        .text
        .arch   generic
        .align 4
        .file 1 "osf-tls.c"
        .loc 1 2
 #      2 main(){
        .globl  main
        .ent    main
        .loc 1 2
main:
        .context full
        ldah    $gp, ($27)!gpdisp!1
        lda     $gp, ($gp)!gpdisp!1
        .frame  $sp, 0, $26
        .prologue 1
L$2:
        .loc 1 3
 #      3 foo = 2;
        call_pal 0x9E # rdunique                                               
  # 000003
        ldq     $0, 96($0)
        ldq     $28, __tlsoffset($gp)!tlsliteral!2
        addq    $0, $28, $0
        ldq     $0, ($0)
        mov     2, $3
        ldah    $0, foo($0)!tlshigh!3
        stq     $3, foo($0)!tlslow!3
        .loc 1 4
 #      4 }
        mov     $31, $0                                                        
  # 000004
        unop
        ret     ($26)
        .end    main
        .loc 1 2

A port will probably be somewhat different from an ELF port since there aren't
the 4 different access models.


             reply	other threads:[~2011-02-07 12:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-07 12:54 ro at gcc dot gnu.org [this message]
2012-03-09 16:12 ` [Bug target/47631] " ro at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-47631-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).