Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Pierre Muller" <muller@ics.u-strasbg.fr>
To: "'Joel Brobecker'" <brobecker@adacore.com>,
	        "'Ulrich Weigand'" <uweigand@de.ibm.com>
Cc: <gdb-patches@sourceware.org>
Subject: RE: [PATCH] gdbadmin/ss/gdb_ari.sh obsolete->regression
Date: Fri, 17 Apr 2009 11:23:00 -0000	[thread overview]
Message-ID: <003c01c9bf4e$a95f28f0$fc1d7ad0$@u-strasbg.fr> (raw)
In-Reply-To: <20090416071722.GF7585@adacore.com>

> -----Message d'origine-----
> De : Joel Brobecker [mailto:brobecker@adacore.com]
> Envoyé : Thursday, April 16, 2009 9:17 AM
> À : Ulrich Weigand
> Cc : Pierre Muller; gdb-patches@sourceware.org
> Objet : Re: [PATCH] gdbadmin/ss/gdb_ari.sh obsolete->regression
> 
> > B.t.w. as you're clearing up ARI results anyway (b.t.w.
> > thank you for your efforts in this area!), there's a
> > number of ARI tests where all remaining hits are in
> > fact false positives:
> >
> > In the Obsolete category:
> >
> > supply_register  (this function no longer exists; ARI
> > finds local struct members with the same name as false
> > positive results)
> >
> > inside_entry_func  (this is now a static routine; the
> > original reason for this ARI entry no longer applies)

 I removed these two from gdb_ari.sh

> > In the Deprecate category:
> >
> > SP_REGNUM, PC_REGNUM, FP0_REGNUM   (these are not defined
> > anywhere any more; ARI finds local definitions with
> > extended names like E_SP_REGNUM etc.)

  OK, these three were DEPRECATED first anyhow...
I also removed those rules.

> > In the Legacy category:
> >
> > legacy_name  (this doesn't exist any more; ARI finds a
> > local variable with the same name)

  I looked at the code in remote.c,
and I am not sure that this is not what is meant by this rule:
there is no legacy_name in any ChangeLog, thus it is probably not 
a function.
 
It looks like this legacy argument in add_packet_config_cmd
add a "set/show remote" entry for
"binary-download-packet" as an alias of "X-packet".

I am wondering if this reminder is not that we should
remove that old "binary-download-packet" entry.
But then there is also still an entry for "binary-download in gdb.texinfo.



> > I think these should also be simply deleted ...
> 
> Fully agreed. Nice catches, Ulrich :)

  Thanks, Ulrich.


Pierre Muller
Pascal language support maintainer for GDB

Here is the change I committed.

Index: gdb_ari.sh
===================================================================
RCS file: /cvs/gdbadmin/ss/gdb_ari.sh,v
retrieving revision 1.87
diff -r1.87 gdb_ari.sh
722,729d721
< BEGIN { doc["inside_entry_func"] = "\
< Replace inside_entry_func with nothing, or a call to
find_pc_partial_function"

<     category["inside_entry_func"] = ari_obsolete
< }
< /(^|[^_[:alnum:]])inside_entry_func([^_[:alnum:]]|$)/ {
<     fail("inside_entry_func")
< }
<
807,816d798
< BEGIN { doc["supply_register"] = "\
< Replace supply_register() with regcache_raw_supply; \
< note that eventually that method may, in turn, be replaced with \
< something parameterized with either a thread or target"
<     category["supply_register"] = ari_obsolete
< }
< /(^|[^_[:alnum:]])supply_register([^_[:alnum:]]|$)/ {
<     fail("supply_register")
< }
<
911,939d892
< # The totally dreaded FP REGNUM code.
<
< BEGIN { doc["SP_REGNUM"] = "\
< Replace SP_REGNUM with something indicating the frame inner-most address"
<     category["SP_REGNUM"] = ari_deprecate
< }
< /(^|[^_[:alnum:]])SP_REGNUM([^_[:alnum:]]|$)/ || \
< /(^|[^_[:alnum:]])set_gdbarch_sp_regnum([^_[:alnum:]]|$)/ {
<     fail("SP_REGNUM")
< }
<
< BEGIN { doc["FP0_REGNUM"] = "\
< Replace FP0_REGNUM with nothing, does not belong in generic code"
<     category["FP0_REGNUM"] = ari_deprecate
< }
< /(^|[^_[:alnum:]])FP0_REGNUM([^_[:alnum:]]|$)/ || \
< /(^|[^_[:alnum:]])set_gdbarch_fp0_regnum([^_[:alnum:]]|$)/ {
<     fail("FP0_REGNUM")
< }
<
< BEGIN { doc["PC_REGNUM"] = "\
< Replace PC_REGNUM with nothing, not needed"
<     category["PC_REGNUM"] = ari_deprecate
< }
< /(^|[^_[:alnum:]])PC_REGNUM([^_[:alnum:]]|$)/ || \
< /(^|[^_[:alnum:]])set_gdbarch_pc_regnum([^_[:alnum:]]|$)/ {
<     fail("PC_REGNUM")
< }
<


  reply	other threads:[~2009-04-17 11:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-14 21:21 Pierre Muller
2009-04-15  6:38 ` Joel Brobecker
2009-04-15  7:12   ` Pierre Muller
2009-04-15 13:52     ` Ulrich Weigand
2009-04-16  9:35       ` Joel Brobecker
2009-04-17 11:23         ` Pierre Muller [this message]
2009-04-17 11:53           ` Ulrich Weigand
2009-04-16  7:16     ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='003c01c9bf4e$a95f28f0$fc1d7ad0$@u-strasbg.fr' \
    --to=muller@ics.u-strasbg.fr \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=uweigand@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox