From: Eli Zaretskii <eliz@gnu.org>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v2 1/2] gdb: merge solib-frv aix-solib debug options into "set/show debug solib"
Date: Mon, 28 Nov 2022 19:24:28 +0200 [thread overview]
Message-ID: <83zgcbm1pv.fsf@gnu.org> (raw)
In-Reply-To: <20221128170049.1094477-1-simon.marchi@polymtl.ca> (message from Simon Marchi via Gdb-patches on Mon, 28 Nov 2022 12:00:48 -0500)
> Cc: Simon Marchi <simon.marchi@polymtl.ca>
> Date: Mon, 28 Nov 2022 12:00:48 -0500
> From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
>
> solib implementations are typically used one at a time. So it will be
> rare that you will want to enable debug for one solib kind, and
> absolutely want to keep the others disabled. To make things simpler,
> instead of adding separate variables / macros / commands for each solib
> implementation, merge the existing ones (frv and aix) into a unified
> "set/show debug solib", with the solib_debug_printf macro.
>
> Change-Id: I6e18bbc7401724f37ae66681badb079d75ecf7fa
> ---
> gdb/NEWS | 12 ++++++
> gdb/doc/gdb.texinfo | 18 +++------
> gdb/solib-aix.c | 39 +++----------------
> gdb/solib-frv.c | 95 +++++++++++----------------------------------
> gdb/solib.c | 16 +++++---
> gdb/solib.h | 12 ++++++
> 6 files changed, 68 insertions(+), 124 deletions(-)
OK for the documentation parts, thanks.
I wonder what the others think about removing those two commands? Do we
have any policy regarding that? Maybe leave them as aliases for the new
command?
next prev parent reply other threads:[~2022-11-28 17:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-28 17:00 Simon Marchi
2022-11-28 17:00 ` [PATCH v2 2/2] gdb: add some debug statements to solib-svr4.c Simon Marchi
2022-11-28 17:24 ` Eli Zaretskii [this message]
2022-11-28 18:29 ` [PATCH v2 1/2] gdb: merge solib-frv aix-solib debug options into "set/show debug solib" Simon Marchi
2022-11-28 18:38 ` Eli Zaretskii
2022-12-02 19:44 ` Simon Marchi
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=83zgcbm1pv.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@polymtl.ca \
/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).