From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4755 invoked by alias); 29 Oct 2013 17:20:52 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 4739 invoked by uid 89); 29 Oct 2013 17:20:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Oct 2013 17:20:50 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VbCyD-00000T-Lv from Maciej_Rozycki@mentor.com ; Tue, 29 Oct 2013 10:20:45 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Oct 2013 10:20:45 -0700 Received: from [172.30.64.122] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Tue, 29 Oct 2013 17:20:43 +0000 Date: Tue, 29 Oct 2013 17:20:00 -0000 From: "Maciej W. Rozycki" To: Steve Ellcey CC: Pedro Alves , Subject: Re: [PATCH] Avoid producing broken non-native core files In-Reply-To: <1383066110.2558.177.camel@ubuntu-sellcey> Message-ID: References: <1383066110.2558.177.camel@ubuntu-sellcey> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-10/txt/msg00905.txt.bz2 On Tue, 29 Oct 2013, Steve Ellcey wrote: > Maciej, I believe this change is the cause of a build failure for me > when using an old GCC (4.1.2) to build gdb. I get: > > cc1: warnings being treated as errors > /scratch/gcc/nightly/src/binutils-gdb/gdb/linux-tdep.c: In function > 'linux_corefile_thread_callback': > /scratch/gcc/nightly/src/binutils-gdb/gdb/linux-tdep.c:1196: warning: > 'siginfo_size' may be used uninitialized in this function > > I do not get this error when using a newer GCC (like 4.4.3 or above). I > can work around it by setting siginfo_size to 0 when it is declared. I > don't know if there is a minimum GCC version required for building gdb > but my build with GCC 4.1.2 used to work. Do you think initializing > siginfo_size is reasonable to allow us to use older GCC's to build gdb? You're right, I noticed this problem in a build I did after I had already committed that change -- it looks like GCC tries to recurse into the static function being called (that is passed a pointer to siginfo_size) to figure out when the variable is initialised and when it is not. And for some compiler's versions (4.3.3 in my case) it gets confused and complains. Sorry to have caused this regression. Here's a change I made last week before I ran out of time; I gather it is the same as yours and it fixes the problem for me. Any objections before I apply it? Do we have an established practice of making comments within the source around compiler shortcoming/bug workarounds -- so that we can remove such clutter later on when we no longer support a given compiler's version? 2013-10-29 Maciej W. Rozycki gdb/ * linux-tdep.c (linux_corefile_thread_callback): Preinitialize siginfo_size. Maciej gdb-core-siginfo-size-init.diff Index: gdb-fsf-trunk-quilt/gdb/linux-tdep.c =================================================================== --- gdb-fsf-trunk-quilt.orig/gdb/linux-tdep.c 2013-10-26 20:59:40.000000000 +0100 +++ gdb-fsf-trunk-quilt/gdb/linux-tdep.c 2013-10-26 21:01:02.848280142 +0100 @@ -1193,7 +1193,7 @@ linux_corefile_thread_callback (struct t struct cleanup *old_chain; struct regcache *regcache; gdb_byte *siginfo_data; - LONGEST siginfo_size; + LONGEST siginfo_size = 0; regcache = get_thread_arch_regcache (info->ptid, args->gdbarch);