From patchwork Mon Sep 9 12:02:07 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 1159692 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-508610-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="ECqtlmoy"; 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 46RmyC61Vrz9s00 for ; Mon, 9 Sep 2019 22:02:58 +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:subject:message-id:mime-version:content-type; q=dns; s= default; b=Coioxt037b+2QJ4mq0r3YwnKBW9z2OxfWZ0yYNRnFxw5Wycc05vaR iOcOM88U1gvuE4SNlIMuzRdx6pzVsQIfD6+pLD0ZyBoHUMje3pJq7AQFPV81fWar HcVYzoQblejLawcPztJvuSv50CI1I+Q8LU640azdM3TQMfmwapbwHc= 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:subject:message-id:mime-version:content-type; s= default; bh=iQ1foMQVxoC6wFQBUkM2jmTFEi0=; b=ECqtlmoyPo21UGZGAWkA dpDrONn6dMAscCVsacXQR4uyzuCr2ASzSEw7ELUXlGTOAERW9otqMkQD+RGrYfdC fVpY0VxIMHvdG8NZyLcjCkaqe+7N7PVLPM3veuSNdzEe9lYVDdc3/PaV3q1+93oV t2FTxxqVxpM6zgQRsL2UjfY= Received: (qmail 62509 invoked by alias); 9 Sep 2019 12:02:11 -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 62449 invoked by uid 89); 9 Sep 2019 12:02:11 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.3 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, SPF_PASS autolearn=ham version=3.3.1 spammy=tus X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Sep 2019 12:02:09 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 89490B670 for ; Mon, 9 Sep 2019 12:02:07 +0000 (UTC) Date: Mon, 9 Sep 2019 14:02:07 +0200 (CEST) From: Richard Biener To: gcc-patches@gcc.gnu.org Subject: [PATCH] Make LTO link pick up compile-time -g Message-ID: User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Currently when you compile with -g -flto and then link without repeating -g you'll get a binary that has all early debug but none of the late because the driver doesn't pass -g along to the LTRANS stage. This has always been the case and as with other options "guessing" correctly is hard. The following goes a very simple way of recording debug_info_level > DINFO_LEVEL_NONE at compile-time into lto-opts.c as -g and picking that one up in lto-wrapper. So if _any_ object was compiled with debug-info (of any kind) then we'll now get -g (sic!) enabled at LTRANS time. The patch also re-instantiates the support for -g0 at link-time, dropping the early created debug as well. There are a gazillion different -g options we'd need to handle if we try to do better like if all compile-time objects had -gdwarf5 enabled then do so at link time. But then there's no change to consistently carry diferent settings to the link stage if you consider inlining and partitioning. So this is really a very poor mans solution that also might uncover issues with -g0 at compile-time vs. -g at link-time if there are mixed -g0/g TUs in the LTO link. We've run into this "issue" with openSUSE packages now built with -flto which in turn means some objects (those linked w/o -g) ended up without the LTRANS debug part... Any opinions welcome. Thanks, Richard. 2019-09-09 Richard Biener * lto-opts.c (lto_write_options): Stream -g when debug is enabled. * lto-wrapper.c (merge_and_complain): Pick up -g. (append_compiler_options): Likewise. (run_gcc): Re-instantiate handling -g0 at link-time. Index: gcc/lto-opts.c =================================================================== --- gcc/lto-opts.c (revision 275454) +++ gcc/lto-opts.c (working copy) @@ -94,6 +94,10 @@ lto_write_options (void) : "-fno-pie"); } + /* If debug info is enabled append -g. */ + if (debug_info_level > DINFO_LEVEL_NONE) + append_to_collect_gcc_options (&temporary_obstack, &first_p, "-g"); + /* Append options from target hook and store them to offload_lto section. */ if (lto_stream_offload_p) { Index: gcc/lto-wrapper.c =================================================================== --- gcc/lto-wrapper.c (revision 275454) +++ gcc/lto-wrapper.c (working copy) @@ -265,6 +265,7 @@ merge_and_complain (struct cl_decoded_op case OPT_fshow_column: case OPT_fcommon: case OPT_fgnu_tm: + case OPT_g: /* Do what the old LTO code did - collect exactly one option setting per OPT code, we pick the first we encounter. ??? This doesn't make too much sense, but when it doesn't @@ -617,6 +618,7 @@ append_compiler_options (obstack *argv_o case OPT_fopenacc: case OPT_fopenacc_dim_: case OPT_foffload_abi_: + case OPT_g: case OPT_O: case OPT_Ofast: case OPT_Og: @@ -1399,6 +1401,10 @@ run_gcc (unsigned argc, char *argv[]) linker_output_rel = !strcmp (option->arg, "rel"); break; + case OPT_g: + /* Recognize -g0. */ + skip_debug = option->arg && !strcmp (option->arg, "0"); + break; default: break;