This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB 6.8.92 available for testing


On 10/02/2009 05:47 PM, Tom Tromey wrote:
"Ralf" == Ralf Corsepius<ralf.corsepius@rtems.org> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]