From: Pedro Alves <palves@redhat.com>
To: Yao Qi <yao@codesourcery.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Tweak gdb.base/async.exp
Date: Fri, 06 Jun 2014 10:15:00 -0000 [thread overview]
Message-ID: <539194B5.7090501@redhat.com> (raw)
In-Reply-To: <1402040654-11738-1-git-send-email-yao@codesourcery.com>
On 06/06/2014 08:44 AM, Yao Qi wrote:
> I see two fails in async.exp on arm-none-eabi target:
>
> nexti&^M
> (gdb) 0x000001ba 14 x = 5; x = 5;^M
> completed.^M
> FAIL: gdb.base/async.exp: nexti&
> finish&^M
> Run till exit from #0 0x000001ba in foo () at /scratch/yqi/arm-none-eabi-lite/src/gdb-trunk/gdb/testsuite/gdb.base/async.c:14^M
> (gdb) 0x000001e6 in main () at /scratch/yqi/arm-none-eabi-lite/src/gdb-trunk/gdb/testsuite/gdb.base/async.c:32^M
> 32 y = foo ();^M
> Value returned is $1 = 8^M
> completed.^M
> FAIL: gdb.base/async.exp: finish&
>
> The corresponding test is "test_background "nexti&" "" ".*y = 3.*"",
> and it assumes that GDB "nexti" into the next source line. It is wrong
> on arm. After "nexti", it still stops at the same source line, and it
> fails.
Note: "nexti" is supposed to skip function calls, but the test
isn't actually testing that works. It'd be nice if it
did. E.g., we'd add:
for (i = 0; i < 2; i++)
foo ();
and "stepi" the first loop iteration looking for the
first address that has a "backtrace" with two frames. The
"call/jmp" instruction that nexti& should step over would
be the address the program was stopped before the last
stepi. We'd run to the address again (for the second iteration),
and do a "nexti&", making sure we land on the next
instruction, after the call returns.
But TBC, since the test doesn't do this today, it's fine to
fix it assuming nexti is just like stepi. With in mind ...
> +# We may nexti into the same source line or into the next source line.
> +# In the former case, the current PC is printed out. We match either
> +# of them.
> +test_background "nexti&" "" ".*( 0x0*$next_insn_addr|y = 3).*"
I'd rather always only check by address. It's simpler and it'd
prevent a bug where we should still end on the same line, like
on ARM, but nexti steps too much and only stops on the
next line.
I think we just need to do:
- x = 5; x = 5;
+ x = 5; x = 5; x = 5;
in the C file? 'x' is volatile, so that'd always makes us land
in the middle of the line.
> +# The PC address is displayed if PC is in the middle of a source line.
> test_background "finish&" \
> - "Run till exit from #0 foo \\(\\) at.*async.c.*\r\n" \
> + "Run till exit from #0 ($hex in )?foo \\(\\) at.*async.c.*\r\n" \
This can then be unconditional too.
> ".*$hex in main \\(\\) at.*async.c.*y = foo \\(\\).*Value returned is.*= 8.*"
>
> set jump_here [gdb_get_line_number "jump here"]
--
Pedro Alves
next prev parent reply other threads:[~2014-06-06 10:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-06 7:46 Yao Qi
2014-06-06 10:15 ` Pedro Alves [this message]
2014-06-06 12:33 ` Yao Qi
2014-06-06 12:48 ` Pedro Alves
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=539194B5.7090501@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=yao@codesourcery.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