From: Pedro Alves <palves@redhat.com>
To: Sanjoy Das <sanjoy@playingwithpointers.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 3/3] Add a test case for the jit-reader interface.
Date: Wed, 17 Oct 2012 16:29:00 -0000 [thread overview]
Message-ID: <507EDCF1.6080305@redhat.com> (raw)
In-Reply-To: <1349696849-9056-4-git-send-email-sanjoy@playingwithpointers.com>
I've looked at the patch and noticed a few minor issues.
On 10/08/2012 12:47 PM, Sanjoy Das wrote:
> --- /dev/null
> +++ b/gdb/testsuite/gdb.base/jit-reader.exp
> @@ -0,0 +1,72 @@
> +# Copyright 2011-2012 Free Software Foundation, Inc.
> +
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program. If not, see <http://www.gnu.org/licenses/>.
> +
> +standard_testfile jithost.c
> +
> +if ![istarget x86_64-*-linux-gnu*] then {
We should move aways from strict istarget checks on x86_64/i686,
due to -m32 or -mx32, or even i686 with -m64. One possibility is:
if { (![istarget x86_64-*-*] && ![istarget i?86-*-*]) || ![is_lp64_target] } {
But I'm not sure whether the test should run on x32.
> + untested jit-reader.exp
> + return -1;
> +}
> +
> +if {[skip_shlib_tests]} {
> + untested jit-reader.exp
These should be silent. IOW, remove the untested calls.
> + return -1
> +}
> +
> +if {[get_compiler_info]} {
> + warning "Could not get compiler info"
> + untested jit-reader.exp
From <http://sourceware.org/gdb/wiki/GDBTestcaseCookbook>:
In untested calls, please spell out the reason the test ends up untested, instead of
just writing the test name, as with the latter we just end up with the test name
duplicated in the gdb.sum output. For example:"
> + return 1
> +}
> +
> +set jit_host_src ${srcfile}
> +set jit_host_bin ${binfile}
> +
> +set include_dir ${objdir}/../../
> +
> +if { [gdb_compile "${srcdir}/${subdir}/${jit_host_src}" "${jit_host_bin}" \
> + executable [list debug incdir=${include_dir}]] != "" } {
> + untested jit-reader.exp
> + return -1
> +}
> +
> +set jit_reader jitreader
> +set jit_reader_src ${jit_reader}.c
> +set jit_reader_bin [standard_output_file ${jit_reader}.so]
> +
> +if { [gdb_compile_shlib "${srcdir}/${subdir}/${jit_reader_src}" "${jit_reader_bin}" \
> + [list debug incdir=${include_dir}]] != "" } {
> + untested jit-reader.exp
> + return -1
> +}
Add a call to gdb_load_shlibs, so the .so is uploaded to remote targets.
(unless the test really only should be run on native targets.)
> +
> +proc jit_reader_test {} {
> + global jit_host_bin
> + global jit_reader_bin
> + global verbose
> +
> + clean_restart $jit_host_bin
> +
> + if {$verbose > 0} {
> + gdb_run_cmd "set debug jit 1"
> + }
> +
> + gdb_test_no_output "jit-reader-load ${jit_reader_bin}"
> + gdb_run_cmd "run"
> +
> + gdb_test "bt" "jit_function_00.*"
> +}
> +
> +jit_reader_test
> diff --git a/gdb/testsuite/gdb.base/jithost.c b/gdb/testsuite/gdb.base/jithost.c
> new file mode 100644
> index 0000000..967245c
> --- /dev/null
> +++ b/gdb/testsuite/gdb.base/jithost.c
The test's sources miss copyright headers.
> diff --git a/gdb/testsuite/gdb.base/jitreader.c b/gdb/testsuite/gdb.base/jitreader.c
> new file mode 100644
> index 0000000..2438b0d
> --- /dev/null
> +++ b/gdb/testsuite/gdb.base/jitreader.c
> @@ -0,0 +1,136 @@
> +#include <stdint.h>
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <string.h>
> +
> +#include "gdb/jit-reader.h"
Is this sure to pick up the build dir's jit-reader.h, or could it trip
on the system's installed copy from the system's gdb version?
I notice that the test's formatting is a bit inconsistent. It's almost GNU
formatting, but at places it misses the space before parens. It's not a
strict requirement for tests to follow the GNU conventions, but I think consistency
would be nice. Issues I noticed (several instances of each):
> +struct jithost_abi {
{ does on next line, indented two spaces.
> +enum gdb_status
> +unwind_frame(struct gdb_reader_funcs* self, struct gdb_unwind_callbacks* cbs)
Missing space before parens.
> +extern struct gdb_reader_funcs* gdb_init_reader(void) {
{ does on next line.
"gdb_reader_funcs *gdb_init_reader"
--
Pedro Alves
next prev parent reply other threads:[~2012-10-17 16:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-08 11:43 [PATCH 0/3] Address review, "fix recent breakage in the JIT reader interface" Sanjoy Das
2012-10-08 11:43 ` [PATCH 2/3] Make jit-reader-load accept absolute paths to reader shared objects Sanjoy Das
2012-10-08 12:34 ` Eli Zaretskii
2012-10-16 20:13 ` Tom Tromey
2012-10-08 11:43 ` [PATCH 1/3] Fix segfault when unwinding JIT frames using a custom reader Sanjoy Das
2012-10-16 20:14 ` Tom Tromey
2012-10-08 11:43 ` [PATCH 3/3] Add a test case for the jit-reader interface Sanjoy Das
2012-10-16 20:16 ` Tom Tromey
2012-10-17 16:16 ` Pedro Alves
2012-10-17 16:27 ` Tom Tromey
2012-10-17 16:35 ` Pedro Alves
2012-10-17 16:29 ` Pedro Alves [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-11-04 16:59 [PATCH 0/3] Address review, "fix recent breakage in the JIT reader interface" Sanjoy Das
2012-11-04 17:00 ` [PATCH 3/3] Add a test case for the jit-reader interface Sanjoy Das
2012-12-01 20:48 ` Jan Kratochvil
2012-12-07 9:15 ` Sanjoy Das
2012-12-10 16:38 ` Jan Kratochvil
2013-01-08 20:40 ` Sanjoy Das
2013-01-09 12:37 ` Jan Kratochvil
2013-01-13 21:58 ` Sanjoy Das
2013-01-14 3:52 ` Jan Kratochvil
2012-09-24 4:48 [PATCH 0/3] Address review, "fix recent breakage in the JIT reader interface" Sanjoy Das
2012-09-24 4:48 ` [PATCH 3/3] Add a test case for the jit-reader interface Sanjoy Das
2012-09-27 21:00 ` Tom Tromey
2012-09-18 4:30 [PATCH 0/3] Fix recent breakage in the JIT reader interface Sanjoy Das
2012-09-18 4:30 ` [PATCH 3/3] Add a test case for the jit-reader interface Sanjoy Das
2012-09-18 19:36 ` 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=507EDCF1.6080305@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=sanjoy@playingwithpointers.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