From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 4/6] Disassembly unit test: disassemble one instruction
Date: Thu, 02 Feb 2017 16:46:00 -0000 [thread overview]
Message-ID: <83019a6f-ad2e-0ecf-0c07-8fc479e46b7b@redhat.com> (raw)
In-Reply-To: <20170124152326.GR28060@E107787-LIN>
On 01/24/2017 03:23 PM, Yao Qi wrote:
> On 17-01-20 00:03:48, Pedro Alves wrote:
>>> + /* Test gdb_disassembler for a given gdbarch by reading data from a
>>> + pre-allocated buffer. If you want to see the disassembled
>>> + instruction printed to gdb_stdout, set DISASSEMBLER_TEST_VERBOSE
>>> + to true. */
>>> +
>>> + class gdb_disassembler_test : public gdb_disassembler
>>> + {
>>> + public:
>>> +
>>> + const bool DISASSEMBLER_TEST_VERBOSE = false;
>>
>> static. We give macros long unique names in order to
>> avoid naming conflicts, but if this is no longer a macro,
>> the name could be shortened, to e.g., just:
>>
>> static const bool verbose = false;
>>
>
> gdb_disassembler_test is a local class, so it can't have a static data
> member.
The end result is broken then, unfortunately. I didn't realize it
either until I saw a spurious fail in the gdb.base/unittest.exp test
today.
Running
gdb -ex "maintenance selftest"
manually I see:
~~~
Type "apropos word" to search for commands related to "word".
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default ARC600 settings.
.long 0x256f003fwarning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default ARC600 settings.
.long 0x256f003fwarning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default A6 settings.
.long 0x256f003fwarning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default ARC601 settings.
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default ARC700 settings.
brkwarning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default A7 settings.
brkwarning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default ARCv2 settings.
brkwarning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default EM settings.
brkwarning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default HS settings.
brkmov r0, #0mov r0, #0mov r0, #0mov r0, #0mov r0, #0mov r0, #0mov r0, #0mov r0, #0mov r0, #0mov r0, #0mov r0, #0mov r0, #0mov r0, #0mov r0, #0mov r0, #0breakbreakbreakbreakbreakbreakbreakbreakbreakbreakbreakbreakbreakbreakbreakbreakbreakbreakbreakM3.L = 0xffff;/* ( -1) M3=0x0xffff(65535) */break 8break 8warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default cris:common_v10_v32 settings.
~~~
etc. (this is what shows up in the gdb.log too).
Note the odd bits of instructions printed.
They appear because here:
class gdb_disassembler_test : public gdb_disassembler
{
public:
const bool verbose = false;
explicit gdb_disassembler_test (struct gdbarch *gdbarch,
const gdb_byte *insn,
size_t len)
: gdb_disassembler (gdbarch,
(verbose ? gdb_stdout : &null_stream),
gdb_disassembler_test::read_memory),
specifically in this line:
(verbose ? gdb_stdout : &null_stream),
"verbose" has not been initialized yet, because the order of initialization
is always base classes first. I.e. "verbose" is only initialized after
the base constructor is called. Since the gdb_disassembler_test object
is created on the stack, "verbose" has garbage at that point, and
thus we end up with the stream incorrectly pointing to gdb_stdout.
I was surprised that GCC doesn't warn about this. I filed a GCC
bug here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79345
I'm not sure whether this was the reason for the unittest.exp
random failure, but I suspect so. (I failed to save the log,
and also forgot to check whether all selftests had passed.)
The patchlet below fixes the spurious insn printing. OK?
diff --git a/gdb/disasm-selftests.c b/gdb/disasm-selftests.c
index 7d0b006..9eb80b4 100644
--- a/gdb/disasm-selftests.c
+++ b/gdb/disasm-selftests.c
@@ -102,13 +102,12 @@ print_one_insn_test (struct gdbarch *gdbarch)
/* Test gdb_disassembler for a given gdbarch by reading data from a
pre-allocated buffer. If you want to see the disassembled
instruction printed to gdb_stdout, set verbose to true. */
+ static const bool verbose = false;
class gdb_disassembler_test : public gdb_disassembler
{
public:
- const bool verbose = false;
-
explicit gdb_disassembler_test (struct gdbarch *gdbarch,
const gdb_byte *insn,
size_t len)
next prev parent reply other threads:[~2017-02-02 16:46 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-10 12:26 [PATCH 0/8] Handle memory error on disassemble Yao Qi
2017-01-10 12:26 ` [PATCH 4/8] Return -1 on memory error in print_insn_msp430 Yao Qi
2017-01-11 21:54 ` Alan Modra
2017-01-12 9:43 ` Yao Qi
2017-01-10 12:26 ` [PATCH 7/8] Disassembly unit test: memory error Yao Qi
2017-01-10 12:26 ` [PATCH 5/8] Remove magic numbers in m68k-dis.c:print_insn_arg Yao Qi
2017-01-11 22:14 ` Alan Modra
2017-01-13 12:23 ` Yao Qi
2017-01-10 12:26 ` [PATCH 6/8] Return -1 on memory error in print_insn_m68k Yao Qi
2017-01-11 22:15 ` Alan Modra
2017-01-12 11:50 ` Yao Qi
2017-01-12 14:38 ` Alan Modra
2017-01-12 14:52 ` Yao Qi
2017-01-13 1:54 ` Alan Modra
2017-01-13 12:29 ` Yao Qi
2017-01-10 12:26 ` [PATCH 3/8] Disassembly unit test: disassemble one instruction Yao Qi
2017-01-11 21:15 ` Simon Marchi
2017-01-12 13:06 ` Pedro Alves
2017-01-12 17:03 ` Yao Qi
2017-01-12 17:43 ` Pedro Alves
2017-01-12 21:04 ` Yao Qi
2017-01-12 14:35 ` Pedro Alves
2017-01-12 15:15 ` Pedro Alves
2017-01-12 15:35 ` Yao Qi
2017-01-12 15:44 ` Pedro Alves
2017-01-12 16:06 ` Pedro Alves
2017-01-10 12:27 ` [PATCH 1/8] Refactor disassembly code Yao Qi
2017-01-11 20:43 ` Simon Marchi
2017-01-12 12:19 ` Yao Qi
2017-01-12 12:36 ` Pedro Alves
2017-01-12 15:29 ` Simon Marchi
2017-01-10 12:27 ` [PATCH 2/8] Call print_insn_mep in mep_gdb_print_insn Yao Qi
2017-01-11 20:50 ` Simon Marchi
2017-01-12 12:21 ` Yao Qi
2017-01-10 12:27 ` [PATCH 8/8] Don't throw exception in dis_asm_memory_error Yao Qi
2017-01-12 16:40 ` Pedro Alves
2017-01-12 21:09 ` Yao Qi
2017-01-16 10:03 ` [PATCH 0/6 v2] Handle memory error on disassemble Yao Qi
2017-01-16 10:03 ` [PATCH 6/6] Don't throw exception in dis_asm_memory_error Yao Qi
2017-01-17 14:42 ` Luis Machado
2017-01-18 14:54 ` Yao Qi
2017-01-18 14:58 ` Luis Machado
2017-01-16 10:03 ` [PATCH 3/6] Call print_insn_mep in mep_gdb_print_insn Yao Qi
2017-01-17 14:19 ` Luis Machado
2017-01-24 10:08 ` Yao Qi
2017-01-24 13:41 ` Luis Machado
2017-01-16 10:03 ` [PATCH 2/6] Refactor disassembly code Yao Qi
2017-01-17 14:14 ` Luis Machado
2017-01-18 16:34 ` Yao Qi
2017-01-18 16:53 ` Luis Machado
2017-01-16 10:03 ` [PATCH 5/6] Disassembly unit test: memory error Yao Qi
2017-01-17 14:38 ` Luis Machado
2017-01-24 15:33 ` Yao Qi
2017-01-20 0:08 ` Pedro Alves
2017-01-16 10:03 ` [PATCH 1/6] New function null_stream Yao Qi
2017-01-17 13:49 ` Luis Machado
2017-01-18 14:45 ` Yao Qi
2017-01-18 14:53 ` Luis Machado
2017-01-18 14:57 ` Simon Marchi
2017-01-18 15:02 ` Luis Machado
2017-01-18 15:18 ` Simon Marchi
2017-01-18 15:29 ` Luis Machado
2017-01-18 15:54 ` Simon Marchi
2017-01-18 16:36 ` Luis Machado
2017-01-16 10:03 ` [PATCH 4/6] Disassembly unit test: disassemble one instruction Yao Qi
2017-01-20 0:04 ` Pedro Alves
2017-01-24 15:23 ` Yao Qi
2017-02-02 16:46 ` Pedro Alves [this message]
2017-02-02 22:12 ` Yao Qi
2017-02-02 23:39 ` [pushed] Fix "maintenance selftest" printing stray instructions (Re: [PATCH 4/6] Disassembly unit test: disassemble one instruction) Pedro Alves
2017-01-25 8:38 ` [PATCH 0/6 v3] Handle memory error on disassembly Yao Qi
2017-01-25 8:38 ` [PATCH 2/6] Refactor disassembly code Yao Qi
2017-01-25 8:38 ` [PATCH 1/6] New function null_stream Yao Qi
2017-01-25 8:38 ` [PATCH 5/6] Disassembly unit test: memory error Yao Qi
2017-01-25 8:38 ` [PATCH 3/6] Call print_insn_mep in mep_gdb_print_insn Yao Qi
2017-01-25 8:38 ` [PATCH 6/6] Don't throw exception in dis_asm_memory_error Yao Qi
2017-01-25 8:38 ` [PATCH 4/6] Disassembly unit test: disassemble one instruction Yao Qi
2017-01-26 11:34 ` [PATCH 0/6 v3] Handle memory error on disassembly Pedro Alves
2017-01-26 15:00 ` Yao Qi
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=83019a6f-ad2e-0ecf-0c07-8fc479e46b7b@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=qiyaoltc@gmail.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