From: Pedro Alves <pedro@palves.net>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 18/18] Introduce catchpoint class
Date: Wed, 4 May 2022 12:37:35 +0100 [thread overview]
Message-ID: <aeb11214-c95a-564f-7da9-fa77c971dc04@palves.net> (raw)
In-Reply-To: <874k2643v4.fsf@tromey.com>
On 2022-05-04 00:02, Tom Tromey wrote:
>>> This changes the hierarchy a little -- some catchpoints now inherit
>>> from base_breakpoint whereas previously they did not. This isn't a
>>> problem, as long as re_set is redefined in catchpoint.
>
> Pedro> This hierarchy change stretches things a bit. By inheriting
> Pedro> base_breakpoint, this is saying that catchpoints is-a
> Pedro> software/hardware breakpoint, while most catchpoints are not.
> Pedro> Catchpoints are exactly the event points that are _not_ some PC
> Pedro> location that execution traps at.
> ...
>
> Pedro> But I suppose in the end either change wouldn't simplify much, if anything.
>
> Well, another option might be to add another constructor to breakpoint
> itself. Then the hierarchy wouldn't have to change, just which
> constructors are visible.
>
> It seems a little weird that these all call init_raw_breakpoint, which
> calls add_location_to_breakpoint. Maybe I need to look into that.
Yeah, agreed on init_raw_breakpoint. AMD's GPU backend needs a custom
internal breakpoint for shared library events, and I need to rework how that's
created after the breakpoints C++-ification. Yesterday I was looking at
it, and the current WIP prototype I was going for (on top of current master)
is something was like this:
struct amd_dbgapi_target_solib_breakpoint : public base_breakpoint
{
amd_dbgapi_target_solib_breakpoint (struct gdbarch *gdbarch_, CORE_ADDR address)
: base_breakpoint ()
{
/* Should be a ctor. */
symtab_and_line sal;
sal.pc = address;
sal.section = find_pc_overlay (sal.pc);
sal.pspace = current_program_space;
init_raw_breakpoint (this, gdbarch_, sal, bp_breakpoint, nullptr);
}
// These do custom things.
void re_set () override;
void check_status (struct bpstat *bs) override;
};
....
std::unique_ptr<breakpoint> b_up
(new amd_dbgapi_target_solib_breakpoint (section->objfile->arch (),
address));
install_breakpoint (true, std::move (b_up), 1);
...
I.e., I exported init_raw_breakpoint, but I think it should be a ctor instead.
next prev parent reply other threads:[~2022-05-04 11:37 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-02 22:15 [PATCH 00/18] Minor breakpoint cleanups Tom Tromey
2022-05-02 22:15 ` [PATCH 01/18] Change print_recreate_thread to a method Tom Tromey
2022-05-02 22:15 ` [PATCH 02/18] Remove breakpoint::ops Tom Tromey
2022-05-02 22:15 ` [PATCH 03/18] Boolify breakpoint::explains_signal Tom Tromey
2022-05-02 22:15 ` [PATCH 04/18] Move works_in_software_mode to watchpoint Tom Tromey
2022-05-02 22:15 ` [PATCH 05/18] Constify breakpoint::print_it Tom Tromey
2022-05-02 22:15 ` [PATCH 06/18] Constify breakpoint::print_one Tom Tromey
2022-05-02 22:15 ` [PATCH 07/18] Constify breakpoint::print_mention Tom Tromey
2022-05-02 22:15 ` [PATCH 08/18] Constify breakpoint::print_recreate Tom Tromey
2022-05-02 22:15 ` [PATCH 09/18] Remove unnecessary line from catch_exec_command_1 Tom Tromey
2022-05-02 22:15 ` [PATCH 10/18] Add constructor to fork_catchpoint Tom Tromey
2022-05-02 22:15 ` [PATCH 11/18] Add constructor to solib_catchpoint Tom Tromey
2022-05-02 22:15 ` [PATCH 12/18] Add constructor to signal_catchpoint Tom Tromey
2022-05-02 22:15 ` [PATCH 13/18] Add constructor to syscall_catchpoint Tom Tromey
2022-05-02 22:15 ` [PATCH 14/18] Add constructor to exception_catchpoint Tom Tromey
2022-05-02 22:15 ` [PATCH 15/18] Disable copying for breakpoint Tom Tromey
2022-05-02 22:15 ` [PATCH 16/18] Remove init_raw_breakpoint_without_location Tom Tromey
2022-05-03 19:26 ` Pedro Alves
2022-05-03 22:43 ` Tom Tromey
2022-05-02 22:15 ` [PATCH 17/18] Add initializers to tracepoint Tom Tromey
2022-05-02 22:15 ` [PATCH 18/18] Introduce catchpoint class Tom Tromey
2022-05-03 19:32 ` Pedro Alves
2022-05-03 23:02 ` Tom Tromey
2022-05-04 11:37 ` Pedro Alves [this message]
2022-05-07 2:19 ` Simon Marchi
2022-05-07 16:07 ` Tom Tromey
2022-05-07 19:31 ` Simon Marchi
2022-05-16 18:22 ` Tom Tromey
2022-05-16 19:29 ` Simon Marchi
2022-05-03 19:33 ` [PATCH 00/18] Minor breakpoint cleanups Pedro Alves
2022-05-06 18:03 ` 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=aeb11214-c95a-564f-7da9-fa77c971dc04@palves.net \
--to=pedro@palves.net \
--cc=gdb-patches@sourceware.org \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).