[Bug breakpoints/13545] New: Incorrect handling of invalidbreakpoints

["mike_wrighton at mentor dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=13545

             Bug #: 13545
           Summary: Incorrect handling of invalid breakpoints
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: breakpoints
        AssignedTo: unassigned@sourceware.org
        ReportedBy: mike_wrighton@mentor.com
    Classification: Unclassified


(Linux x86, MI mode)

If the user inserts an invalid breakpoint (e.g. 0x0) when gdb is suspended,
then continues, gdb first reports the target as running, then shows a warning
and reports that the target has stopped:

^running
*running,thread-id="1"
(gdb)
&"Warning:\n"
&"Cannot insert breakpoint 2.\n"
&"Error accessing memory address 0x0: Input/output error.\n"
&"\n"
~"0x08048422 in main () at
/home/mike/mentor/workspaces/runtime-New_configuration/test/src/test.c:14\n"
~"14\t n = factorial ;\n"
*stopped,frame=
...

This is confusing for IDEs as it appears that the continue command has
completed with no errors. Gdb handles subsequent continue commands correctly
e.g. the command is rejected with '^error'.

After some investigation, what appears to be happening is that gdb replaces and
steps over the current instruction before it attempts to insert the invalid
breakpoint, and in stepping that instruction it reports that the target is
running. When it resumes to insert the invalid breakpoint, it errors, although
the error is just printed and not passed up back to the continue command
function. At this point gdb is in an invalid state - the PC is at the original
location + 1 and subsequent calls to continue fail.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.