* Re: RFA: Testsuite patches...
[not found] ` <3980469B.E0BD7ED2@cygnus.com>
@ 2000-07-27 8:11 ` Scott Bambrough
2000-07-27 17:39 ` Andrew Cagney
1 sibling, 0 replies; 6+ messages in thread
From: Scott Bambrough @ 2000-07-27 8:11 UTC (permalink / raw)
To: Fernando Nasser; +Cc: GDB Patches Mail List
> > 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.
> >
> > * gdb.base/sect-cmd.exp: Run tests for all targets. Use
> > 'section .text' clause for Linux in set section command
> > test.
> >
> > * gdb.base/so-impl-ld.exp: Added wildcard to
> > handle the gnu-oldld case on ARM.
> >
> > * gdb.base/so-indr-cl.exp: Run tests for *-*-linux-gnu*.
> > * gdb.base/watchpoint.exp (test_stepping): Clear xfail
> > for ARM targets.
> >
> > I've had these tests in my tree for quite a while now. Most were HP specific,
> > but I believe they are generic enough for all platforms, or
> > at least all Linux platforms. I've tested them on Linux on ARM and x86. I
> > suggest we add them in and deal with failures on specific targets as they
> > happen. Comments?
> >
Fernando Nasser wrote:
>
> Will *you* be willing to "deal" with the failures, and on a timely fashion?
I can try, but I don't see why I should have to. They are new tests for most
targets, previously most of these tests only ran on HP machines. I looked into
them to find out why they weren't running on my ARM Linux system. The ones
above I feel should run on all platforms, at least all Linux platforms. If they
fail the maintainer should look into the problem. If something like environ.exp
fails on all embedded type platforms, I can look into restricting it to Linux
only, but I think it should run on HPUX, Solaris, DOS, Windows etc. I don't
have access to all these platforms.
> > BTW, I had to tweak to linux-thread.c to get environ.exp to run
>
> I belive this touches someone else's mainainership as well.
Mark Kettenis and/or Jim Blandy should probably look at it.
Scott
--
Scott Bambrough - Software Engineer
REBEL.COM http://www.rebel.com
NetWinder http://www.netwinder.org
From brolley@redhat.com Thu Jul 27 09:59:00 2000
From: Dave Brolley <brolley@redhat.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH][RFA]: sim/common: Cpu Frequence and Exec Time
Date: Thu, 27 Jul 2000 09:59:00 -0000
Message-id: <39806B05.96F0DA12@redhat.com>
X-SW-Source: 2000-07/msg00336.html
Content-length: 1415
Hi,
The attached patch adds a field to the common cpu profiling
information which represents the clock frequency of the CPU. The
new field is PROFILE_CPU_FREQ and it can be set internally by the
simulator (intended to be used for the default setting) or by the
user via the new simulator command line option:
--profile-cpu-frequency=<frequency>
where <frequency> is an integer optionally followed by the suffix
mhz or khz or any non-ambiguous abbreviation. The suffix is not
case sensitive. Example:
--profile-cpu-frequency=400mhz
Simulators should override a frequency of 0 with the appropriate
default.
If the frequency has been set and profiling is enabled, then the
profile output will contain a calculation of the simulated
execution time based on the number of cycles executed and the
given frequency.
I'm seeking approval to commit this. This was added to on of our
simuators at the request of a customer, and I thought it would be
useful in general.
Dave
2000-07-27 Dave Brolley <brolley@redhat.com>
* sim-profile.h (PROFILE_DATA): Add cpu_freq.
(PROFILE_CPU_FREQ): New macro.
* sim-profile.c (OPTION_PROFILE_CPU_FREQUENCY): New enumerator.
(profile-options): Add profile-cpu-frequency.
(parse_frequency): New function.
(profile_option_handler): Handle OPTION_PROFILE_CPU_FREQUENCY.
(profile_print_speed): Print cpu frequency and simulated execution time.
Re-indent other items to match.
From msnyder@redhat.com Thu Jul 27 11:13:00 2000
From: Michael Snyder <msnyder@redhat.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb-patches@sources.redhat.com, jimb@cygnus.com
Subject: Re: [PING][RFA] Fall back on dynamic symtab in solib.c:bdf_lookup_symbol
Date: Thu, 27 Jul 2000 11:13:00 -0000
Message-id: <39807BB0.763D@redhat.com>
References: <200007270710.e6R7AjS00711@delius.kettenis.local>
X-SW-Source: 2000-07/msg00337.html
Content-length: 213
Mark Kettenis wrote:
>
> I'm still looking for approval of the following patch:
>
> http://sources.redhat.com/ml/gdb-patches/2000-05/msg00318.html
This looks perfectly safe to me, but I'm not the maintainer.
From msnyder@redhat.com Thu Jul 27 11:34:00 2000
From: Michael Snyder <msnyder@redhat.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFA: Testsuite patches...
Date: Thu, 27 Jul 2000 11:34:00 -0000
Message-id: <398080CA.13A5@redhat.com>
References: <39803B5C.9C31BB15@netwinder.org>
X-SW-Source: 2000-07/msg00338.html
Content-length: 2090
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.
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?
> 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.
>
> 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.
>
> * gdb.base/sect-cmd.exp: Run tests for all targets. Use
> 'section .text' clause for Linux in set section command
> test.
>
> * gdb.base/so-impl-ld.exp: Added wildcard to
> handle the gnu-oldld case on ARM.
>
> * gdb.base/so-indr-cl.exp: Run tests for *-*-linux-gnu*.
> * gdb.base/watchpoint.exp (test_stepping): Clear xfail
> for ARM targets.
>
> I've had these tests in my tree for quite a while now. Most were HP specific,
> but I believe they are generic enough for all platforms, or
> at least all Linux platforms. I've tested them on Linux on ARM and x86. I
> suggest we add them in and deal with failures on specific targets as they
> happen. Comments?
>
> BTW, I had to make the change to tweak to linux-thread.c to get environ.exp to
> run correctly. I changed this rather than the pattern to match in the test for
> fear of breaking the test on HP platforms.
>
> Scott
>
> --
> Scott Bambrough - Software Engineer
> REBEL.COM http://www.rebel.com
> NetWinder http://www.netwinder.org
>
> ---------------------------------------------------------------
>
> Name: gdbtest.patch
> Part 1.2 Type: application/x-unknown-content-type-patch_auto_file
> Encoding: base64
From msnyder@redhat.com Thu Jul 27 11:38:00 2000
From: Michael Snyder <msnyder@redhat.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: Fernando Nasser <fnasser@cygnus.com>, GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFA: Testsuite patches...
Date: Thu, 27 Jul 2000 11:38:00 -0000
Message-id: <39808189.579F@redhat.com>
References: <39803B5C.9C31BB15@netwinder.org> <3980469B.E0BD7ED2@cygnus.com> <39804FC2.764BCDCC@netwinder.org>
X-SW-Source: 2000-07/msg00339.html
Content-length: 1951
Scott Bambrough wrote:
>
> > > 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.
> > >
> > > * gdb.base/sect-cmd.exp: Run tests for all targets. Use
> > > 'section .text' clause for Linux in set section command
> > > test.
> > >
> > > * gdb.base/so-impl-ld.exp: Added wildcard to
> > > handle the gnu-oldld case on ARM.
> > >
> > > * gdb.base/so-indr-cl.exp: Run tests for *-*-linux-gnu*.
> > > * gdb.base/watchpoint.exp (test_stepping): Clear xfail
> > > for ARM targets.
> > >
> > > I've had these tests in my tree for quite a while now. Most were HP specific,
> > > but I believe they are generic enough for all platforms, or
> > > at least all Linux platforms. I've tested them on Linux on ARM and x86. I
> > > suggest we add them in and deal with failures on specific targets as they
> > > happen. Comments?
> > >
>
> Fernando Nasser wrote:
> >
> > Will *you* be willing to "deal" with the failures, and on a timely fashion?
>
> I can try, but I don't see why I should have to. They are new tests for most
> targets, previously most of these tests only ran on HP machines. I looked into
> them to find out why they weren't running on my ARM Linux system. The ones
> above I feel should run on all platforms, at least all Linux platforms. If they
> fail the maintainer should look into the problem. If something like environ.exp
> fails on all embedded type platforms, I can look into restricting it to Linux
> only, but I think it should run on HPUX, Solaris, DOS, Windows etc. I don't
> have access to all these platforms.
Then can you tell us more about the tests that you
think should run on them? And who you think should
do the work? We like to get problem reports about
problems, not tests that are not expected to pass.
From guo@cup.hp.com Thu Jul 27 17:26:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] gdb.java/configure.in
Date: Thu, 27 Jul 2000 17:26:00 -0000
Message-id: <Pine.LNX.4.10.10007271725050.2248-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-07/msg00340.html
Content-length: 1581
gdb.java/configure.in erroneously specified a nonexistent file javamisc.exp
as unique file.
- Jimmy
Thu Jul 27 17:23:22 Jimmy Guo <guo@cup.hp.com>
* gdb.java/configure.in: Use jmisc.exp as unique file.
* gdb.java/configure: Rebuilt.
Index: gdb.java/configure.in
/usr/local/bin/diff -c -w -L gdb.java/configure.in gdb.java/configure.in@@/main/cygnus/0 gdb.java/configure.in
*** gdb.java/configure.in
--- gdb.java/configure.in Thu Jul 27 17:21:23 2000
***************
*** 1,7 ****
dnl Process this file file with autoconf to produce a configure script.
AC_PREREQ(2.5)
! AC_INIT(javamisc.exp)
CC=${CC-cc}
AC_SUBST(CC)
--- 1,7 ----
dnl Process this file file with autoconf to produce a configure script.
AC_PREREQ(2.5)
! AC_INIT(jmisc.exp)
CC=${CC-cc}
AC_SUBST(CC)
Index: gdb.java/configure
/usr/local/bin/diff -c -w -L gdb.java/configure gdb.java/configure@@/main/cygnus/0 gdb.java/configure
*** gdb.java/configure
--- gdb.java/configure Thu Jul 27 17:22:21 2000
***************
*** 458,464 ****
# A filename unique to this package, relative to the directory that
# configure is in, which we can look for to find out if srcdir is correct.
! ac_unique_file=javamisc.exp
# Find the source files, if location was not specified.
if test -z "$srcdir"; then
--- 458,464 ----
# A filename unique to this package, relative to the directory that
# configure is in, which we can look for to find out if srcdir is correct.
! ac_unique_file=jmisc.exp
# Find the source files, if location was not specified.
if test -z "$srcdir"; then
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFA: Testsuite patches...
[not found] ` <3980469B.E0BD7ED2@cygnus.com>
2000-07-27 8:11 ` RFA: Testsuite patches Scott Bambrough
@ 2000-07-27 17:39 ` Andrew Cagney
1 sibling, 0 replies; 6+ messages in thread
From: Andrew Cagney @ 2000-07-27 17:39 UTC (permalink / raw)
To: Fernando Nasser, Scott Bambrough, Michael Snyder; +Cc: GDB Patches Mail List
Um, careful here.
I don't think the question to ask is ``who will fix the failures''.
Rather, I think people should be asking ``does the test check correct
functionality''?
If the test is correct and applicable to more than just HP then I think
it should be enabled. If it adds to the number of failures for certain
targets then ``oops'' :-) I'd assume the relevant maintainers would
simply append this to their list of known problems.
Perhaphs post something like a transcript (assuming they are not to
large) of each test so people can see them in action.
As a generalization, GDB desperatly needs more tests.
enjoy,
Andrew
From ac131313@cygnus.com Thu Jul 27 20:59:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Dave Brolley <brolley@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH][RFA]: sim/common: Cpu Frequence and Exec Time
Date: Thu, 27 Jul 2000 20:59:00 -0000
Message-id: <398104FD.8FB4ACBE@cygnus.com>
References: <39806B05.96F0DA12@redhat.com>
X-SW-Source: 2000-07/msg00342.html
Content-length: 270
Dave,
This doesn't compile on the mn10300 (PROFILE_MODEL_TOTAL_CYCLES is only
defined when WITH_PROFILE_MODEL_P). When making changes to sim/common,
it is a good idea to quickly re-compile (not test) a variant of each sim
so that this sort of thing shows up.
Andrew
From ac131313@cygnus.com Fri Jul 28 00:17:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [maint] target maintainers
Date: Fri, 28 Jul 2000 00:17:00 -0000
Message-id: <39813390.FD4535EF@cygnus.com>
X-SW-Source: 2000-07/msg00343.html
Content-length: 2188
Hello,
Appended is an updated target/architecture maintainer list. I've gone
through and listed everything (I could never remember what was where).
I'd also like to propose that any target that doesn't have an active
maintainer be identified as ``maintenance only''. All maintainers can
make mechanical changes to such targets (params, multi-arch, spelling,
indentation, -W....) - just as long as it still builds :-). A
non-mechanical change would be something that needs to be tested. Put
forward one of these and I'll make you the maintainer :-)
Wonder if this makes sense.
Andrew
Target/Architecture:
Generic ISA (Instruction Set Architecture) issues, API variants, CPU
variants. *-tdep.c. The Target/Architecture maintainer works with the
host maintainer when resolving build issues. The Target/Architecture
maintainer works with the native maintainer when resolving API issues.
a29k maintenance only
alpha maintenance only
arc maintenance only
arm Fernando Nasser fnasser@cygnus.com
Jim Ingham jingham@apple.com
Scott Bambrough scottb@netwinder.org
convex OBSOLETE
d10v Andrew Cagney cagney@cygnus.com
d30v David Taylor taylor@cygnus.com
djgpp (see native and host)
fr30 maintenance only
h8300 maintenance only
h8500 maintenance only
i386 Mark Kettenis kettenis@gnu.org
i960 maintenance only
ia64 Kevin Buettner kevinb@cygnus.com
m32r Michael Snyder msnyder@cygnus.com
m68hc11 maintenance only
m68k maintenance only
m88k maintenance only
mcore maintenance only
mips Andrew Cagney cagney@cygnus.com
mn10200 maintenance only
mn10300 Andrew Cagney cagney@cygnus.com
ns32k maintenance only
pa Jeff Law law@cygnus.com
powerpc Kevin Buettner kevinb@cygnus.com
Elena Zannoni ezannoni@cygnus.com
pyramid OBSOLETE
romp maintenance only
rs6000 maintenance only
sparc David Taylor taylor@cygnus.com
tahoe OBSOLETE
tic80 maintenance only
v850 maintenance only
vax maintenance only
w65 maintenance only
z8k maintenance only
All maintainers can make changes to OBSOLETE targets.
All maintainers can make maintenance changes to ``maintenance only''
targets.
From guo@cup.hp.com Fri Jul 28 10:17:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH 1 of 2] readline rl_prompt corruption fix
Date: Fri, 28 Jul 2000 10:17:00 -0000
Message-id: <Pine.LNX.4.10.10007281012060.7566-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-07/msg00344.html
Content-length: 4043
This is part 1 of 2 patches to fix readline rl_prompt string corruption
problem. This patch is for the readline library that readline will
store a copy of the passed in prompt string. The next patch is for
gdb/event-top.c to plug a mem leak due to this change.
- Jimmy
Fri Jul 28 09:58:55 Jimmy Guo <guo@cup.hp.com>
* readline.c: Initalize globals rl_initialized rl_prompt.
(readline): Use a copy of prompt instead of itself when
assigning to rl_prompt in readline ().
* callback.c (rl_callback_handler_install): Use a copy of
prompt instead of itself when assigning to rl_prompt.
* display.c: Initialize local_prompt and local_prompt_prefix.
Index: readline.c
/usr/local/bin/diff -c -w -L readline.c readline.c@@/main/cygnus/6 readline.c
*** readline.c
--- readline.c Fri Jul 28 09:57:29 2000
***************
*** 119,125 ****
int rl_arg_sign = 1;
/* Non-zero means we have been called at least once before. */
! static int rl_initialized;
/* If non-zero, this program is running in an EMACS buffer. */
static int running_in_emacs;
--- 119,125 ----
int rl_arg_sign = 1;
/* Non-zero means we have been called at least once before. */
! static int rl_initialized = 0;
/* If non-zero, this program is running in an EMACS buffer. */
static int running_in_emacs;
***************
*** 153,159 ****
int readline_echoing_p = 1;
/* Current prompt. */
! char *rl_prompt;
int rl_visible_prompt_length = 0;
/* Set to non-zero by calling application if it has already printed rl_prompt
--- 153,159 ----
int readline_echoing_p = 1;
/* Current prompt. */
! char *rl_prompt = NULL;
int rl_visible_prompt_length = 0;
/* Set to non-zero by calling application if it has already printed rl_prompt
***************
*** 251,257 ****
{
char *value;
! rl_prompt = prompt;
/* If we are at EOF return a NULL string. */
if (rl_pending_input == EOF)
--- 251,259 ----
{
char *value;
! if (rl_prompt)
! free (rl_prompt);
! rl_prompt = prompt ? strdup (prompt) : 0;
/* If we are at EOF return a NULL string. */
if (rl_pending_input == EOF)
***************
*** 260,266 ****
return ((char *)NULL);
}
! rl_visible_prompt_length = rl_expand_prompt (rl_prompt);
rl_initialize ();
(*rl_prep_term_function) (_rl_meta_flag);
--- 262,269 ----
return ((char *)NULL);
}
! rl_visible_prompt_length = (rl_prompt && *rl_prompt) ?
! rl_expand_prompt (rl_prompt) : 0;
rl_initialize ();
(*rl_prep_term_function) (_rl_meta_flag);
Index: callback.c
/usr/local/bin/diff -c -w -L callback.c callback.c@@/main/cygnus/2 callback.c
*** callback.c
--- callback.c Fri Jul 28 09:55:11 2000
***************
*** 81,88 ****
char *prompt;
VFunction *linefunc;
{
! rl_prompt = prompt;
! rl_visible_prompt_length = rl_prompt ? rl_expand_prompt (rl_prompt) : 0;
rl_linefunc = linefunc;
_rl_callback_newline ();
}
--- 81,91 ----
char *prompt;
VFunction *linefunc;
{
! if (rl_prompt)
! free (rl_prompt);
! rl_prompt = prompt ? strdup (prompt) : 0;
! rl_visible_prompt_length = (rl_prompt && *rl_prompt) ?
! rl_expand_prompt (rl_prompt) : 0;
rl_linefunc = linefunc;
_rl_callback_newline ();
}
Index: display.c
/usr/local/bin/diff -c -w -L display.c display.c@@/main/cygnus/7 display.c
*** display.c
--- display.c Fri Jul 28 09:56:05 2000
***************
*** 146,152 ****
/* Default and initial buffer size. Can grow. */
static int line_size = 1024;
! static char *local_prompt, *local_prompt_prefix;
static int visible_length, prefix_length;
/* The number of invisible characters in the line currently being
--- 146,152 ----
/* Default and initial buffer size. Can grow. */
static int line_size = 1024;
! static char *local_prompt = NULL, *local_prompt_prefix = NULL;
static int visible_length, prefix_length;
/* The number of invisible characters in the line currently being
^ permalink raw reply [flat|nested] 6+ messages in thread
* 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-07-28 11:47 ` Fernando Nasser
@ 2000-07-28 12:26 ` Scott Bambrough
2000-07-28 13:43 ` Fernando Nasser
0 siblings, 1 reply; 6+ messages in thread
From: Scott Bambrough @ 2000-07-28 12:26 UTC (permalink / raw)
To: Fernando Nasser; +Cc: GDB Patches Mail List
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 16675 bytes --]
Fernando Nasser wrote:
>
> > 2000-07-26 Scott Bambrough <scottb@netwinder.org>
> > * gdb.base/environ.exp: Run tests for all targets.
> >
> > 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.
These two need to go hand in hand, otherwise we get failures in environ.exp. I
sent a response to Michael Snyder's comments about this to him yesterday. I
just realized it didn't go to the list; so I forwarded it to the list as well.
I will wait to check these in until I hear about the change in linux-thread.c.
I'm also been thinking that maybe I shouldn't enable this for all targets, the
show/set/unset environment commands may fail on embedded targets. They should
work fine on any target that has an environment. The info program tests should
work on all targets. Maybe this test should be split up? Comments?
> > * gdb.base/sect-cmd.exp: Run tests for all targets. Use
> > 'section .text' clause for Linux in set section command
> > test.
> > * gdb.base/so-indr-cl.exp: Run tests for *-*-linux-gnu*.
I'll withdraw these, fix them up and resubmit them for approval.
> > 2000-07-26 Scott Bambrough <scottb@netwinder.org>
> >
> > * gdb.base/recurse.exp: Run tests for all targets.
> > * gdb.base/so-impl-ld.exp: Added wildcard to
> > handle the gnu-oldld case on ARM.
> > * gdb.base/watchpoint.exp (test_stepping): Clear xfail
> > for ARM targets.
I will apply these today.
Scott
--
Scott Bambrough - Software Engineer
REBEL.COM http://www.rebel.com
NetWinder http://www.netwinder.org
From ezannoni@cygnus.com Fri Jul 28 12:26:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] Multiarch DO_REGISTERS_INFO
Date: Fri, 28 Jul 2000 12:26:00 -0000
Message-id: <14721.56903.448617.375558@kwikemart.cygnus.com>
X-SW-Source: 2000-07/msg00349.html
Content-length: 5215
OK to commit?
2000-07-28 Elena Zannoni <ezannoni@kwikemart.cygnus.com>
* gdbarch.sh: Multiarch DO_REGISTERS_INFO macro.
* gdbarch.h, gdbarch.c: Regenerate.
Index: gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.32
diff -c -u -p -r1.32 gdbarch.sh
cvs server: conflicting specifications of output style
--- gdbarch.sh 2000/07/27 04:01:24 1.32
+++ gdbarch.sh 2000/07/28 19:24:14
@@ -314,6 +314,7 @@ v:2:MAX_REGISTER_RAW_SIZE:int:max_regist
f:2:REGISTER_VIRTUAL_SIZE:int:register_virtual_size:int reg_nr:reg_nr::0:0
v:2:MAX_REGISTER_VIRTUAL_SIZE:int:max_register_virtual_size::::0:-1
f:2:REGISTER_VIRTUAL_TYPE:struct type *:register_virtual_type:int reg_nr:reg_nr::0:0
+f:2:DO_REGISTERS_INFO:void:do_registers_info:int reg_nr, int fpregs:reg_nr, fpregs::0:0
#
v:1:USE_GENERIC_DUMMY_FRAMES:int:use_generic_dummy_frames::::0:-1
v:2:CALL_DUMMY_LOCATION:int:call_dummy_location::::0:0
Index: gdbarch.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.h,v
retrieving revision 1.26
diff -c -u -r1.26 gdbarch.h
cvs server: conflicting specifications of output style
--- gdbarch.h 2000/07/27 04:01:24 1.26
+++ gdbarch.h 2000/07/28 19:24:42
@@ -389,6 +389,15 @@
#endif
#endif
+typedef void (gdbarch_do_registers_info_ftype) (int reg_nr, int fpregs);
+extern void gdbarch_do_registers_info (struct gdbarch *gdbarch, int reg_nr, int fpregs);
+extern void set_gdbarch_do_registers_info (struct gdbarch *gdbarch, gdbarch_do_registers_info_ftype *do_registers_info);
+#if GDB_MULTI_ARCH
+#if (GDB_MULTI_ARCH > 1) || !defined (DO_REGISTERS_INFO)
+#define DO_REGISTERS_INFO(reg_nr, fpregs) (gdbarch_do_registers_info (current_gdbarch, reg_nr, fpregs))
+#endif
+#endif
+
extern int gdbarch_use_generic_dummy_frames (struct gdbarch *gdbarch);
extern void set_gdbarch_use_generic_dummy_frames (struct gdbarch *gdbarch, int use_generic_dummy_frames);
#if GDB_MULTI_ARCH
Index: gdbarch.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.c,v
retrieving revision 1.32
diff -c -u -r1.32 gdbarch.c
cvs server: conflicting specifications of output style
--- gdbarch.c 2000/07/27 04:01:24 1.32
+++ gdbarch.c 2000/07/28 19:25:02
@@ -161,6 +161,7 @@
gdbarch_register_virtual_size_ftype *register_virtual_size;
int max_register_virtual_size;
gdbarch_register_virtual_type_ftype *register_virtual_type;
+ gdbarch_do_registers_info_ftype *do_registers_info;
int use_generic_dummy_frames;
int call_dummy_location;
gdbarch_call_dummy_address_ftype *call_dummy_address;
@@ -296,6 +297,7 @@
0,
0,
0,
+ 0,
generic_get_saved_register,
0,
0,
@@ -523,6 +525,9 @@
if ((GDB_MULTI_ARCH >= 2)
&& (gdbarch->register_virtual_type == 0))
internal_error ("gdbarch: verify_gdbarch: register_virtual_type invalid");
+ if ((GDB_MULTI_ARCH >= 2)
+ && (gdbarch->do_registers_info == 0))
+ internal_error ("gdbarch: verify_gdbarch: do_registers_info invalid");
if ((GDB_MULTI_ARCH >= 1)
&& (gdbarch->use_generic_dummy_frames == -1))
internal_error ("gdbarch: verify_gdbarch: use_generic_dummy_frames invalid");
@@ -869,6 +874,13 @@
"REGISTER_VIRTUAL_TYPE(reg_nr)",
XSTRING (REGISTER_VIRTUAL_TYPE (reg_nr)));
#endif
+#if defined (DO_REGISTERS_INFO) && GDB_MULTI_ARCH
+ /* Macro might contain `[{}]' when not multi-arch */
+ fprintf_unfiltered (file,
+ "gdbarch_dump: %s # %s\n",
+ "DO_REGISTERS_INFO(reg_nr, fpregs)",
+ XSTRING (DO_REGISTERS_INFO (reg_nr, fpregs)));
+#endif
#ifdef USE_GENERIC_DUMMY_FRAMES
fprintf_unfiltered (file,
"gdbarch_dump: USE_GENERIC_DUMMY_FRAMES # %s\n",
@@ -1466,6 +1478,13 @@
(long) current_gdbarch->register_virtual_type
/*REGISTER_VIRTUAL_TYPE ()*/);
#endif
+#ifdef DO_REGISTERS_INFO
+ if (GDB_MULTI_ARCH)
+ fprintf_unfiltered (file,
+ "gdbarch_dump: DO_REGISTERS_INFO = 0x%08lx\n",
+ (long) current_gdbarch->do_registers_info
+ /*DO_REGISTERS_INFO ()*/);
+#endif
#ifdef USE_GENERIC_DUMMY_FRAMES
fprintf_unfiltered (file,
"gdbarch_dump: USE_GENERIC_DUMMY_FRAMES = %ld\n",
@@ -2481,6 +2500,23 @@
gdbarch_register_virtual_type_ftype register_virtual_type)
{
gdbarch->register_virtual_type = register_virtual_type;
+}
+
+void
+gdbarch_do_registers_info (struct gdbarch *gdbarch, int reg_nr, int fpregs)
+{
+ if (gdbarch->do_registers_info == 0)
+ internal_error ("gdbarch: gdbarch_do_registers_info invalid");
+ if (gdbarch_debug >= 2)
+ fprintf_unfiltered (gdb_stdlog, "gdbarch_do_registers_info called\n");
+ gdbarch->do_registers_info (reg_nr, fpregs);
+}
+
+void
+set_gdbarch_do_registers_info (struct gdbarch *gdbarch,
+ gdbarch_do_registers_info_ftype do_registers_info)
+{
+ gdbarch->do_registers_info = do_registers_info;
}
int
From Stephane.Carrez@worldnet.fr Fri Jul 28 12:46:00 2000
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Stephane Carrez <Stephane.Carrez@free.fr>, gdb-patches@sourceware.cygnus.com
Subject: Re: [Patch 6/7]: 68HC11 port of gdb (sim-misc single step fix)
Date: Fri, 28 Jul 2000 12:46:00 -0000
Message-id: <3982002E.1F34EFF9@worldnet.fr>
References: <39568A82.A0B2BFEB@free.fr> <3980227F.A6FC263B@cygnus.com>
X-SW-Source: 2000-07/msg00353.html
Content-length: 4102
Hi!
Andrew Cagney a écrit :
>
> Stephane Carrez wrote:
>
> > 2000-06-25 Stephane Carrez <Stephane.Carrez@worldnet.fr>
> >
> > * nrun.c (main): Print the simulator statistics only in
> > verbose mode.
> > * hw-properties.h (hw_find_integer_array_property): Fix
> > prototype (use signed_cell).
>
> I've committed these, thanks.
>
> > * sim-resume.c (sim_resume): Install the single step event
> > after having processed some current pending events. It may happen
> > that some ticks are not yet processed after a break/single step
> > command from GDB. In that case, installing the single step event
> > before processing pending events will activate the single step
> > without actually having executed any instruction.
>
> I don't think this is right. When the simulator does a restart, a
> second has_stepped event would be scheduled and the first would be lost.
>
Yes but I have another problem.
For my simulator, the number of ticks is advanced at each instruction by
the number of cycles the instruction takes. I have instructions that
can take 4 cycles up to 70 cycles. [I'm doing this to keep the simulator
behavior as close as possible to reality. The timer and all other devices
are in sync with the cpu.]
After each instruction the number of ticks is incremented with 'sim_events_tickn'
by the number of cycles the instruction took. Sometimes all the ticks are
taken into account, and sometimes some of them are saved in 'nr_ticks_to_process'.
If this happens we process a pending event. Such event stops the simulator
(for example because it was a single step). So, at that point,
nr_ticks_to_process != 0.
Now, next time I enter in 'sim_resume', we schedule a single step event for
tick 1. In general this is the next one. We then call 'sim_events_preprocess'.
Here we rememeber that we have some 'nr_ticks_to_process' and
we process them. Since the single step event is next (because at T+1),
it is processed and we stop the simulator (before having restarted it!!).
The fix I suggest consists in installing the single step event after we
have processed the pending ticks in 'nr_ticks_to_process'. By doing so,
the pending ticks in 'nr_ticks_to_process' don't break the single step.
> Andrew
>
> > diff -Nrup --exclude-from=gdb-exclude.lst /src/gnu/cygnus/gdb/sim/common/sim-resume.c gdb/sim/common/sim-resume.c
> > --- /src/gnu/cygnus/gdb/sim/common/sim-resume.c Mon Jul 12 13:14:09 1999
> > +++ gdb/sim/common/sim-resume.c Mon Feb 21 09:00:23 2000
> > @@ -51,8 +51,6 @@ sim_resume (SIM_DESC sd,
> > sim_events_deschedule (sd, engine->stepper);
> > engine->stepper = NULL;
> > }
> > - if (step)
> > - engine->stepper = sim_events_schedule (sd, 1, has_stepped, sd);
> >
> > sim_module_resume (sd);
> >
> > @@ -69,6 +67,9 @@ sim_resume (SIM_DESC sd,
> > sim_events_preprocess (sd, last_cpu_nr >= nr_cpus, next_cpu_nr >= nr_cpus);
> > if (next_cpu_nr >= nr_cpus)
> > next_cpu_nr = 0;
> > +
> > + if (step)
> > + engine->stepper = sim_events_schedule (sd, 1, has_stepped, sd);
> >
> > /* Only deliver the siggnal ]sic] the first time through - don't
> > re-deliver any siggnal during a restart. */
>
> Note the comment about siggnals[sic].
>
> Andrew
ssignal does not seem to be ever used. It seemed to be ignored in most
simulators (and in sim_engine_run).
I don't reach that point anyway when the problem occurs. I don't return
from 'sim_events_preprocess' because it calls 'sim_engine_halt' that longjumps
to return (due to single step event we just scheduled).
Stephane
-----------------------------------------------------------------------
Home Office
E-mail: stcarrez@worldnet.fr Stephane.Carrez@sun.com
WWW: http://home.worldnet.fr/stcarrez http://www.sun.com
Mail: 17, rue Foucher Lepelletier 6, avenue Gustave Eiffel
92130 Issy Les Moulineaux 78182 Saint Quentin en Yvelines
France
From Stephane.Carrez@worldnet.fr Fri Jul 28 12:46:00 2000
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [maint] target maintainers
Date: Fri, 28 Jul 2000 12:46:00 -0000
Message-id: <39820022.79D89624@worldnet.fr>
References: <39813390.FD4535EF@cygnus.com>
X-SW-Source: 2000-07/msg00352.html
Content-length: 548
Hi!
Andrew Cagney a écrit :
> [...]
>
> m68hc11 maintenance only
I can be the maintainer of that platform.
Stephane
-----------------------------------------------------------------------
Home Office
E-mail: stcarrez@worldnet.fr Stephane.Carrez@sun.com
WWW: http://home.worldnet.fr/stcarrez http://www.sun.com
Mail: 17, rue Foucher Lepelletier 6, avenue Gustave Eiffel
92130 Issy Les Moulineaux 78182 Saint Quentin en Yvelines
France
From Stephane.Carrez@worldnet.fr Fri Jul 28 12:46:00 2000
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Stephane Carrez <Stephane.Carrez@free.fr>, gdb-patches@sourceware.cygnus.com
Subject: Re: [Patch 5/7]: 68HC11 port of gdb (sim-overlap address maps)
Date: Fri, 28 Jul 2000 12:46:00 -0000
Message-id: <3982000B.B590C544@worldnet.fr>
References: <39568A64.830EC800@free.fr> <39802053.B4BCAD4E@cygnus.com>
X-SW-Source: 2000-07/msg00351.html
Content-length: 1573
Hi!
Thanks a lot for integration of the patches!
Andrew Cagney a écrit :
>
> Stephane Carrez wrote:
> >
> > Hi!
> >
> > The following patch adds the support to overlap some address spaces.
> > I need this for 68hc11 because the IO is mapped over the normal memory.
> > The internal RAM is mapped in the same way. Both may be moved at any
> > 4K boundary. The EEPROM can be unmapped, showing up what is underneath it.
> >
> > Each device has an overlap flag that tells whether overlapping is
> > allowed or not. The default is to disable that. This is the current
> > behavior.
> >
> > When overlapping is allowed, we just record the mapping rather than
> > rejecting it.
>
> I'm not sure I understand the change. The memory model has the idea of
> layers. Overlapping memory can normally be handled by that. The memory
> would be set up as:
>
> first layer: eeprom
> second layer: memory
>
> is this in addition to the layers?
>
> Andrew
Ok. I didn't understand the role of the level. It's not easy to guess that...:-)
If what I understand now is right, I should be able to do the overlapping I need.
Thanks,
Stephane
-----------------------------------------------------------------------
Home Office
E-mail: stcarrez@worldnet.fr Stephane.Carrez@sun.com
WWW: http://home.worldnet.fr/stcarrez http://www.sun.com
Mail: 17, rue Foucher Lepelletier 6, avenue Gustave Eiffel
92130 Issy Les Moulineaux 78182 Saint Quentin en Yvelines
France
From guo@cup.hp.com Fri Jul 28 13:07:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] gdbarch.c(gdbarch_dump)
Date: Fri, 28 Jul 2000 13:07:00 -0000
Message-id: <Pine.LNX.4.10.10007281305390.8159-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-07/msg00354.html
Content-length: 1243
This patch is to prevent sizeof.exp 'maint print arch' to trigger
gdb_internal_error (). inferior.h defines default to be the
gdb_internal_error () call.
Fri Jul 28 13:01:35 Jimmy Guo <guo@cup.hp.com>
* gdbarch.c (gdbarch_dump): dump CALL_DUMMY_BREAKPOINT_OFFSET value
only if CALL_DUMMY_BREAKPOINT_OFFSET_P.
Index: gdbarch.c
/usr/local/bin/diff -c -L gdbarch.c gdbarch.c@@/main/_guo_unified_merge/7 gdbarch.c
*** gdbarch.c
--- gdbarch.c Fri Jul 28 12:51:17 2000
***************
*** 1456,1464 ****
(long) CALL_DUMMY_START_OFFSET);
#endif
#ifdef CALL_DUMMY_BREAKPOINT_OFFSET
! fprintf_unfiltered (file,
! "gdbarch_dump: CALL_DUMMY_BREAKPOINT_OFFSET = 0x%08lx\n",
! (long) CALL_DUMMY_BREAKPOINT_OFFSET);
#endif
#ifdef CALL_DUMMY_BREAKPOINT_OFFSET_P
fprintf_unfiltered (file,
--- 1456,1465 ----
(long) CALL_DUMMY_START_OFFSET);
#endif
#ifdef CALL_DUMMY_BREAKPOINT_OFFSET
! if (CALL_DUMMY_BREAKPOINT_OFFSET_P)
! fprintf_unfiltered (file,
! "gdbarch_dump: CALL_DUMMY_BREAKPOINT_OFFSET = 0x%08lx\n",
! (long) CALL_DUMMY_BREAKPOINT_OFFSET);
#endif
#ifdef CALL_DUMMY_BREAKPOINT_OFFSET_P
fprintf_unfiltered (file,
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFA: Testsuite patches...
2000-07-28 12:26 ` Scott Bambrough
@ 2000-07-28 13:43 ` Fernando Nasser
0 siblings, 0 replies; 6+ messages in thread
From: Fernando Nasser @ 2000-07-28 13:43 UTC (permalink / raw)
To: Scott Bambrough; +Cc: GDB Patches Mail List
Scott Bambrough wrote:
>
> Fernando Nasser wrote:
> >
> > > 2000-07-26 Scott Bambrough <scottb@netwinder.org>
> > > * gdb.base/environ.exp: Run tests for all targets.
> > >
> > > 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.
>
> These two need to go hand in hand, otherwise we get failures in environ.exp. I
> sent a response to Michael Snyder's comments about this to him yesterday. I
> just realized it didn't go to the list; so I forwarded it to the list as well.
> I will wait to check these in until I hear about the change in linux-thread.c.
> I'm also been thinking that maybe I shouldn't enable this for all targets, the
> show/set/unset environment commands may fail on embedded targets. They should
> work fine on any target that has an environment. The info program tests should
> work on all targets. Maybe this test should be split up? Comments?
>
Good point. You can activate it just for native targets.
if [is_remote target]
skip the tests.
--
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 guo@cup.hp.com Fri Jul 28 13:49:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] dejagnu lib/framework.exp
Date: Fri, 28 Jul 2000 13:49:00 -0000
Message-id: <Pine.LNX.4.10.10007281341530.8492-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-07/msg00357.html
Content-length: 1879
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 {
^ 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