* RE: Question: gdb.tui/tui-layout-asm.exp
[not found] ` <20210719164804.GC1688065@embecosm.com>
@ 2021-07-19 22:22 ` Carl Love
2021-07-20 8:01 ` Andreas Schwab
0 siblings, 1 reply; 5+ messages in thread
From: Carl Love @ 2021-07-19 22:22 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Question: gdb.tui/tui-layout-asm.exp
2021-07-19 22:22 ` Question: gdb.tui/tui-layout-asm.exp Carl Love
@ 2021-07-20 8:01 ` Andreas Schwab
2021-07-20 17:41 ` Carl Love
0 siblings, 1 reply; 5+ messages in thread
From: Andreas Schwab @ 2021-07-20 8:01 UTC (permalink / raw)
To: Carl Love via Gdb; +Cc: Andrew Burgess, Carl Love
On Jul 19 2021, Carl Love via Gdb wrote:
> 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?
Have you checked that [Term::get_line 1] really returns the same thing
in both calls?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Question: gdb.tui/tui-layout-asm.exp
2021-07-20 8:01 ` Andreas Schwab
@ 2021-07-20 17:41 ` Carl Love
2021-07-20 18:06 ` Carl Love
0 siblings, 1 reply; 5+ messages in thread
From: Carl Love @ 2021-07-20 17:41 UTC (permalink / raw)
To: Andreas Schwab, Carl Love via Gdb
Andreas:
On Tue, 2021-07-20 at 10:01 +0200, Andreas Schwab wrote:
> On Jul 19 2021, Carl Love via Gdb wrote:
>
> > 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?
>
> Have you checked that [Term::get_line 1] really returns the same
> thing
> in both calls?
I had to rewrite the if statement a bit to be able to get to the result
of the get_line 1 read after the wait_for. The code is now:
while (1) {
# Grab the second line, this is about to become the first line.
puts " "
set line [Term::get_line 2]
puts "Carll line $line"
...
if {[Term::wait_for $re_line]} {
puts "Carll re_line $re_line"
set line1 [Term::get_line 1]
puts "Carll line1 $line1"
if {[regexp $re_line $line1]} {
puts "Carll true"
# We scrolled successfully.
} else {
puts "Carll match false"
fail "$testname (scroll failed)"
Term::dump_screen
break
}
} else {
puts "Carll wait for false"
fail "$testname (scroll failed)"
Term::dump_screen
break
}
The output is:
Carll line | 0x100007a8 <__glink_PLTresolve+48> bctr |
CARLL, timeout, return 1
Carll re_line \|\s+0x100007a8\s+<__glink_PLTresolve\+48>\s+bctr\s+\|
Carll line1 | 0x100007a8 <__glink_PLTresolve+48> bctr |
Carll true
Carll line | 0x100007ac <__libc_start_main@plt> b 0x10000778 <__glink_PLTres|
CARLL, timeout, return 1
Carll re_line \|\s+0x100007ac\s+<__libc_start_main@plt>\s+b\s+0x10000778\s+<__glink_PLTres\|
Carll line1 | 0x100007ac <__libc_start_main@plt> b 0x10000778 <__glink_PLTres|
Carll true
Carll line | 0x100007b0 <__gmon_start__@plt> b 0x10000778 <__glink_PLTres|
CARLL, timeout, return 1
Carll re_line \|\s+0x100007b0\s+<__gmon_start__@plt>\s+b\s+0x10000778\s+<__glink_PLTres\|
Carll line1 | 0x100007b0 <__gmon_start__@plt> b 0x10000778 <__glink_PLTresolve> | <-- the read after the wait_for read more characters
Carll match false
FAIL: gdb.tui/tui-layout-asm.exp: scroll to end of assembler (scroll failed)
The initial read of line 2, which then becomes re_line has fewer
characters in it than when the same line is read the second time. The
second read occurs following the wait_for statement.
I played a little to try and put a wait_for in when doing the initial
"get_line 2". That wait doesn't seem to work correctly. I am looking
at the library routine to see if I am not use the wait_for call
correctly. It is not clear yet why I get more characters the "second"
time the line is read. I will keep digging but please let me know if
you have any thoughts on the issue. Thanks.
Carl
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Question: gdb.tui/tui-layout-asm.exp
2021-07-20 17:41 ` Carl Love
@ 2021-07-20 18:06 ` Carl Love
2021-07-20 18:16 ` Carl Love
0 siblings, 1 reply; 5+ messages in thread
From: Carl Love @ 2021-07-20 18:06 UTC (permalink / raw)
To: Andreas Schwab, Carl Love via Gdb
Andreas:
> Carll re_line \|\s+0x100007b0\s+<__gmon_start__@plt>\s+b\s+0x1000077
> 8\s+<__glink_PLTres\|
> Carll line1 | 0x100007b0 <__gmon_start__@plt> b 0x10000778
> <__glink_PLTresolve> | <-- the read after the wait_for
> read more characters
> Carll match
> false
>
> FAIL: gdb.tui/tui-layout-asm.exp: scroll to end of assembler (scroll
> failed)
>
>
> The initial read of line 2, which then becomes re_line has fewer
> characters in it than when the same line is read the second
> time. The
> second read occurs following the wait_for statement.
>
Looking at the screen dumps you can see the output formatting changed
based on the length of the fields.
Initially the dump looks like:
Screen Dump (80 x 24):
0 +------------------------------------------------------------------------------+
1 | 0x100007ac <__libc_start_main@plt> b 0x10000778 <__glink_PLTres|
2 | 0x100007b0 <__gmon_start__@plt> b 0x10000778 <__glink_PLTres|
3 | 0x100007b4 <_fini> lis r2,4098 |
4 | 0x100007b8 <_fini+4> addi r2,r2,32512 |
5 | 0x100007bc <_fini+8> mflr r0 |
After the down key is sent to gdb, the screen dump becomes:
FAIL: gdb.tui/tui-layout-asm.exp: scroll to end of assembler (scroll failed)
Screen Dump (80 x 24):
0 +------------------------------------------------------------------------------+
1 | 0x100007b0 <__gmon_start__@plt> b 0x10000778 <__glink_PLTresolve> |
2 | 0x100007b4 <_fini> lis r2,4098 |
3 | 0x100007b8 <_fini+4> addi r2,r2,32512 |
4 | 0x100007bc <_fini+8> mflr r0 |
It looks like the width of the second colum changes one the line with <
__libc_start_main@plt> is no longer being displayed.
I will look to see if we can make the screen width a little wider.
Carl
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Question: gdb.tui/tui-layout-asm.exp
2021-07-20 18:06 ` Carl Love
@ 2021-07-20 18:16 ` Carl Love
0 siblings, 0 replies; 5+ messages in thread
From: Carl Love @ 2021-07-20 18:16 UTC (permalink / raw)
To: Andreas Schwab, Carl Love via Gdb, cel
Andreas:
Making the window wider and adjusting the check for the box size fixes
the issues. The following is the patch to fix the problems.
Simple fix once we got all the way down to what was really going on.
Thanks for the help.
Carl
--------------------------------------------------------------------
gdb/testsuite/gdb.tui/tui-layout-asm.exp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gdb/testsuite/gdb.tui/tui-layout-asm.exp b/gdb/testsuite/gdb.tui/
tui-layout-asm.exp
index 19ce333ca9e..75e0d6b3a07 100644
--- a/gdb/testsuite/gdb.tui/tui-layout-asm.exp
+++ b/gdb/testsuite/gdb.tui/tui-layout-asm.exp
@@ -24,7 +24,7 @@ if {[build_executable "failed to prepare" ${testfile} ${srcf
ile}] == -1} {
return -1
}
-Term::clean_restart 24 80 $testfile
+Term::clean_restart 24 90 $testfile
if {![Term::prepare_for_tui]} {
unsupported "TUI not supported"
return
@@ -32,7 +32,7 @@ if {![Term::prepare_for_tui]} {
# This puts us into TUI mode, and should display the ASM window.
Term::command_no_prompt_prefix "layout asm"
-Term::check_box_contents "check asm box contents" 0 0 80 15 "<main>"
+Term::check_box_contents "check asm box contents" 0 0 90 15 "<main>"
# Scroll the ASM window down using the down arrow key. In an ideal
# world we'd like to use PageDown here, but currently our terminal
--
2.17.1
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-07-20 18:16 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <c9c9f9f9af7ae99468baa7fd885538af4a694714.camel@us.ibm.com>
[not found] ` <20210719164804.GC1688065@embecosm.com>
2021-07-19 22:22 ` Question: gdb.tui/tui-layout-asm.exp Carl Love
2021-07-20 8:01 ` Andreas Schwab
2021-07-20 17:41 ` Carl Love
2021-07-20 18:06 ` Carl Love
2021-07-20 18:16 ` Carl Love
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).