* How do I get regexp from expect at gdb_expect?
@ 2005-01-29 2:57 Bob Rossi
2005-01-29 3:09 ` Paul Hilfinger
0 siblings, 1 reply; 20+ messages in thread
From: Bob Rossi @ 2005-01-29 2:57 UTC (permalink / raw)
To: GDB
Hi,
I'm using expect with GDB and I've come across a problem. For instance,
say I have,
gdb_expect $tmt {
-re "(Ending remote debugging.*$mi_gdb_prompt\[ \]*$)" {
# at this point, how do I get the string that matched the above
# regex?
}
}
}
I need to be able to get the string that matched the regex at the -re.
If I can get this data, I think I will successfully be able to get the
MI output parser to parse the output of GDB with the existing testsuite.
This will at least ensure that the syntax is correct, and will stay
correct.
I hope it is possible to get the information that I need ...
Any help would be greatly appreciated,
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-01-29 2:57 How do I get regexp from expect at gdb_expect? Bob Rossi
@ 2005-01-29 3:09 ` Paul Hilfinger
2005-01-29 3:11 ` Bob Rossi
2005-01-31 15:07 ` Bob Rossi
0 siblings, 2 replies; 20+ messages in thread
From: Paul Hilfinger @ 2005-01-29 3:09 UTC (permalink / raw)
To: GDB; +Cc: Bob Rossi
> Hi,
>
> I'm using expect with GDB and I've come across a problem. For instance,
> say I have,
>
> gdb_expect $tmt {
> -re "(Ending remote debugging.*$mi_gdb_prompt\[ \]*$)" {
> # at this point, how do I get the string that matched the above
> # regex?
> }
> }
> }
Here is some relevant documentation:
Upon matching a pattern (or eof or full_buffer), any
matching and previously unmatched output is saved in
the variable expect_out(buffer) [as in $expect_out(buffer)].
Up to 9 regexp sub-
string matches are saved in the variables
expect_out(1,string) through expect_out(9,string). If
the -indices flag is used before a pattern, the start-
ing and ending indices (in a form suitable for lrange)
of the 10 strings are stored in the variables
expect_out(X,start) and expect_out(X,end) where X is a
digit, corresponds to the substring position in the
buffer. 0 refers to strings which matched the entire
pattern...
P. Hilfinger
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-01-29 3:09 ` Paul Hilfinger
@ 2005-01-29 3:11 ` Bob Rossi
2005-01-29 3:16 ` Bob Rossi
2005-01-31 15:07 ` Bob Rossi
1 sibling, 1 reply; 20+ messages in thread
From: Bob Rossi @ 2005-01-29 3:11 UTC (permalink / raw)
To: Paul Hilfinger; +Cc: GDB
On Fri, Jan 28, 2005 at 07:09:15PM -0800, Paul Hilfinger wrote:
>
> > Hi,
> >
> > I'm using expect with GDB and I've come across a problem. For instance,
> > say I have,
> >
> > gdb_expect $tmt {
> > -re "(Ending remote debugging.*$mi_gdb_prompt\[ \]*$)" {
> > # at this point, how do I get the string that matched the above
> > # regex?
> > }
> > }
> > }
>
> Here is some relevant documentation:
>
> Upon matching a pattern (or eof or full_buffer), any
> matching and previously unmatched output is saved in
> the variable expect_out(buffer) [as in $expect_out(buffer)].
> Up to 9 regexp sub-
> string matches are saved in the variables
> expect_out(1,string) through expect_out(9,string). If
> the -indices flag is used before a pattern, the start-
> ing and ending indices (in a form suitable for lrange)
> of the 10 strings are stored in the variables
> expect_out(X,start) and expect_out(X,end) where X is a
> digit, corresponds to the substring position in the
> buffer. 0 refers to strings which matched the entire
> pattern...
Thanks, I did see that, however, I think there is a problem because I'm
calling a Tcl function called 'gdb_expect', instead of expect. I don't
know how that change's the situation.
Bob Rossi
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-01-29 3:11 ` Bob Rossi
@ 2005-01-29 3:16 ` Bob Rossi
0 siblings, 0 replies; 20+ messages in thread
From: Bob Rossi @ 2005-01-29 3:16 UTC (permalink / raw)
To: Paul Hilfinger, GDB
On Fri, Jan 28, 2005 at 10:11:13PM -0500, Bob Rossi wrote:
> On Fri, Jan 28, 2005 at 07:09:15PM -0800, Paul Hilfinger wrote:
> >
> > > Hi,
> > >
> > > I'm using expect with GDB and I've come across a problem. For instance,
> > > say I have,
> > >
> > > gdb_expect $tmt {
> > > -re "(Ending remote debugging.*$mi_gdb_prompt\[ \]*$)" {
> > > # at this point, how do I get the string that matched the above
> > > # regex?
> > > }
> > > }
> > > }
> >
> > Here is some relevant documentation:
> >
> > Upon matching a pattern (or eof or full_buffer), any
> > matching and previously unmatched output is saved in
> > the variable expect_out(buffer) [as in $expect_out(buffer)].
> > Up to 9 regexp sub-
> > string matches are saved in the variables
> > expect_out(1,string) through expect_out(9,string). If
> > the -indices flag is used before a pattern, the start-
> > ing and ending indices (in a form suitable for lrange)
> > of the 10 strings are stored in the variables
> > expect_out(X,start) and expect_out(X,end) where X is a
> > digit, corresponds to the substring position in the
> > buffer. 0 refers to strings which matched the entire
> > pattern...
>
> Thanks, I did see that, however, I think there is a problem because I'm
> calling a Tcl function called 'gdb_expect', instead of expect. I don't
> know how that change's the situation.
Paul, thanks for the info, apparently this works even through the
gdb_expect call.
Bob Rossi
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-01-29 3:09 ` Paul Hilfinger
2005-01-29 3:11 ` Bob Rossi
@ 2005-01-31 15:07 ` Bob Rossi
2005-01-31 16:28 ` Daniel Jacobowitz
1 sibling, 1 reply; 20+ messages in thread
From: Bob Rossi @ 2005-01-31 15:07 UTC (permalink / raw)
To: Paul Hilfinger; +Cc: GDB
On Fri, Jan 28, 2005 at 07:09:15PM -0800, Paul Hilfinger wrote:
>
> > Hi,
> >
> > I'm using expect with GDB and I've come across a problem. For instance,
> > say I have,
> >
> > gdb_expect $tmt {
> > -re "(Ending remote debugging.*$mi_gdb_prompt\[ \]*$)" {
> > # at this point, how do I get the string that matched the above
> > # regex?
> > }
> > }
> > }
>
> Here is some relevant documentation:
>
> Upon matching a pattern (or eof or full_buffer), any
> matching and previously unmatched output is saved in
> the variable expect_out(buffer) [as in $expect_out(buffer)].
> Up to 9 regexp sub-
> string matches are saved in the variables
> expect_out(1,string) through expect_out(9,string). If
> the -indices flag is used before a pattern, the start-
> ing and ending indices (in a form suitable for lrange)
> of the 10 strings are stored in the variables
> expect_out(X,start) and expect_out(X,end) where X is a
> digit, corresponds to the substring position in the
> buffer. 0 refers to strings which matched the entire
> pattern...
As an update, I've written the MI Output Command parser as a Tcl extension
and I've put a call in mi-support.exp:mi_gdb_test to test the syntax of
the MI Output Command.
I'm having a problem determining if GDB is broken, or if expect is
giving me the wrong string back. I suspect it's the ladder.
Here's the place where I get the string from Expect, I do several lines
of instrumentation. The data is below, everything after ### and before
### is what's given from Expect.
-re "(\[\r\n\]*(($pattern)\[\r\n\]+$mi_gdb_prompt\[ \]*$))" {
set entire_out $expect_out(1,string)
set mi_out $expect_out(2,string)
set pattern_out $expect_out(3,string)
set parse_result [gdbmi_parse $mi_out]
if [string match "syntax error" $parse_result] then {
fail "parsing MI output command"
puts "COMMAND($command)"
puts "ENTIRE_OUT###$entire_out###"
puts "PATTER_TO_END###$mi_out###"
puts "PATTER_OUT###$pattern_out###"
puts "BUFFER###$expect_out(buffer)###"
}
if ![string match "" $message] then {
pass "$message"
}
set result 0
}
COMMAND(201-break-list)
ENTIRE_OUT###201-break-list
201^done,BreakpointTable={nr_rows="0",nr_cols="6",hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[]}
(gdb)
###
PATTER_TO_END###201-break-list
201^done,BreakpointTable={nr_rows="0",nr_cols="6",hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[]}
(gdb)
###
PATTER_OUT###201-break-list
201^done,BreakpointTable={nr_rows="0",nr_cols="6",hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[]}###
BUFFER###201-break-list
201^done,BreakpointTable={nr_rows="0",nr_cols="6",hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[]}
(gdb)
###
The problem is, Expect is saying that '201-break-list' is part of the MI
output command. This is incorrect and would mean that GDB is not
behaving properly. However, the log file shows that GDB is *not*
outputting the unwanted data as part of the MI Output Command,
201-break-list^M
201^done,BreakpointTable={nr_rows="0",nr_cols="6",hdr=[{width="3",alignment="-1"
(gdb) ^M
FAIL: gdb.mi/mi-basics.exp: parsing MI output command
Also, if I run the commands manually, I do not see the extra
'201-break-list' in the MI output command.
Is there any way I can make Expect tell me only the output?
Does the regular expression also parse the input to GDB?
Any help would be greatly appreciated.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-01-31 15:07 ` Bob Rossi
@ 2005-01-31 16:28 ` Daniel Jacobowitz
2005-01-31 16:59 ` Bob Rossi
2005-01-31 21:10 ` Bob Rossi
0 siblings, 2 replies; 20+ messages in thread
From: Daniel Jacobowitz @ 2005-01-31 16:28 UTC (permalink / raw)
To: Paul Hilfinger, GDB
On Mon, Jan 31, 2005 at 10:06:52AM -0500, Bob Rossi wrote:
> On Fri, Jan 28, 2005 at 07:09:15PM -0800, Paul Hilfinger wrote:
> >
> > > Hi,
> > >
> > > I'm using expect with GDB and I've come across a problem. For instance,
> > > say I have,
> > >
> > > gdb_expect $tmt {
> > > -re "(Ending remote debugging.*$mi_gdb_prompt\[ \]*$)" {
> > > # at this point, how do I get the string that matched the above
> > > # regex?
> > > }
> > > }
> > > }
> >
> > Here is some relevant documentation:
> >
> > Upon matching a pattern (or eof or full_buffer), any
> > matching and previously unmatched output is saved in
> > the variable expect_out(buffer) [as in $expect_out(buffer)].
> > Up to 9 regexp sub-
> > string matches are saved in the variables
> > expect_out(1,string) through expect_out(9,string). If
> > the -indices flag is used before a pattern, the start-
> > ing and ending indices (in a form suitable for lrange)
> > of the 10 strings are stored in the variables
> > expect_out(X,start) and expect_out(X,end) where X is a
> > digit, corresponds to the substring position in the
> > buffer. 0 refers to strings which matched the entire
> > pattern...
>
> As an update, I've written the MI Output Command parser as a Tcl extension
> and I've put a call in mi-support.exp:mi_gdb_test to test the syntax of
> the MI Output Command.
>
> I'm having a problem determining if GDB is broken, or if expect is
> giving me the wrong string back. I suspect it's the ladder.
>
> Here's the place where I get the string from Expect, I do several lines
> of instrumentation. The data is below, everything after ### and before
> ### is what's given from Expect.
>
> -re "(\[\r\n\]*(($pattern)\[\r\n\]+$mi_gdb_prompt\[ \]*$))" {
> set entire_out $expect_out(1,string)
> set mi_out $expect_out(2,string)
> set pattern_out $expect_out(3,string)
>
> set parse_result [gdbmi_parse $mi_out]
> if [string match "syntax error" $parse_result] then {
> fail "parsing MI output command"
> puts "COMMAND($command)"
> puts "ENTIRE_OUT###$entire_out###"
> puts "PATTER_TO_END###$mi_out###"
> puts "PATTER_OUT###$pattern_out###"
> puts "BUFFER###$expect_out(buffer)###"
> }
>
> if ![string match "" $message] then {
> pass "$message"
> }
> set result 0
> }
You've left out your pattern, and the context. I recommend using
"exp_internal 1" to debug this sort of problem; that will show you what
expect is doing.
> The problem is, Expect is saying that '201-break-list' is part of the MI
> output command. This is incorrect and would mean that GDB is not
> behaving properly. However, the log file shows that GDB is *not*
> outputting the unwanted data as part of the MI Output Command,
>
> 201-break-list^M
> 201^done,BreakpointTable={nr_rows="0",nr_cols="6",hdr=[{width="3",alignment="-1"
> (gdb) ^M
> FAIL: gdb.mi/mi-basics.exp: parsing MI output command
GDB echoes what you type. Expect receives this and treats it as
output, because that's what it is. You'll need to consume it
explicitly (but be careful - there are dragons here - what GDB outputs
may have extra non-printing characters for line wrapping on long
input).
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-01-31 16:28 ` Daniel Jacobowitz
@ 2005-01-31 16:59 ` Bob Rossi
2005-01-31 21:10 ` Bob Rossi
1 sibling, 0 replies; 20+ messages in thread
From: Bob Rossi @ 2005-01-31 16:59 UTC (permalink / raw)
To: Paul Hilfinger, GDB
On Mon, Jan 31, 2005 at 11:26:10AM -0500, Daniel Jacobowitz wrote:
> On Mon, Jan 31, 2005 at 10:06:52AM -0500, Bob Rossi wrote:
> > On Fri, Jan 28, 2005 at 07:09:15PM -0800, Paul Hilfinger wrote:
> > >
> > > > Hi,
> > > >
> > > > I'm using expect with GDB and I've come across a problem. For instance,
> > > > say I have,
> > > >
> > > > gdb_expect $tmt {
> > > > -re "(Ending remote debugging.*$mi_gdb_prompt\[ \]*$)" {
> > > > # at this point, how do I get the string that matched the above
> > > > # regex?
> > > > }
> > > > }
> > > > }
> > >
> > > Here is some relevant documentation:
> > >
> > > Upon matching a pattern (or eof or full_buffer), any
> > > matching and previously unmatched output is saved in
> > > the variable expect_out(buffer) [as in $expect_out(buffer)].
> > > Up to 9 regexp sub-
> > > string matches are saved in the variables
> > > expect_out(1,string) through expect_out(9,string). If
> > > the -indices flag is used before a pattern, the start-
> > > ing and ending indices (in a form suitable for lrange)
> > > of the 10 strings are stored in the variables
> > > expect_out(X,start) and expect_out(X,end) where X is a
> > > digit, corresponds to the substring position in the
> > > buffer. 0 refers to strings which matched the entire
> > > pattern...
> >
> > As an update, I've written the MI Output Command parser as a Tcl extension
> > and I've put a call in mi-support.exp:mi_gdb_test to test the syntax of
> > the MI Output Command.
> >
> > I'm having a problem determining if GDB is broken, or if expect is
> > giving me the wrong string back. I suspect it's the ladder.
> >
> > Here's the place where I get the string from Expect, I do several lines
> > of instrumentation. The data is below, everything after ### and before
> > ### is what's given from Expect.
> >
> > -re "(\[\r\n\]*(($pattern)\[\r\n\]+$mi_gdb_prompt\[ \]*$))" {
> > set entire_out $expect_out(1,string)
> > set mi_out $expect_out(2,string)
> > set pattern_out $expect_out(3,string)
> >
> > set parse_result [gdbmi_parse $mi_out]
> > if [string match "syntax error" $parse_result] then {
> > fail "parsing MI output command"
> > puts "COMMAND($command)"
> > puts "ENTIRE_OUT###$entire_out###"
> > puts "PATTER_TO_END###$mi_out###"
> > puts "PATTER_OUT###$pattern_out###"
> > puts "BUFFER###$expect_out(buffer)###"
> > }
> >
> > if ![string match "" $message] then {
> > pass "$message"
> > }
> > set result 0
> > }
>
> You've left out your pattern, and the context. I recommend using
> "exp_internal 1" to debug this sort of problem; that will show you what
> expect is doing.
>
> > The problem is, Expect is saying that '201-break-list' is part of the MI
> > output command. This is incorrect and would mean that GDB is not
> > behaving properly. However, the log file shows that GDB is *not*
> > outputting the unwanted data as part of the MI Output Command,
> >
> > 201-break-list^M
> > 201^done,BreakpointTable={nr_rows="0",nr_cols="6",hdr=[{width="3",alignment="-1"
> > (gdb) ^M
> > FAIL: gdb.mi/mi-basics.exp: parsing MI output command
>
> GDB echoes what you type. Expect receives this and treats it as
> output, because that's what it is. You'll need to consume it
> explicitly (but be careful - there are dragons here - what GDB outputs
> may have extra non-printing characters for line wrapping on long
> input).
Why does GDB echo the MI commands? Isn't that functionality part of
readline, which is not part of the MI interface?
I've never noticed that GDB echo's the output, and it's not in the
gdb.log file.
BTW, I sent in the output of the dbg.log file from runtest, which is
here,
http://sources.redhat.com/ml/gdb/2005-01/msg00162.html
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-01-31 16:28 ` Daniel Jacobowitz
2005-01-31 16:59 ` Bob Rossi
@ 2005-01-31 21:10 ` Bob Rossi
2005-01-31 21:21 ` Daniel Jacobowitz
1 sibling, 1 reply; 20+ messages in thread
From: Bob Rossi @ 2005-01-31 21:10 UTC (permalink / raw)
To: Paul Hilfinger, GDB
> You've left out your pattern, and the context. I recommend using
> "exp_internal 1" to debug this sort of problem; that will show you what
> expect is doing.
OK, here's an example of the problem, here's the output for 2
consecutive commands given to GDB.
First, 200-break-delete is sent. The '200-break-delete' is in the
'expect_out(buffer)' output, which leads me to believe the testsuite is
echoing the input command. This in itself is probably wrong. However, the
'200-break-delete' is not in the matched regular expression
'expect_out(0,string)'.
The next command, '200-break-list' is in both the 'expect_out(buffer)'
and in the 'expect_out(0,string)'. This leads me to believe that there
is something wrong with the regular expression matching. It can match
things that it shouldn't, which could mask problems.
I don't really understand what you are saying about 'GDB is echoing
commands'. I do understand that when you are at the terminal running
GDB, GDB allows the terminal to 'echo' the char's typed. However, if you
fork/exec GDB, and send it a command, it will not 'echo' the data back
to your process. Isn't this the way Expect works?
The output is below.
Thanks,
Bob Rossi
send: sending "200-break-delete\n" to { exp11 }
expect: does "" (spawn_id exp11) match regular expression "\*\*\* DOSEXIT code.*"? no
"Ending remote debugging.*[(]gdb[)] \r\n[ ]*$"? no
"([\r\n]*((\^done)[\r\n]+[(]gdb[)] \r\n[ ]*$))"? no
"(^FOOBAR$)$"? no
"Undefined.* command:.*[(]gdb[)] \r\n[ ]*$"? no
"Ambiguous command.*[(]gdb[)] \r\n[ ]*$"? no
"Program exited with code [0-9]+.*[(]gdb[)] \r\n[ ]*$"? no
"The program is not being run.*[(]gdb[)] \r\n[ ]*$"? no
".*[(]gdb[)] \r\n[ ]*$"? no
"<return>"? no
"\(y or n\) "? no
full_buffer? no
200-break-delete
200^done
(gdb)
expect: does "200-break-delete\r\n200^done\r\n(gdb) \r\n" (spawn_id exp11) match regular expression "\*\*\* DOSEXIT code.*"? no
"Ending remote debugging.*[(]gdb[)] \r\n[ ]*$"? no
"([\r\n]*((\^done)[\r\n]+[(]gdb[)] \r\n[ ]*$))"? yes
expect: set expect_out(0,string) "^done\r\n(gdb) \r\n"
expect: set expect_out(1,string) "^done\r\n(gdb) \r\n"
expect: set expect_out(2,string) "^done\r\n(gdb) \r\n"
expect: set expect_out(3,string) "^done"
expect: set expect_out(spawn_id) "exp11"
expect: set expect_out(buffer) "200-break-delete\r\n200^done\r\n(gdb) \r\n"
PASS: gdb.mi/mi2-basics.exp: break-delete (all) operation
send: sending "201-break-list\n" to { exp11 }
expect: does "" (spawn_id exp11) match regular expression "\*\*\* DOSEXIT code.*"? no
"Ending remote debugging.*[(]gdb[)] \r\n[ ]*$"? no
"([\r\n]*((.*\^done,BreakpointTable=\{.*,body=\[\]\})[\r\n]+[(]gdb[)] \r\n[ ]*$))"? no
"(^FOOBAR$)$"? no
"Undefined.* command:.*[(]gdb[)] \r\n[ ]*$"? no
"Ambiguous command.*[(]gdb[)] \r\n[ ]*$"? no
"Program exited with code [0-9]+.*[(]gdb[)] \r\n[ ]*$"? no
"The program is not being run.*[(]gdb[)] \r\n[ ]*$"? no
".*[(]gdb[)] \r\n[ ]*$"? no
"<return>"? no
"\(y or n\) "? no
full_buffer? no
201-break-list
201^done,BreakpointTable={nr_rows="0",nr_cols="6",hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[]}
(gdb)
expect: does "201-break-list\r\n201^done,BreakpointTable={nr_rows="0",nr_cols="6",hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[]}\r\n(gdb) \r\n" (spawn_id exp11) match regular expression "\*\*\* DOSEXIT code.*"? no
"Ending remote debugging.*[(]gdb[)] \r\n[ ]*$"? no
"([\r\n]*((.*\^done,BreakpointTable=\{.*,body=\[\]\})[\r\n]+[(]gdb[)] \r\n[ ]*$))"? yes
expect: set expect_out(0,string) "201-break-list\r\n201^done,BreakpointTable={nr_rows="0",nr_cols="6",hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[]}\r\n(gdb) \r\n"
expect: set expect_out(1,string) "201-break-list\r\n201^done,BreakpointTable={nr_rows="0",nr_cols="6",hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[]}\r\n(gdb) \r\n"
expect: set expect_out(2,string) "201-break-list\r\n201^done,BreakpointTable={nr_rows="0",nr_cols="6",hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[]}\r\n(gdb) \r\n"
expect: set expect_out(3,string) "201-break-list\r\n201^done,BreakpointTable={nr_rows="0",nr_cols="6",hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[]}"
expect: set expect_out(spawn_id) "exp11"
expect: set expect_out(buffer) "201-break-list\r\n201^done,BreakpointTable={nr_rows="0",nr_cols="6",hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[]}\r\n(gdb) \r\n"
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-01-31 21:10 ` Bob Rossi
@ 2005-01-31 21:21 ` Daniel Jacobowitz
2005-01-31 22:00 ` Bob Rossi
0 siblings, 1 reply; 20+ messages in thread
From: Daniel Jacobowitz @ 2005-01-31 21:21 UTC (permalink / raw)
To: GDB
On Mon, Jan 31, 2005 at 04:10:42PM -0500, Bob Rossi wrote:
> > You've left out your pattern, and the context. I recommend using
> > "exp_internal 1" to debug this sort of problem; that will show you what
> > expect is doing.
>
> OK, here's an example of the problem, here's the output for 2
> consecutive commands given to GDB.
>
> First, 200-break-delete is sent. The '200-break-delete' is in the
> 'expect_out(buffer)' output, which leads me to believe the testsuite is
> echoing the input command. This in itself is probably wrong. However, the
> '200-break-delete' is not in the matched regular expression
> 'expect_out(0,string)'.
expect: does "200-break-delete\r\n200^done\r\n(gdb) \r\n" (spawn_id exp11) match regular expression "\*\*\* DOSEXIT code.*"? no
"([\r\n]*((\^done)[\r\n]+[(]gdb[)] \r\n[ ]*$))"? yes
It's not in your $expect_out(0,string) because it didn't match your
first parenthesized bit. It's in expect_out(buffer) at this point.
> The next command, '200-break-list' is in both the 'expect_out(buffer)'
> and in the 'expect_out(0,string)'. This leads me to believe that there
> is something wrong with the regular expression matching. It can match
> things that it shouldn't, which could mask problems.
>
> I don't really understand what you are saying about 'GDB is echoing
> commands'. I do understand that when you are at the terminal running
> GDB, GDB allows the terminal to 'echo' the char's typed. However, if you
> fork/exec GDB, and send it a command, it will not 'echo' the data back
> to your process. Isn't this the way Expect works?
Expect works on a terminal. It's not instrumenting GDB to find out
what GDB is writing; it's accepting whatever input comes to its side of
the terminal. Which includes things echoed by the terminal. In
readline mode GDB turns off echo and provides the echo manually; in MI
mode, it does not touch the terminal, which echoes by default.
It's just your patterns that are producing a difference.
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-01-31 21:21 ` Daniel Jacobowitz
@ 2005-01-31 22:00 ` Bob Rossi
2005-01-31 22:04 ` Daniel Jacobowitz
0 siblings, 1 reply; 20+ messages in thread
From: Bob Rossi @ 2005-01-31 22:00 UTC (permalink / raw)
To: GDB
> > The next command, '200-break-list' is in both the 'expect_out(buffer)'
> > and in the 'expect_out(0,string)'. This leads me to believe that there
> > is something wrong with the regular expression matching. It can match
> > things that it shouldn't, which could mask problems.
> >
> > I don't really understand what you are saying about 'GDB is echoing
> > commands'. I do understand that when you are at the terminal running
> > GDB, GDB allows the terminal to 'echo' the char's typed. However, if you
> > fork/exec GDB, and send it a command, it will not 'echo' the data back
> > to your process. Isn't this the way Expect works?
>
> Expect works on a terminal. It's not instrumenting GDB to find out
> what GDB is writing; it's accepting whatever input comes to its side of
> the terminal. Which includes things echoed by the terminal. In
> readline mode GDB turns off echo and provides the echo manually; in MI
> mode, it does not touch the terminal, which echoes by default.
>
> It's just your patterns that are producing a difference.
OOOOOO, Thanks! I didn't realize Expect use's the terminal in this way,
I think re-writing the mi_gdb_test regex from this,
-re "\[\r\n\]*($pattern)\[\r\n\]+$mi_gdb_prompt\[ \]*$" {
to this,
-re "\[\r\n\]*$command(\[\r\n\]*(($pattern)\[\r\n\]+$mi_gdb_prompt\[ \]*$))" {
solve's the problem!
It also tighten's up the MI output command matching, I honestly don't
know how the -break-delete was getting eaten in the regular expression,
unless $pattern happened to have a .*. Oops, in that case, I guess we
aren't really validation much, anything could have come out of GDB, and
it probably would have passed.
I'll consider adding this patch to the testsuite once I find the rest of
the testcase's that make the MI output command syntax checker fail.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-01-31 22:00 ` Bob Rossi
@ 2005-01-31 22:04 ` Daniel Jacobowitz
2005-01-31 22:12 ` Bob Rossi
0 siblings, 1 reply; 20+ messages in thread
From: Daniel Jacobowitz @ 2005-01-31 22:04 UTC (permalink / raw)
To: GDB
On Mon, Jan 31, 2005 at 05:00:50PM -0500, Bob Rossi wrote:
> It also tighten's up the MI output command matching, I honestly don't
> know how the -break-delete was getting eaten in the regular expression,
> unless $pattern happened to have a .*. Oops, in that case, I guess we
> aren't really validation much, anything could have come out of GDB, and
> it probably would have passed.
Your pattern doesn't start with an anchor. -break-delete wasn't eaten;
we just started matching after it.
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-01-31 22:04 ` Daniel Jacobowitz
@ 2005-01-31 22:12 ` Bob Rossi
2005-02-01 3:52 ` Daniel Jacobowitz
0 siblings, 1 reply; 20+ messages in thread
From: Bob Rossi @ 2005-01-31 22:12 UTC (permalink / raw)
To: GDB
On Mon, Jan 31, 2005 at 05:03:54PM -0500, Daniel Jacobowitz wrote:
> On Mon, Jan 31, 2005 at 05:00:50PM -0500, Bob Rossi wrote:
> > It also tighten's up the MI output command matching, I honestly don't
> > know how the -break-delete was getting eaten in the regular expression,
> > unless $pattern happened to have a .*. Oops, in that case, I guess we
> > aren't really validation much, anything could have come out of GDB, and
> > it probably would have passed.
>
> Your pattern doesn't start with an anchor. -break-delete wasn't eaten;
> we just started matching after it.
Please forgive my ignorance, I've been reading online as much as
possible to understand tcl/expect ...
I understand how anchors work, however, I didn't realize you could start
matching in the middle of what the 'buffer' is. If it started matching
after it, does that mean it's skipped forever? So basically, you can
match a subset of the output, and the rest is lost (never matched)?
If that's the case, the testsuite for the MI is matching even less than
I thought. GDB could output almost anything, but then just have to match
the last string, and the testcase would pass, correct?
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-01-31 22:12 ` Bob Rossi
@ 2005-02-01 3:52 ` Daniel Jacobowitz
2005-02-01 14:20 ` Bob Rossi
0 siblings, 1 reply; 20+ messages in thread
From: Daniel Jacobowitz @ 2005-02-01 3:52 UTC (permalink / raw)
To: GDB
On Mon, Jan 31, 2005 at 05:12:47PM -0500, Bob Rossi wrote:
> On Mon, Jan 31, 2005 at 05:03:54PM -0500, Daniel Jacobowitz wrote:
> > On Mon, Jan 31, 2005 at 05:00:50PM -0500, Bob Rossi wrote:
> > > It also tighten's up the MI output command matching, I honestly don't
> > > know how the -break-delete was getting eaten in the regular expression,
> > > unless $pattern happened to have a .*. Oops, in that case, I guess we
> > > aren't really validation much, anything could have come out of GDB, and
> > > it probably would have passed.
> >
> > Your pattern doesn't start with an anchor. -break-delete wasn't eaten;
> > we just started matching after it.
>
> Please forgive my ignorance, I've been reading online as much as
> possible to understand tcl/expect ...
>
> I understand how anchors work, however, I didn't realize you could start
> matching in the middle of what the 'buffer' is. If it started matching
> after it, does that mean it's skipped forever? So basically, you can
> match a subset of the output, and the rest is lost (never matched)?
That's correct.
> If that's the case, the testsuite for the MI is matching even less than
> I thought. GDB could output almost anything, but then just have to match
> the last string, and the testcase would pass, correct?
Yes. Sometimes this is even deliberate - fixing it would be
interesting, but probably quite hard.
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-02-01 3:52 ` Daniel Jacobowitz
@ 2005-02-01 14:20 ` Bob Rossi
2005-02-01 14:23 ` Daniel Jacobowitz
0 siblings, 1 reply; 20+ messages in thread
From: Bob Rossi @ 2005-02-01 14:20 UTC (permalink / raw)
To: GDB
On Mon, Jan 31, 2005 at 10:52:36PM -0500, Daniel Jacobowitz wrote:
> On Mon, Jan 31, 2005 at 05:12:47PM -0500, Bob Rossi wrote:
> > On Mon, Jan 31, 2005 at 05:03:54PM -0500, Daniel Jacobowitz wrote:
> > > On Mon, Jan 31, 2005 at 05:00:50PM -0500, Bob Rossi wrote:
> > > > It also tighten's up the MI output command matching, I honestly don't
> > > > know how the -break-delete was getting eaten in the regular expression,
> > > > unless $pattern happened to have a .*. Oops, in that case, I guess we
> > > > aren't really validation much, anything could have come out of GDB, and
> > > > it probably would have passed.
> > >
> > > Your pattern doesn't start with an anchor. -break-delete wasn't eaten;
> > > we just started matching after it.
> >
> > Please forgive my ignorance, I've been reading online as much as
> > possible to understand tcl/expect ...
> >
> > I understand how anchors work, however, I didn't realize you could start
> > matching in the middle of what the 'buffer' is. If it started matching
> > after it, does that mean it's skipped forever? So basically, you can
> > match a subset of the output, and the rest is lost (never matched)?
>
> That's correct.
>
> > If that's the case, the testsuite for the MI is matching even less than
> > I thought. GDB could output almost anything, but then just have to match
> > the last string, and the testcase would pass, correct?
>
> Yes. Sometimes this is even deliberate - fixing it would be
> interesting, but probably quite hard.
Could we have GDB turn off echo'ing with an MI command.
-mi-disable-echo
I think that would fix this entire problem.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-02-01 14:20 ` Bob Rossi
@ 2005-02-01 14:23 ` Daniel Jacobowitz
2005-02-01 14:39 ` Bob Rossi
0 siblings, 1 reply; 20+ messages in thread
From: Daniel Jacobowitz @ 2005-02-01 14:23 UTC (permalink / raw)
To: GDB
On Tue, Feb 01, 2005 at 09:20:08AM -0500, Bob Rossi wrote:
> Could we have GDB turn off echo'ing with an MI command.
>
> -mi-disable-echo
>
> I think that would fix this entire problem.
I don't think there's a problem to be fixed; and it wouldn't "fix"
anything, since you'd still have to go through the testsuite, add
leading anchors, and make sure any other messages were handled. Plus
it would mean teaching the MI driver to mess with terminal modes.
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-02-01 14:23 ` Daniel Jacobowitz
@ 2005-02-01 14:39 ` Bob Rossi
2005-02-01 15:20 ` Daniel Jacobowitz
2005-02-01 15:58 ` Dave Korn
0 siblings, 2 replies; 20+ messages in thread
From: Bob Rossi @ 2005-02-01 14:39 UTC (permalink / raw)
To: GDB
On Tue, Feb 01, 2005 at 09:23:15AM -0500, Daniel Jacobowitz wrote:
> On Tue, Feb 01, 2005 at 09:20:08AM -0500, Bob Rossi wrote:
> > Could we have GDB turn off echo'ing with an MI command.
> >
> > -mi-disable-echo
> >
> > I think that would fix this entire problem.
>
> I don't think there's a problem to be fixed; and it wouldn't "fix"
> anything, since you'd still have to go through the testsuite, add
> leading anchors, and make sure any other messages were handled. Plus
> it would mean teaching the MI driver to mess with terminal modes.
Well, I'm trying to take testing the output of the MI testsuite to the
next level. Instead of just matching regular expressions, and letting
any output from GDB before the "match" get by, I'm trying to match only
output that has the correct MI output syntax.
Unfortunately, as of know, there are 2 holes in the testsuite that I have
found so far. The first is that Expect also matches the "echoed" data.
This data isn't even seen by real front end clients, and, it's not even
really the output of GDB. So this data must be removed from the output
stream if the syntax of the MI command is going to be validated.
Second, it looks as if extra data could come out of GDB, and still pass
the testsuite. This certainly would stop me from validating the syntax,
since, there would be no point in validating only 9/10 of the output of
an MI output command. Also, if GDB was outputting some extra data, front
end clients would most likely break, while the testsuite could continue
passing just fine.
I would do the work of adding, the leading anchors and making sure all
other loose ends were tied up.
With all of this in mind, does disabling the 'echoing' of the terminal
sound reasonable?
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-02-01 14:39 ` Bob Rossi
@ 2005-02-01 15:20 ` Daniel Jacobowitz
2005-02-01 15:38 ` Bob Rossi
2005-02-01 15:58 ` Dave Korn
1 sibling, 1 reply; 20+ messages in thread
From: Daniel Jacobowitz @ 2005-02-01 15:20 UTC (permalink / raw)
To: GDB
On Tue, Feb 01, 2005 at 09:39:17AM -0500, Bob Rossi wrote:
> With all of this in mind, does disabling the 'echoing' of the terminal
> sound reasonable?
I still think you want to handle this in TCL, not by playing terminal
control games in GDB itself.
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-02-01 15:20 ` Daniel Jacobowitz
@ 2005-02-01 15:38 ` Bob Rossi
0 siblings, 0 replies; 20+ messages in thread
From: Bob Rossi @ 2005-02-01 15:38 UTC (permalink / raw)
To: GDB
On Tue, Feb 01, 2005 at 10:19:50AM -0500, Daniel Jacobowitz wrote:
> On Tue, Feb 01, 2005 at 09:39:17AM -0500, Bob Rossi wrote:
> > With all of this in mind, does disabling the 'echoing' of the terminal
> > sound reasonable?
>
> I still think you want to handle this in TCL, not by playing terminal
> control games in GDB itself.
OK, I'll look into this, I do see how it could be very difficult,
especially if the command being echo'd could contain newlines...
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: How do I get regexp from expect at gdb_expect?
2005-02-01 14:39 ` Bob Rossi
2005-02-01 15:20 ` Daniel Jacobowitz
@ 2005-02-01 15:58 ` Dave Korn
2005-02-01 16:10 ` 'Bob Rossi'
1 sibling, 1 reply; 20+ messages in thread
From: Dave Korn @ 2005-02-01 15:58 UTC (permalink / raw)
To: 'Bob Rossi', 'GDB'
> -----Original Message-----
> From: gdb-owner On Behalf Of Bob Rossi
> Sent: 01 February 2005 14:39
> With all of this in mind, does disabling the 'echoing' of the terminal
> sound reasonable?
.... just so long as you create a duplicate of the entire existing testsuite
that runs without echos, in order to be sure that _both_ modes work .... <g>
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How do I get regexp from expect at gdb_expect?
2005-02-01 15:58 ` Dave Korn
@ 2005-02-01 16:10 ` 'Bob Rossi'
0 siblings, 0 replies; 20+ messages in thread
From: 'Bob Rossi' @ 2005-02-01 16:10 UTC (permalink / raw)
To: Dave Korn; +Cc: 'GDB'
On Tue, Feb 01, 2005 at 03:58:40PM -0000, Dave Korn wrote:
> > -----Original Message-----
> > From: gdb-owner On Behalf Of Bob Rossi
> > Sent: 01 February 2005 14:39
>
> > With all of this in mind, does disabling the 'echoing' of the terminal
> > sound reasonable?
>
>
> .... just so long as you create a duplicate of the entire existing testsuite
> that runs without echos, in order to be sure that _both_ modes work .... <g>
Honestly, I could be way off on this, but I don't think that the 'echo'
feature of the MI testsuite is testing anything important. In fact, the
front ends using GDB in this way will never see the 'echo'd' data.
I sort of think it would make complete sense to have Expect not look at
the 'echo'd' data from the terminal. After all, the MI interface wasn't
meant to be run on the terminal ...
Bob Rossi
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2005-02-01 16:10 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-29 2:57 How do I get regexp from expect at gdb_expect? Bob Rossi
2005-01-29 3:09 ` Paul Hilfinger
2005-01-29 3:11 ` Bob Rossi
2005-01-29 3:16 ` Bob Rossi
2005-01-31 15:07 ` Bob Rossi
2005-01-31 16:28 ` Daniel Jacobowitz
2005-01-31 16:59 ` Bob Rossi
2005-01-31 21:10 ` Bob Rossi
2005-01-31 21:21 ` Daniel Jacobowitz
2005-01-31 22:00 ` Bob Rossi
2005-01-31 22:04 ` Daniel Jacobowitz
2005-01-31 22:12 ` Bob Rossi
2005-02-01 3:52 ` Daniel Jacobowitz
2005-02-01 14:20 ` Bob Rossi
2005-02-01 14:23 ` Daniel Jacobowitz
2005-02-01 14:39 ` Bob Rossi
2005-02-01 15:20 ` Daniel Jacobowitz
2005-02-01 15:38 ` Bob Rossi
2005-02-01 15:58 ` Dave Korn
2005-02-01 16:10 ` 'Bob Rossi'
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox