This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: (hardware) watchpoints and actions
- From: <Paul_Koning at Dell dot com>
- To: <david dot taylor at emc dot com>
- Cc: <duane at duaneellis dot com>, <gdb at sourceware dot org>
- Date: Thu, 12 Nov 2015 20:50:41 +0000
- Subject: Re: (hardware) watchpoints and actions
- Authentication-results: sourceware.org; auth=none
- References: <20151112091432 dot 5c1bb9f86d671edec44bb378f25c04cc dot fb8bf6e151 dot wbe at email03 dot secureserver dot net> <64A9FD4472059B48AC8F38981B7DA5342EF9BD5FDD at MX37A dot corp dot emc dot com>
> On Nov 12, 2015, at 3:44 PM, taylor, david <david.taylor@emc.com> wrote:
> ...
> But the code that supports this type of stuff often works better if it is compiled into the actual application, which to some degree violates the "do not ship debug code in production code" rule.
>
> The code *IS* compiled into the application. The GDB stub is always compiled in.
>
> The stub is NOT debug code. It enables the developer to examine the system, set
> breakpoints, tracepoints, watchpoints, or whatever.
>
> Another rule is to test what you ship. You don't want to debug with the stub removed.
> And if a problem is found in testing, it's much easier to track it down if the stub is
> compiled in. The stub is always compiled in. It is part of the shipped product.
That's fine if your security mechanisms are good enough to prevent unauthorized access to the stub in a production setting. That's the issue that the "don't ship debug code" rule is concerned with.
paul