From: Daniel Jacobowitz <drow@mvista.com>
To: gdb-patches@sources.redhat.com
Subject: Re: PATCH: breakpoints for gdbserver
Date: Sat, 20 Apr 2002 10:04:00 -0000 [thread overview]
Message-ID: <20020420130453.A19720@nevyn.them.org> (raw)
In-Reply-To: <20020416013218.A1180@nevyn.them.org>
On Tue, Apr 16, 2002 at 01:32:18AM -0400, Daniel Jacobowitz wrote:
> This gives gdbserver a framework for memory-shadowing breakpoints, invisible
> to GDB. They won't behave gracefully if GDB tries to single-step over them
> or if the user puts breakpoints at the same places; I intend to control all
> the cases where gdbserver might insert them with command line options, so
> that if (say) you want to debug LinuxThreads, you can turn off gdbserver
> thread support. That's the only way to get reasonable results, IMHO.
>
> There's a little bit of ugliness here, in that some targets do not support
> PTRACE_SINGLESTEP. If gdbserver does not know how to single-step a target,
> the backend for that target should supply a function to find a safe
> instruction that we know will be reached, to place a temporary breakpoint
> on. It can be the next instruction, or it can be the function return
> address, since the only places these breakpoints will be used (so far, at
> least) are on empty marker functions in the dynamic linker or in
> LinuxThreads or in some similar event-based debugging technique. Hurdles
> will be dealt with as they arise; I don't want to over-complicate this.
> Both single-step and resume breakpoint methods have been tested.
>
> The only target to actually support breakpoints right now is i386-*-linux-gnu.
> I'll go through and add breakpoints for all the other gdbserver targets at a
> not-too-future date.
>
> I'll commit this in a day or so unless someone sees a problem with it. Next
> on my list is a per-inferior register cache, and then I'll knuckle down to
> the core of an actual threads package. No documentation is needed with this
> patch, although when I have a little time I may write a small gdbserver
> internals document... on the off chance someone actually wants to resurrect
> this on a target I don't have, and all...
Committed.
> 2002-04-16 Daniel Jacobowitz <drow@mvista.com>
>
> * gdbserver/mem-break.c: New file.
> * gdbserver/mem-break.h: New file.
> * gdbserver/Makefile.in: Add mem-break.o rule; update server.h
> dependencies.
> * gdbserver/inferiors.c (struct inferior_info): Add target_data
> member.
> (clear_inferiors): Free target_data member if set.
> (inferior_target_data, set_inferior_target_data): New functions.
> * gdbserver/linux-i386-low.c (i386_breakpoint, i386_breakpoint_len)
> (i386_stop_pc, i386_set_pc): New. Add to the_low_target.
> * gdbserver/linux-low.c (linux_bp_reinsert): New variable.
> (struct inferior_linux_data): New.
> (linux_create_inferior): Use set_inferior_target_data.
> (linux_attach): Likewise. Call add_inferior.
> (linux_wait_for_one_inferior): New function.
> (linux_wait): Call it.
> (linux_write_memory): Add const.
> (initialize_low): Call set_breakpoint_data.
> * gdbserver/linux-low.h (struct linux_target_ops): Add breakpoint
> handling members.
> * gdbserver/server.c (attach_inferior): Remove extra add_inferior
> call.
> * gdbserver/server.h: Include mem-break.h. Update inferior.c
> prototypes.
> * gdbserver/target.c (read_inferior_memory)
> (write_inferior_memory): New functions.
> * gdbserver/target.h (read_inferior_memory)
> (write_inferior_memory): Change macros to prototypes.
> (struct target_ops): Update comments. Add const to write_memory
> definition.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
prev parent reply other threads:[~2002-04-20 17:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-15 22:32 Daniel Jacobowitz
2002-04-15 22:47 ` Andrew Cagney
2002-04-16 7:35 ` Daniel Jacobowitz
2002-04-20 10:04 ` Daniel Jacobowitz [this message]
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=20020420130453.A19720@nevyn.them.org \
--to=drow@mvista.com \
--cc=gdb-patches@sources.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