From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Jimmy Guo Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] dejagnu lib/framework.exp Date: Fri, 28 Jul 2000 14:17:00 -0000 Message-id: <3981F6D9.F23429DE@cygnus.com> References: X-SW-Source: 2000-07/msg00358.html 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 > > * 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)" To: "'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 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 * 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;