Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Yao Qi <qiyaoltc@gmail.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 1/3] Redesign mock environment for gdbarch selftests
Date: Tue, 03 Oct 2017 11:06:00 -0000	[thread overview]
Message-ID: <86k20c7aob.fsf@gmail.com> (raw)
In-Reply-To: <1506957311-30028-2-git-send-email-palves@redhat.com> (Pedro	Alves's message of "Mon, 2 Oct 2017 16:15:09 +0100")

Pedro Alves <palves@redhat.com> writes:

> If there's already a running target when you type "maint selftest",
> then we bail out, instead of pushing a new target on top of the
> existing one (and thus killing the debug session).  I think that's OK,
> because self tests are really mean to be run from a clean state right
> after GDB is started.  I'm adding that skipping just as safe measure
> just in case someone (as I've done it) types "maint selftest" on the
> command line while already debugging something.

That is a goo catch, but IMO, we shouldn't allow running unit tests
during debugging session.  GDB unit tests touch many things, and some of
them are global states in GDB.  It is difficult to know what global
states we need to restore after tests.

>
> (In my multi-target branch, where this patch originated from, we don't
> actually need to bail out, because there each inferior has its own
> target stack).
>
> Also, note that the current code was doing:
>
>  current_inferior()->gdbarch = gdbarch;
>
> without taking care to restore the previous gdbarch.  This means that
> GDB's state was being left inconsistent after running the self tests,,
> further supporting the point that there's probably not much
> expectation that mixing "maint selftests" and regular debugging in the
> same GDB invocation really works.

You are right, we should manage the expectation of mixing debugging and
"maint selftests".  My suggestion is that "please do run selftests
with regular debugging".

> -    raw_set_cached_value (regnum, buf);
> +    to_magic = OPS_MAGIC;
> +    to_stratum = process_stratum;
> +    to_has_memory = test_target_has_memory;
> +    to_has_stack = test_target_has_stack;
> +    to_has_registers = test_target_has_registers;
> +    to_prepare_to_store = test_target_prepare_to_store;
> +    to_fetch_registers = test_target_fetch_registers;

to_fetch_registers is TARGET_DEFAULT_IGNORE, so we don't need define
test_target_fetch_registers if we disallow running selftests with
regular debugging.

> +    to_store_registers = test_target_store_registers;

> +    to_thread_architecture = default_thread_architecture;
> +    to_thread_address_space = default_thread_address_space;

Any reason to set to_thread_address_space and to_thread_architecture?
Can't we use the default value?

-- 
Yao (齐尧)


  reply	other threads:[~2017-10-03 11:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-02 15:15 [PATCH 0/3] Fix "Remote 'g' packet reply is too long" problems with multiple inferiors Pedro Alves
2017-10-02 15:15 ` [PATCH 1/3] Redesign mock environment for gdbarch selftests Pedro Alves
2017-10-03 11:06   ` Yao Qi [this message]
2017-10-03 12:05     ` Pedro Alves
2017-10-04 10:39       ` Yao Qi
2017-10-02 15:15 ` [PATCH 2/3] Reimplement support for "maint print registers" with no running inferior yet Pedro Alves
2017-10-03 11:17   ` Yao Qi
2017-10-02 15:15 ` [PATCH 3/3] Fix "Remote 'g' packet reply is too long" problems with multiple inferiors Pedro Alves
2017-10-03 11:36   ` Yao Qi
2017-10-03 11:40   ` Yao Qi
2017-10-03 12:21     ` Pedro Alves
2017-10-03 14:02       ` Pedro Alves
2017-10-04 10:21         ` Yao Qi
2017-10-04 17:38           ` Pedro Alves
2017-10-05 16:50   ` Ulrich Weigand
2017-10-05 17:08     ` Pedro Alves
2017-12-12 21:33   ` Maciej W. Rozycki
2017-12-13  0:45     ` Pedro Alves
2017-12-13 11:31       ` Maciej W. Rozycki

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=86k20c7aob.fsf@gmail.com \
    --to=qiyaoltc@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --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