RE: Question: gdb.tui/tui-layout-asm.exp
Carl Love via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
Andrew, gdb developers:
>.... I think
> that for some reason this check is failing:
>
> if {[Term::wait_for $re_line] \
> && [regexp $re_line [Term::get_line 1]]} {
>
> If this was not failing, and you kept scrolling far enough, then a
> blank like would appear.
Yes, that test does appear to be failing. I have added some debug
statements to the gdb.tui/tui-layout-asm.exp test as follows:
set line1 [Term::get_line 1]
puts " "
puts "Carll line1 $line1"
puts "Carll re_line $re_line"
if {([Term::wait_for $re_line] \
&& [regexp $re_line [Term::get_line 1]])} {
puts "Carll true"
# We scrolled successfully.
} else {
puts "Carll false"
fail "$testname (scroll failed)"
Term::dump_screen
break
}
The interesting output is:
Carll line1 | 0x100007a4 <__glink_PLTresolve+44> ld r11,8(r11) |
Carll re_line \|\s+0x100007a8\s+<__glink_PLTresolve\+48>\s+bctr\s+\|
CARLL, timeout, return 1
Carll true
Carll line1 | 0x100007a8 <__glink_PLTresolve+48> bctr |
Carll re_line \|\s+0x100007ac\s+<__libc_start_main@plt>\s+b\s+0x10000778\s+<__glink_PLTres\| <--should match
CARLL, timeout, return 1
Carll true
Carll line1 | 0x100007ac <__libc_start_main@plt> b 0x10000778 <__glink_PLTres| <-- this line but the test fails
Carll re_line \|\s+0x100007b0\s+<__gmon_start__@plt>\s+b\s+0x10000778\s+<__glink_PLTres\|
CARLL, timeout, return 1
Carll false
FAIL: gdb.tui/tui-layout-asm.exp: scroll to end of assembler (scroll failed)
So the if statement is checking to see if line1 matches the re_line
above it. The match statement is
[regexp $re_line [Term::get_line 1]]
The final test fails for some reason? Note this is the first test were
a line had an @ symbol in it. The value of re_line which is
set re_line [string_to_regexp $line]
looks like the generated regular expression of the line should match
the next $line1 string. I am not aware of the @ having any special
meaning in a regular expression that would confuse the regexp command?
Maybe someone else can spot why the two lines don't seem to match?
They look OK to me.
Carl