[RFA] gdb_ari.sh patch to eliminate wrong critical errors

[RFA] gdb_ari.sh patch to eliminate wrong critical errors

[Pierre Muller]

  strerror and floatformat_to_double are two
entries at top of ARI web pages
shown as critical regressions, but which are due to
changes in the implementations of their substitutes.
See
http://sourceware.org/gdb/current/ari/
  This patch fixes removes three entries:
1) strerror	2	Do not use strerror(), instead use safe_strerror()
2) floatformat to double	1	Do not use floatformat_to_double()
from libierty, instead use floatformat_to_doublest()
3) gdb/utils.c missing strerror
appearing in that order in the Critical section.

  I tested this locally and it does reduce the 
number of critical entries to 4.
  
  Daniel, could you please commit this?

  Remaining problems are:
1) inline	9	Do not use the inline attribute; 
since the compiler generally ignores this, better 
algorithm selection is needed to improved performance
  This problem is limited to three files:
vec.c (1) vec.h (7) and xtensa-tdep.c (1).
It could be easily removed, but I was wondering if 
there was a special reason why vec.h 
had some many.

2) GNU/Linux	4	Do not use `Linux', instead use `Linux kernel' 
or `GNU/Linux system'; comments should clearly differentiate between 
the two (this test assumes that word `Linux' appears on the same line 
as the word `GNU' or `kernel'
  This one is a little too subtle for me, as I am hardly able to
distinguish between 'GNU/Linux system' and 'Linux kernel'...

3) hash	3	Do not use ` #...', instead use `#...'
(some compilers only correctly parse a C preprocessor directive 
when `#' is the first character on the line)
  This 3 appearances are in:
  ada-lex.c (2) and xtensa-tdep.c (1)
  But ada-lex.c is an automatically generated file, and I am even wondering
why 
this file is checked.

4) obsolete system	2	No config file for system
These 2 entries are configure.host and configure.tgt
which are again generated files...

Pierre Muller

ChangeLog pseudo-entry:

2007-10-10  Pierre Muller  <muller@ics.u-strasbg.fr>

	* gdb_ari.sh (strerror): update rule to reflect
	implementation of safe_strerror in posix-hdep.c and mingw-hdep.c.
	(floatformat_to_double): update rule to accept
	call in gdb/doublest.c source.

$ cvs diff -up gdb_ari.sh
Index: gdb_ari.sh
===================================================================
RCS file: /cvs/gdbadmin/ss/gdb_ari.sh,v
retrieving revision 1.74
diff -u -p -r1.74 gdb_ari.sh
--- gdb_ari.sh  8 Oct 2007 12:01:35 -0000       1.74
+++ gdb_ari.sh  10 Oct 2007 07:54:54 -0000
@@ -488,7 +488,8 @@ BEGIN { doc["strerror"] = "\
 Do not use strerror(), instead use safe_strerror()"
     category["strerror"] = ari_regression
     fix("strerror", "gdb/gdb_string.h", 1)
-    fix("strerror", "gdb/utils.c", 1)
+    fix("strerror", "gdb/mingw-hdep.c", 1)
+    fix("strerror", "gdb/posix-hdep.c", 1)
 }
 /(^|[^_[:alnum:]])strerror[[:space:]]*\(/ {
     fail("strerror")
@@ -989,6 +990,7 @@ get_frame_locals_address, or get_frame_a
 BEGIN { doc["floatformat_to_double"] = "\
 Do not use floatformat_to_double() from libierty, \
 instead use floatformat_to_doublest()"
+    fix("floatformat_to_double", "gdb/doublest.c", 1)
     category["floatformat_to_double"] = ari_regression
 }
 /(^|[^_[:alnum:]])floatformat_to_double[[:space:]]*\(/ {
Pierre Muller

Re: [RFA] gdb_ari.sh patch to eliminate wrong critical errors

['Daniel Jacobowitz']

On Wed, Oct 10, 2007 at 10:09:18AM +0200, Pierre Muller wrote:
>   I tested this locally and it does reduce the 
> number of critical entries to 4.
>   
>   Daniel, could you please commit this?

Done.

>   Remaining problems are:
> 1) inline	9	Do not use the inline attribute; 
> since the compiler generally ignores this, better 
> algorithm selection is needed to improved performance
>   This problem is limited to three files:
> vec.c (1) vec.h (7) and xtensa-tdep.c (1).
> It could be easily removed, but I was wondering if 
> there was a special reason why vec.h 
> had some many.

No really good reason.  The above is someone's particular opinion on
the inline keyword (probably Andrew's, as he wrote the ARI stuff, but
I don't know for sure who - maybe someone else on the list knows).
vec.c / vec.h were written by Nathan for GCC, and the GCC project has
a very different opinion on the use of the inline keyword.

Perhaps the fact that the compiler sources think inline is worthwhile
should give us a hint...

> 3) hash	3	Do not use ` #...', instead use `#...'
> (some compilers only correctly parse a C preprocessor directive 
> when `#' is the first character on the line)
>   This 3 appearances are in:
>   ada-lex.c (2) and xtensa-tdep.c (1)
>   But ada-lex.c is an automatically generated file, and I am even wondering
> why 
> this file is checked.

Probably shouldn't be.

> 4) obsolete system	2	No config file for system
> These 2 entries are configure.host and configure.tgt
> which are again generated files...

No they aren't.  They're maintained by hand.

I can not figure out where this message comes from or what it means.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA] gdb_ari.sh patch to eliminate wrong critical errors

[Ulrich Weigand]

Daniel Jacobowitz wrote:

> > 4) obsolete system	2	No config file for system
> > These 2 entries are configure.host and configure.tgt
> > which are again generated files...
> 
> No they aren't.  They're maintained by hand.
> 
> I can not figure out where this message comes from or what it means.

What the message means is apparently that there is an entry in
configure.host or configure.tgt that refers to an .mh / .mt file
that actually does not exist.

There used to be a script gdb_orphan.sh that generated those 
messages into a file ari.orphan.bug.  However, Andrew removed
the gdb_orphan.sh script from the "ss" repository on 2005/08/14.

But apparently the last generated ari.orphan.bug file is still
around somewhere (even though it is never regenerated), and
thus those two lines (which are probably long since fixed)
will continue to show up in every new ARI report.  (Note that
at the bottom of the ARI web site there still is a link to
that file.)

I guess someone with access to the web server will have to
track down and delete that file.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [RFA] gdb_ari.sh patch to eliminate wrong critical errors

['Daniel Jacobowitz']

On Wed, Oct 10, 2007 at 04:43:57PM +0200, Ulrich Weigand wrote:
> What the message means is apparently that there is an entry in
> configure.host or configure.tgt that refers to an .mh / .mt file
> that actually does not exist.
> 
> There used to be a script gdb_orphan.sh that generated those 
> messages into a file ari.orphan.bug.  However, Andrew removed
> the gdb_orphan.sh script from the "ss" repository on 2005/08/14.
> 
> But apparently the last generated ari.orphan.bug file is still
> around somewhere (even though it is never regenerated), and
> thus those two lines (which are probably long since fixed)
> will continue to show up in every new ARI report.  (Note that
> at the bottom of the ARI web site there still is a link to
> that file.)

Right you are:

-rw-r--r--  1 gdbadmin gdb 191 Aug 14  2005 ./current/ari/ari.orphan.bug

It's gone now.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA] gdb_ari.sh patch to eliminate wrong critical errors

[Jim Blandy]

'Daniel Jacobowitz' <drow at false.org> writes:
>> 1) inline	9	Do not use the inline attribute; 
>> since the compiler generally ignores this, better 
>> algorithm selection is needed to improved performance
>>   This problem is limited to three files:
>> vec.c (1) vec.h (7) and xtensa-tdep.c (1).
>> It could be easily removed, but I was wondering if 
>> there was a special reason why vec.h 
>> had some many.
>
> No really good reason.  The above is someone's particular opinion on
> the inline keyword (probably Andrew's, as he wrote the ARI stuff, but
> I don't know for sure who - maybe someone else on the list knows).
> vec.c / vec.h were written by Nathan for GCC, and the GCC project has
> a very different opinion on the use of the inline keyword.
>
> Perhaps the fact that the compiler sources think inline is worthwhile
> should give us a hint...

Yeah, I'm not sure I agree with the ARI's opinion either.  GDB has
plenty of room for algorithmic improvements, but if adding an 'inline'
to a particular function made it go faster, why not use it?

Well, this is exactly why the ARI explicitly forbids us from taking it
seriously: to encourage people to disagree, debate and refine.  I
think that check should go.

Re: [RFA] gdb_ari.sh patch to eliminate wrong critical errors

[Mark Kettenis]

> From: Jim Blandy <jimb@codesourcery.com>
> Date: Wed, 10 Oct 2007 08:04:30 -0700
> 
> 'Daniel Jacobowitz' <drow at false.org> writes:
> >> 1) inline	9	Do not use the inline attribute; 
> >> since the compiler generally ignores this, better 
> >> algorithm selection is needed to improved performance
> >>   This problem is limited to three files:
> >> vec.c (1) vec.h (7) and xtensa-tdep.c (1).
> >> It could be easily removed, but I was wondering if 
> >> there was a special reason why vec.h 
> >> had some many.
> >
> > No really good reason.  The above is someone's particular opinion on
> > the inline keyword (probably Andrew's, as he wrote the ARI stuff, but
> > I don't know for sure who - maybe someone else on the list knows).
> > vec.c / vec.h were written by Nathan for GCC, and the GCC project has
> > a very different opinion on the use of the inline keyword.
> >
> > Perhaps the fact that the compiler sources think inline is worthwhile
> > should give us a hint...
> 
> Yeah, I'm not sure I agree with the ARI's opinion either.  GDB has
> plenty of room for algorithmic improvements, but if adding an 'inline'
> to a particular function made it go faster, why not use it?

The point is that in many cases it doesn't.  Inlining generally
increases code size, and therefore tends to increase cache pressure,
which often results in slower code.  And of course it makes code much
harder to debug.

Update ARI pages

[Pierre Muller]

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of 'Daniel Jacobowitz'
> Sent: Wednesday, October 10, 2007 2:02 PM
> To: Pierre Muller
> Cc: gdb-patches@sourceware.org
> Subject: Re: [RFA] gdb_ari.sh patch to eliminate wrong critical errors
> 
> On Wed, Oct 10, 2007 at 10:09:18AM +0200, Pierre Muller wrote:
> >   I tested this locally and it does reduce the
> > number of critical entries to 4.
> >
> >   Daniel, could you please commit this?
> 
> Done.

  Strange, because the ARI from today still do not
reflect the changes :(
  The gdb_ari.sh still contains the old 'strerror' rule
for which the implementation should be in gdb/utils.c file.
  Maybe the files executing every night are not automatically
synchronized with the cvs repository.

  Daniel, someone having direct access to the web server
is needed here, could you take a look at it?
  Maybe running ./do-scp in the directory
that is used for the nightly update would be enough.

  It might also be a good time (as 6.7 just came out)
to refresh the 'last release' page, but, to be honest,

  I tried to write a custom script for that:

#!/bin/sh
# Copy release to temp dir; directory unsure, based on do-snapshot script
version=6.7
tmpdir=/sourceware/snapshot-tmp/gdb/release/gdb-${version}
wwwdir=/www/sourceware/htdocs/gdb/download
cp /sourceware/ftp/anonftp/pub/gdb/releases/gdb-${version}.tar.gz
${tmpdir}/update-web-ari
# Move to temp dir
cd ${tmpdir}/update-web-ari
#Gunzip tar file
gunzip gdb-${version}.tar.gz
# Run update-web-ari script, destination web dir also uncertain...
$(HOME)/ss/update-web-ari ${tmpdir}/update-web-ari/gdb.tar
${tmpdir}/update-web-ari ${wwwdir} /ari gdb

  But I don't know if the paths are still valid.

Could you try it out?

Pierre
  


 

Re: Update ARI pages

['Daniel Jacobowitz']

On Thu, Oct 11, 2007 at 09:26:20AM +0200, Pierre Muller wrote:
>   Strange, because the ARI from today still do not
> reflect the changes :(
>   The gdb_ari.sh still contains the old 'strerror' rule
> for which the implementation should be in gdb/utils.c file.
>   Maybe the files executing every night are not automatically
> synchronized with the cvs repository.

Right, I forgot to update the master copy.

>   It might also be a good time (as 6.7 just came out)
> to refresh the 'last release' page, but, to be honest,

I don't even think this is worth doing.  Does anyone else?  The ARI
is a development tool; it's not important for release branches.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Update ARI pages

[Joel Brobecker]

> I don't even think this is worth doing.  Does anyone else?  The ARI
> is a development tool; it's not important for release branches.

I agree with Daniel.

-- 
Joel

RE: Update ARI pages

[Pierre Muller]

 I think that there is a misunderstanding:
  I didn't want to have a daily updated page that would use the
release branch, but simply change the pages with the results
of the last release.
  
  Anyhow, we should either update the pages
http://sourceware.org/gdb/download/ari/
to give results from 6.7 or completely remove
the link to 'last release' in all the ARI pages.

  I am still in favor of going writing a small script that
would check the last released version,
and regenerate the download/ari pages
if the version changed.

Pierre Muller
  

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Joel Brobecker
> Sent: Thursday, October 11, 2007 6:50 PM
> To: Pierre Muller; gdb-patches@sourceware.org
> Subject: Re: Update ARI pages
> 
> > I don't even think this is worth doing.  Does anyone else?  The ARI
> > is a development tool; it's not important for release branches.
> 
> I agree with Daniel.
> 
> --
> Joel

Re: Update ARI pages

['Daniel Jacobowitz']

On Thu, Oct 11, 2007 at 09:26:20AM +0200, Pierre Muller wrote:
>   It might also be a good time (as 6.7 just came out)
> to refresh the 'last release' page, but, to be honest,
> 
>   I tried to write a custom script for that:

I played around with this for a bit.  Eventually I realized that
this is in our release checklist already.  It's right below the
bit that says how to update the online documentation.  Joel,
you've been doing that bit - any particular reason you didn't
do the ARI too?

Joel, I stumbled on the scary set of shell scripts in
~gdbadmin/gdb-release.  At least no one can say they could replace you
with a _small_ shell script... I borrowed the update-web-docs command
line from one script, compared with the gdbint manual, and established
that this command ought to regenerate the ARI directories:

  /bin/sh ~/ss/update-web-ari \
          ~ftp/pub/gdb/releases/gdb-6.7.tar.bz2 \
           $PWD/www \
           /www/sourceware/htdocs/gdb/download/ari \
           gdb

$PWD/www is a temporary directory that the script will create and then
delete.  I didn't generate them into the final output directory, but
I did run the script into a temporary location, and it seems fine.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Update ARI pages

[Joel Brobecker]

> I played around with this for a bit.  Eventually I realized that
> this is in our release checklist already.  It's right below the
> bit that says how to update the online documentation.  Joel,
> you've been doing that bit - any particular reason you didn't
> do the ARI too?

No, I just missed it!

> Joel, I stumbled on the scary set of shell scripts in
> ~gdbadmin/gdb-release.

Ah, the cat is out of the bag... I wrote these scripts in preparation
to the gdb-6.7 release, wanted to have a couple of release cycles done
with them before I announced them. The number of scripts is indeed
scary, but this is mostly because there are lots of little steps to go
through during the release. Each step pretty much has its own script
(more or less).

The idea is that the scripts act as two things:
  - An electronic reminder of all the actions to be done, where I need
    to acknowledge all actions I'm supposed to do before the script
    moves on.  This is to avoid forgetting about the ARI for instance...
  - Do automatically what can easily be done automatically.

The conjunction of the two dramatically reduce the amount of time
it takes to produce a release (creating the branch took about 1h,
and so did producing the gdb-6.7 release).

The entry point for the scripts is one single script, called "release.sh".
It knows what you've done so far, and just picks up where you left.

I am not going to write more about this for now, as this is a bit
off topic for this thread. I intend to contribute this to GDB eventually
and re-write the documentation accordingly (describe the release process
as well as the internals of the scripts).

>   /bin/sh ~/ss/update-web-ari \
>           ~ftp/pub/gdb/releases/gdb-6.7.tar.bz2 \
>            $PWD/www \
>            /www/sourceware/htdocs/gdb/download/ari \
>            gdb

New script added :), so it should not be forgotten again. I ran
the new script manually, and checked the results on the web,
which seem fine. Let me know if there are some errors.

-- 
Joel

Re: Update ARI pages

[Daniel Jacobowitz]

On Wed, Oct 24, 2007 at 01:40:58PM -0700, Joel Brobecker wrote:
> New script added :), so it should not be forgotten again. I ran
> the new script manually, and checked the results on the web,
> which seem fine. Let me know if there are some errors.

Thanks!

-- 
Daniel Jacobowitz
CodeSourcery

RE: Update ARI pages

[Pierre Muller]

Thanks, it looks much better now
if you follow the 'last release' link
on the ARI pages.

Pierre

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Joel Brobecker
> Sent: Wednesday, October 24, 2007 10:41 PM
> To: Pierre Muller; gdb-patches@sourceware.org
> Subject: Re: Update ARI pages
> 
> > I played around with this for a bit.  Eventually I realized that
> > this is in our release checklist already.  It's right below the
> > bit that says how to update the online documentation.  Joel,
> > you've been doing that bit - any particular reason you didn't
> > do the ARI too?
> 
> No, I just missed it!
> 
> > Joel, I stumbled on the scary set of shell scripts in
> > ~gdbadmin/gdb-release.
> 
> Ah, the cat is out of the bag... I wrote these scripts in preparation
> to the gdb-6.7 release, wanted to have a couple of release cycles done
> with them before I announced them. The number of scripts is indeed
> scary, but this is mostly because there are lots of little steps to go
> through during the release. Each step pretty much has its own script
> (more or less).
> 
> The idea is that the scripts act as two things:
>   - An electronic reminder of all the actions to be done, where I need
>     to acknowledge all actions I'm supposed to do before the script
>     moves on.  This is to avoid forgetting about the ARI for
> instance...
>   - Do automatically what can easily be done automatically.
> 
> The conjunction of the two dramatically reduce the amount of time
> it takes to produce a release (creating the branch took about 1h,
> and so did producing the gdb-6.7 release).
> 
> The entry point for the scripts is one single script, called
> "release.sh".
> It knows what you've done so far, and just picks up where you left.
> 
> I am not going to write more about this for now, as this is a bit
> off topic for this thread. I intend to contribute this to GDB
> eventually
> and re-write the documentation accordingly (describe the release
> process
> as well as the internals of the scripts).
> 
> >   /bin/sh ~/ss/update-web-ari \
> >           ~ftp/pub/gdb/releases/gdb-6.7.tar.bz2 \
> >            $PWD/www \
> >            /www/sourceware/htdocs/gdb/download/ari \
> >            gdb
> 
> New script added :), so it should not be forgotten again. I ran
> the new script manually, and checked the results on the web,
> which seem fine. Let me know if there are some errors.
> 
> --
> Joel

Re: [RFA] gdb_ari.sh patch to eliminate wrong critical errors

[Ulrich Weigand]

Pierre Muller wrote:

> 2) GNU/Linux	4	Do not use `Linux', instead use `Linux kernel' 
> or `GNU/Linux system'; comments should clearly differentiate between 
> the two (this test assumes that word `Linux' appears on the same line 
> as the word `GNU' or `kernel'
>   This one is a little too subtle for me, as I am hardly able to
> distinguish between 'GNU/Linux system' and 'Linux kernel'...

I've committed the following patch to fix those instances.  I hope
I got all of them ...

Bye,
Ulrich

ChangeLog:

	* linux-nat.c (lin_lwp_attach_lwp): Use "Linux kernel 2.6.19"
	instead of "Linux 2.6.19" in comment.
	(linux_xfer_partial): Use "GNU/Linux target" instead of 
	"Linux target" in comment.
	* m68klinux-tdep.c (m68k_linux_inferior_created): Likewise.
	(m68k_linux_get_sigtramp_info): Likewise.

Index: gdb/linux-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/linux-nat.c,v
retrieving revision 1.69
diff -c -p -r1.69 linux-nat.c
*** gdb/linux-nat.c	2 Oct 2007 16:33:35 -0000	1.69
--- gdb/linux-nat.c	11 Oct 2007 19:26:38 -0000
*************** lin_lwp_attach_lwp (ptid_t ptid, int ver
*** 902,908 ****
  	{
  	  /* If we fail to attach to the thread, issue a warning,
  	     but continue.  One way this can happen is if thread
! 	     creation is interrupted; as of Linux 2.6.19, a kernel
  	     bug may place threads in the thread list and then fail
  	     to create them.  */
  	  warning (_("Can't attach %s: %s"), target_pid_to_str (ptid),
--- 902,908 ----
  	{
  	  /* If we fail to attach to the thread, issue a warning,
  	     but continue.  One way this can happen is if thread
! 	     creation is interrupted; as of Linux kernel 2.6.19, a
  	     bug may place threads in the thread list and then fail
  	     to create them.  */
  	  warning (_("Can't attach %s: %s"), target_pid_to_str (ptid),
*************** linux_xfer_partial (struct target_ops *o
*** 3212,3218 ****
  			     offset, len);
  }
  
! /* Create a prototype generic Linux target.  The client can override
     it with local methods.  */
  
  static void
--- 3212,3218 ----
  			     offset, len);
  }
  
! /* Create a prototype generic GNU/Linux target.  The client can override
     it with local methods.  */
  
  static void
Index: gdb/m68klinux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/m68klinux-tdep.c,v
retrieving revision 1.25
diff -c -p -r1.25 m68klinux-tdep.c
*** gdb/m68klinux-tdep.c	8 Oct 2007 12:54:07 -0000	1.25
--- gdb/m68klinux-tdep.c	11 Oct 2007 19:26:38 -0000
*************** static int target_is_uclinux;
*** 213,220 ****
  static void
  m68k_linux_inferior_created (struct target_ops *objfile, int from_tty)
  {
!   /* Record that we will need to re-evaluate whether we are running on
!      a uClinux or normal Linux target (see m68k_linux_get_sigtramp_info).  */
    target_is_uclinux = -1;
  }
  
--- 213,220 ----
  static void
  m68k_linux_inferior_created (struct target_ops *objfile, int from_tty)
  {
!   /* Record that we will need to re-evaluate whether we are running on a
!      uClinux or normal GNU/Linux target (see m68k_linux_get_sigtramp_info).  */
    target_is_uclinux = -1;
  }
  
*************** m68k_linux_get_sigtramp_info (struct fra
*** 227,233 ****
  
    if (target_is_uclinux == -1)
      {
!       /* Determine whether we are running on a uClinux or normal Linux
           target so we can use the correct sigcontext layouts.  */
      
        CORE_ADDR dummy;
--- 227,233 ----
  
    if (target_is_uclinux == -1)
      {
!       /* Determine whether we are running on a uClinux or normal GNU/Linux
           target so we can use the correct sigcontext layouts.  */
      
        CORE_ADDR dummy;


-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

RE: [RFA] gdb_ari.sh patch to eliminate wrong critical errors

[Pierre Muller]

Thanks Ulrich,

  The current ARI page look much better!
Only the inline and hash critical bugs remain.

  To get a ARI page that would better
catch new regression, I could move all
deprecated and obsolete bugs that have
currently a zero count to ari_regression category,
this would trigger them to appear on front,
before the large table if someone reintroduces them.

  Should I submit a RFA for this?

Pierre

PS: 
  There are 6 deprecated functions that have a -1 count.
Which seems to be related to function name appearing in comments
or disabled code.

Re: [RFA] gdb_ari.sh patch to eliminate wrong critical errors

['Daniel Jacobowitz']

On Mon, Oct 15, 2007 at 11:24:55AM +0200, Pierre Muller wrote:
>   Should I submit a RFA for this?

Seems fine to me.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA] gdb_ari.sh patch to eliminate wrong critical errors

[Ulrich Weigand]

Pierre,

>   The current ARI page look much better!
> Only the inline and hash critical bugs remain.

I'm not sure if these categories really make sense ...

>   To get a ARI page that would better
> catch new regression, I could move all
> deprecated and obsolete bugs that have
> currently a zero count to ari_regression category,
> this would trigger them to appear on front,
> before the large table if someone reintroduces them.

As the comment at the top of gdb_ari.sh, there are two
types of checks:

# Permenant checks take the form:

#     Do not use XXXX, ISO C 90 implies YYYY
#     Do not use XXXX, instead use YYYY''.

# and should never be removed.

# Temporary checks take the form:

#     Replace XXXX with YYYY

# and once they reach zero, can be eliminated.

Only those checks that *can* regress should be moved to
the ari_regression category, those that cannot (e.g. use
of a function that has actually been removed) should just
deleted completely.


>   There are 6 deprecated functions that have a -1 count.
> Which seems to be related to function name appearing in comments
> or disabled code.

There is some logic that subtracts 2 from the count (to avoid
counting the function definition and declaration).  This logic
gets it wrong in some cases; e.g. it leads to negative values
for some functions that have already been completely removed.

(On the other hand, even some functions with count 0 are in
fact still used, because the one use happens to be in a file
that is for some reason excluded from the ARI scan.  So you
should double-check for each case you remove that there is
indeed no more reference.)


Thanks for working on clearing up the ARI!

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [RFA] gdb_ari.sh patch to eliminate wrong critical errors

[Ulrich Weigand]

I wrote:
> (On the other hand, even some functions with count 0 are in
> fact still used, because the one use happens to be in a file
> that is for some reason excluded from the ARI scan.  So you
> should double-check for each case you remove that there is
> indeed no more reference.)

On the other hand, there's also the opposite scenario: in some
cases, a function/macro has already been removed, but the ARI
still finds apparent uses (which are in fact just occurances
of local variable etc. that just happen to have the same name
as the removed global construct).

I'm aware of at least the following checks that can be removed:

supply_register (finds a local struct member)
obj_private (finds a local variable)
inside_entry_func (find a -now- static function)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com