From patchwork Sun Jun 24 11:50:29 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 933903 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-480382-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="vVWB9hvf"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 41D9c83vStz9s01 for ; Sun, 24 Jun 2018 21:50:46 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:mime-version:content-type; q=dns; s=default; b=HSo9b0uRFINKFzf2ttSBZz9Rzi5J+l0IiKDd1+ujG6QJ36Ec0V Wik6DkjTyRRmnw9cwdnJ91B+5lLvGY/EYW288yUrRBys4ALgVS7ZqgSauokUwq2B LENtd5uAwxuMOMubsRNhN6mBRcKcEpWILFNMPuQhXvz9e66PBTbtjCVMk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:mime-version:content-type; s= default; bh=30pPn+zEHeYeFyKfhKAl0RX3O5A=; b=vVWB9hvfn1PyKSpg0nKd FUZkxjBzkgC57PWiugMMcJh85QW8UvAUXpsg9NjDKRfiTIJa0vJS+Fa626VRbJUK 1w8p5ehR1ikC71twAKl765RRJxQn1iRRLkXao4ZmAEycfVG0Yg0A8VObFS/VaWsH j5uK6GOOSCpQ5Kgkl4UDQ58= Received: (qmail 387 invoked by alias); 24 Jun 2018 11:50:37 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 377 invoked by uid 89); 24 Jun 2018 11:50:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.2 spammy=H*MI:localhost, UD:i386.md, i386.md, i386md X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 24 Jun 2018 11:50:34 +0000 Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4A6FFADA2; Sun, 24 Jun 2018 11:50:31 +0000 (UTC) Date: Sun, 24 Jun 2018 13:50:29 +0200 From: Tom de Vries To: gcc-patches@gcc.gnu.org Cc: Uros Bizjak , Jan Hubicka Subject: [PATCH, PR86257, i386/debug] Fix insn prefix in tls_global_dynamic_64_ Message-ID: <20180624115027.zjjyorpdpb32ekm6@localhost.localdomain> MIME-Version: 1.0 Content-Disposition: inline User-Agent: NeoMutt/20170912 (1.9.0) X-IsSubscribed: yes Hi, [ The analysis of this PR was done at https://stackoverflow.com/a/33557963 , November 2015. ] This tls sequence: ... 0x00 .byte 0x66 0x01 leaq x@tlsgd(%rip),%rdi 0x08 .word 0x6666 0x0a rex64 0x0b call __tls_get_addr@plt ... starts with an insn prefix, produced using a .byte. When using a .loc before the sequence, it's associated with the next assembly instruction, which is the leaq, so the .loc will end up pointing inside the sequence rather than to the start of the sequence. And when the linker relaxes the sequence, the .loc may end up pointing inside an insn. This will cause an executable containing such a misplaced .loc to crash when gdb continues from the associated breakpoint. This patch fixes the problem by using data16 to generate the prefix. Bootstrapped and reg-tested on x86_64. OK for trunk? Thanks, - Tom [i386/debug] Fix insn prefix in tls_global_dynamic_64_ 2018-06-22 Tom de Vries PR debug/86257 * config/i386/i386.md (define_insn "*tls_global_dynamic_64_"): Use data16 instead of .byte for insn prefix. * gcc.dg/pr86257.c: New test. --- gcc/config/i386/i386.md | 13 ++++++++++++- gcc/testsuite/gcc.dg/pr86257.c | 14 ++++++++++++++ 2 files changed, 26 insertions(+), 1 deletion(-) diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md index eb77ef3c08f..6f2300057aa 100644 --- a/gcc/config/i386/i386.md +++ b/gcc/config/i386/i386.md @@ -14733,7 +14733,18 @@ "TARGET_64BIT" { if (!TARGET_X32) - fputs (ASM_BYTE "0x66\n", asm_out_file); + /* The .loc directive has effect for 'the immediately following assembly + instruction'. So for a sequence: + .loc f l + .byte x + insn1 + the 'immediately following assembly instruction' is insn1. + We want to emit an insn prefix here, but if we use .byte (as shown in + 'ELF Handling For Thread-Local Storage'), a preceding .loc will point + inside the insn sequence, rather than to the start. After relaxation + of the sequence by the linker, the .loc might point inside an insn. + Use data16 prefix instead, which doesn't have this problem. */ + fputs ("\tdata16", asm_out_file); output_asm_insn ("lea{q}\t{%E1@tlsgd(%%rip), %%rdi|rdi, %E1@tlsgd[rip]}", operands); if (TARGET_SUN_TLS || flag_plt || !HAVE_AS_IX86_TLS_GET_ADDR_GOT) diff --git a/gcc/testsuite/gcc.dg/pr86257.c b/gcc/testsuite/gcc.dg/pr86257.c new file mode 100644 index 00000000000..3287c190d36 --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr86257.c @@ -0,0 +1,14 @@ +/* { dg-require-effective-target fpic } */ +/* { dg-require-effective-target tls } */ +/* { dg-options "-g -fPIC" } */ + +__thread int i; + +void +foo(void) +{ + i = 0; +} + +/* { dg-final { scan-assembler "data16\[ \t\]*leaq" } } */ +/* { dg-final { scan-assembler-not "\.byte\[ \t\]*0x66\n\[ \t\]*leaq" } } */