Re: libiberty strsignal changes cause windows compilation breakage

Re: libiberty strsignal changes cause windows compilation breakage

[Mark Kettenis]

   Date: Thu, 01 Jun 2000 15:57:10 +1000
   From: Andrew Cagney <ac131313@cygnus.com>

   Chris Faylor wrote:
   > 
   > The strsignal file in libiberty was recently updated to include
   > "string.h".  This has an unpleasant side effect on cygwin in that the
   > declaration for strsignal in newlib's string.h is essentially this:

   POSIX doesn't appear to list strsignal().  Would you know its history? 
   First thing is to figure out what the definition should be according to
   a standard rather than someones passing whim.

It's marked as a GNU extension in the GNU C Library.  The copyright
date on the file that implements it suggests that it was created in
1991.  The first ChangeLog entry mentioning strsignal() is from April
1992.  If you're really interested you could ask Roland McGrath.

Both Solaris and FreeBSD have strsignal() too.  In all three cases
it's prototype is:

   extern char *strsignal (int);

So I'd suggest aligning libiberty with the rest of the world.

   Hmm, find | grep strsignal

	   convex-tdep.c:/* OBSOLETE */strsignal()
	   corelow.c: safe_strsignal()
	   sun386-nat.c:safe_strsignal()
	   umax-xdep.c:safe_strsignal()

   and utils.c defines save_strsignal().  Shouldn't corelow.c be calling
   target_signal_to_string()? I'll ignore sun386-nat.c and umax-xdep.c as
   we could probably slip in a ``OBSOLETE'' while no one was looking :-)

I'll be happy to look the other way :-)

Mark
From ac131313@cygnus.com Thu Jun 01 20:04:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Pulling in purging of deprecated code?
Date: Thu, 01 Jun 2000 20:04:00 -0000
Message-id: <393723F4.48AA76AA@cygnus.com>
X-SW-Source: 2000-06/msg00010.html
Content-length: 571

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
From kevinb@cygnus.com Fri Jun 02 00:50:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Proposal: convert function definitions to prototyped form
Date: Fri, 02 Jun 2000 00:50:00 -0000
Message-id: <1000602075018.ZM29997@ocotillo.lan>
X-SW-Source: 2000-06/msg00011.html
Content-length: 11314

As many of you know, I'm in the midst of purging the use of ``PARAMS''
in prototyped function declarations from the gdb sources.  After this
activity is concluded, I'd like to begin converting function
definitions whose parameters are declared using the traditional C
style to the ISO C prototyped form.  I.e, I'd like to convert
functions of the form

    int
    foo (a, b, c)
         int a;
         char *b;
         int *c;
    {
      ...
    }

to

    int foo (int a, char *b, int *c)
    {
      ...
    }

To this end, I've been working on a script to automate most of this
conversion.  I've appended a work-in-progress version to the end of
this message and will discuss it in some detail further below.

But first...  it's been pointed out to me that the ``protoize''
program is supposed to do the same thing.  I gave ``protoize'' a whirl
and noticed the following problems:

    1) A substantial amount of initial setup is involved.  Only in
       the simplest cases could you just feed a list of files to
       work on to protoize and expect it to work okay.  In particular,
       for gdb, I found it necessary to do a configure *in the source
       directory* so that xm.h, tm.h, and nm.h are set up.  I also
       found it necessary to build in bfd so that certain header
       files are created.

       The reason all of this is necessary is because protoize invokes
       gcc to learn about the program.  As a consequence, it is also
       important to know the set of -I switches that one normally feeds
       to gcc to do a build.

    2) ``protoize'' fails to convert functions disabled by ifdefs for
       the given platform.  OTOH, on some other platform(s), these
       functions might not be disabled and would be converted.  E.g,
       in breakpoint.c, on my GNU/Linux/x86 machine, protoize failed
       to convert create_longjmp_breakpoint() which is protected by an
       "#ifdef GET_LONGJMP_TARGET".

    3) ``protoize'' screws up on PTR types.  E.g, in breakpoint.c, it
       converted

            static int
            cover_target_enable_exception_callback (arg)
                 PTR arg;

       to

            static int
            cover_target_enable_exception_callback (__builtin_va_list arg)

    4) ``protoize'' does not reformat long argument lists.  The lists
       end up entirely contained on one line.

For more information on protoize, see the "Running protoize" page:

    http://gcc.gnu.org/onlinedocs/gcc_2.html#SEC48

and the "Caveats of using protoize" page:

    http://gcc.gnu.org/onlinedocs/gcc_7.html#SEC135

Two of my goals in creating the scripts for the PARAMS purging
activities was that the scripts should be 1) easy to invoke and 2)
require no hand editing of the output when done.  I.e, you shouldn't
have to edit any of the files that these scripts touch in order to fix
errors so that you can build again.  OTOH, the script may leave
certain portions of the file alone that could possibly have be
converted had the script been a little smarter.  The things that the
script fails to convert *will* have to be fixed later on (in order to
complete the cleanup activity), either by another script, or by hand. 
For the PARAMS purging activity, I have spent a fair amount of time
examining the diffs to make sure that this is indeed the case.  (And
I intend to do the same for the activity in this proposal.)

The reason that it is so important to avoid any hand edits is that we
want people who have local repositories or checked out source trees to
be able to run these conversion scripts against them so that merges
will be less painful.  (Even easy.)

With that said, keeping in mind the problems I noted above, I conclude
that ``protoize'' is not the appropriate tool for us to use to convert
function definitions in the gdb sources to their prototyped form.

Now, I'll tell you about the fix-decls script (see below).

The fix-decls script is run via "fix-decls <dirname>" where <dirname>
is the name of the directory to (recursively) fix.  It only touches
the .c files, with the exception of gnu-regex.c and the testsuite
files.  After it converts a traditional C style declaration to a
prototyped one, it invokes GNU indent (on the function declaration
only) to make sure that our indentation standards are still adhered
to.  There is no gratuitous reformatting of any other code.

Here are a list of things that it won't handle (at the moment,
anyway):

    - declarations with comments in them
    - function pointers
    - array declarations
    - malformed declarations (e.g, look at m88k_skip_prologue in m88k-tdep.c)

Functions with traditional C declarations with any of the above in
them will be left alone.  (And need to be converted by hand at some
point.)  But this isn't so bad.  When I ran the script over the gdb
sources, it converted 5,204 function definitions.  After throwing
out gnu-regex.c (which needs to track glibc), all of the stuff in
the testsuite, and everything in tui (which has ifdefs around each
and every function declaration), there are only 143 cases left to
examine by hand.  I've sampled these and many of them are unhandled
due to having comments following a parameter's type declaration.
If I could figure out what to do about comments, we'd have even
fewer cases to fix up by hand.

Here are some of the more interesting cases that it does handle:

Missing int in declaration (i960-tdep.c):

 CORE_ADDR
-frame_args_address (fi, must_be_correct)
-     struct frame_info *fi;
+frame_args_address (struct frame_info *fi, int must_be_correct)
 {

Comma separated parameter lists (remote-mm.c):

 static void
-init_target_mm (tstart, tend, dstart, dend, entry, ms_size, rs_size, arg_start)
-     ADDR32 tstart, tend, dstart, dend, entry;
-     INT32 ms_size, rs_size;
-     ADDR32 arg_start;
+init_target_mm (ADDR32 tstart, ADDR32 tend, ADDR32 dstart, ADDR32 dend,
+		ADDR32 entry, INT32 ms_size, INT32 rs_size, ADDR32 arg_start)
 {

Comma separated list with differing number of stars on the parameter
names (sparc-tdep.c):

 static branch_type
-isbranch (instruction, addr, target)
-     long instruction;
-     CORE_ADDR addr, *target;
+isbranch (long instruction, CORE_ADDR addr, CORE_ADDR * target)
 {

And another one (command.c):

 struct cmd_list_element *
-lookup_cmd_1 (text, clist, result_list, ignore_help_classes)
-     char **text;
-     struct cmd_list_element *clist, **result_list;
-     int ignore_help_classes;
+lookup_cmd_1 (char **text, struct cmd_list_element *clist,
+	      struct cmd_list_element **result_list, int ignore_help_classes)
 {

Out of order comma separated parameter list - note positions of ``from''
and ``to'' (gdbserver/remote-utils.c):

 void
-decode_M_packet (from, mem_addr_ptr, len_ptr, to)
-     char *from, *to;
-     CORE_ADDR *mem_addr_ptr;
-     unsigned int *len_ptr;
+decode_M_packet (char *from, CORE_ADDR * mem_addr_ptr, unsigned int *len_ptr,
+		 char *to)
 {

Finally, I should note that I've done a test build on GNU/Linux/x86
and had no build problems, nor did I see any regressions when I ran
the testsuite.

The fix-decls script is below.  I'd be interested in finding out if
anyone else has a favorite script for doing this sort of thing.  Other
comments welcome too.

--- fix-decls ---
#!/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') {
	    $File::Find::prune = 1;
	} elsif (-f && -T && /\.c$/ && $_ ne "gnu-regex.c") {
	    push @ARGV, $File::Find::name;
	}
    },
    $root
);

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

while (<>) {
    s/
	^			# line start
	( 
	  \w+			# function name
	)
	(
	  \s*			# spaces
	  \(			# left paren
	  \s*			# spaces
	)
	(
	  (?:\w+\s*,\s*)*	# 1 thru N-1 parameter names
	  \w+			# last parameter name
	)
	(
	  \s*			# spaces
	  \)			# right paren
	)
	(
	  (?:
	    [^;{}()]+;		# trad C parameter decl
	  )*
	)
	(
	  \s*			# spaces
	)
	(?=^{)			# lookahead to make sure we see a
				# right curly brace at the beginning
				# of the line
    /
	fix_decl($1, $2, $3, $4, $5, $6);
    /smgex;

    s/
	^			# line start
	( 
	  \w+			# function name
	)
	\s*			# spaces
	\(			# left paren
	\s*			# spaces
	\)			# right paren
	(?=\s*^{)		# lookahead to make sure we see a
				# right curly brace at the beginning
				# of the line
     /$1 (void)/smgx;

    print;
}

sub fix_decl {
    my ($funcname, $lparen, $params, $rparen, $decls, $spaces) = @_;
    my %h = ();
    my ($param, $decl);

    # Define $bailstr to be the original function declaration.  We
    # return it when we see something which doesn't make sense.
    my $bailstr = $funcname . $lparen . $params . $rparen . $decls . $spaces;

    if ($funcname =~ /^(do|while|if)$/) {
	# 'if', 'do', and 'while' are not function names
	# find_overload_match() in valops.c contains an if statement
	# which is confused as a function if we don't have this test.
	return $bailstr;
    }

    foreach $param (split /\s*,\s*/, $params) {
	if (defined $h{$param} || $param eq 'void') {
	    # Bail; either param has already been encountered or
	    # it's void in which case the decl in question is already
	    # ISO C.
	    return $bailstr;
	}
	$h{$param} = "int $param";	# Default
    }

    $decls =~ s/\s*;\Z//;		# remove final semicolon
    			
    foreach $decl (split /\s*;\s*/, $decls) {
	my ($type, $dparams) = 
	    $decl =~ /^				# beginning of string
	              (.*?)			# type
	              (				# dparams...
		        (?:
			  \**			#  stars
			  \s*			#  spaces
			  \w+			#  identifier
			  \s*			#  spaces
			  ,			#  comma
			  \s*			#  spaces
			)*			# any number of the above
			\**			#  stars
			\s*			#  spaces
			\w+			#  identifier
		      )
		      $				# end of string
		     /sx;
	return $bailstr			if !defined $type || !defined $dparams;
	$type =~ s/\A\s+//;		# nuke leading spaces
	$type =~ s/\s+\Z//;		# nuke trailing spaces
	return $bailstr			if $type eq '';
					# Bail if no type
	foreach $param (split /\s*,\s*/, $dparams) {

	    my ($stars, $stripped_param) = 
		$param =~ /(\**)\s*(\w+)/;

	    if (!defined($stripped_param) || !defined $h{$stripped_param}) {
		# Either we couldn't find the parameter or else
		# the parameter wasn't found in the parameter list
		return $bailstr;
	    }
	    $h{$stripped_param} = "$type $param";
	}
    }

    my $newparams = join(', ', map { $h{$_} } split(/\s*,\s*/, $params));

    my $newdecl = reindent("$funcname ($newparams)\n{\n}\n");
    $newdecl =~ s/{\n}//;
    return $newdecl;
}


sub reindent {
    my ($decl, $line_length) = @_;
    $line_length = 80		unless defined $line_length;
    my ($rfh, $wfh, $efh) = (FileHandle->new, FileHandle->new,
					      FileHandle->new);
    my $pid = open3($wfh, $rfh, $efh, "indent -l$line_length");
    $rfh->input_record_separator(undef);
    $efh->input_record_separator(undef);
    $wfh->print($decl);
    $wfh->close();
    my $replacement = <$rfh>;
    $rfh->close();
    my $errstr = <$efh>;
    $efh->close();
    waitpid $pid, 0;
    $replacement =~ s#\n$##;
    if ($errstr ne "") {
	print STDERR "Check $ARGV...\n$errstr\nInput:$decl\nOutput:$replacement\n\n"
    }
    $replacement;
}
--- end fix-decls ---
From kevinb@cygnus.com Fri Jun 02 01:12:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: Pulling in purging of deprecated code?
Date: Fri, 02 Jun 2000 01:12:00 -0000
Message-id: <1000602081230.ZM30038@ocotillo.lan>
References: <393723F4.48AA76AA@cygnus.com> <ac131313@cygnus.com>
X-SW-Source: 2000-06/msg00012.html
Content-length: 361

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
From ac131313@cygnus.com Fri Jun 02 02:42:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Proposal: convert function definitions to prototyped form
Date: Fri, 02 Jun 2000 02:42:00 -0000
Message-id: <3937816C.E66B9AE0@cygnus.com>
References: <1000602075018.ZM29997@ocotillo.lan>
X-SW-Source: 2000-06/msg00013.html
Content-length: 1445

Kevin Buettner wrote:
> 
> As many of you know, I'm in the midst of purging the use of ``PARAMS''
> in prototyped function declarations from the gdb sources.  After this
> activity is concluded, I'd like to begin converting function
> definitions whose parameters are declared using the traditional C
> style to the ISO C prototyped form.  I.e, I'd like to convert
> functions of the form
> 
>     int
>     foo (a, b, c)
>          int a;
>          char *b;
>          int *c;
>     {
>       ...
>     }
> 
> to
> 
>     int foo (int a, char *b, int *c)
>     {
>       ...
>     }

(you mean
	int
	foo (int a, char *b, int *c)
:-)

The obvious thing to note is that by moving to pure ISO-C we eliminate
the type promotion problems.  For instance:

	void foo (enum e e);
	void
	foo (e)
		enum e e;
	{
	}

is not well defined and many compilers reject it.  Plenty of similar
examples (involving char, short, and the like exist).

It is one less issue that people need to worry about.

The only concern I have is, given the slightly more complex nature of
the script (compared to PARAMS) there is a possibility that the
conversion re-orders or re-types the argument list.  With that in mind,
should a pre-cursor to this be to least have prototypes for all
(global?) functions (-Wmissing-prototypes?) or only do the conversion
when there is a prototype visible?

	Andrew

PS: You may want to add gdb/*-share to the list of directories to avoid.
From mslater@usa.com Fri Jun 02 03:52:00 2000
From: Michael Slater <mslater@usa.com>
To: gdb@sourceware.cygnus.com
Subject: xxgdb settings
Date: Fri, 02 Jun 2000 03:52:00 -0000
Message-id: <383188705.959943090785.JavaMail.root@web421-mc.mail.com>
X-SW-Source: 2000-06/msg00014.html
Content-length: 847

Hello ,

I am not sure is this the right forum to ask for help on the problems on the xxgdb ( front-end for gdb), if not please excuse me.

I took the latest version (xxgdb-1.12)of xxgdb and compiled the same as in the readme file provided in the package .
The package is working fine , but I always see a ^M after the completion of a line .

The FAQ said that the problem could be due to usage of non ANSI include files while compiling using gcc , and asked me to run fixinclude script(of the gcc) on the include files .
     But that didnt solve the problem .

Is anybody using the xxgdb , and facing the same problem .
If anybody knows of a way to overcome it , please let me know .

Thanks in advance 
 Cheers
  Mike
______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup