* 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).