From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59869 invoked by alias); 4 Feb 2020 20:58:57 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 59833 invoked by uid 89); 4 Feb 2020 20:58:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=H*MI:lan, HX-HELO:sk:mail-qv X-HELO: mail-qv1-f45.google.com Received: from mail-qv1-f45.google.com (HELO mail-qv1-f45.google.com) (209.85.219.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Feb 2020 20:58:54 +0000 Received: by mail-qv1-f45.google.com with SMTP id g6so60109qvy.5 for ; Tue, 04 Feb 2020 12:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:date:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=ju4naqHxuFG4rquCoQUodujhf5gkvr+UvnIikBI7lHE=; b=URE3ElbFvrmiDbTY50QCHKmOpVyN0w+4EuC6gVt+LVtZGTKiPcgZDGRcrgXYn42GXr 1F06a4JFxRhnnDcDgxafnBumr3r7UTcGBEhICE3xr0R+ZPXHiVSc7rGdOAL3+3CdG5Dg 0IJqIuwMshyJanK9OguIBC3VLIyDH5yZeeHKx2UE+v4MdGhtz2ghsnqwexvUBH/etopF M014I0Ne/7fR3nRfxSwv5v6bnLxWznWLW27dIJNWfX8lGbQ07sL2s4Mc/EyPDYzdSgXO fK9NjOMrCiAJiJvBEkIk3cOMdbqD8oTYtoEyVXWN3W7j1uSuopZVdQ/dWG4LiJu9Lp6J ddHg== Return-Path: Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id x126sm11880104qkc.42.2020.02.04.12.58.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Feb 2020 12:58:52 -0800 (PST) From: Arvind Sankar Date: Tue, 04 Feb 2020 20:58:00 -0000 To: gcc-help@gcc.gnu.org Cc: binutils@sourceware.org Subject: gcc-nm behavior with -flto Message-ID: <20200204205851.GA3873578@rani.riverdale.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-SW-Source: 2020-02/txt/msg00033.txt.bz2 Hi, I get some odd symbol types when using gcc-nm on an lto file. Given the source file void text(void) {} int data = 1; int bss = 0; int common; gcc -c test.c && gcc-nm test.o: 0000000000000000 B bss 0000000000000004 C common 0000000000000000 D data 0000000000000000 T text gcc -flto -c test.c && gcc-nm test.o: 00000000 T bss 00000000 C common 00000000 T data 00000000 T text gcc -flto -fno-common -c test.c && gcc-nm test.o: 00000000 T bss 00000000 T common 00000000 T data 00000000 T text i.e. with LTO, .bss and .data symbols are shown as text symbols instead by gcc-nm. This causes issues with configure scripts that use libtool when the CFLAGS contain both -flto and -fno-common. There's a section in the configure script that tries to figure out how to parse nm's output. It compiles a source file that contains a common symbol and a function, then parses nm output to create a second .c file with those declarations, and tries to check that everything is working by linking them together. In the -flto -fno-common case, the second file ends up with both symbols turning into functions which then gives a link-time error.