Pulling in purging of deprecated code?

Pulling in purging of deprecated code?

[Andrew Cagney]

Hello,

With the 4.18 release, gdb started identifying obsolete code that was
going to be deleted.  The 5.0 release saw the first of that code
removed.

I'd like to suggest a slight acceleration of the process.  As soon as
(or slightly after) a release has gone out the obsolete code be removed.

This would remove the overlap that currently exists (hosts/targets may
be obsolete from the previous or next release) and also reduce the
amount of bagage GDB carries.  

Since the repository is public (and downloadable) the full history is
accessable.

	thoughts,
		Andrew

Re: Pulling in purging of deprecated code?

[Kevin Buettner]

On Jun 2,  1:03pm, Andrew Cagney wrote:

> With the 4.18 release, gdb started identifying obsolete code that was
> going to be deleted.  The 5.0 release saw the first of that code
> removed.
> 
> I'd like to suggest a slight acceleration of the process.  As soon as
> (or slightly after) a release has gone out the obsolete code be removed.

I'm for it.

Kevin

gdb@gnu.org Discussion

[Andrew Cagney]

People on this mailing list should be aware of the discussion:

http://sources.redhat.com/ml/overseers/2000-q4/threads.html#00214

	sorry,
		Andrew

Re: gdb@gnu.org Discussion

[Kevin Buettner]

On Nov 23,  3:47pm, Andrew Cagney wrote:

> People on this mailing list should be aware of the discussion:
> 
> http://sources.redhat.com/ml/overseers/2000-q4/threads.html#00214

Indeed we should!

For those of you who have not had a chance to look it over yet, it is
about eliminating this mailing list (gdb@sources.redhat.com) in favor
of a newly created list hosted at gnu.org.

I think that the members of this forum should be allowed to weigh in
with their opinions on whether they think this is a good thing or not
prior to it actually happening.  In particular, I would like to
understand the technical reasons for eliminating this mailing list in
favor of another.  In my opinion, there should be some very compelling
technical reasons for such an action...

Of even greater import though is the fact that this mailing list move
is apparently being mandated by some sort of shadow organization of
which we know almost nothing about.  From my reading of the discussion
that Andrew pointed out, I've learned the following:

 - This shadow organization has at least twelve members.

 - Four of the members seem to be Stan Shebs, Andrew Cagney,
   Todd Whitesel, and Robert Dewar.

 - The mailing list that these members use to converse amongst
   themselves is gdbheads@gnu.org.  It is apparently a private
   list.

 - There appears to be some disagreement within the shadow
   organization (henceforth referred to as "gdbheads") regarding
   whether the mailing list move is a good idea or not.

I would like to know the following (for a start):

 - Who are the rest of the gdbheads?

 - What are their qualifications?  (Perhaps the various members
   could step forward and "introduce" themselves?)

 - What is the charter of the gdbheads?

 - What was the process used to select the gdbheads?

 - How do the current maintainers (as listed in the MAINTAINERS file)
   and other contributors fit into this new picture?

Kevin

Re: gdb@gnu.org Discussion

[Russ Allbery]

I'm totally unqualified to step in here, as I'm not a maintainer of any
kind, just an interested party who follows a lot of the compiler and
autoconf-related mailing lists.  But given that several other projects
have already gone through this process, and given that I'm as outside of
an observer as it's possible to have (I guarantee that I'm not part of any
shadow organization that gets confided in :)), I'll throw out a couple of
things just 'cause.

Feel free to ignore me completely and pay attention to the people who
really know what's going on.

Kevin Buettner <kevinb@cygnus.com> writes:

> On Nov 23,  3:47pm, Andrew Cagney wrote:
>> People on this mailing list should be aware of the discussion:
>> 
>> http://sources.redhat.com/ml/overseers/2000-q4/threads.html#00214

> Indeed we should!

> For those of you who have not had a chance to look it over yet, it is
> about eliminating this mailing list (gdb@sources.redhat.com) in favor
> of a newly created list hosted at gnu.org.

After having read all the way through that thread (which was interesting,
definitely, and didn't take that long to read through), I don't think
that's a completely accurate characterization of the *intent* (possibly as
opposed to what steps have been taken so far).

The intent is to host the GDB mailing lists (and presumably the web pages;
no one's talking about the CVS repository, which as with most things
related to the compiler and development tools is a more complicated
problem) at gnu.org rather than at a site affiliated with a particular
company.  This isn't a new idea for FSF projects, honestly; I've seen
exactly this situation play out with several things I've been watching.

Whether or not the existing list will be moved intact to another host or
if people will need to switch over is one of the points being debated.

> I think that the members of this forum should be allowed to weigh in
> with their opinions on whether they think this is a good thing or not
> prior to it actually happening.  In particular, I would like to
> understand the technical reasons for eliminating this mailing list in
> favor of another.  In my opinion, there should be some very compelling
> technical reasons for such an action...

There aren't technical reasons to do this.  The reasons for doing this are
related to the public image of GDB maintenance and the desire to avoid
tying the GNU project to any particular company, regardless of what
company that is.

It's my firm belief, as about as much of an outsider as you can get (I
work for Stanford University, I have no affiliation with Red Hat beyond
owning some -- very small amounts -- of their stock, I'm not a GNU
maintainer, and I don't even have assignment papers filed), that this is
an accurate statement of the reasons and that this is not coming out of
Red Hat bashing, some desire to punish Red Hat, or anything of the sort.

I also can see the FSF's point.  Admittedly, I *personally* consider it a
fairly minor point and it wouldn't affect my willingness to contribute to
GDB, but I can understand how a public association with Red Hat *may*
discourage a Red Hat competitor from wanting to contribute to GDB
development.  I don't know if it's ever happened; it probably hasn't.  But
I also don't think it's a position completely without merit.

> Of even greater import though is the fact that this mailing list move is
> apparently being mandated by some sort of shadow organization of which
> we know almost nothing about.

Said "shadow organization" is the GDB Steering Committee (being formed),
from what I can tell reading those same messages.  Now *I* knew that a GDB
Steering Committee was in the process of being formed, probably, along the
same lines as the GCC Steering Committee, and as stated above, I'm hardly
someone that anyone is going to talk to.  :)  I don't recall where I saw
that information, though; it's possible that it was on some other public
mailing list rather than the GDB list.

As a sysadmin who installs GDB and uses it periodically, and as an
observer of the GCC project from the very beginning of the egcs lists, I'm
wholeheartedly in favor of the establishment of such a committee and most
of my guesses as to who might be on such a committee seem to be born out
by the above-referenced thread.  I think it's greatly helped the GCC
project to have such a committee, and it's a model that's been used
successfully with other free software projects.

Openness of deliberations among a committee like this does always come up;
there's been an excellent discussion of this on the GCC mailing list
recently (and a very calm and reasonable discussion).  But, again as a
complete outsider (a contributor may have other views), I find such a
committee to be mostly a substitute for a human maintainer, and a single
human maintainer isn't expected to record in public all of the thoughts
they have about a decision before they make it.  :)  They're just required
to explain and justify their decision.  Similarly, I see no particular
reason to require that a steering committee mailing list be open to
subscribers or be publically archived provided that the decisions and
their justifications are explained in public.  As has been pointed out on
the GCC list, a lot of what is discussed on such a list is private issues
such as personality conflicts that are better off being kept confidential
so that they can be resolved without lots of public bickering distracting
people doing work from doing that work.

Anyway, that's just my two cents.  I find the moving about of mailing
lists bothersome in the short term, since it's a pain to adjust all my
mail splitting rules, but I also know quite well that in two or three
months I will have completely forgotten about it, so if there's long-term
benefit for making the move, I can definitely see the justification for
it.  And as a sysadmin, I offer my sincere gratitude in advance to the
poor people who get to implement it and thoroughly understand their
annoyance at having to change something that's working for no technical
reasons.

-- 
Russ Allbery (rra@stanford.edu)             < http://www.eyrie.org/~eagle/ >

Re: gdb@gnu.org Discussion

[Stan Shebs]

Kevin Buettner wrote:
> 
> Of even greater import though is the fact that this mailing list move
> is apparently being mandated by some sort of shadow organization of
> which we know almost nothing about.  From my reading of the discussion
> that Andrew pointed out, I've learned the following:

"Shadow organization" is a rather loaded term for the GDB
steering committee, which has been mentioned on this list
on a couple occasions:

http://sources.redhat.com/ml/gdb/1999-q2/msg00125.html

is the first reference to the idea of a steering committee, while 

http://sources.redhat.com/ml/gdb/2000-q1/msg00205.html

is the start of a dozen-odd-message thread discussing ideas about
the committee's role in GDB.  I know there has been extensive discussion
of it within Cygnus, because I started the discussion! :-) In fact,
I think you participated in the discussion as well, although I don't
have those mail archives to quote from.

I suppose the committee seems shadowy because while the idea has been
around for some time, the organization process has been slow, and
strictly speaking, the committee doesn't officially exist yet.

>  - The mailing list that these members use to converse amongst
>    themselves is gdbheads@gnu.org.  It is apparently a private
>    list.

That's right.  In this respect we are following the GCC steering
committee practice - they also have a private list.

> I would like to know the following (for a start):
> 
>  - Who are the rest of the gdbheads?
> 
>  - What are their qualifications?  (Perhaps the various members
>    could step forward and "introduce" themselves?)
> 
>  - What is the charter of the gdbheads?

All these questions were supposed to be answered in the announcement
that RMS was preparing, when the question of what to use for contact
addresses came up, and I (unwisely, it seems :-) ) asked the sources
overseers about the plausibility of moving the GDB list before making
the announcement; with the rather tense reaction that can be seen via
the link that Andrew posted.  The best suggestion I've seen so far is
that the contact address question simply be deferred, so that RMS
can make the announcement without adding any further delays, and so
everybody can get on to the business of flaming the steering committee
directly...

>  - What was the process used to select the gdbheads?

It's been pretty much anybody who expressed interest in the steering
committee, constrained by a general desire to keep the committee from
being too large initially, and to not have a majority of the membership
be from any one company.

>  - How do the current maintainers (as listed in the MAINTAINERS file)
>    and other contributors fit into this new picture?

Since the committee is not yet responsible for GDB (that's what RMS'
announcement was supposed to inaugurate!), no decisions have been made,
but I doubt there will be much if any change in day-to-day work.  The
committee's role is more to develop consensus on difficult issues that
no single GDB hacker can decide unilaterally.  I expect the details
will be laid out in the committee's web pages, again following the
GCC model, which has worked pretty well.

I think Russ Allbery did a fine job of answering many of the implied
questions, so I'll defer to his message for those.

Stan

Re: gdb@gnu.org Discussion

[Eli Zaretskii]

> Date: Fri, 24 Nov 2000 16:29:57 -0800
> From: Stan Shebs <shebs@apple.com>
> 
> >  - How do the current maintainers (as listed in the MAINTAINERS file)
> >    and other contributors fit into this new picture?
> 
> Since the committee is not yet responsible for GDB (that's what RMS'
> announcement was supposed to inaugurate!), no decisions have been made,
> but I doubt there will be much if any change in day-to-day work.  The
> committee's role is more to develop consensus on difficult issues that
> no single GDB hacker can decide unilaterally.  I expect the details
> will be laid out in the committee's web pages, again following the
> GCC model, which has worked pretty well.

Caveat emptor!

With all due respect to the GCC steering committee and the job it
performs, I'd like to point out that the GDB development team has
quite a different style of making decisions than the GCC team.  The
most prominent evidence to the difference in style is the relatively
high number of discussions on GCC-related forums where people get
flamed or treated with vitriol, for no good reason, while discussing
design issues; such incidents are practically absent from GDB forums.
'Nuff said.

This doesn't mean to say that a steering committee for GDB is
necessarily a bad idea, but IMHO it does mean that we shouldn't
blindly copy GCC models without thinking about that first.

Re: gdb@gnu.org Discussion

[Chris G. Demetriou]

I for one, would find a move to the gnu.org mailing list server to be
very annoying.

I've subscribed this list and several others to internal newsgroups
for reading by interested people here.

I've tried to do the same with @gnu.org lists, with absolutely no
luck; nothing i've tried has worked, though i'll admit that i've not
tried contacting postmaster@.  (Really, though, that shouldn't be
necessary; it just shouldn't be a problem to begin with.)

So, i think it kinda bites to move the list, unless wherever it's
moving to has list-related services at least as good as sourceware.



cgd

Re: gdb@gnu.org Discussion

[Eli Zaretskii]

> From: cgd@sibyte.com (Chris G. Demetriou)
> Date: 26 Nov 2000 22:58:33 -0800
> 
> I've subscribed this list and several others to internal newsgroups
> for reading by interested people here.
> 
> I've tried to do the same with @gnu.org lists, with absolutely no
> luck; nothing i've tried has worked

FWIW, I had no problems whatsoever to subscribe to any of the gnu.org
mailing lists.  I'm currently subscribed to about half a dozen of
them.

I cannot imagine what kind of problems could you have subscribing.

Re: gdb@gnu.org Discussion

[Chris G. Demetriou]

Eli Zaretskii <eliz@delorie.com> writes:
> FWIW, I had no problems whatsoever to subscribe to any of the gnu.org
> mailing lists.  I'm currently subscribed to about half a dozen of
> them.
> 
> I cannot imagine what kind of problems could you have subscribing.

Not "me subscribing."  Me subscribing a local mailing list.

I'll admit, I've not tried in a few months.  I'll give it another go;
maybe things have gotten better, or i'll manage to try a trick that
i'd not tried previously...

Re: gdb@gnu.org Discussion

[Stan Shebs]

Eli Zaretskii wrote:
> 
> With all due respect to the GCC steering committee and the job it
> performs, I'd like to point out that the GDB development team has
> quite a different style of making decisions than the GCC team.  The
> most prominent evidence to the difference in style is the relatively
> high number of discussions on GCC-related forums where people get
> flamed or treated with vitriol, for no good reason, while discussing
> design issues; such incidents are practically absent from GDB forums.
> 'Nuff said.

An interesting insight, I've been ruminating on it.

I think the differences are mainly due to individual personalities;
at the risk of angering *everybody* by generalizing :-) , I'll observe
that GCC developers have tended to be more abrasive online than GDB
developers.  This has been the case for a long time, at least since 1993,
when I started at Cygnus fulltime.  Indeed, the GCC committee has
helped to tone this down, by publicly reining in people who've gone
out of bounds; on the old gcc2 list, there were few expectations
of civility, and things would get pretty hot regularly.

Discussion style is one thing that's under our collective control,
independent of maintainers, committees, etc.  If we each commit 
ourselves to not flame, and to respond temperately to flames by others,
the overall tone of the discussion will always be civil.

Stan

Re: gdb@gnu.org Discussion

[Eli Zaretskii]

> Date: Tue, 28 Nov 2000 12:33:35 -0800
> From: Stan Shebs <shebs@apple.com>
> 
> Discussion style is one thing that's under our collective control,
> independent of maintainers, committees, etc.  If we each commit 
> ourselves to not flame, and to respond temperately to flames by others,
> the overall tone of the discussion will always be civil.

No argument here.

However, the main point of what I've written (perhaps not clearly
enough, as I'm usually embarrassed to hint at personalities in public
forums) was that GDB does not _need_ a committee to behave in a civil
manner.

When the committee's role is considered, and a reference to its
success with GCC is made, I think we should ask ourselves, what part
of that success is due to committee's role in toning down flame wars
which in the GDB case don't exist in the first place.

free() vs xfree() vs FREEIF() vs ISO-C

[Andrew Cagney]

Hello,

One of the issues that fell out of the alloca() discussion was the
portability of free().  While ISO-C guarentees that free(NULL) doesn't
dump core, many pre-ISO-C libc's don't offer that guarentee.

I can think of several ways of refining the coding standard to avoid
this:

	o	Add/use xfree() which
		would guard against NULL.

	o	adopt FREEIF() for for
		the same reason

	o	leave things as is
		and assume people will
		remember to check the
		arg before calling xfree().

Does anyone have any thoughts?  I tend towards the first one as that is
fairly easy to implement.  If adopted, I'd beg/borrow/con someone into
converting all free() and free((PTR)) calls into xfree() :-)

	Andrew

Re: free() vs xfree() vs FREEIF() vs ISO-C

[Kevin Buettner]

On Nov 30, 12:35pm, Andrew Cagney wrote:

> 	o	Add/use xfree() which
> 		would guard against NULL.
[...]

> Does anyone have any thoughts?  I tend towards the first one as that is
> fairly easy to implement.  If adopted, I'd beg/borrow/con someone into
> converting all free() and free((PTR)) calls into xfree() :-)

I like this approach too.

I've eyeballed the diff output from the script below and it seems to
give pretty good results.  I'll do a test build, and if all is well,
I'll post an rfc patch to gdb-patches.  (Note that this patch doesn't
do any reindenting, but in the diffs I've looked at it, I don't see
a need for it in our present source tree.)

To run this script, just set your current directory to the gdb directory
and then do

    subst-free-xfree .

(note the dot) or do
    
    subst-free-xfree /path/to/gdb/sources

from anywhere.

--- subst-free-xfree ---
#!/usr/bin/perl -w

use File::Find;
use FileHandle;
use IPC::Open3;
use English;

my ($root) = @ARGV;

if (!defined($root)) {
    die "Usage: $0 root\n";
}

@ARGV = ();

find(
    sub { 
	if ($_ eq 'testsuite' || (-d && /-share$/)) {
	    $File::Find::prune = 1;
	} elsif (-f && -T && /\.c$/ && $_ ne "gnu-regex.c") {
	    push @ARGV, $File::Find::name;
	}
    },
    $root
);

$INPLACE_EDIT = '';
undef $/;			# slurp entire files

while (<>) {
    s/\bfree \(/xfree (/g;
    s/\bmake_cleanup \(free,/make_cleanup (xfree,/g;
    s/\bfree\)/xfree)/g;
    print;
}
--- end subst-free-xfree ---

Re: Pulling in purging of deprecated code?

[Andrew Cagney]

Andrew Cagney wrote:
> 
> Hello,
> 
> With the 4.18 release, gdb started identifying obsolete code that was
> going to be deleted.  The 5.0 release saw the first of that code
> removed.
> 
> I'd like to suggest a slight acceleration of the process.  As soon as
> (or slightly after) a release has gone out the obsolete code be removed.
> 
> This would remove the overlap that currently exists (hosts/targets may
> be obsolete from the previous or next release) and also reduce the
> amount of bagage GDB carries.
> 
> Since the repository is public (and downloadable) the full history is
> accessable.

To close this.  I got one response (agreeing with the proposal) so I'll
shortly be following this through.

	Andrew

abort() to internal_error()

[Andrew Cagney]

Hello,

KevinB's kindly cooked up a script that will replace all instances of:

	abort ();

with

	internal_error (__FILE__, __LINE__, "function calls abort ()");

Applying and committing this script will signify the end of a very long
campain I've been waging with GDB - to significantly reduce the
likelhood that GDB dumps core.

From memory, this has been discussed several times before (and is listed
in the TODO file).  The only problem I can think of is the message. 
However, if you think about it:

	(gdb) pwd
	internal_error: /a/b/c/d/foo.c:47: function calls abort ()
	....

is still infinatly better than something like

	(gdb) pwd
	Program received SIGXYZZY, core dumped
	$

so I think is good enough,

comments?

	Andrew

Re: abort() to internal_error()

[Kevin Buettner]

On Feb 16, 10:04am, Andrew Cagney wrote:

> KevinB's kindly cooked up a script that will replace all instances of:
> 
> 	abort ();
> 
> with
> 
> 	internal_error (__FILE__, __LINE__, "function calls abort ()");
> 
> Applying and committing this script will signify the end of a very long
> campain I've been waging with GDB - to significantly reduce the
> likelhood that GDB dumps core.
> 
> >From memory, this has been discussed several times before (and is listed
> in the TODO file).  The only problem I can think of is the message. 
> However, if you think about it:
> 
> 	(gdb) pwd
> 	internal_error: /a/b/c/d/foo.c:47: function calls abort ()
> 	....
> 
> is still infinatly better than something like
> 
> 	(gdb) pwd
> 	Program received SIGXYZZY, core dumped
> 	$
> 
> so I think is good enough,
> 
> comments?

It should be noted that if the "function calls abort ()" message is
unpalatable for some reason (e.g, lack of specificity), these can be
replaced with something more suitable over time.  In each case, the
choice of a more suitable message will likely depend upon the context,
so I think that Andrew's suggestion is a reasonable first step.  It is
certainly better than what we have now...

Kevin

Re: abort() to internal_error()

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> KevinB's kindly cooked up a script that will replace all instances of:
Andrew>
Andrew> 	abort ();
Andrew>
Andrew> with
Andrew>
Andrew> 	internal_error (__FILE__, __LINE__, "function calls abort ()");
Andrew>
Andrew> Applying and committing this script will signify the end of a very long
Andrew> campain I've been waging with GDB - to significantly reduce the
Andrew> likelhood that GDB dumps core.

This is good enough to go in as is, but I wonder if there is any way
can improve the message.  IMO "function calls abort ()" is wrong, or
at best misleading, since the function no longer calls abort().
Perhaps "failed internal consistancy check" is generic enough without
mentioning abort()?

Of course, these can, and I suspect will be changed to be specific to
the error condition in the fullness of time.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: abort() to internal_error()

[Andrew Cagney]

"J.T. Conklin" wrote:

> This is good enough to go in as is, but I wonder if there is any way
> can improve the message.  IMO "function calls abort ()" is wrong, or
> at best misleading, since the function no longer calls abort().
> Perhaps "failed internal consistancy check" is generic enough without
> mentioning abort()?

Thankyou!  I couldn't think of anything sensible.

	Andrew

PS: Must not suggest ``Houston, we have a problem''....

Re: abort() to internal_error()

[Kevin Buettner]

On Feb 16,  3:11pm, Andrew Cagney wrote:

> > This is good enough to go in as is, but I wonder if there is any way
> > can improve the message.  IMO "function calls abort ()" is wrong, or
> > at best misleading, since the function no longer calls abort().
> > Perhaps "failed internal consistancy check" is generic enough without
> > mentioning abort()?
> 
> Thankyou!  I couldn't think of anything sensible.

I've adjusted my script to use "failed internal consistency check"
instead.  (I'll post a patch after the discussion dies down...)

Kevin

ia64/xm-aix.h #define GDB_GREGSET_T prgregset_t

[Andrew Cagney]

Just FYI,

I don't think that the file gdb/config/ia64/xm-aix.h should contain the
text:

+ #define GDB_GREGSET_T prgregset_t
+ #define GDB_FPREGSET_T prfpregset_t

My understanding of GDB_GREGSET_T is that it is a native target thingie
(nm-*.h) and not a host compile thingie (xm-*.h).  I suspect this was
picked up through a sequence of cut/pastes of previous xm-*.h files -
many of the xm-*.h files contain the wrong thing.

Think of xm-*.h files as GDB's poor predecessor to autoconf.  In theory,
with autoconf, the xm-*.h files are not even needed.

	enjoy,
		Andrew

Re: ia64/xm-aix.h #define GDB_GREGSET_T prgregset_t

[Kevin Buettner]

On Feb 27, 12:42pm, Andrew Cagney wrote:

> I don't think that the file gdb/config/ia64/xm-aix.h should contain the
> text:
> 
> + #define GDB_GREGSET_T prgregset_t
> + #define GDB_FPREGSET_T prfpregset_t

I've just committed a patch to fix this problem.  See

    http://sources.redhat.com/ml/gdb-patches/2001-03/msg00044.html

Kevin