(hardware) watchpoints and actions

Paul_Koning@Dell.com Paul_Koning@Dell.com
Thu Nov 12 20:50:00 GMT 2015

> 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.


More information about the Gdb mailing list