gdb.gdb/ testcase issues.

gdb.gdb/ testcase issues.

[Manoj Iyer]

The testcase under gdb.gdb will work only for gdb that is not stripped.
This is because in the testcases breakpoints are being set on static
functions in gdb, and when gdb is stripped these functions are gone from
the symbol table. Is there any real reason for setting breakpoints on such
fucntions? If not I will be happy to provide a patch that fixes this
problem.

Thanks
-----
manjo
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Cognito ergo sum                                                          +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Re: gdb.gdb/ testcase issues.

[Michael Chastain]

Hi Manoj,

First thing ... do you have a copyright assignment on file
for gdb?

> Is there any real reason for setting breakpoints on such fucntions?
> If not I will be happy to provide a patch that fixes this problem.

I don't know any reason, but I haven't looked yet.

The counter-question is: why are you running gdb.gdb tests on a stripped
gdb executable?  Other parts of selftest.exp depend on stepping one
source line at a time, which won't work with a stripped executable.

Michael

Re: gdb.gdb/ testcase issues.

[Manoj Iyer]

> First thing ... do you have a copyright assignment on file
> for gdb?

Will get back to you on that.

>
> > Is there any real reason for setting breakpoints on such fucntions?
> > If not I will be happy to provide a patch that fixes this problem.
>
> I don't know any reason, but I haven't looked yet.
>
> The counter-question is: why are you running gdb.gdb tests on a stripped
> gdb executable?  Other parts of selftest.exp depend on stepping one
> source line at a time, which won't work with a stripped executable.
>

The reason is, the GDB that is shipped in a distro is stripped, and I used
the --tool_exec= option to use this GDB that is installed in /usr/bin. So
my understanding so far is that the testcases under gdb.gdb are to be used
only for a GDB that is build fresh from sources and not that is installed
on the system. If that is the case then they need to be modified in such a
way that they report that "the testcase does not support stripped gdb --
unsupported" or something of that nature. Is that ok?

--
Manoj Iyer

Re: gdb.gdb/ testcase issues.

[Michael Chastain]

Manoj Iyer <manjo@austin.ibm.com> wrote:
> Will get back to you on that.

Okay.  I can't accept any patches larger than trivial without
a copyright assignment, though.

> The reason is, the GDB that is shipped in a distro is stripped, and I used
> the --tool_exec= option to use this GDB that is installed in /usr/bin.

Ah, that is a valid use case for testing a stripped gdb.

First it would help to file a PR to track this issue.

It would be nice to have some common code for this.

Three of the four test scripts in gdb.gdb have their own 'setup_test',
and the fourth script has another copy of the same code.  I would like
to see the common code factored into one place, lib/self-support.exp.

Then setup_test calls gdb_load which calls gdb_file_cmd.  You could get
into gdb_file_cmd and detect "(no debugging symbols found)" and add a
channel to return that information.  Or, in setup_test, you could
do something right after the call to gdb_load to check for debugging
symbols.

If there are no debugging symbols, then I think that the test script
should return one UNRESOLVED result and not continue testing.

I'm not sure UNRESOLVED is the right result.  Perhaps UNTESTED would
be better.  But not UNSUPPORTED -- UNSUPPORTED means that a feature
is missing in the system under test.

Michael

[RFC] GDB testsuite patch.

[Manoj Iyer]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4264 bytes --]


Hi all,

Here is a patch to gdb/lib/gdb.exp, this patch handles the case when the
GDB that is tested is stripped and has no debugging information.

I have created this patch according to Michael's recomendations (see
below).

I tested this with gdb.gdb/complaints.exp and below are the new output.

New output on screen
----------------
======================= start paste ========================
Running target unix/-m32
Using ./dejagnu/baseboards/unix.exp as board description file for target.
Using ./dejagnu/config/unix.exp as generic interface file for target.
Using ./config/unix.exp as tool-and-target-specific interface file.
Running ./gdb.gdb/complaints.exp ...

                === gdb Summary ===

# of untested testcases         1
/usr/bin/gdb version  6.1 -nx

0

======================= end paste ======================

New output to gdb.log
-----------------
================== start paste ========================
Running target unix/-m32
Using ./dejagnu/baseboards/unix.exp as board description file for target.
Using ./dejagnu/config/unix.exp as generic interface file for target.
Using ./config/unix.exp as tool-and-target-specific interface file.
Running ./gdb.gdb/complaints.exp ...
GNU gdb 6.1^M
Copyright 2004 Free Software Foundation, Inc.^M
GDB is free software, covered by the GNU General Public License, and you
are^M
welcome to change it and/or distribute copies of it under certain
conditions.^M
Type "show copying" to see the conditions.^M
There is absolutely no warranty for GDB.  Type "show warranty" for
details.^M
This GDB was configured as "ppc-suse-linux".^M
(gdb) set height 0^M
(gdb) set width 0^M
(gdb) file xgdb^M
Reading symbols from xgdb...(no debugging symbols found)...done.^M
Using host libthread_db library "/lib/tls/libthread_db.so.1".^M
(gdb) UNTESTED: gdb.gdb/complaints.exp: skip tests no debugging
information found.
testcase ./gdb.gdb/complaints.exp completed in 0 seconds

                === gdb Summary ===

# of untested testcases         1
Executing on host: /usr/bin/gdb -nw --command gdb_cmd    (timeout = 300)
GNU gdb 6.1^M
Copyright 2004 Free Software Foundation, Inc.^M
GDB is free software, covered by the GNU General Public License, and you
are^M
welcome to change it and/or distribute copies of it under certain
conditions.^M
Type "show copying" to see the conditions.^M
There is absolutely no warranty for GDB.  Type "show warranty" for
details.^M
This GDB was configured as "ppc-suse-linux".^M
/usr/bin/gdb version  6.1 -nx

runtest completed at Tue Aug 24 18:23:46 2004

========================= end paste =================================

-----
Manjo
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Cognito ergo sum                                                          +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

On Fri, 20 Aug 2004, Michael Chastain wrote:

> Manoj Iyer <manjo@austin.ibm.com> wrote:
> > Will get back to you on that.
>
> Okay.  I can't accept any patches larger than trivial without
> a copyright assignment, though.
>
> > The reason is, the GDB that is shipped in a distro is stripped, and I used
> > the --tool_exec= option to use this GDB that is installed in /usr/bin.
>
> Ah, that is a valid use case for testing a stripped gdb.
>
> First it would help to file a PR to track this issue.
>
> It would be nice to have some common code for this.
>
> Three of the four test scripts in gdb.gdb have their own 'setup_test',
> and the fourth script has another copy of the same code.  I would like
> to see the common code factored into one place, lib/self-support.exp.
>
> Then setup_test calls gdb_load which calls gdb_file_cmd.  You could get
> into gdb_file_cmd and detect "(no debugging symbols found)" and add a
> channel to return that information.  Or, in setup_test, you could
> do something right after the call to gdb_load to check for debugging
> symbols.
>
> If there are no debugging symbols, then I think that the test script
> should return one UNRESOLVED result and not continue testing.
>
> I'm not sure UNRESOLVED is the right result.  Perhaps UNTESTED would
> be better.  But not UNSUPPORTED -- UNSUPPORTED means that a feature
> is missing in the system under test.
>
> Michael
>

[-- Attachment #2: GDB testsuite patch --]
[-- Type: TEXT/PLAIN, Size: 599 bytes --]

diff -Naur ./old/src/gdb/testsuite/lib/gdb.exp ./new/src/gdb/testsuite/lib/gdb.exp
--- ./old/src/gdb/testsuite/lib/gdb.exp	2004-08-24 18:16:00.892190792 -0500
+++ ./new/src/gdb/testsuite/lib/gdb.exp	2004-08-24 18:16:49.542249312 -0500
@@ -975,6 +975,10 @@
 
     send_gdb "file $arg\n"
     gdb_expect 120 {
+	-re "Reading symbols from.*no debugging symbols found.* $" {
+	    untested "skip tests no debugging information found."
+	    return -1
+	}
         -re "Reading symbols from.*done.*$gdb_prompt $" {
             verbose "\t\tLoaded $arg into the $GDB"
             return 0

Re: [RFC] GDB testsuite patch.

[Daniel Jacobowitz]

On Tue, Aug 24, 2004 at 11:29:12PM -0500, Manoj Iyer wrote:
> 
> Hi all,
> 
> Here is a patch to gdb/lib/gdb.exp, this patch handles the case when the
> GDB that is tested is stripped and has no debugging information.
> 
> I have created this patch according to Michael's recomendations (see
> below).

Michael wrote:

> > Three of the four test scripts in gdb.gdb have their own 'setup_test',
> > and the fourth script has another copy of the same code.  I would like
> > to see the common code factored into one place, lib/self-support.exp.
> >
> > Then setup_test calls gdb_load which calls gdb_file_cmd.  You could get
> > into gdb_file_cmd and detect "(no debugging symbols found)" and add a
> > channel to return that information.  Or, in setup_test, you could
> > do something right after the call to gdb_load to check for debugging
> > symbols.
> >
> > If there are no debugging symbols, then I think that the test script
> > should return one UNRESOLVED result and not continue testing.
> >
> > I'm not sure UNRESOLVED is the right result.  Perhaps UNTESTED would
> > be better.  But not UNSUPPORTED -- UNSUPPORTED means that a feature
> > is missing in the system under test.

That's not the same as what you've done.  gdb_file_cmd should not
always fail for objects without debugging information, since there are
other tests that work OK without it.  This only applies to the gdb.gdb/
tests.

-- 
Daniel Jacobowitz

Re: [RFC] GDB testsuite patch.

[Michael Chastain]

Daniel Jacobowitz <drow@false.org> wrote:
> That's not the same as what you've done.  gdb_file_cmd should not
> always fail for objects without debugging information, since there are
> other tests that work OK without it.  This only applies to the gdb.gdb/
> tests.

Damn, I noticed this, but I got so caught up in the procedural criticism,
I forgot to mention it.

Daniel is right; gdb_file_cmd is not a good place to test for this
unconditionally.  You have to look in gdb.gdb/*.exp and find a good
way so that you make this check only for gdb.gdb/*.exp.

Michael

Re: [RFC] GDB testsuite patch.

[Michael Chastain]

Good morning Manoj,

This design is okay but the implementation needs some more work.
Here's a whole bunch of comments.  Please re-work your patch and
re-submit it.

Don't let the length of this email intimidate you.  This is mostly
procedural stuff that everybody runs into when they start working on FSF
projects.

Michael

-- Anchor the tail of the pattern.

   Your pattern says:

      -re "Reading symbols from.*no debugging symbols found.* $"

   This works as long as gdb output arrives in one big packet.
   However, sometimes the gdb output gets broken up and arrives
   in several packets.  When that happens, the ".* $" at the end
   of your pattern will succeed prematurely before all of the
   packets arrive, leaving some unmatched characters in the stream.

   So you have to write:

      -re "Reading symbols from.*no debugging symbols found.*$gdb_prompt $"

   That forces the pattern to keep scanning gdb output until it
   gets to the final "(gdb) ".

-- ChangeLog entry.  When you submit a patch, please submit a ChangeLog
   entry to go with it.  In general, the right ChangeLog file is the
   ChangeLog file nearest to the file that you are patching.  In this
   case, it's gdb/testsuite/ChangeLog.

   And you format the ChangeLog paragraph as a little block of
   text in front of the "diff", rather than including
   "diff ChangeLog" with the diff.  That's the Gnu style;
   it makes it easier to merge patches.
   
   See the gdb-patches mailing list archive for examples.

-- Test with current gdb.  I noticed your test was with gdb 6.1.
   You should at least be testing with gdb 6.2; preferably with
   the CVS version of gdb.

-- Run the whole test suite.

   A change in lib/gdb.exp affects the execution of every test script.
   It's great to show that gdb.gdb/complaints.exp improved.  But you
   also have to check that other tests didn't get broken.

   The procedure is:
   
      check out the CVS version of gdb
      run the whole test suite
      save the gdb.sum and gdb.log files
      apply your patch
      run the whole test suite again
      diff the first gdb.sum against the new gdb.sum
      if there are differences, check out what changed in gdb.log

   Unfortunately, there are about six test scripts that are unstable
   and give different results from run to run.  So you have to use
   your judgement with these, which generally means "ignore them":

      gdb.cp/annota2.exp
      gdb.cp/annota3.exp
      gdb.threads/manythreads.exp
      gdb.threads/print-threads.exp
      gdb.threads/schedlock.exp
      gdb.threads/watchthreads.exp

   If you're not sure whether a change in gdb.sum results came
   from your patch or from run-to-run instability, you can
   check the gdb-testers@ archive and see if I've mentioned that
   particular test in my results.  Or you can ask me or ask one
   of the lists.  Or you can submit the patch anyways and say
   "I saw a regression in gdb.foo/bar.exp but I'm not sure if
   my patch caused it or not".

   Getting back to the "whole test suite" ... there is at least
   one test script, gdb.base/nodebug.exp, which explicitly tests
   how gdb works when the target program has no debugging symbols.
   Your patch might interfere with that.  So you have to run the
   whole test suite before-and-after, to find any interference
   like that.

-- Last, patch submissions for gdb go to the gdb-patches@ mailing
   list, not the gdb@ mailing list.