Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
  • * Re: RFA: Testsuite patches...
       [not found] <39803B5C.9C31BB15@netwinder.org>
       [not found] ` <3980469B.E0BD7ED2@cygnus.com>
@ 2000-07-28 11:47 ` Fernando Nasser
  2000-07-28 12:26   ` Scott Bambrough
  1 sibling, 1 reply; 6+ messages in thread
From: Fernando Nasser @ 2000-07-28 11:47 UTC (permalink / raw)
  To: Scott Bambrough; +Cc: GDB Patches Mail List

Scott Bambrough wrote:
> 
> 2000-07-26  Scott Bambrough <scottb@netwinder.org>
> 
>         * linux-thread.c (linux_threads_pid_to_str):  Change "Pid" to
>         "process" to allow gdb.base/environ.exp to pass all tests.
>         Change capitalization on "Thread" for consistency.
> 
I forwarded the above change to the maintainers requesting their approval.


> 2000-07-26  Scott Bambrough <scottb@netwinder.org>
> 
>         * gdb.base/environ.exp: Run tests for all targets.
>         * gdb.base/recurse.exp: Run tests for all targets.
> 
These two are OK.


>         * gdb.base/sect-cmd.exp: Run tests for all targets.  Use
>         'section .text' clause for Linux in set section command
>         test.
> 
This is not.  The expect code must be changed to memorize if the architecture
uses .text or CODE and use it subsequently. 


>         * gdb.base/so-impl-ld.exp: Added wildcard to
>         handle the gnu-oldld case on ARM.
> 
All right.  Godd catch.  Thanks.


>         * gdb.base/so-indr-cl.exp: Run tests for *-*-linux-gnu*.
You must also add a comment (as is done in so-impl-ld.exp) explaining that this 
is also known to run in Linux (version?).  The comment there says it *must* be
a HP target and we will contradict it with the code.

>         * gdb.base/watchpoint.exp (test_stepping): Clear xfail
>         for ARM targets.
> 
You are the boss here :-) Let's add this one.



Scott, you can either wait a bit for me to make the changes or, if you find
some spare cycles, do the changes yourself.  We need to wait for the Linux thread
folks to authorize the change to linux-threads.c (which will probably be soon
anyways).

Thanks for the patch.

Regards,
Fernando




-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From scottb@netwinder.org Fri Jul 28 12:03:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFA: Testsuite patches...
Date: Fri, 28 Jul 2000 12:03:00 -0000
Message-id: <3981D792.20F9AD64@netwinder.org>
X-SW-Source: 2000-07/msg00347.html
Content-length: 2003

Michael Snyder wrote:
> 
> I don't see any reference to the string "Pid" in environ.exp,
> and the references to "process" are not testing the output
> that you changed.  Why do you want this change?

Because the output generated by gdb uses pid_to_str which eventually resolves to
the function I have changed.  environ.exp expects process instead of Pid.  HP
has its own version of pid_to_str which uses process as well.  Basically this
change allows the last test in environ.exp to succeed on ARM and x86 Linux. 
These are the only systems I have available ATM.
 
> >         Change capitalization on "Thread" for consistency.
> 
> Consistency with what?  I'm not strongly opposed, but since
> SOMEONE may depend on this output, I'd like to know the
> motivation for changing it.

child_pid_to_str in hppa-nat.c returns either "process pid"
child_pid_to_str in inftarg.c returns either "thread tid" or "process pid"
child_pid_to_str in lynx-nat.c returns either "process pid thread tid" or
"process pid"
normal_pid_to_str returns either "thread pid" or "process pid"
linuxthreads_pid_to_str returns "Thread tid", "Pid pid", my changes makes this
"thread tid", "process pid"

cygwin_pid_to_str returns "thread tid.pid" or "process pid"
gnu_pid_to_str returns "thread pid.tid" or "process pid"

hpux_pid_to_str returns "Thread tid"
procfs_pid_to_str returns "LWP tid", "Process pid" 
uw_thread_pid_to_str returns "LWP tid", "Process pid", "Thread tid"
solaris_pid_to_str returns "Thread tid (LWP lwpid)", "Thread tid (defunct)",
"LWP lwpid", "Thread tid",  "process pid"
thread_db_pid_to_str returns "Thread tid (LWP lwpid)", "Thread tid (state str)",
"LWP lwpid", "thread tid", "process pid"

There is not a whole lot of consistency, but I thought it was more more
consistent on the whole with other functions that returned "thread id", "process
id".  Matter of personal opinion I guess.


-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From ezannoni@cygnus.com Fri Jul 28 12:23:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [REPOST PATCH] Fix double pseudoregs in LE target
Date: Fri, 28 Jul 2000 12:23:00 -0000
Message-id: <14721.56729.351998.370048@kwikemart.cygnus.com>
X-SW-Source: 2000-07/msg00348.html
Content-length: 4198

I am reposting this, the previous post to sources.redhat.com didn't
work.

I just commited this SH change (see comments in code):

2000-07-28  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>

        * sh-tdep.c (sh_gdbarch_init): For sh4 initialize
        register_convert_to_raw, register_convert_to_virtual,
        register_convertible.
        (sh_sh4_register_convertible): New function.
        (sh_sh4_register_convert_to_virtual): New function.
        (sh_sh4_register_convert_to_raw): New function.
        Include floatformat.h.

Index: sh-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sh-tdep.c,v
retrieving revision 1.11
diff -c -u -p -r1.11 sh-tdep.c
--- sh-tdep.c	2000/07/26 23:04:44	1.11
+++ sh-tdep.c	2000/07/28 15:13:43
@@ -37,6 +37,7 @@
 #include "inferior.h"		/* for BEFORE_TEXT_END etc. */
 #include "gdb_string.h"
 #include "arch-utils.h"
+#include "floatformat.h"
 
 #undef XMALLOC
 #define XMALLOC(TYPE) ((TYPE*) xmalloc (sizeof (TYPE)))
@@ -1530,6 +1531,71 @@ sh_default_register_virtual_type (reg_nr
   return builtin_type_int;
 }
 
+/* On the sh4, the DRi pseudo registers are problematic if the target
+   is little endian. When the user writes one of those registers, for
+   instance with 'ser var $dr0=1', we want the double to be stored
+   like this: 
+   fr0 = 0x00 0x00 0x00 0x00 0x00 0xf0 0x3f 
+   fr1 = 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
+
+   This corresponds to little endian byte order & big endian word
+   order.  However if we let gdb write the register w/o conversion, it
+   will write fr0 and fr1 this way:
+   fr0 = 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+   fr1 = 0x00 0x00 0x00 0x00 0x00 0xf0 0x3f
+   because it will consider fr0 and fr1 as a single LE stretch of memory.
+   
+   To achieve what we want we must force gdb to store things in
+   floatformat_ieee_double_littlebyte_bigword (which is defined in
+   include/floatformat.h and libiberty/floatformat.c.
+
+   In case the target is big endian, there is no problem, the
+   raw bytes will look like:
+   fr0 = 0x3f 0xf0 0x00 0x00 0x00 0x00 0x00
+   fr1 = 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
+
+   The other pseudo registers (the FVs) also don't pose a problem
+   because they are stored as 4 individual FP elements. */
+
+int
+sh_sh4_register_convertible (int nr)
+{
+  if (TARGET_BYTE_ORDER == LITTLE_ENDIAN)
+    return (gdbarch_tdep (current_gdbarch)->DR0_REGNUM <= nr
+	    && nr <= gdbarch_tdep (current_gdbarch)->DR14_REGNUM);
+  else 
+    return 0;
+}
+
+void
+sh_sh4_register_convert_to_virtual (int regnum, struct type *type,
+                                  char *from, char *to)
+{
+  if (regnum >= gdbarch_tdep (current_gdbarch)->DR0_REGNUM 
+      && regnum <= gdbarch_tdep (current_gdbarch)->DR14_REGNUM)
+    {
+      DOUBLEST val;
+      floatformat_to_doublest (&floatformat_ieee_double_littlebyte_bigword, from, &val);
+      store_floating(to, TYPE_LENGTH(type), val);
+    }
+  else
+    error("sh_register_convert_to_virtual called with non DR register number");
+}
+
+void
+sh_sh4_register_convert_to_raw (struct type *type, int regnum,
+                              char *from, char *to)
+{
+  if (regnum >= gdbarch_tdep (current_gdbarch)->DR0_REGNUM 
+      && regnum <= gdbarch_tdep (current_gdbarch)->DR14_REGNUM)
+    {
+      DOUBLEST val = extract_floating (from, TYPE_LENGTH(type));
+      floatformat_from_doublest (&floatformat_ieee_double_littlebyte_bigword, &val, to);
+    }
+  else
+    error("sh_register_convert_to_raw called with non DR register number");
+}
+
 void
 sh_fetch_pseudo_register (int reg_nr)
 {
@@ -1953,6 +2019,9 @@ sh_gdbarch_init (info, arches)
       set_gdbarch_num_pseudo_regs (gdbarch, 12);
       set_gdbarch_max_register_raw_size (gdbarch, 4 * 4);
       set_gdbarch_max_register_virtual_size (gdbarch, 4 * 4);
+      set_gdbarch_register_convert_to_raw (gdbarch, sh_sh4_register_convert_to_raw);
+      set_gdbarch_register_convert_to_virtual (gdbarch, sh_sh4_register_convert_to_virtual);
+      set_gdbarch_register_convertible (gdbarch, sh_sh4_register_convertible);
       tdep->FPUL_REGNUM = 23;
       tdep->FPSCR_REGNUM = 24;
       tdep->FP15_REGNUM = 40;


^ permalink raw reply	[flat|nested] 6+ messages in thread
    • * RE: RFA: Testsuite patches...
@ 2000-08-02 10:59 Donn Terry
  0 siblings, 0 replies; 6+ messages in thread
From: Donn Terry @ 2000-08-02 10:59 UTC (permalink / raw)
  To: 'Daniel Berlin', Kevin Buettner
  Cc: Andrew Cagney, GDB Discussion, GDB Patches Mail List

One of the first rules of testing: don't discard useful tests.
Thus, I agree that the tests should be added as they are generated.

The problem ISN'T the tests, it's the apparent regression (and the
work that that causes).  Blaming the tests is like blaming the messenger.
Having been in the business of doing a new port over a protracted
period (and of the whole toolchain) it has been a real pain for me
to deal with this problem, but I would never, ever object to including
a new (valid, of course) test.

In the gcc case there has been a database of "who failed what", which gives
me a clue as to whether it's a new test that most systems don't pass (and
I sould defer working on it to more immediate (for me) things) or something
I should fix now.  It's the lack of THAT data that makes including the
new tests painful.  (The gcc tool is less-than-perfect, but moving
it to a central server would address the biggest of the problems.)

XFAIL is a very crude tool: it doesn't really say what "reasonable
expectation" is for any given platform.  However, it's a help, but
has often been abused.

Bright ideas on how to manage the problem of apparent regressions would
be most useful.  Certainly educating the people who look at the
regression results that because the set of regressions is growing,
there will be continuous new failures would be useful.

(One bright idea: insist that the body of the test describe precisely
what is being tested and why, the expectation of which systems should
or should not pass (not in detail, but "RISCs probably will have trouble
with this because..."), and a date(!!!) will make it much easier to
make an informed judgement on a new failure.   Another: include date
of addition in a place where the final report can say something like:
"Tests younger than 30 days: nnn pass; mmm fail.
 Tests younger than 90 days..."

(This makes it easier to show to some manager that it's new tests
that are a problem.)

Donn


> -----Original Message-----
> From: Daniel Berlin [ mailto:dberlin@redhat.com ]
> Sent: Wednesday, August 02, 2000 9:45 AM
> To: Kevin Buettner
> Cc: Andrew Cagney; GDB Discussion; GDB Patches Mail List
> Subject: Re: RFA: Testsuite patches...
> 
> 
> Kevin Buettner <kevinb@cygnus.com> writes:
> 
> > On Aug 2,  9:55pm, Andrew Cagney wrote:
> > 
> > > I think GDB should be accepting tests (provided that they are
> > > rigiously examined) even when they add failures - just as long as
> > > the failures examine real bugs.  I think this also better reflects
> > > what really goes on.
> > 
> > I agree.
> > 
> > If we make "no new failures" the criteria for whether a 
> test is added
> > to the testsuite or not, then it seems to me that we'll end 
> up adding
> > very few new tests just because it's so difficult for any one person
> > to test on all affected targets.  (And it really doesn't work to
> > post a patch and expect everyone affected to try it.)
> > 
> > It makes sense to me to spread the workload by adding a 
> test and then
> > expecting the various maintainers to make sure that the test passes
> > (or gets suitably tweaked) for their targets.
> > 
> > Kevin
> 
> This seems like a better idea.
> 
> In fact, I propose the following, or something like it:
> 
> We accept all new tests people are willing to contribute, whether GDB
> passes them or not, on any platform (assuming the test itself is
> showing a problem with GDB, or something that should eventually work
> in GDB, like say, virtual function calling).
> 
> We have a seperate directory in the testsuite for tests that nobody
> has any idea whether it will pass on all platforms or not, or whether
> GDB can do that yet or not.
> 
> That way, even if you XFAIL'd the test (so people didn't bitch about
> the failures), at least I could look in that test results for 
> that directory when I wanted to know what should be
> working, but isn't, etc.
> 
> Or maybe i'm just babbling.
> --Dan
> 
From fnasser@cygnus.com Wed Aug 02 11:11:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Donn Terry <donnte@microsoft.com>
Cc: "'Daniel Berlin'" <dberlin@redhat.com>, Kevin Buettner <kevinb@cygnus.com>, Andrew Cagney <ac131313@cygnus.com>, GDB Discussion <gdb@sourceware.cygnus.com>, GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFA: Testsuite patches...
Date: Wed, 02 Aug 2000 11:11:00 -0000
Message-id: <39886458.CAC5D8EB@cygnus.com>
References: <309F4FC4705DC844987051A517E9E39B16EFE6@red-pt-02.redmond.corp.microsoft.com>
X-SW-Source: 2000-08/msg00042.html
Content-length: 1153

One thing that I have proposed once, just because of this problem, was to create
the KNOWN failures category.  This was to prevent abusing XFAIL that means that 
a test is expected to fail in a certain platform because of problems not related
to the tool being tested (a OS portability problem, bug, old OS version etc).

This category would also be used to link to the bug database (gnats?) so that 
by the tests results we could could compile a list of known issues and also so
that we could activate the tests after fixing the bug.

It was decided, at the time, that we should just XFAIL the tests and add 
appropriate comments telling that this was a known bug and mentioning the bug
database ticket (abusing XFAIL a little more IMO).

We can add the tests and mark them as XFAILs (with the appropriate comments).
This way we keep increasing the test base and still can use the number of failures
to check the result of changes etc.

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From msnyder@redhat.com Wed Aug 02 11:13:00 2000
From: Michael Snyder <msnyder@redhat.com>
To: Donn Terry <donnte@microsoft.com>
Cc: "'Daniel Berlin'" <dberlin@redhat.com>, Kevin Buettner <kevinb@cygnus.com>, Andrew Cagney <ac131313@cygnus.com>, GDB Discussion <gdb@sourceware.cygnus.com>, GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFA: Testsuite patches...
Date: Wed, 02 Aug 2000 11:13:00 -0000
Message-id: <398864C6.426E@redhat.com>
References: <309F4FC4705DC844987051A517E9E39B16EFE6@red-pt-02.redmond.corp.microsoft.com>
X-SW-Source: 2000-08/msg00043.html
Content-length: 4497

Donn Terry wrote:
> 
> One of the first rules of testing: don't discard useful tests.
> Thus, I agree that the tests should be added as they are generated.

We do not have to throw away the tests.
Convert them into problem reports.
That is how we traditionally keep track of problems.
We do not traditionally note a problem by adding
a test that will fail.  If we know of a problem, 
there is an established way to keep track of it.

Adding a test that will fail is a very annoying way
to ask someone to fix something, IMHO.


> 
> The problem ISN'T the tests, it's the apparent regression (and the
> work that that causes).  Blaming the tests is like blaming the messenger.
> Having been in the business of doing a new port over a protracted
> period (and of the whole toolchain) it has been a real pain for me
> to deal with this problem, but I would never, ever object to including
> a new (valid, of course) test.
> 
> In the gcc case there has been a database of "who failed what", which gives
> me a clue as to whether it's a new test that most systems don't pass (and
> I sould defer working on it to more immediate (for me) things) or something
> I should fix now.  It's the lack of THAT data that makes including the
> new tests painful.  (The gcc tool is less-than-perfect, but moving
> it to a central server would address the biggest of the problems.)
> 
> XFAIL is a very crude tool: it doesn't really say what "reasonable
> expectation" is for any given platform.  However, it's a help, but
> has often been abused.
> 
> Bright ideas on how to manage the problem of apparent regressions would
> be most useful.  Certainly educating the people who look at the
> regression results that because the set of regressions is growing,
> there will be continuous new failures would be useful.
> 
> (One bright idea: insist that the body of the test describe precisely
> what is being tested and why, the expectation of which systems should
> or should not pass (not in detail, but "RISCs probably will have trouble
> with this because..."), and a date(!!!) will make it much easier to
> make an informed judgement on a new failure.   Another: include date
> of addition in a place where the final report can say something like:
> "Tests younger than 30 days: nnn pass; mmm fail.
>  Tests younger than 90 days..."
> 
> (This makes it easier to show to some manager that it's new tests
> that are a problem.)
> 
> Donn
> 
> > -----Original Message-----
> > From: Daniel Berlin [ mailto:dberlin@redhat.com ]
> > Sent: Wednesday, August 02, 2000 9:45 AM
> > To: Kevin Buettner
> > Cc: Andrew Cagney; GDB Discussion; GDB Patches Mail List
> > Subject: Re: RFA: Testsuite patches...
> >
> >
> > Kevin Buettner <kevinb@cygnus.com> writes:
> >
> > > On Aug 2,  9:55pm, Andrew Cagney wrote:
> > >
> > > > I think GDB should be accepting tests (provided that they are
> > > > rigiously examined) even when they add failures - just as long as
> > > > the failures examine real bugs.  I think this also better reflects
> > > > what really goes on.
> > >
> > > I agree.
> > >
> > > If we make "no new failures" the criteria for whether a
> > test is added
> > > to the testsuite or not, then it seems to me that we'll end
> > up adding
> > > very few new tests just because it's so difficult for any one person
> > > to test on all affected targets.  (And it really doesn't work to
> > > post a patch and expect everyone affected to try it.)
> > >
> > > It makes sense to me to spread the workload by adding a
> > test and then
> > > expecting the various maintainers to make sure that the test passes
> > > (or gets suitably tweaked) for their targets.
> > >
> > > Kevin
> >
> > This seems like a better idea.
> >
> > In fact, I propose the following, or something like it:
> >
> > We accept all new tests people are willing to contribute, whether GDB
> > passes them or not, on any platform (assuming the test itself is
> > showing a problem with GDB, or something that should eventually work
> > in GDB, like say, virtual function calling).
> >
> > We have a seperate directory in the testsuite for tests that nobody
> > has any idea whether it will pass on all platforms or not, or whether
> > GDB can do that yet or not.
> >
> > That way, even if you XFAIL'd the test (so people didn't bitch about
> > the failures), at least I could look in that test results for
> > that directory when I wanted to know what should be
> > working, but isn't, etc.
> >
> > Or maybe i'm just babbling.
> > --Dan
> >
From guo@cup.hp.com Wed Aug 02 11:20:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: Kevin Buettner <kevinb@cygnus.com>, Andrew Cagney <ac131313@cygnus.com>, GDB Discussion <gdb@sourceware.cygnus.com>, GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFA: Testsuite patches...
Date: Wed, 02 Aug 2000 11:20:00 -0000
Message-id: <Pine.LNX.4.10.10008021058430.12072-100000@hpcll168.cup.hp.com>
References: <m31z07bojh.fsf@dan2.cygnus.com>
X-SW-Source: 2000-08/msg00044.html
Content-length: 1824

Just like to point out that with my latest patch to dejagnu relaxing
PRMS id pattern (which I will commit today), you can do something like:

setup_xfail "*-*-*" NOT_YET_SUPPORTED

This is the test point level control we can play with.  For brand-new
tests awaiting check-out on supported platforms, maybe a simple naming
convention with a starting _ would be effective enough.

In principle I agree we should relax the test acceptance criteria a bit,
but at the same time we need to consider the impact of high level of
FAILs to the ongoing development effort (at HP we have no FAILs in our
top-of-trunk and all XFAILs are explained by defect IDs, or something
like 'NOT_YET_SUPPORTED').  And I'm just suggesting a couple of ways to
let people interpret test outcomes selectively.

A new temporary staging test tree might be useful but I'm not sure how
that could complicate HP's multipass testing scheme where we selectively
run tests with different compilers / options based on test directories
-- unless you replicate the top level test tree under this staging tree.

- Jimmy

>Kevin Buettner <kevinb@cygnus.com> writes:
>
>In fact, I propose the following, or something like it:
>
>We accept all new tests people are willing to contribute, whether GDB
>passes them or not, on any platform (assuming the test itself is
>showing a problem with GDB, or something that should eventually work
>in GDB, like say, virtual function calling).
>
>We have a seperate directory in the testsuite for tests that nobody
>has any idea whether it will pass on all platforms or not, or whether
>GDB can do that yet or not.
>
>That way, even if you XFAIL'd the test (so people didn't bitch about
>the failures), at least I could look in that test results for that directory when I wanted to know what should be
>working, but isn't, etc.


^ permalink raw reply	[flat|nested] 6+ messages in thread
    end of thread, other threads:[~2000-08-02 10:59 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <39803B5C.9C31BB15@netwinder.org>
     [not found] ` <3980469B.E0BD7ED2@cygnus.com>
2000-07-27  8:11   ` RFA: Testsuite patches Scott Bambrough
2000-07-27 17:39   ` Andrew Cagney
2000-07-28 11:47 ` Fernando Nasser
2000-07-28 12:26   ` Scott Bambrough
2000-07-28 13:43     ` Fernando Nasser
2000-08-02 10:59 Donn Terry

    This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox