This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fully anchor mi_gdb_test expected results.


On Thu, Aug 04, 2005 at 12:11:21AM -0400, Daniel Jacobowitz wrote:
> On Wed, Aug 03, 2005 at 10:50:45PM -0400, Bob Rossi wrote:
> > Hi,
> > 
> > This testsuite change simply does several simple things. First, when
> > creating a new pty for the inferior, this change turn's terminal
> > echo'ing off. This allows the expected results back from GDB/MI to not
> > have to have the command sent to GDB in it. The surprising thing with 
> > this change is that even when GDB shares the terminal's PTY with the 
> > inferior, not putting the echo'd data in the expected command still
> > works.
> > 
> > The only other notable change here is this,
> > 
> >    -   -re "\[\r\n\]*($pattern)\[\r\n\]+$mi_gdb_prompt\[ \]*$" {
> >    +   -re "^(.*$pattern\[\r\n\]+$mi_gdb_prompt\[ \]*)$" {
> > 
> > that is the change that fully anchor's the output from GDB. The reason
> > this is necessary is because with this change, I can grab the full
> > response from GDB for a command. With this response I can do syntax
> > checking with the parser that I wrote.
> > 
> > What does everyone think?
> 
> We're not using readline in this mode; we shouldn't have particularly
> funny wrapping issues on the terminal, should we?  Can we match the
> echoing instead of having to mess with stty?

Correct, this has nothing to do with readline. There are several
problems with allowing the terminal to echo while testing the GDB/MI
output. Sorry in advance for the long Email.

- The first problem is that this is most likely not the scenario
with most front ends. I will risk making a fool of myself by stating
that I think most front end's probably communicate with GDB over a pipe,
in which case, the echo'ing is not happening, and FE's do not have to
deal with this data in the response.

- The testsuite has several ares (which I modified in patch), that have
  .* at the beggining of there regex, to bypass the echo'd data. As an
  example,
      - ".*123\\^error,msg=\"mi_cmd_disassemble: Invalid filename.\"" \
      + "123\\^error,msg=\"mi_cmd_disassemble: Invalid filename.\"" \

      or

      - -re ".*102-break-delete\r\n102\\\^done\r\n$mi_gdb_prompt$" {
      + -re "102\\\^done\r\n$mi_gdb_prompt$" {

  I'm not convinced the .* _needs_ to be in the patterns above, so this
  point might be a minor point. The case below might take into account
  the above case.

- Even worse, the general purpose MI "expect" pattern looks like,

    -re "\[\r\n\]*($pattern)\[\r\n\]+$mi_gdb_prompt\[ \]*$" {

  which simply allows any data at the beggining of the match. So I could
  easily modify an MI command to output "HAHAHA, YOU CAN'T TEST ME", as
  the first thing it outputs, and it would go unnoticed in the
  testsuite. Probably the reason this could not have been done before is
  because the MI input command was being echo'd back, and it would be
  complicated to match that data.

- Now, my personal favorite. In order to parse the MI output command, I
  need only the MI output command, not the echo'd MI input command
  given. So, in order to get only the MI output command, I would have to
  do 1 of several things.
     - Turn terminal echo'ing off. (the safest)
     - Make sure every test has the GDB expected pattern be the absolute
       beginning of the MI output command. Then I could assume in the
       general purpose match that the pattern was the beggining. It
       would look something like this,
         -re "^.*($pattern\[\r\n\]+$mi_gdb_prompt\[ \]*)$" {
       I don't like this approach because it makes the testcase do
       specific things in order to make sure that the syntax checking
       was done properly.

What do you think of all of this?

Thanks,
Bob Rossi


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]