[commit] gdb_bytize arm-tdep.c

[commit] gdb_bytize arm-tdep.c

[Mark Kettenis]

I know there are quite a few commercial parties with interests in gdb.
Whenever I encounter things like this, I'd almost say they're just a
bunch of freeloaders.  Heck, I'l just say it.  They're a bunch of evil
capitalist freeloaders.

Daniel, it's things like this why we need to have -Werror by default
as soon as possible.

Committed as obvious.

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>
	* arm-tdep.c (arm_return_value): Change type of readbuf and
	writebuf arguments to `gdb_byte *'.

Index: arm-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/arm-tdep.c,v
retrieving revision 1.203
diff -u -p -r1.203 arm-tdep.c
--- arm-tdep.c 22 Dec 2005 17:06:25 -0000 1.203
+++ arm-tdep.c 15 Jan 2006 14:44:18 -0000
@@ -1,7 +1,8 @@
 /* Common target dependent code for GDB on ARM systems.
 
    Copyright (C) 1988, 1989, 1991, 1992, 1993, 1995, 1996, 1998, 1999,
-   2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
+   2000, 2001, 2002, 2003, 2004, 2005, 2006
+   Free Software Foundation, Inc.
 
    This file is part of GDB.
 
@@ -2258,8 +2259,8 @@ arm_store_return_value (struct type *typ
 
 static enum return_value_convention
 arm_return_value (struct gdbarch *gdbarch, struct type *valtype,
-		  struct regcache *regcache, void *readbuf,
-		  const void *writebuf)
+		  struct regcache *regcache, gdb_byte *readbuf,
+		  const gdb_byte *writebuf)
 {
   if (TYPE_CODE (valtype) == TYPE_CODE_STRUCT
       || TYPE_CODE (valtype) == TYPE_CODE_UNION

Re: [commit] gdb_bytize arm-tdep.c

[Daniel Jacobowitz]

On Sun, Jan 15, 2006 at 03:51:31PM +0100, Mark Kettenis wrote:
> I know there are quite a few commercial parties with interests in gdb.
> Whenever I encounter things like this, I'd almost say they're just a
> bunch of freeloaders.  Heck, I'l just say it.  They're a bunch of evil
> capitalist freeloaders.
> 
> Daniel, it's things like this why we need to have -Werror by default
> as soon as possible.

Mark, please refrain from voicing this opinion on the list, OK?  As one
of the primary commercial interested parties for this file, I am not an
evil capitalist freeloader, I'm a busy man with no free time.  I find
your message remarkably insulting.

We need -Werror enabled by default so that someone will feel forced to
fix up a bunch of semantically _USELESS_ GCC warnings that annoy the
GDB developers?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [commit] gdb_bytize arm-tdep.c

[Mark Kettenis]

> Date: Sun, 15 Jan 2006 11:49:08 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Sun, Jan 15, 2006 at 03:51:31PM +0100, Mark Kettenis wrote:
> > I know there are quite a few commercial parties with interests in gdb.
> > Whenever I encounter things like this, I'd almost say they're just a
> > bunch of freeloaders.  Heck, I'l just say it.  They're a bunch of evil
> > capitalist freeloaders.
> > 
> > Daniel, it's things like this why we need to have -Werror by default
> > as soon as possible.
> 
> Mark, please refrain from voicing this opinion on the list, OK?  As one
> of the primary commercial interested parties for this file, I am not an
> evil capitalist freeloader, I'm a busy man with no free time.  I find
> your message remarkably insulting.

Sorry Daniel, it wasn't my intention to personally insult you.  It's
just that I sometimes get very frustrated by the lack of attention
these companies have for things that aren't immedialety visible to
their customers.  Even if they heavily rely on that code.  Take the
code in remote.c for example.  I bet I can find several buffer
overflows in that code in 10 minutes.  Why should I, as a volunteer,
fix that code when there are quite a few people around that make money
of it?

> We need -Werror enabled by default so that someone will feel forced to
> fix up a bunch of semantically _USELESS_ GCC warnings that annoy the
> GDB developers?

If one of the annoyed GDB developers finds a way to silence the
useless GCC warnings introduced in GCC 4, while keeping the useful
warnings, I'm all for it.

Re: [commit] gdb_bytize arm-tdep.c

[Jim Blandy]

On 1/15/06, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> I know there are quite a few commercial parties with interests in gdb.
> Whenever I encounter things like this, I'd almost say they're just a
> bunch of freeloaders.  Heck, I'l just say it.  They're a bunch of evil
> capitalist freeloaders.

I'm not sure that's accurate or fair.

If a volunteer like yourself, working for their own satisfaction,
contributes a port of GDB to some processor, and then finishes school
or changes jobs or for whatever reason leaves the scene, how is that
different from a commercial interest getting a contract to do a port
but then later not allocating money to maintain the port?  Do
individuals have a moral obligation to stick around indefinitely?

I think we all agree that unmaintained ports are a burden on GDB, and
that it's in the project's interests to have policies in place for
phasing out code nobody is willing to bring up to current standards. 
But unmaintained code can come from many sources.

But let's suppose it usually does come from commercial interests.  It
could nonetheless be true that companies exhibit *more* committement
to their contributions than individuals, if companies simply
contribute more overall.  That is, even if most of our problems with
unmaintained code can be traced back to corporate contributions,
corporations could still be more committed maintainers, on a
per-contribution basis.  I don't know if that's true, but given that
Cygnus and Red Hat routinely sell support contracts as follow-ups to
port contracts, it wouldn't surprise me.

This isn't some veiled personal counter-attack; it's clear you, Mark,
are very committed to backing up your work.  But I want to consider
non-commercial contributors as a whole; treating the stars of the
category as typical representatives is unfair.

If there really is a problem here, then the steering committee is
obliged to pursue policies to correct it.  They're charged with
protecting Project GNU's interests, not making sure GDB is a suitable
money-making vehicle for private interests.  But I think overall we're
in a win-win situation, even if everyone doesn't get exactly what they
want all the time.