From: Hui Zhu <teawater@gmail.com>
To: Pedro Alves <palves@redhat.com>
Cc: Eli Zaretskii <eliz@gnu.org>, Hui Zhu <hui_zhu@mentor.com>,
gdb-patches ml <gdb-patches@sourceware.org>,
Marc Khouzam <marc.khouzam@ericsson.com>
Subject: Re: [PATCH] add -s option to make -break-insert support dprintf
Date: Tue, 16 Apr 2013 09:31:00 -0000 [thread overview]
Message-ID: <CANFwon39WwkSx_D4a=B7gzKJ+usRTqtuB=T0cOAc15Mar_38Cw@mail.gmail.com> (raw)
In-Reply-To: <516C2972.1030802@redhat.com>
On Tue, Apr 16, 2013 at 12:23 AM, Pedro Alves <palves@redhat.com> wrote:
> On 04/15/2013 03:57 PM, Hui Zhu wrote:
>> On Fri, Apr 12, 2013 at 7:34 PM, Pedro Alves <palves@redhat.com> wrote:
>>> On 04/12/2013 11:38 AM, Hui Zhu wrote:
>>>>>>
>>>>>> I still get:
>>>>>>
>>>>>> $ make check gdbserver RUNTESTFLAGS="--target_board=native-gdbserver mi-dprintf.exp"
>>>> This part is really odd.
>>>> In my part, without "sleep 1" will random get fail with "Set dprintf
>>>> style to agent ".
>>>> The reason of fail is test try to check the output before it call
>>>> send_gdb "set dprintf-style agent\n".
>>>> This is why I add a "sleep 1" for it.
>>>>
>>>> But looks it still not OK in your part, so I change it to:
>>>> mi_gdb_test "pwd" ".*"
>>>>
>>>> If it is still not OK in your part, I suggest remove this part of test
>>>> because it is not very important for this test. The "set
>>>> dprintf-style agent" is tested in "dprintf.exp".
>>>>
>>>
>>> No, it's not okay. And it's not okay to just sweep it under the rug.
>>>
>>> I believe the problem is that the test is sending CLI resumption commands:
>>>
>>> + mi_gdb_test "continue" ".*At foo entry.*arg=1234, g=1234.*" "mi 1st dprintf"
>>> + mi_gdb_test "continue" ".*At foo entry.*arg=1235, g=2222.*" "mi 2nd dprintf"
>>>
>>> "continue" sent from MI causes two prompts to appear:
>>>
>>> (gdb)
>>> continue
>>> &"continue\n"
>>> ~"Continuing.\n"
>>> ^running
>>> *running,thread-id="all"
>>> (gdb)
>>> =breakpoint-modified,bkpt={number="6",type="breakpoint",disp="keep",enabled="y",addr="0x000000000045a3ff",func="main",file="../../src/gdb/gdb.c",fullname="/home/pedro/gdb/mygit/src/gdb/gdb.c",line="32",thread-groups=["i1"],times="1",original-location="/home/pedro/gdb/mygit/src/gdb/gdb.c:32"}
>>> ~"\nBreakpoint "
>>> ~"6, main (argc=1, argv=0x7fffffffdc58) at ../../src/gdb/gdb.c:32\n"
>>> ~"32\t args.use_windows = 0;\n"
>>> *stopped,reason="breakpoint-hit",disp="keep",bkptno="6",frame={addr="0x000000000045a3ff",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffdc58"}],file="../../src/gdb/gdb.c",fullname="/home/pedro/gdb/mygit/src/gdb/gdb.c",line="32"},thread-id="1",stopped-threads="all",core="0"
>>> (gdb)
>>>
>>> and that is confusing the test (the regex for the prompt is probably stopping
>>> at the first prompt sometimes).
>>>
>>> The test should be adjusted to do MI -exec-continue instead, with
>>> mi_execute_to "exec-continue", mi_send_resuming_command "exec-continue"
>>> or something like that.
>>>
>>> BTW, you don't need to use gdbserver to trigger the issue. Native
>>> works too. E.g., leave this running, and eventually, it should FAIL
>>> and stop:
>>>
>>> $ (set -e; while true; do make check RUNTESTFLAGS="mi-dprintf.exp"; done)
>>>
>>> gdb/contrib/expect-read1.sh probably makes this reproducible all
>>> the time, though I haven't tried.
>>
>>
>> Post a new version change the continue to mi_run_cmd, gdb_expect and
>> mi_send_resuming_command.
>> It works OK with loop test.
>
> $ (set -e; while true; do make check RUNTESTFLAGS="mi-dprintf.exp"; done)
> ...
> Running ../../../src/gdb/testsuite/gdb.mi/mi-dprintf.exp ...
> FAIL: gdb.mi/mi-dprintf.exp: gdb: mi 1st dprintf stop (timeout)
> FAIL: gdb.mi/mi-dprintf.exp: mi 1st dprintf, agent
> FAIL: gdb.mi/mi-dprintf.exp: mi 2nd dprintf, agent
> FAIL: gdb.mi/mi-dprintf.exp: mi info dprintf second time
>
> Did you try gdb/contrib/expect-read1.sh ?
What I did is:
EXPECT=../contrib/expect-read1.sh make check RUNTESTFLAGS="mi-dprintf.exp"
EXPECT=../contrib/expect-read1.sh make check
RUNTESTFLAGS="--target_board=native-gdbserver mi-dprintf.exp"
And it is OK in my part. I did something wrong?
Thanks,
Hui
>
> --
> Pedro Alves
>
next prev parent reply other threads:[~2013-04-16 1:56 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-28 17:44 Hui Zhu
2013-03-28 18:37 ` Eli Zaretskii
2013-03-29 16:12 ` Hui Zhu
2013-03-29 16:13 ` Eli Zaretskii
2013-04-09 23:31 ` Pedro Alves
2013-04-10 19:44 ` Marc Khouzam
2013-04-10 19:45 ` Pedro Alves
2013-04-11 6:15 ` Hui Zhu
2013-04-11 17:47 ` Pedro Alves
2013-04-12 14:56 ` Hui Zhu
2013-04-12 15:22 ` Pedro Alves
2013-04-15 18:59 ` Hui Zhu
2013-04-15 19:41 ` Pedro Alves
2013-04-16 9:31 ` Hui Zhu [this message]
2013-04-22 1:25 ` Yao Qi
2013-04-12 16:03 ` Eli Zaretskii
2013-04-13 14:16 ` Tom Tromey
2013-04-15 18:04 ` Hui Zhu
2013-04-15 19:36 ` Pedro Alves
2013-04-16 9:31 ` Hui Zhu
2013-04-22 0:18 ` Tom Tromey
2013-04-22 9:07 ` Hui Zhu
2013-04-25 6:51 ` Tom Tromey
2013-05-03 5:43 ` Hui Zhu
2013-05-07 20:50 ` Tom Tromey
2013-05-10 10:57 ` Hui Zhu
2013-05-10 15:24 ` Tom Tromey
2013-05-11 2:38 ` Hui Zhu
2013-05-11 7:29 ` Eli Zaretskii
2013-05-13 3:39 ` Hui Zhu
2013-05-13 15:55 ` Eli Zaretskii
2013-05-14 4:56 ` Hui Zhu
2013-05-20 7:31 ` Hui Zhu
2013-05-20 15:44 ` Eli Zaretskii
2013-05-21 4:25 ` Hui Zhu
2013-05-21 8:10 ` [patch] Fix racy FAILs due to "read1" [Re: [PATCH] add -s option to make -break-insert support dprintf] Jan Kratochvil
2013-05-21 9:30 ` Hui Zhu
2013-05-21 15:01 ` [commit] " Jan Kratochvil
2013-05-22 1:05 ` Hui Zhu
2013-05-23 14:03 ` [patch] Fix racy FAILs #2 " Jan Kratochvil
2013-05-24 15:37 ` [commit] " Jan Kratochvil
2013-05-27 11:02 ` Hui Zhu
2013-05-13 16:23 ` [PATCH] add -s option to make -break-insert support dprintf Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANFwon39WwkSx_D4a=B7gzKJ+usRTqtuB=T0cOAc15Mar_38Cw@mail.gmail.com' \
--to=teawater@gmail.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=hui_zhu@mentor.com \
--cc=marc.khouzam@ericsson.com \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox