From: Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tom@tromey.com>
Subject: Re: [PATCH][gdb/testsuite] Reimplement gdb.gdb/python-interrupts.exp as unittest
Date: Wed, 22 Sep 2021 12:17:46 +0200 [thread overview]
Message-ID: <d767624c-250e-9777-ee07-e7160a68c0bb@suse.de> (raw)
In-Reply-To: <20210911120254.GA19083@delia.home>
On 9/11/21 2:02 PM, Tom de Vries wrote:
> +#if GDB_SELF_TEST
> +namespace selftests {
> +extern void (*hook_set_active_ext_lang) (void);
> +void (*hook_set_active_ext_lang) (void) = nullptr;
> +}
> +#endif
> +
> /* Set the currently active extension language to NOW_ACTIVE.
> The result is a pointer to a malloc'd block of memory to pass to
> restore_active_ext_lang.
> @@ -708,6 +715,11 @@ install_gdb_sigint_handler (struct signal_handler *previous)
> struct active_ext_lang_state *
> set_active_ext_lang (const struct extension_language_defn *now_active)
> {
> +#if GDB_SELF_TEST
> + if (selftests::hook_set_active_ext_lang)
> + selftests::hook_set_active_ext_lang ();
> +#endif
In particular, I'd like feedback on whether this is acceptable.
F.i., I could do instead the less intrusive (but also less flexible):
...
#if GDB_SELF_TEST
namespace selftests {
extern int hook_raise_at_entry_active_ext_lang;
int hook_raise_at_entry_active_ext_lang = 0;
#endif
struct active_ext_lang_state *
set_active_ext_lang (const struct extension_language_defn *now_active)
{
#if GDB_SELF_TEST
if (selftests::hook_raise_at_entry_active_ext_lang)
raise (hook_raise_at_entry_active_ext_lang);
#endif
...
The hook that is a function pointer is the most flexible, but possibly
less safe. OTOH, it is in the selftest code, which we disable by
default in release branches, so by default this is not included in
releases. OTOH, it's still possible to enable it in releases using
--enable-unit-tests. Perhaps this could be handled using a
DEVEL_GDB_SELF_TEST, which is disabled in release branches independent
of --enable-unit-tests?
Any comment appreciated.
Thanks,
- Tom
next prev parent reply other threads:[~2021-09-22 10:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-11 12:02 Tom de Vries via Gdb-patches
2021-09-22 10:17 ` Tom de Vries via Gdb-patches [this message]
2021-10-07 14:36 ` [PING][PATCH][gdb/testsuite] " Tom de Vries via Gdb-patches
2021-10-19 18:10 ` [PATCH][gdb/testsuite] " Tom Tromey
2021-10-19 22:00 ` Tom de Vries via Gdb-patches
2021-10-19 18:09 ` Tom Tromey
2021-10-19 21:56 ` Tom de Vries via Gdb-patches
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=d767624c-250e-9777-ee07-e7160a68c0bb@suse.de \
--to=gdb-patches@sourceware.org \
--cc=tdevries@suse.de \
--cc=tom@tromey.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