From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12705 invoked by alias); 27 Jul 2002 22:40:46 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 12698 invoked from network); 27 Jul 2002 22:40:46 -0000 Received: from unknown (HELO igw3.watson.ibm.com) (198.81.209.18) by sources.redhat.com with SMTP; 27 Jul 2002 22:40:46 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g6RMebC04490; Sat, 27 Jul 2002 18:40:37 -0400 Received: from makai.watson.ibm.com (makai.watson.ibm.com [9.2.216.144]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g6RMebH29058; Sat, 27 Jul 2002 18:40:37 -0400 Received: from watson.ibm.com (localhost [127.0.0.1]) by makai.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) with ESMTP id SAA31344; Sat, 27 Jul 2002 18:40:32 -0400 Message-Id: <200207272240.SAA31344@makai.watson.ibm.com> To: Richard Henderson cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Re: thread-local storage: c front end and generic backend patch In-Reply-To: Message from Richard Henderson of "Sat, 27 Jul 2002 14:47:59 PDT." <20020727144759.E28013@redhat.com> Date: Sat, 27 Jul 2002 16:18:00 -0000 From: David Edelsohn X-SW-Source: 2002-07/txt/msg01628.txt.bz2 I think of data, common, bss, weak, etc. mapping into the following, basic characteristics: 1) Initialized Data (data section) versus Uninitialized Data (bss section, blank static storage initialized with zeros). 2) Global scope versus Local scope. 3) Multiple symbol definitions merged (common) or error (no-common). Common specifies global, uninitialized data which is merged with other definitions of the same global symbol by the linker. Local common specifies local, uninitialized data which is merged with other definitions of the same local symbol by the *assembler*. If a data section global symbol definition does not override a common symbol, the common symbol is instantiated in the BSS section. Explicitly defining a BSS symbol specifies global, uninitialized data which *cannot* be merged and is an error if a duplicate definition of the global symbol appears in another module. In other words, BSS but not COMMON. ASM_OUTPUT_COMMON generates an uninitialized, global, common-label name. ASM_OUTPUT_LOCAL generates an uninitialized, local, common-label name. ASM_OUTPUT_BSS generates an uninitialized, global name. David> Is ".common" all common or only global common? Richard> Only global, I'd say. Local common doesn't make any sense when Richard> you think of the linker semantics. Right, because it's assembler semantics, not linker semantics. Richard> Local common _is_ BSS. Perhaps the target doesn't support changing Richard> to a section via .bss and emitting symbols, but that's the effect Richard> of e.g. the .lcomm directive. Well, sort of. Local common is allocated in the BSS section, but it's scope is local, while a BSS symbol can have global scope. And local common symbols can be merged by the assembler, while pure BSS symbols cannot have duplicates. What I meant by no connection between local common and BSS is that there is no connection between an assembler/linker allowing GCC to emit unique BSS symbol definitions which cannot be merged (using ASM_OUTPUT_BSS) and allowing uninitialized data through local common. The current logic in varasm.c means that if the target does not support directly emitting a BSS global symbol, then it does not support local common either and no uninitialized local data is generated. If you want GCC DECL_COMMON to mean linker-only common, fine. David> * varasm.c (assemble_variable): Narrow test for uninitialized David> without BSS target support. Richard> This is about what I had in mind. Any additional change you want me to make, such as localizing this logic in asm_emit_uninitialized, or can I commit the patch as posted? Thanks, David