From: Yao Qi <yao@codesourcery.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: GDB Patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Fix gdb.trace/mi-traceframe-changed.exp to check for target trace support
Date: Fri, 10 Jan 2014 02:17:00 -0000 [thread overview]
Message-ID: <52CF57CF.9030503@codesourcery.com> (raw)
In-Reply-To: <52CF4B40.3030500@codesourcery.com>
On 01/10/2014 09:22 AM, Yao Qi wrote:
> On 01/10/2014 05:21 AM, Sergio Durigan Junior wrote:
>> > gdb.trace/mi-traceframe-changed.exp was running without actually
>> > checking if the target supported tracing or not. So I wrote this patch
>> > to fix the issue.
> The patch looks a right fix. Any tracepoint related tests should check
> whether target supports tracing or not at first.
>
> I did it through an oversight when I wrote this case.
Ah, I read the patch and mi-traceframe-change.exp again, and find my
last comment is wrong. Sorry for the confusion.
The first half of mi-traceframe-changed.exp (test_tfind_tfile) is to
test "=traceframe-changed" on tfile target, which is produced by
tfile.c. It is expected to run on native debugging. The second half
of mi-traceframe-changed.exp (test_tfile_remote) is to test
"=traceframe-changed" on remote target with a gdbserver connected. We
can see mi-traceframe-changed.exp has already have the code to check
target supports tracing or not.
The root cause is that tfile.c isn't portable and unable to produce
trace file properly for s390x. Search FIXME in it.
We should skip test_find_tfile for targets other than x86-linux or
x86_64-linux. Alternatively, we can modify tfile.c for s390x, but I
think "generating tfile on a unsupported-tracing target" isn't useful.
--
Yao (é½å°§)
next prev parent reply other threads:[~2014-01-10 2:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-09 21:21 Sergio Durigan Junior
2014-01-10 1:23 ` Yao Qi
2014-01-10 2:17 ` Yao Qi [this message]
2014-01-10 3:58 ` Sergio Durigan Junior
2014-01-10 10:57 ` Pedro Alves
2014-01-10 17:31 ` Sergio Durigan Junior
2014-01-10 18:57 ` Pedro Alves
2014-01-10 20:41 ` Sergio Durigan Junior
2014-01-13 17:12 ` Pedro Alves
2014-01-15 20:37 ` Sergio Durigan Junior
2014-01-16 18:20 ` 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=52CF57CF.9030503@codesourcery.com \
--to=yao@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=sergiodj@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).