Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: Steve Ellcey <sellcey@mips.com>
Cc: Pedro Alves <palves@redhat.com>, <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Avoid producing broken non-native core files
Date: Tue, 29 Oct 2013 17:20:00 -0000	[thread overview]
Message-ID: <alpine.DEB.1.10.1310291703590.12843@tp.orcam.me.uk> (raw)
In-Reply-To: <1383066110.2558.177.camel@ubuntu-sellcey>

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  <macro@codesourcery.com>

	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);
 


  reply	other threads:[~2013-10-29 17:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-15 14:21 Maciej W. Rozycki
2013-10-16 15:22 ` Pedro Alves
2013-10-16 20:09   ` Maciej W. Rozycki
2013-10-18 15:12     ` Pedro Alves
2013-10-23 22:03       ` Maciej W. Rozycki
2013-10-24 14:32         ` Pedro Alves
2013-10-29 17:02         ` Steve Ellcey
2013-10-29 17:20           ` Maciej W. Rozycki [this message]
2013-10-29 17:28             ` Steve Ellcey
2013-10-29 17:38           ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.1.10.1310291703590.12843@tp.orcam.me.uk \
    --to=macro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=sellcey@mips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox