From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17325 invoked by alias); 15 Sep 2009 16:16:35 -0000 Received: (qmail 17238 invoked by uid 48); 15 Sep 2009 16:16:17 -0000 Date: Tue, 15 Sep 2009 16:16:00 -0000 Message-ID: <20090915161617.17237.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug debug/41357] libgomp build fail In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "davek at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-09/txt/msg01381.txt.bz2 ------- Comment #12 from davek at gcc dot gnu dot org 2009-09-15 16:16 ------- (In reply to comment #11) > The bogus const info is added in at the end of this call chain, when generating > the var die: > > #0 0x004d0679 in add_const_value_attribute (die=0x7fcbd660, rtl=0x7fd20270) > at /gnu/gcc/gcc/gcc/tree.h:182 > and indeed, it works by simply punting if the symbol ref in question points to > a TLS item, but the flags are wrong in the rtx that is passed in: > > (symbol_ref:SI ("gomp_tls_data") [flags 0x42] gomp_tls_data>) > > This apparently has SYMBOL_REF_TLS_MODEL (rtl) == TLS_MODEL_NONE, so we never > bail out the escape hatch and end up calling add_AT_addr() to create the > DW_AT_const_value that needs relocating against the undefined symbol. It's this part of add_location_or_const_value_attribute() that is adding the bad const value: /* If we have tried to generate the location otherwise, and it didn't work out (we wouldn't be here if we did), and we have a one entry location list, try generating a location from that. */ if (loc_list && loc_list->first) { enum var_init_status status; node = loc_list->first; status = NOTE_VAR_LOCATION_STATUS (node->var_loc_note); rtl = NOTE_VAR_LOCATION (node->var_loc_note); if (GET_CODE (rtl) == VAR_LOCATION && GET_CODE (XEXP (rtl, 1)) != PARALLEL) rtl = XEXP (XEXP (rtl, 1), 0); if (CONSTANT_P (rtl) || GET_CODE (rtl) == CONST_STRING) { add_const_value_attribute (die, rtl); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ return; } (gdb) print (var_loc_list *)0x7fd36d30 $1 = (struct var_loc_list_def *) 0x7fd36d30 (gdb) print $1[0] $2 = {first = 0x7fd36d20, last = 0x7fd36d20, decl_id = 3277} (gdb) print $1[0].first $3 = (struct var_loc_node *) 0x7fd36d20 (gdb) print $1[0].first[0] $4 = {var_loc_note = 0x7fcdd000, label = 0x7ff27298 "*LVL49", section_label = 0xd8e60a "*Ltext0", next = 0x0} (gdb) print $1[0].first[0].var_loc_note $5 = (rtx) 0x7fcdd000 (gdb) call debug_rtx($1[0].first[0].var_loc_note) (note 85 4 66 (var_location thr (expr_list:REG_DEP_TRUE (symbol_ref:SI ("gomp_tl s_data") [flags 0x42] ) (const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION) So, the NOTE_VAR_LOCATION stored in the location list's first entry's var_loc_note field points to this definition that already has incorrect (non-TLS) flags in the rtl. If we look at the var_decl it's based on: (gdb) call debug_tree(0x7fe190c0) unit size align 32 symtab 2145789512 alias set 7 canonical type 0x7fe7df90 fields unsigned SI file /gnu/gcc/gcc/libgomp/libgomp.h line 327 col 10 size unit size align 32 offset_align 128 offset bit offset context chain > context pointer_to_this chain > addressable used public external tls-local-exec BLK file /gnu/gcc/gcc/libgom p/libgomp.h line 361 col 36 size unit size align 32 (mem/s/c:BLK (symbol_ref:SI ("gomp_tls_data") [flags 0x42] ) [7 gomp_tls_data+0 S52 A32]) chain > (gdb) I notice that the tls-local-exec flag is set but there's no TLS mode in the RTL, again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357