Dejagnu testing issue

Dejagnu testing issue

[Kevin Pouget]

Hello,

I'm trying to build regression tests with DejaGNU, but I can't see how
to solve this problem:

how can I read a value from what GDB writes, and use it later to
validate some tests.

For instance, the pid:

I know it's it "info inferiors" --> ".*process HERE .*", I would like
to save it, and then do something like "detach", "attach $PID"

(don't get me wrong, I know there are some alternatives to get the
PID, but I really want to read it from a GDB command)


By the way, is it a normal that I can't set a thread breakpoint this way:

> break <somewhere> thread $_thread
> Junk after thread keyword.

(that would have bypassed the problem described above !)


Thanks,

Kevin

Re: Dejagnu testing issue

[Jan Kratochvil]

On Thu, 20 Oct 2011 16:47:10 +0200, Kevin Pouget wrote:
> how can I read a value from what GDB writes, and use it later to
> validate some tests.

See for example gdb.base/attach-pie-noexec.exp and $expect_out(1,string)
there.


Regards,
Jan

Re: Dejagnu testing issue

[Tom Tromey]

>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:

Kevin> how can I read a value from what GDB writes, and use it later to
Kevin> validate some tests.

Kevin> For instance, the pid:

Kevin> I know it's it "info inferiors" --> ".*process HERE .*", I would like
Kevin> to save it, and then do something like "detach", "attach $PID"

Kevin> (don't get me wrong, I know there are some alternatives to get the
Kevin> PID, but I really want to read it from a GDB command)

You can do it, with some difficulty, using gdb_test_multiple and
examining expect_out in your match.  This is done in some places in the
code.

Kevin> By the way, is it a normal that I can't set a thread breakpoint this way:

>> break <somewhere> thread $_thread
>> Junk after thread keyword.

Kevin> (that would have bypassed the problem described above !)

Yes, the 'thread' modifier just takes an integer.
You can use eval though:

    eval "break ... thread %d", $_thread

Tom

Re: Dejagnu testing issue

[Kevin Pouget]

On Thu, Oct 20, 2011 at 5:02 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:
>
> Kevin> how can I read a value from what GDB writes, and use it later to
> Kevin> validate some tests.
>
> Kevin> For instance, the pid:
>
> Kevin> I know it's it "info inferiors" --> ".*process HERE .*", I would like
> Kevin> to save it, and then do something like "detach", "attach $PID"
>
> Kevin> (don't get me wrong, I know there are some alternatives to get the
> Kevin> PID, but I really want to read it from a GDB command)
>
> You can do it, with some difficulty, using gdb_test_multiple and
> examining expect_out in your match.  This is done in some places in the
> code.

Thanks for your reponses (and sorry for posted on the wrong
mailing-list, it was supposed to go to gdb@sourceware.org)

for the record, here is the way to get the pid based on "expect_out":

gdb_test_multiple "info inferior" "list inferiors" {
    -re ".* \* 1.*process (\[0-9\]*).*$gdb_prompt $" {
	set pid $expect_out(1,string)
	pass "list inferiors"
    }
}


> Kevin> By the way, is it a normal that I can't set a thread breakpoint this way:
>
>>> break <somewhere> thread $_thread
>>> Junk after thread keyword.
>
> Kevin> (that would have bypassed the problem described above !)
>
> Yes, the 'thread' modifier just takes an integer.
> You can use eval though:
>
>    eval "break ... thread %d", $_thread


from a user point of view, it's not obvious why $_thread is not an
integer / what it actually is, but I guess there are some background
reasons. Anyway, output parsing and `eval' did the trick, thanks


Kevin


Kevin

Re: Dejagnu testing issue

[Jan Kratochvil]

On Fri, 21 Oct 2011 10:14:42 +0200, Kevin Pouget wrote:
> for the record, here is the way to get the pid based on "expect_out":
> 
> gdb_test_multiple "info inferior" "list inferiors" {
>     -re ".* \* 1.*process (\[0-9\]*).*$gdb_prompt $" {
> 	set pid $expect_out(1,string)
> 	pass "list inferiors"
>     }
> }

While it works to make it working as was intended it could be for example:

gdb_test_multiple "info inferior" "list inferiors" {
    -re "\r\n\\* 1 *process (\[0-9\]*) .*\r\n$gdb_prompt $" {
        set pid $expect_out(1,string)
        pass "list inferiors"
    }
}

Initial .* is redundant, start of the expect string is not anchored.

\* is equal to * as the first level of backslashes is parsed by TCL
interpreter, not by the regex compiler.

If one fixes \* -> \\* to really match an asterisk it no longer matches.
The asterisk is preceded by a newline, not by a space as in your regex string.


Regards,
Jan

Re: Dejagnu testing issue

[Kevin Pouget]

On Fri, Oct 21, 2011 at 10:32 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Fri, 21 Oct 2011 10:14:42 +0200, Kevin Pouget wrote:
>> for the record, here is the way to get the pid based on "expect_out":
>>
>> gdb_test_multiple "info inferior" "list inferiors" {
>>     -re ".* \* 1.*process (\[0-9\]*).*$gdb_prompt $" {
>>       set pid $expect_out(1,string)
>>       pass "list inferiors"
>>     }
>> }
>
> While it works to make it working as was intended it could be for example:
>
> gdb_test_multiple "info inferior" "list inferiors" {
>    -re "\r\n\\* 1 *process (\[0-9\]*) .*\r\n$gdb_prompt $" {
>        set pid $expect_out(1,string)
>        pass "list inferiors"
>    }
> }
>
> Initial .* is redundant, start of the expect string is not anchored.
>
> \* is equal to * as the first level of backslashes is parsed by TCL
> interpreter, not by the regex compiler.
>
> If one fixes \* -> \\* to really match an asterisk it no longer matches.
> The asterisk is preceded by a newline, not by a space as in your regex string.

Thanks for this precision, the Dejagnu testsuite is not the easiest
tool to master ...

> Initial .* is redundant, start of the expect string is not anchored.

just with this comment, I noticed that a lot of my tests not wrong,
but not correctly written at least, and almost the same for
> If one fixes \* -> \\* to really match an asterisk it no longer matches.


Cordially,

Kevin