Re: ARI troubles

Re: ARI troubles

[Pedro Alves]

On 04/24/2012 11:40 PM, Pierre Muller wrote:

> My problem here is that the same gdb_ari.sh script
> is used both for trunk as well as fixes branch...
> 
> How should I cope with such changes?


The script should really be imported to the gdb tree, and
then trunk and branches would have their own versions/revisions
of the script.  The web bits of the ARI would then be adjusted
to invoke the script found in the gdb sources being tested.

More glue could also be moved/added to the gdb tree, making it
easy for people to run the gdb_ari.sh script themselves.

-- 
Pedro Alves

Re: ARI troubles

[Joel Brobecker]

> > My problem here is that the same gdb_ari.sh script
> > is used both for trunk as well as fixes branch...
> > 
> > How should I cope with such changes?
> 
> 
> The script should really be imported to the gdb tree, and
> then trunk and branches would have their own versions/revisions
> of the script.

Agreed. Let's move the script over to the GDB sources, and then
we can document Pierre the official maintainer of that script.

> The web bits of the ARI would then be adjusted to invoke the script
> found in the gdb sources being tested.

That should be relatively easy to do, and we can keep two copies
around for a day or two while we make the transition...

-- 
Joel

RE: ARI troubles

[Pierre Muller]

Big question:
  where do we put this script?

Pierre

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Joel Brobecker
> Envoyé : mercredi 25 avril 2012 17:56
> À : Pedro Alves
> Cc : Pierre Muller; gdb-patches@sourceware.org
> Objet : Re: ARI troubles
> 
> > > My problem here is that the same gdb_ari.sh script
> > > is used both for trunk as well as fixes branch...
> > >
> > > How should I cope with such changes?
> >
> >
> > The script should really be imported to the gdb tree, and
> > then trunk and branches would have their own versions/revisions
> > of the script.
> 
> Agreed. Let's move the script over to the GDB sources, and then
> we can document Pierre the official maintainer of that script.
> 
> > The web bits of the ARI would then be adjusted to invoke the script
> > found in the gdb sources being tested.
> 
> That should be relatively easy to do, and we can keep two copies
> around for a day or two while we make the transition...

Re: ARI troubles

[Doug Evans]

src/gdb/contrib?
src/contrib?

gcc has lots of utility scripts in their top level contrib directory.

On Wed, Apr 25, 2012 at 9:10 AM, Pierre Muller
<pierre.muller@ics-cnrs.unistra.fr> wrote:
> Big question:
>  where do we put this script?
>
> Pierre
>
>> -----Message d'origine-----
>> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
>> owner@sourceware.org] De la part de Joel Brobecker
>> Envoyé : mercredi 25 avril 2012 17:56
>> À : Pedro Alves
>> Cc : Pierre Muller; gdb-patches@sourceware.org
>> Objet : Re: ARI troubles
>>
>> > > My problem here is that the same gdb_ari.sh script
>> > > is used both for trunk as well as fixes branch...
>> > >
>> > > How should I cope with such changes?
>> >
>> >
>> > The script should really be imported to the gdb tree, and
>> > then trunk and branches would have their own versions/revisions
>> > of the script.
>>
>> Agreed. Let's move the script over to the GDB sources, and then
>> we can document Pierre the official maintainer of that script.
>>
>> > The web bits of the ARI would then be adjusted to invoke the script
>> > found in the gdb sources being tested.
>>
>> That should be relatively easy to do, and we can keep two copies
>> around for a day or two while we make the transition...
>

Re: ARI troubles

[Joel Brobecker]

> src/gdb/contrib?
> src/contrib?
> 
> gcc has lots of utility scripts in their top level contrib directory.

We also have a few scripts in the src/gdb/ subdirectory. Putting
gdb_ari.sh there would keep them all together...

-- 
Joel

Re: ARI troubles

[Doug Evans]

On Wed, Apr 25, 2012 at 9:56 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> src/gdb/contrib?
>> src/contrib?
>>
>> gcc has lots of utility scripts in their top level contrib directory.
>
> We also have a few scripts in the src/gdb/ subdirectory. Putting
> gdb_ari.sh there would keep them all together...

That's how things like libiberty grow into unwieldy monsters. :-)
And now there's too much inertia to do any better.

RE: ARI troubles

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Doug Evans
> Envoyé : jeudi 26 avril 2012 17:40
> À : Joel Brobecker
> Cc : Pierre Muller; Pedro Alves; gdb-patches@sourceware.org
> Objet : Re: ARI troubles
> 
> On Wed, Apr 25, 2012 at 9:56 AM, Joel Brobecker <brobecker@adacore.com>
> wrote:
> >> src/gdb/contrib?
> >> src/contrib?
> >>
> >> gcc has lots of utility scripts in their top level contrib directory.
> >
> > We also have a few scripts in the src/gdb/ subdirectory. Putting
> > gdb_ari.sh there would keep them all together...

  I think that those scripts
are used to generate sources in the build directory, no?

 
> That's how things like libiberty grow into unwieldy monsters. :-)
> And now there's too much inertia to do any better.

The usage of gdb_ari.sh is much more limited,
normal users, who just want to compile
a released GDB source, probably have no interest in that tool...

  Thus a discrete sub-directory would seem more natural
to me.

  Note that the current ARI page
lists several scripts:
Scripts: gdb_ari.sh gdb_copyright.sh gdb_find.sh gdb_indent.sh
gdb_makefile.sh gdb_orphan.sh

but I doubt the others are really up to date and used.

Pierre

Re: ARI troubles

[Joel Brobecker]

> Thus a discrete sub-directory would seem more natural to me.

I do not have a strong opinion on this. Any location is really
fine with me.

-- 
Joel

Re: ARI troubles

[Jan Kratochvil]

On Thu, 26 Apr 2012 18:15:45 +0200, Joel Brobecker wrote:
> > Thus a discrete sub-directory would seem more natural to me.
> 
> I do not have a strong opinion on this. Any location is really
> fine with me.

I am fine with gdb/ but it should be checked in somewhere where it can be
modified, I even wrote
	[ARI patch] Verify cross-arch .S testsuite files compatibility
	http://sourceware.org/ml/gdb-patches/2012-03/msg00511.html

and I still have to do what the patch does by hand
	Re: Crash regression for gdb.ada/*.exp [Re: [RFA 2/3] Initial Fission support, rewrite DIE reading]
	http://sourceware.org/ml/gdb-patches/2012-04/msg01079.html


Thanks,
Jan

ARI troubles

[Pierre Muller]

  Hi all,
it's been a long time since I really looked at the ARI web page...
I wanted to remove the inline ARI rule as
discussed earlier on the list.


It degraded quite a lot recently:

http://sourceware.org/gdb/current/ari/

But most of the critical renentrant bugs are just
problems releated to introduction
of
common/common-utils.[ch]

My problem here is that the same gdb_ari.sh script
is used both for trunk as well as fixes branch...

How should I cope with such changes?




Pierre Muller
GDB pascal language maintainer


PS: Should I commit the change below
that effecitvely removed inline ARI rule?


Index: gdb_ari.sh
===================================================================
RCS file: /cvs/gdbadmin/ss/gdb_ari.sh,v
retrieving revision 1.110
diff -u -p -r1.110 gdb_ari.sh
--- gdb_ari.sh  30 May 2011 19:55:37 -0000      1.110
+++ gdb_ari.sh  24 Apr 2012 22:39:35 -0000
@@ -676,15 +676,16 @@ FNR == 1 {
     }
 }

-BEGIN { doc["inline"] = "\
-Do not use the inline attribute; \
-since the compiler generally ignores this, better algorithm selection \
-is needed to improved performance"
-    category["inline"] = ari_code
-}
-/(^|[^_[:alnum:]])inline([^_[:alnum:]]|$)/ {
-    fail("inline")
-}
+# Commented out, but left inside sources, just in case.
+# BEGIN { doc["inline"] = "\
+# Do not use the inline attribute; \
+# since the compiler generally ignores this, better algorithm selection \
+# is needed to improved performance"
+#    category["inline"] = ari_code
+# }
+# /(^|[^_[:alnum:]])inline([^_[:alnum:]]|$)/ {
+#     fail("inline")
+# }

 # This test is obsolete as this type
 # has been deprecated and finally suppressed from GDB sources
cvs diff: Diffing CVSROOT