From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21916 invoked by alias); 2 Oct 2009 16:57:07 -0000 Received: (qmail 21894 invoked by uid 22791); 2 Oct 2009 16:57:06 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mout4.freenet.de (HELO mout4.freenet.de) (195.4.92.94) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 02 Oct 2009 16:57:01 +0000 Received: from [195.4.92.24] (helo=14.mx.freenet.de) by mout4.freenet.de with esmtpa (ID ralf.corsepius@freenet.de) (port 25) (Exim 4.69 #92) id 1MtlQx-0002xo-76; Fri, 02 Oct 2009 18:56:43 +0200 Received: from hsi-kbw-078-043-063-233.hsi4.kabel-badenwuerttemberg.de ([78.43.63.233]:63981 helo=[192.168.1.104]) by 14.mx.freenet.de with esmtpsa (ID ralf.corsepius@freenet.de) (TLSv1:AES256-SHA:256) (port 465) (Exim 4.69 #94) id 1MtlQx-0002rb-3D; Fri, 02 Oct 2009 18:56:43 +0200 Message-ID: <4AC630C8.5090508@rtems.org> Date: Fri, 02 Oct 2009 16:57:00 -0000 From: Ralf Corsepius User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3 MIME-Version: 1.0 To: tromey@redhat.com CC: Joel Brobecker , gdb@sourceware.org, Jan Kratochvil Subject: Re: GDB 6.8.92 available for testing References: <20090930204828.GB31446@adacore.com> <4AC41F44.1040502@rtems.org> <20091001170744.GC6532@adacore.com> <4AC4E4F6.5080500@rtems.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00046.txt.bz2 On 10/02/2009 05:47 PM, Tom Tromey wrote: >>>>>> "Ralf" == Ralf Corsepius writes: >>>>>> > Ralf> Eg. this one: > Ralf> http://sourceware.org/ml/gdb-patches/2009-09/msg00585.html > > I checked this in. > > Ralf> and this one: > Ralf> http://sourceware.org/ml/gdb-patches/2009-09/msg00556.html > > Ralf> But I presume, I can consider the later one to be rejected - This > Ralf> doesn't help anybody, but ... you want it this way, so be it. > > I think 'len' should be 'unsigned int', not 'size_t'. > I think, len should be size_t, like any "sizeof"'s return type. This also manifests in how "len" is being used in the fragment in question: sparc32_store_return_value (struct type *type, struct regcache *regcache, const gdb_byte *valbuf) { size_t len = TYPE_LENGTH (type); gdb_byte buf[8]; gdb_assert (!sparc_structure_or_union_p (type)); gdb_assert (!(sparc_floating_p (type) && len == 16)); if (sparc_floating_p (type)) { /* Floating return values. */ memcpy (buf, valbuf, len); regcache_cooked_write (regcache, SPARC_F0_REGNUM, buf); if (len > 4) regcache_cooked_write (regcache, SPARC_F1_REGNUM, buf + 4); } else { /* Integral and pointer return values. */ gdb_assert (sparc_integral_or_pointer_p (type)); if (len > 4) { gdb_assert (len == 8); memcpy (buf, valbuf, 8); regcache_cooked_write (regcache, SPARC_O1_REGNUM, buf + 4); } else { /* ??? Do we need to do any sign-extension here? */ memcpy (buf + 4 - len, valbuf, len); } regcache_cooked_write (regcache, SPARC_O0_REGNUM, buf); } } ... Note: memcpy(..., len) Apart of this, I can't imagine changing this "int" into "size_t" to have any negative impact. That is, though the origin for the patch might be a bug in GCC, I don't see how the patch can be harmful. Ralf