Re: [RFA] new test for separate debug info

Elena Zannoni
2003-11-14T15:52:20Z

Michael Elizabeth Chastain writes:
> eza> What happens is that gdb_load errors out and calls perror, then
> eza> returns 1. All I have done is wrap gdb_load in a check for a 1 return
> eza> value.
>
> Here's the part that's confusing me. Your gdb_load wrapper
> says "if [gdb_load ...] { unsupported ...}", but your gdb.sum
> file says "# of unresolved test cases: 1". The call to "unsupported"
> doesn't fit the result of "unresolved"!
>

Ah, I didn't notice that.
Groan, look at dejagnu/lib/framework.exp:

# If we have too many warnings or errors,
# the output of the test can't be considered correct.
if { $warning_threshold > 0 && $warncnt >= $warning_threshold
|| $perror_threshold > 0 && $errcnt >= $perror_threshold } {
verbose "Error/Warning threshold exceeded: \
$errcnt $warncnt (max. $perror_threshold $warning_threshold)"
set type UNRESOLVED
}

Since we got a perror from the previous load, the error threshold is
exceeded and the code above triggers, changing the UNSUPPORTED to
UNRESOLVED.

If I run with -v, I get this bit of output:
Error/Warning threshold exceeded: 1 0 (max. 1 3)

what to do? Maybe just get rid of the unsupported call, and just get
out of the test. But then the failure wouldn't be recorded, there
would just be the error. Alternatively maybe we could raise temporarily the
error threshold to 2.

global perror_threshold
set perror_threshold [expr $perror_threshold + 1]
if [gdb_load ${binfile}] {
unsupported "Gdb cannot process a separate debug info file"
return -1
}
set perror_threshold [expr $perror_threshold - 1]

Not pretty, I know.

elena