This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: (hardware) watchpoints and actions
- From: <duane at duaneellis dot com>
- To: "taylor, david" <david dot taylor at emc dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Thu, 12 Nov 2015 15:33:55 -0700
- Subject: RE: (hardware) watchpoints and actions
- Authentication-results: sourceware.org; auth=none
duane> a) Most "gdb-server" type things are rather "dumb" they do not
know what symbols are.
david> [snip; see] maint agent [snip]
david> Our stubs (both old and new) contain substantial tracepoint
support.
Hmm, you learn something every day.
I am very familiar with several gdbserver JTAG type debug environments
(mostly bare metal), where this feature is *NOT* supported. I have spent
very little time in the linux based gdb-server, hence my ignorance of
this feature.
david> The code *IS* compiled into the application. The GDB stub is
always compiled in.
Yes, that is quite a different environment then my background.
Paul @ Dell - brings up another point - security/access control to the
GDB stub feature.
In your case "compiled-in-gdb-stub" is a product requirement, and/or
product feature.
In the space constrained world (ie: micro controller, and/or bare-metal)
(1) you often don't have code/ram space for items like this,
(2) for performance reasons, this code must be removed
(3) There is no support for this in the underling operating system (if
there is one)
(4) Or the GDB server exists external to the target (ie: JTAG)
Each of us come from different backgrounds.
-Duane.