Re: [RFA] new test script for gnatsweb gdb/15

[Michael Elizabeth Chastain <chastain at cygnus dot com>]

> I guess there is no way to detect this malfunction without going all the
> way to the crash, right?

There might be some obscure gdb command to peel off one layer of type
information at a time, but I don't know what it is off-hand.  It's a
lot simpler just to crash gdb.

I could write the test so that if gdb-under-test crashes, I get a FAIL.
Some tests are written like that.  But the natural way to write the test
crashes gdb.  Heck, there could be 20 other places where gdb crashes
during the test suite, and nobody notices because gdb.sum does not
report ERROR.

> Could you please take a look and see if you can't incorporate this into
> that file (and if you feel like do the same with that struct2.exp)?

No.  My stack is too deep:

  I took some time away from my primary project to look at gdb test
  results from a different project.

  I saw a funny result in gdb.base/selftest.exp.  I fired up the new gdb
  on itself to investigate the funny result.

  I tried a 'maint print symbols' and the superior gdb core dumped.

  I analyzed *that* core dump.  I determined that it also occurs in
  sourceware cvs gdb, so I filed a bug report; wrote, tested, and
  submitted a bug fix; and wrote, tested, and submitted a test suite.

I need to finish my interaction with sourceware, so I can get back
to analyzing that funny result on that different project, and then
analyze the other test failures on that project, and then return to my
primary project.

So I have no time to do anything with structs2.exp, and I have very little
time for modifying structs3.exp.  Someone else (or me at a different time)
will have to do the work of collecting the structs* patches.

If my new structs3.c/structs3.exp is not good enough then I will withdraw
the patch.

Michael Elizabeth Chastain
<chastain@redhat.com>
"love without fear"