Re: [PATCH] dejagnu lib/framework.exp

Re: [PATCH] dejagnu lib/framework.exp

[Fernando Nasser]

Jimmy, your patch is correct.  Having it as global prevents someone to
mistakenly set it on the test file and calling pass from inside a proc
and causing it not to see it.

However, I am not aware of ay test that sets this (used to xfail depending
on compiler flags used).

And it is probably unrelated to your problem as well.

But please check this in so both pass and fail look the same.

Thanks.

Fernando



Jimmy Guo wrote:
> 
> After picking up updates during the past ~30 days, gdb testing
> sporadically issues UNRESOLVED messages for test points that look
> perfectly fine (and there's no usual error / warning messages
> accompanying these UNRESOLVED messages).
> 
> While I'm still scratching my head to root cause this annoyance, here is
> a patch to the only one of a tiny number of dejagnu updates that is
> questionable: compiler_conditional_xfail_data was made a global in
> 'proc fail' ... to be consistent 'proc pass' needs to do the same thing
> as well.  However I'm not sure if somehow this would fix my problem ...
> 
> Fri Jul 28 13:39:27     Jimmy Guo       <guo@cup.hp.com>
> 
>         * lib/framework.exp (pass): make compiler_conditional_xfail_data
>         a global, corresponding to a recent change to 'proc fail'.
> 
> Index: lib/framework.exp
> /usr/local/bin/diff -c -L lib/framework.exp lib/framework.exp@@/main/cygnus/5 lib/framework.exp
> *** lib/framework.exp
> --- lib/framework.exp   Fri Jul 28 13:38:25 2000
> ***************
> *** 672,685 ****
>   # Record that a test has passed
>   #
>   proc pass { message } {
> !     global xfail_flag
> 
>       # if we have a conditional xfail setup, then see if our compiler flags match
> !     if [uplevel {info exists compiler_conditional_xfail_data}] {
> !       if [uplevel {check_conditional_xfail $compiler_conditional_xfail_data}] {
>             set xfail_flag 1
>         }
> !       uplevel {unset compiler_conditional_xfail_data}
>       }
> 
>       if $xfail_flag {
> --- 672,685 ----
>   # Record that a test has passed
>   #
>   proc pass { message } {
> !     global xfail_flag compiler_conditional_xfail_data
> 
>       # if we have a conditional xfail setup, then see if our compiler flags match
> !     if [ info exists compiler_conditional_xfail_data ] {
> !       if [check_conditional_xfail $compiler_conditional_xfail_data] {
>             set xfail_flag 1
>         }
> !       unset compiler_conditional_xfail_data
>       }
> 
>       if $xfail_flag {

-- 
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 tonic@sequent.com Fri Jul 28 15:06:00 2000
From: "Brethour, Tanya (tonic)" <tonic@sequent.com>
To: "'gdb-patches@sourceware.cygnus.com'" <gdb-patches@sourceware.cygnus.com>
Subject: Threads Continue/Stop
Date: Fri, 28 Jul 2000 15:06:00 -0000
Message-id: <166E75C06F27D211B9860000C0AE13F50939634D@wembley.sequent.com>
X-SW-Source: 2000-07/msg00359.html
Content-length: 1935

Hello!

I found this on a web page.. so read it before you get to my questions:

--------------- http://www.lns.cornell.edu/public/COMP/info/gdb/gdb_7.html
Whenever your program stops under GDB for any reason, all threads of
execution stop, not just the current thread. This allows
you to examine the overall state of the program, including switching between
threads, without worrying that things may change
underfoot. 

   Conversely, whenever you restart the program, all threads start executing.
This is true even when single-stepping with
commands like step or next. 

In particular, GDB cannot single-step all threads in lockstep. Since thread
scheduling is up to your debugging target's operating
system (not controlled by GDB), other threads may execute more than one
statement while the current thread completes a single
step. Moreover, in general other threads stop in the middle of a statement,
rather than at a clean statement boundary, when the
program stops. 

You might even find your program stopped in another thread after continuing
or even single-stepping. This happens whenever some
other thread runs into a breakpoint, a signal, or an exception before the
first thread completes whatever you requested. 

--------------

Ok here are my questions:

1) Does the inferior_pid change to the current thread or to the thread that
hits either a break point or is created? (So for example.. if I get a
SIGNALLED wait event.. then I set inferior_pid to the thread that got a
signal? Or does inferior_pid never change and remains the first pid/thread id
that is created?)

2) When the target specific resume function is called, does -1 signal to
resume all threads? And if step is set, does that mean to step the
inferior_pid only and to resume all remaining threads?

3) Should a function be called in the child_wait target specific function
that stops ALL threads when ANY thread gets stopped?

Thanks for your help!
tanya
From ezannoni@cygnus.com Fri Jul 28 16:46:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: [PATCH] Fix double pseudoregs in LE targets
Date: Fri, 28 Jul 2000 16:46:00 -0000
Message-id: <14721.41935.973055.24649@kwikemart.cygnus.com>
X-SW-Source: 2000-07/msg00360.html
Content-length: 4084

FYI.
I have just checked this in.
See comment in patch.

Elena

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;

Re: [PATCH] dejagnu lib/framework.exp

[Jimmy Guo]

And here is my analysis of the UNRESOLVED message:

UNRESOLVED is printed if errcnt >= error_threshold (set at 1).
errcnt is reset after each test point.
delete_breakpoint can call perror _easily_ if pattern matching becomes
out of sync:
    Sometimes test codes might have something like:
	 send_gdb <command_string>
	 <continue on without matching for gdb response>
    The resulting gdb prompt will stay in the expect buffer and
    sometimes if GDB response is slow it starts a chain reaction of
    all following tests matching "$gdb_prompt $" ... sooner or later
    it reaches proc delete_breakpoint and that proc will happily
    issue an perror :(

    In other cases, delete_breakpoint would confuse itself with the
    tight loop of 'send_gdb "y\n"' and 'exp_continue'.

I'll patch up some of the tests, and will do some larger scale changes
in lib/gdb.exp to:
1) have more robust delete_breakpoint implementation.
2) capture and handle runto perrors (reset errcnt afterwards) instead of 
   spilling into the next test point.

I will find the time to refresh my memory on commiting the patch via CVS
(yes I have enough information on how to do this ...), and commit this
framework.exp patch.


- Jimmy


On Fri, 28 Jul 2000, Fernando Nasser wrote:

>Jimmy, your patch is correct.  Having it as global prevents someone to
>mistakenly set it on the test file and calling pass from inside a proc
>and causing it not to see it.
>
>However, I am not aware of ay test that sets this (used to xfail depending
>on compiler flags used).
>
>And it is probably unrelated to your problem as well.
>
>But please check this in so both pass and fail look the same.