Re: A testsuite update, for the curious

Re: A testsuite update, for the curious

[Michael Elizabeth Chastain]

Hi Daniel,

We're in danger here of doing partial analysis on a lot of bugs
and not finishing any of them.  Well, okay, I'm in that danger.
You get a lot of stuff committed.  :)

> It is dependent (like the rest of gdb.gdb/) on the compiler used to
> build gdb and the optimization level.  Do you use 2.95.3 +
> optimization to build any of your GDB's?

I don't control any optimization dimension, so all my tests are
at default optimization.  So that explains why you see stuff in
complaints.exp and I don't see it.

I do test with many gcc's including gcc 2.95.3.

I could really use a big home cluster!

Michael C

Re: A testsuite update, for the curious

[Michael Elizabeth Chastain]

Daniel Jacobowitz writes:
> One FAIL from gdb.gdb/complaints.exp.

Hey, I'm not getting any FAILs from gdb.gdb/complaints.exp in any
of my tested configurations.

> a testsuite bug that only shows up with a relative path to configure,

You probably already figured this out:

  # TODO: gdb.base/corefile.exp cannot handle relative objdir
  #       it does "cd ${objdir}/${subdir}; ${binfile};" when
  #       ${binfile} == ${objdir}/${subdir}/${testfile}.

The fix is probably just s/${binfile}/${testfile} .

BTW I am unable to run corefile.exp on native i686-pc-linux-gnu red-hat-8.0
because red hat 8.0 turns on the kernel flag for core file names so that
the names are 'core.12345' instead of 'core'.

> And something else is wrong in print-threads.exp; I occasionally see a
> SIGSEGV in the testsuite log.  But I can't reproduce it often enough to
> get a good look at it.

I get sporadic ERRORs in gdb.trace/actions.exp.  I am not seeing this
behavior in print-threads.exp and I am running 100+ of them per week
(I run a lot of "infrastructure" test runs that I don't publish, but I
would notice a bunch of core-dump-induced madness).  I do see one other
print-threads.exp problem that manifests with sourceware TCL+Expect+Dejagnu
and does not manifest with stock TCL+Expect+Dejagnu.  So it's quite
possible that there are races that never get scheduled depending on
subtle things like the version of Expect that you test with.

Michael C

Re: A testsuite update, for the curious

[Daniel Jacobowitz]

On Tue, Jan 14, 2003 at 02:18:37AM -0600, Michael Elizabeth Chastain wrote:
> Daniel Jacobowitz writes:
> > One FAIL from gdb.gdb/complaints.exp.
> 
> Hey, I'm not getting any FAILs from gdb.gdb/complaints.exp in any
> of my tested configurations.

It is dependent (like the rest of gdb.gdb/) on the compiler used to
build gdb and the optimization level.  Do you use 2.95.3 +
optimization to build any of your GDB's?

> > a testsuite bug that only shows up with a relative path to configure,
> 
> You probably already figured this out:
> 
>   # TODO: gdb.base/corefile.exp cannot handle relative objdir
>   #       it does "cd ${objdir}/${subdir}; ${binfile};" when
>   #       ${binfile} == ${objdir}/${subdir}/${testfile}.
> 
> The fix is probably just s/${binfile}/${testfile} .
> 
> BTW I am unable to run corefile.exp on native i686-pc-linux-gnu red-hat-8.0
> because red hat 8.0 turns on the kernel flag for core file names so that
> the names are 'core.12345' instead of 'core'.

Oh, very neat.  I don't know why I didn't ever see this one; I was
referring to one of the new MI tests.

I get a lot of garbage core.NUMBER files but they're from one of the
other tests... a threaded one I think.

> > And something else is wrong in print-threads.exp; I occasionally see a
> > SIGSEGV in the testsuite log.  But I can't reproduce it often enough to
> > get a good look at it.
> 
> I get sporadic ERRORs in gdb.trace/actions.exp.  I am not seeing this
> behavior in print-threads.exp and I am running 100+ of them per week
> (I run a lot of "infrastructure" test runs that I don't publish, but I
> would notice a bunch of core-dump-induced madness).  I do see one other
> print-threads.exp problem that manifests with sourceware TCL+Expect+Dejagnu
> and does not manifest with stock TCL+Expect+Dejagnu.  So it's quite
> possible that there are races that never get scheduled depending on
> subtle things like the version of Expect that you test with.

I've never seen the ERRORs; how bizarre... I'll look at your logs
sometime.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

A testsuite update, for the curious

[Daniel Jacobowitz]

As of right now, on my system, using GCC 2.95.3 and -gstabs+, I see:

                === gdb Summary ===

# of expected passes            8546
# of unexpected failures        6
# of unexpected successes       4
# of expected failures          168
# of known failures             5
# of untested testcases         9
# of unsupported tests          1


Two XPASS's from constvars.exp.  I think these should just be removed, but
I'll investigate later.

One XPASS from interrupt.exp.  This has been there forever; it comes and
goes; no one knows.

One FAIL from default.exp, "info float".  Patch posted for comments.

Two FAILs from store.exp.  I know how to fix these, after discussing it with
Andrew a few days ago.  I'll do it soon, probably tomorrow.

An XPASS from virtfunc.exp.  If it's actually working correctly we can and
should remove the xfail; I'll investigate later.

One FAIL from gdb.gdb/complaints.exp.  This has been around for a little
while; I haven't looked at it yet.  Oh, it's a bug I see very frequently. 
Given:
93      static int
94      captured_command_loop (void *data)
95      {
96        if (command_loop_hook == NULL)
97          command_loop ();
and GCC 2.95.3 + optimization, we place the breakpoint after the conditional
branch, and lose.  I'm not entirely sure why this happens but it seems that
it may be a bad interaction with my previous workaround for bad stabs from
this compiler (but it's not that simple, since I first remember seeing it
two years or so before I implemented the workaround).  I'll dig through my
notes for the previous patch and see if I can manage to accomodate both
forms of bugginess.  If not, I'm not going to sweat this one too much, but
I'd like to.

One FAIL from killed.exp, which should be a KFAIL.  I'll probably get this
tomorrow, since I missed it my last pass through.

One FAIL from print-threads.exp.  Patch posted Friday for comments; though I
can't really say that I like it, I don't see a better solution to the
problem.


That's five fails easily (or otherwise, for print-threads.exp) addressed,
three xpasses we can probably remove, and one intermittent XPASS.

There's also intermittent schedlock.exp failures (testsuite problem, still
trying to figure out what to do about it), a testsuite bug that only shows
up with a relative path to configure, a testsuite bug (mine) that only shows
up when $objdir == $srcdir, and an intermittent failure in pthreads.exp
(Kevin B. posted a patch for it months ago).  And something else is wrong in
print-threads.exp; I occasionally see a SIGSEGV in the testsuite log.  But I
can't reproduce it often enough to get a good look at it.

Not too shabby.  If I can figure out what to do about the last stabs bug we
can actually have a configuration down to no failures (and six KFAILs,
which do need to be addressed, but my goal here is strictly regression
usability for the testsuite right now) (and 168 XFAILs, which do need to be
itemized and considered eventually).

Then I'll pick another one and go back to work.  Any configuration but this
particular one needs some work in the C++ arena, and we're getting closer to
ready for that every day.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: A testsuite update, for the curious

[Daniel Jacobowitz]

On Tue, Jan 14, 2003 at 12:05:19AM -0500, Daniel Jacobowitz wrote:
> One FAIL from gdb.gdb/complaints.exp.  This has been around for a little
> while; I haven't looked at it yet.  Oh, it's a bug I see very frequently. 
> Given:
> 93      static int
> 94      captured_command_loop (void *data)
> 95      {
> 96        if (command_loop_hook == NULL)
> 97          command_loop ();
> and GCC 2.95.3 + optimization, we place the breakpoint after the conditional
> branch, and lose.  I'm not entirely sure why this happens but it seems that
> it may be a bad interaction with my previous workaround for bad stabs from
> this compiler (but it's not that simple, since I first remember seeing it
> two years or so before I implemented the workaround).  I'll dig through my
> notes for the previous patch and see if I can manage to accomodate both
> forms of bugginess.  If not, I'm not going to sweat this one too much, but
> I'd like to.

I don't think it's reliably fixable.  Here's the problem.  With all
compilers, we assume (correctly it seems) that:

 - the beginning of the function is before the prologue (duh)
 - the second line note is after the prologue

With most working compilers:
 - the first line note is at the beginning of the function, before the
   prologue
 - the second line note is immediately after the prologue, a good place
   to stop

With GCC 2.95.3:
  - the first line note is somewhere in the middle of the prologue,
    generally between stack frame adjustment and storing local
    variables into their frame slots (if any, so sometimes it's at the
    end of the prologue)
  - the second line note may mark the end of the prologue, but with
    optimization if the first two line notes were in the same place
    (i.e. no stack temps being saved after stack frame adjustment)
    then one of them will be deleted.  Then the second line note marks
    an arbitrary line in the function.

There can be branches between the first two line notes :(  So the debug
info workaround in place for this compiler can not be extended to
reliably cover this problem.


Since we call the prologue skipper from find_pc_start_sal anyway, it
would be nice for it to return a flag indicating "no, you really can
not extend this address to the next line boundary".... since obviously
this comment:
     - Compilers usually emit line number info that marks the prologue
       as its own "source line".  So the ending address of that "line"
       is the end of the prologue.  If available, this is the most
       reliable method.
has a certain flaw.

We don't always call the prologue skipper from in_prologue (), though.
Why does it use a different search order than find_function_start_sal ()?

Is calling the prologue skipper every time acceptable?  Should we just
write off this as lost?  I like the surety of having the architecture
specific code have a chance to say "no, this is a branch, don't think
it's in the prologue!" since this bug does repeatedly bite me when I'm
debugging optimized code.  On the other hand, if we ignore it a little
longer it'll go away.  GCC 3.x is fixed.  So if the consensus is that
it's too much effort to bother, I can handle that and just crawl back
into my hole.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: A testsuite update, for the curious

[Daniel Jacobowitz]

On Tue, Jan 14, 2003 at 01:50:48AM -0500, Daniel Jacobowitz wrote:
> On Tue, Jan 14, 2003 at 12:05:19AM -0500, Daniel Jacobowitz wrote:
> > One FAIL from gdb.gdb/complaints.exp.  This has been around for a little
> > while; I haven't looked at it yet.  Oh, it's a bug I see very frequently. 
> > Given:
> > 93      static int
> > 94      captured_command_loop (void *data)
> > 95      {
> > 96        if (command_loop_hook == NULL)
> > 97          command_loop ();
> > and GCC 2.95.3 + optimization, we place the breakpoint after the conditional
> > branch, and lose.  I'm not entirely sure why this happens but it seems that
> > it may be a bad interaction with my previous workaround for bad stabs from
> > this compiler (but it's not that simple, since I first remember seeing it
> > two years or so before I implemented the workaround).  I'll dig through my

Heh.  For the curious, this was:

Date: Tue, 11 Jan 2000 00:42:19 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: 54734@bugs.debian.org
Cc: gcc-bugs@gcc.gnu.org, gdb@sourceware.cygnus.com
Subject: problems with line numbering

And at the time I came to the same conclusion; that we could not trust
the debug information regarding the end of the prologue, and we were
already getting the right answer in <arch>_skip_prologue, and then
discarding it.  If the prologue skipper says that it hit the end of the
prologue, I still don't see the point of using debug info to skip
forward farther.  I'm sure there's a case where this is appropriate but
I can't construct one.

Don't think that message got any answers.  It's in the dozen or so
oldest open bug reports for Debian's GDB package (a lot of the older
ones are either fixed, or ObjC related).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer