and though bugs are the bane of my existence, rest assured the wretched thing will get the best of care here

  1. 29 Oct, 2014 4 commits
    • Joel Brobecker's avatar
      Set GDB version number to 7.8.1. · 21de41c0
      Joel Brobecker authored
      gdb/ChangeLog:
      
      	* version.in: Set GDB version number to 7.8.1.
      21de41c0
    • Pedro Alves's avatar
      PR 17408 - assertion failure in switch_back_to_stepped_thread · c85bfef3
      Pedro Alves authored
      This PR shows that GDB can easily trigger an assertion here, in
      infrun.c:
      
       5392              /* Did we find the stepping thread?  */
       5393              if (tp->control.step_range_end)
       5394                {
       5395                  /* Yep.  There should only one though.  */
       5396                  gdb_assert (stepping_thread == NULL);
       5397
       5398                  /* The event thread is handled at the top, before we
       5399                     enter this loop.  */
       5400                  gdb_assert (tp != ecs->event_thread);
       5401
       5402                  /* If some thread other than the event thread is
       5403                     stepping, then scheduler locking can't be in effect,
       5404                     otherwise we wouldn't have resumed the current event
       5405                     thread in the first place.  */
       5406                  gdb_assert (!schedlock_applies (currently_stepping (tp)));
       5407
       5408                  stepping_thread = tp;
       5409                }
      
      Like:
      
       gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed.
      
      The way the assertion is written is assuming that with schedlock=step
      we'll always leave threads other than the one with the stepping range
      locked, while that's not true with the "next" command.  With schedlock
      "step", other threads still run unlocked when "next" detects a
      function call and steps over it.  Whether that makes sense or not,
      still, it's documented that way in the manual.  If another thread hits
      an event that doesn't cause a stop while the nexting thread steps over
      a function call, we'll get here and fail the assertion.
      
      The fix is just to adjust the assertion.  Even though we found the
      stepping thread, we'll still step-over the breakpoint that just
      triggered correctly.
      
      Surprisingly, gdb.threads/schedlock.exp doesn't have any test that
      steps over a function call.  This commits fixes that.  This ensures
      that "next" doesn't switch focus to another thread, and checks whether
      other threads run locked or not, depending on scheduler locking mode
      and command.  There's a lot of duplication in that file that this ends
      cleaning up.  There's more that could be cleaned up, but that would
      end up an unrelated change, best done separately.
      
      This new coverage in schedlock.exp happens to trigger the internal
      error in question, like so:
      
       FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error)
       FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error)
       FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error)
       FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error)
       FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error)
       FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0)
       FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount)
      
      That's because we have more than one thread running the same loop, and
      while one thread is stepping over a function call, the other thread
      hits the step-resume breakpoint of the first, which needs to be
      stepped over, and we end up in switch_back_to_stepped_thread exactly
      in the problem case.
      
      I think a simpler and more directed test is also useful, to not rely
      on internal breakpoint magics.  So this commit also adds a test that
      has a thread trip on a conditional breakpoint that doesn't cause a
      user-visible stop while another thread is stepping over a call.  That
      currently fails like this:
      
       FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error)
      
      Tested on x86_64 Fedora 20.
      
      gdb/
      2014-10-29  Pedro Alves  <palves@redhat.com>
      
      	PR gdb/17408
      	* infrun.c (switch_back_to_stepped_thread): Use currently_stepping
      	instead of assuming a thread with a stepping range is always
      	stepping.
      
      gdb/testsuite/
      2014-10-29  Pedro Alves  <palves@redhat.com>
      
      	PR gdb/17408
      	* gdb.threads/schedlock.c (some_function): New function.
      	(call_function): New global.
      	(MAYBE_CALL_SOME_FUNCTION): New macro.
      	(thread_function): Call it.
      	* gdb.threads/schedlock.exp (get_args): Add description parameter,
      	and use it instead of a global counter.  Adjust all callers.
      	(get_current_thread): Use "find current thread" for test message
      	here rather than having all callers pass down the same string.
      	(goto_loop): New procedure, factored out from ...
      	(my_continue): ... this.
      	(step_ten_loops): Change parameter from test message to command to
      	use.  Adjust.
      	(list_count): Delete global.
      	(check_result): New procedure, factored out from duplicate top
      	level code.
      	(continue tests): Wrap in with_test_prefix.
      	(test_step): New procedure, factored out from duplicate top level
      	code.
      	(top level): Test "step" in combination with all scheduler-locking
      	modes.  Test "next" in combination with all scheduler-locking
      	modes, and in combination with stepping over a function call or
      	not.
      	* gdb.threads/next-bp-other-thread.c: New file.
      	* gdb.threads/next-bp-other-thread.exp: New file.
      c85bfef3
    • Pedro Alves's avatar
      PR python/17372 - Python hangs when displaying help() · cbd6f6bf
      Pedro Alves authored
      This is more of a readline/terminal issue than a Python one.
      
      PR17372 is a regression in 7.8 caused by the fix for PR17072:
      
       commit 0017922d
       Author: Pedro Alves <palves@redhat.com>
       Date:   Mon Jul 14 19:55:32 2014 +0100
      
          Background execution + pagination aborts readline/gdb
      
          gdb_readline_wrapper_line removes the handler after a line is
          processed.  Usually, we'll end up re-displaying the prompt, and that
          reinstalls the handler.  But if the output is coming out of handling
          a stop event, we don't re-display the prompt, and nothing restores the
          handler.  So the next input wakes up the event loop and calls into
          readline, which aborts.
      ...
          gdb/
          2014-07-14  Pedro Alves  <palves@redhat.com>
      
              PR gdb/17072
              * top.c (gdb_readline_wrapper_line): Tweak comment.
              (gdb_readline_wrapper_cleanup): If readline is enabled, reinstall
              the input handler callback.
      
      The problem is that installing the input handler callback also preps
      the terminal, putting it in raw mode and with echo disabled, which is
      bad if we're going to call a command that assumes cooked/canonical
      mode, and echo enabled, like in the case of the PR, Python's
      interactive shell.  Another example I came up with that doesn't depend
      on Python is starting a subshell with "(gdb) shell /bin/sh" from a
      multi-line command.  Tests covering both these examples are added.
      
      The fix is to revert the original fix for PR gdb/17072, and instead
      restore the callback handler after processing an asynchronous target
      event.
      
      Furthermore, calling rl_callback_handler_install when we already have
      some input in readline's line buffer discards that input, which is
      obviously a bad thing to do while the user is typing.  No specific
      test is added for that, because I first tried calling it even if the
      callback handler was still installed and that resulted in hundreds of
      failures in the testsuite.
      
      gdb/
      2014-10-29  Pedro Alves  <palves@redhat.com>
      
      	PR python/17372
      	* event-top.c (change_line_handler): Call
      	gdb_rl_callback_handler_remove instead of
      	rl_callback_handler_remove.
      	(callback_handler_installed): New global.
      	(gdb_rl_callback_handler_remove, gdb_rl_callback_handler_install)
      	(gdb_rl_callback_handler_reinstall): New functions.
      	(display_gdb_prompt): Call gdb_rl_callback_handler_remove and
      	gdb_rl_callback_handler_install instead of
      	rl_callback_handler_remove and rl_callback_handler_install.
      	(gdb_disable_readline): Call gdb_rl_callback_handler_remove
      	instead of rl_callback_handler_remove.
      	* event-top.h (gdb_rl_callback_handler_remove)
      	(gdb_rl_callback_handler_install)
      	(gdb_rl_callback_handler_reinstall): New declarations.
      	* infrun.c (reinstall_readline_callback_handler_cleanup): New
      	cleanup function.
      	(fetch_inferior_event): Install it.
      	* top.c (gdb_readline_wrapper_line) Call
      	gdb_rl_callback_handler_remove instead of
      	rl_callback_handler_remove.
      	(gdb_readline_wrapper_cleanup): Don't call
      	rl_callback_handler_install.
      
      gdb/testsuite/
      2014-10-29  Pedro Alves  <palves@redhat.com>
      
      	PR python/17372
      	* gdb.python/python.exp: Test a multi-line command that spawns
      	interactive Python.
      	* gdb.base/multi-line-starts-subshell.exp: New file.
      cbd6f6bf
    • GDB Administrator's avatar
      Automatic date update in version.in · c9792faa
      GDB Administrator authored
      c9792faa
  2. 28 Oct, 2014 1 commit
  3. 27 Oct, 2014 1 commit
  4. 26 Oct, 2014 1 commit
  5. 25 Oct, 2014 1 commit
  6. 24 Oct, 2014 1 commit
  7. 23 Oct, 2014 1 commit
  8. 22 Oct, 2014 1 commit
  9. 21 Oct, 2014 1 commit
  10. 20 Oct, 2014 1 commit
  11. 19 Oct, 2014 1 commit
  12. 18 Oct, 2014 1 commit
  13. 17 Oct, 2014 5 commits
    • Pedro Alves's avatar
      PR gdb/17471: Repeating a background command makes it foreground · 36c57a3c
      Pedro Alves authored
      When we repeat a command, by just pressing <ret>, the input from the
      previous command is reused for the new command invocation.
      
      When an execution command strips the "&" out of its incoming argument
      string, to detect background execution, we poke a '\0' directly to the
      incoming argument string.
      
      Combine both, and a repeat of a background command loses the "&".
      
      This is actually only visible if args other than "&" are specified
      (e.g., "c 1&" or "next 2&" or "c -a&"), as in the special case of "&"
      alone (e.g. "c&") doesn't actually clobber the incoming string.
      
      Fix this by making strip_bg_char return a new string instead of poking
      a hole in the input string.
      
      New test included.
      
      Tested on x86_64 Fedora 20, native and gdbserver.
      
      gdb/
      2014-10-17  Pedro Alves  <palves@redhat.com>
      
      	PR gdb/17471
      	* infcmd.c (strip_bg_char): Change prototype and rewrite.  Now
      	returns a copy of the input.
      	(run_command_1, continue_command, step_1, jump_command)
      	(signal_command, until_command, advance_command, finish_command)
      	(attach_command): Adjust and install a cleanup to free the
      	stripped args.
      
      gdb/testsuite/
      2014-10-17  Pedro Alves  <palves@redhat.com>
      
      	PR gdb/17471
      	* gdb.base/bg-execution-repeat.c: New file.
      	* gdb.base/bg-execution-repeat.exp: New file.
      36c57a3c
    • Pedro Alves's avatar
      PR gdb/17300: Input after "c -a" crashes readline/GDB · e37951dc
      Pedro Alves authored
      If all threads in the target were already running when the user does
      "c -a", nothing puts the inferior's terminal settings in effect and
      removes stdin from the event loop, which we must when running a
      foreground command.  The result is that user input afterwards crashes
      readline/gdb:
      
       (gdb) start
       Temporary breakpoint 1 at 0x4005d4: file continue-all-already-running.c, line 23.
       Starting program: continue-all-already-running
      
       Temporary breakpoint 1, main () at continue-all-already-running.c:23
       23        sleep (10);
       (gdb) c -a&
       Continuing.
       (gdb) c -a
       Continuing.
       p 1
       readline: readline_callback_read_char() called with no handler!
       Aborted (core dumped)
       $
      
      Backtrace:
      
       Program received signal SIGABRT, Aborted.
       0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
       56        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
       (top-gdb) p 1
       $1 = 1
       (top-gdb) bt
       #0  0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
       #1  0x0000003b36a36f68 in __GI_abort () at abort.c:89
       #2  0x0000000000784aa9 in rl_callback_read_char () at readline/callback.c:116
       #3  0x0000000000619181 in rl_callback_read_char_wrapper (client_data=0x0) at gdb/event-top.c:167
       #4  0x0000000000619557 in stdin_event_handler (error=0, client_data=0x0) at gdb/event-top.c:373
       #5  0x000000000061814a in handle_file_event (data=...) at gdb/event-loop.c:763
       #6  0x0000000000617631 in process_event () at gdb/event-loop.c:340
       #7  0x00000000006176f8 in gdb_do_one_event () at gdb/event-loop.c:404
       #8  0x0000000000617748 in start_event_loop () at gdb/event-loop.c:429
       #9  0x00000000006191b3 in cli_command_loop (data=0x0) at gdb/event-top.c:182
       #10 0x000000000060f538 in current_interp_command_loop () at gdb/interps.c:318
       #11 0x0000000000610701 in captured_command_loop (data=0x0) at gdb/main.c:323
       #12 0x000000000060c3f5 in catch_errors (func=0x6106e6 <captured_command_loop>, func_args=0x0, errstring=0x9002c1 "", mask=RETURN_MASK_ALL)
           at gdb/exceptions.c:237
       #13 0x0000000000611bff in captured_main (data=0x7fffffffd780) at gdb/main.c:1151
       #14 0x000000000060c3f5 in catch_errors (func=0x610afe <captured_main>, func_args=0x7fffffffd780, errstring=0x9002c1 "", mask=RETURN_MASK_ALL)
           at gdb/exceptions.c:237
       #15 0x0000000000611c28 in gdb_main (args=0x7fffffffd780) at gdb/main.c:1159
       #16 0x000000000045ef97 in main (argc=5, argv=0x7fffffffd888) at gdb/gdb.c:32
       (top-gdb)
      
      Tested on x86_64 Fedora 20, native and gdbserver.
      
      gdb/
      2014-10-17  Pedro Alves  <palves@redhat.com>
      
      	PR gdb/17300
      	* infcmd.c (continue_1): If continuing all threads in the
      	foreground, make sure the inferior's terminal settings are put in
      	effect.
      
      gdb/testsuite/
      2014-10-17  Pedro Alves  <palves@redhat.com>
      
      	PR gdb/17300
      	* gdb.base/continue-all-already-running.c: New file.
      	* gdb.base/continue-all-already-running.exp: New file.
      e37951dc
    • Pedro Alves's avatar
      PR gdb/17472: With annotations, input while executing in the foreground crashes readline/GDB · 04f05157
      Pedro Alves authored
      Jan caught an intermittent GDB crash with the annota1.exp test:
      
       Starting program: .../gdb/testsuite/gdb.base/annota1 ^M
       [...]
       FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
       [...]
       readline: readline_callback_read_char() called with no handler!^M
       ERROR: Process no longer exists
      
      All we need to is to continue the inferior in the foreground, and type
      a command while the inferior is running.  E.g.:
      
       (gdb) set annotate 2
      
       ▒▒pre-prompt
       (gdb)
       ▒▒prompt
       c
      
       ▒▒post-prompt
       Continuing.
      
       ▒▒starting
      
       ▒▒frames-invalid
      
       *inferior is running now*
      
       p 1<ret>
      
       readline: readline_callback_read_char() called with no handler!
       Aborted (core dumped)
       $
      
      
      When we run a foreground execution command we call
      target_terminal_inferior to stop GDB from processing input, and to put
      the inferior's terminal settings in effect.  Then we tell readline to
      hide the prompt with display_gdb_prompt, which clears readline's input
      callback too.  When the target stops, we call target_terminal_ours,
      which re-installs stdin in the event loop, and then we redisplay the
      prompt, reinstalling the readline callbacks.
      
      However, when annotations are in effect, the "frames-invalid"
      annotation code calls target_terminal_ours after 'resume' had already
      called target_terminal_inferior:
      
       (top-gdb) bt
       #0  0x000000000056b82f in annotate_frames_invalid () at gdb/annotate.c:219
       #1  0x000000000072e6cc in reinit_frame_cache () at gdb/frame.c:1705
       #2  0x0000000000594bb9 in registers_changed_ptid (ptid=...) at gdb/regcache.c:612
       #3  0x000000000064cca1 in target_resume (ptid=..., step=1, signal=GDB_SIGNAL_0) at gdb/target.c:2136
       #4  0x00000000005f57af in resume (step=1, sig=GDB_SIGNAL_0) at gdb/infrun.c:2263
       #5  0x00000000005f6051 in proceed (addr=18446744073709551615, siggnal=GDB_SIGNAL_DEFAULT, step=1) at gdb/infrun.c:2613
      
      And then once we hide the prompt and remove readline's input handler
      callback, we're in a bad state.  We end up with the target running
      supposedly in the foreground, but with stdin still installed on the
      event loop.  Any input then calls into readline, which aborts because
      no rl_linefunc callback handler is installed:
      
       Program received signal SIGABRT, Aborted.
       0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
       56        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
      
       (top-gdb) bt
       #0  0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
       #1  0x0000003b36a36f68 in __GI_abort () at abort.c:89
       During symbol reading, debug info gives source 9 included from file at zero line 0.
       During symbol reading, debug info gives command-line macro definition with non-zero line 19: _STDC_PREDEF_H 1.
       #2  0x0000000000784a25 in rl_callback_read_char () at src/readline/callback.c:116
       #3  0x0000000000619111 in rl_callback_read_char_wrapper (client_data=0x0) at src/gdb/event-top.c:167
       #4  0x00000000006194e7 in stdin_event_handler (error=0, client_data=0x0) at src/gdb/event-top.c:373
       #5  0x00000000006180da in handle_file_event (data=...) at src/gdb/event-loop.c:763
       #6  0x00000000006175c1 in process_event () at src/gdb/event-loop.c:340
       #7  0x0000000000617688 in gdb_do_one_event () at src/gdb/event-loop.c:404
       #8  0x00000000006176d8 in start_event_loop () at src/gdb/event-loop.c:429
       #9  0x0000000000619143 in cli_command_loop (data=0x0) at src/gdb/event-top.c:182
       #10 0x000000000060f4c8 in current_interp_command_loop () at src/gdb/interps.c:318
       #11 0x0000000000610691 in captured_command_loop (data=0x0) at src/gdb/main.c:323
       #12 0x000000000060c385 in catch_errors (func=0x610676 <captured_command_loop>, func_args=0x0, errstring=0x900241 "", mask=RETURN_MASK_ALL)
           at src/gdb/exceptions.c:237
       #13 0x0000000000611b8f in captured_main (data=0x7fffffffd7b0) at src/gdb/main.c:1151
       #14 0x000000000060c385 in catch_errors (func=0x610a8e <captured_main>, func_args=0x7fffffffd7b0, errstring=0x900241 "", mask=RETURN_MASK_ALL)
           at src/gdb/exceptions.c:237
       #15 0x0000000000611bb8 in gdb_main (args=0x7fffffffd7b0) at src/gdb/main.c:1159
       #16 0x000000000045ef57 in main (argc=3, argv=0x7fffffffd8b8) at src/gdb/gdb.c:32
      
      The fix is to make the annotation code call target_terminal_inferior
      again after printing, if the inferior's settings were in effect.
      
      While at it, when we're doing output only, instead of
      target_terminal_ours, we should call target_terminal_ours_for_output.
      The latter doesn't actually remove stdin from the event loop, and also
      leaves SIGINT forwarded to the target.
      
      New test included.
      
      Tested on x86_64 Fedora 20, native and gdbserver.
      
      gdb/
      2014-10-17  Pedro Alves  <palves@redhat.com>
      
      	PR gdb/17472
      	* annotate.c (annotate_breakpoints_invalid): Use
      	target_terminal_our_for_output instead of target_terminal_ours.
      	Give back the terminal to the target.
      	(annotate_frames_invalid): Likewise.
      
      gdb/testsuite/
      2014-10-17  Pedro Alves  <palves@redhat.com>
      
      	PR gdb/17472
      	* gdb.base/annota-input-while-running.c: New file.
      	* gdb.base/annota-input-while-running.exp: New file.
      04f05157
    • Pedro Alves's avatar
      Make common code handle target_terminal_* idempotency · 92e08c0d
      Pedro Alves authored
      I found a place that should be giving back the terminal to the target,
      but only if the target was already owning it.  So I need to add a
      getter for who owns the terminal.
      
      The trouble is that several places/target have their own globals to
      track this state:
      
       - inflow.c:terminal_is_ours
       - remote.c:remote_async_terminal_ours_p
       - linux-nat.c:async_terminal_is_ours
       - go32-nat.c:terminal_is_ours
      
      While one might think of adding a new target_ops method to query this,
      conceptually, this state isn't really part of a particular target_ops.
      Considering multi-target, the core shouldn't have to ask all targets
      to know whether it's GDB that owns the terminal.  There's only one GDB
      (or rather, only one top level interpreter).
      
      So what this comment does is add a new global that is tracked by the
      core instead.  A subsequent pass may later remove the other globals.
      
      Tested on x86_64 Fedora 20, native and gdbserver.
      
      gdb/
      2014-10-17  Pedro Alves  <palves@redhat.com>
      
      	* target.c (enum terminal_state): New enum.
      	(terminal_state): New global.
      	(target_terminal_init): New function.
      	(target_terminal_inferior): Skip if inferior already owns the
      	terminal.
      	(target_terminal_ours, target_terminal_ours_for_output): New
      	functions.
      	* target.h (target_terminal_init): Convert to function prototype.
      	(target_terminal_ours_for_output): Convert to function prototype
      	and tweak comment.
      	(target_terminal_ours): Convert to function prototype and tweak
      	comment.
      	* windows-nat.c (do_initial_windows_stuff): Call
      	target_terminal_init instead of child_terminal_init_with_pgrp.
      92e08c0d
    • GDB Administrator's avatar
      Automatic date update in version.in · e7366593
      GDB Administrator authored
      e7366593
  14. 16 Oct, 2014 1 commit
  15. 15 Oct, 2014 3 commits
    • Doug Evans's avatar
      PR python/17364 · 244fe82b
      Doug Evans authored
      gdb/ChangeLog:
      
      	* python/lib/gdb/__init__.py (packages): Add "printer".
      	* python/lib/gdb/command/bound_registers.py: Moved to ...
      	* python/lib/gdb/printer/bound_registers.py: ... here.
      	Add printer to global set of builtin printers.  Rename printer from
      	"bound" to "mpx_bound128".
      	* python/lib/gdb/printing.py (_builtin_pretty_printers): New global,
      	registered as global "builtin" printer.
      	(add_builtin_pretty_printer): New function.
      	* data-directory/Makefile.in (PYTHON_FILE_LIST): Update, and add
      	gdb/printer/__init__.py.
      244fe82b
    • Joel Brobecker's avatar
      state->dr_control_mirror == 0 failed assertion in gdbserver on Windows XP · a70c6d64
      Joel Brobecker authored
      When using GDBserver on Windows XP, GDBserver reports an assertion
      failure after hitting a hardware watchpoint. The problem was reproduced
      using the sources from gdb.ada/int_deref, but should probably reproduce
      with any scenario involving hardware watchpoints.
      
      In our scenario, we break on line 5, just before the increment, insert
      a watchhpoint on it, and then continue:
      
          (gdb) b foo.adb:5
          Breakpoint 1 at 0x4017c2: file foo.adb, line 5.
          (gdb) cont
          Continuing.
      
          Breakpoint 1, foo () at foo.adb:5
          5          Pck.Watch := Pck.Watch + 1;
          (gdb) watch watch
          Hardware watchpoint 2: watch
          (gdb) c
          Continuing.
          Remote communication error.  Target disconnected.: Invalid argument.
      
      The immediate cause for the communication error is easily explained,
      gdbserver crashes due to a failed assertion:
      
          x86_remove_aligned_watchpoint: Assertion `state->dr_control_mirror == 0' failed.
      
      The assertion occurs because debug_reg_state.dr_control_mirror gets
      overwritten by the value read from the inferior, when processing
      the watchpoint event in win32_wait: win32_wait finds that we stopped,
      calls get_thread_regcache which causes i386_get_thread_context to
      get called, which then...
      
        if (th->tid == current_event->dwThreadId)
          {
            /* Copy dr values from the current thread.  */
            struct x86_debug_reg_state *dr = &debug_reg_state;
            [...]
            dr->dr_control_mirror = th->context.Dr7;
          }
      
      Both should be identical, normally making this a no-op, but
      it turns out that bits 12-11-10 are documented as being fixed
      and equal to 001. Our handling of dr_control_mirror does not
      manage those bits, and leaves them as zeros instead. So, when
      we overwrite the value from the thread's DR7 register, we
      accidentally set bit 10, causing state->dr_control_mirror
      to be 0x400 after we've cleared everything internally.
      
      This patch fixes the issue by removing the statement setting
      state->dr_control_mirror to the thread's DR7 register value.
      
      gdb/gdbserver/ChangeLog:
      
              PR server/17487
              * win32-i386-low.c (i386_get_thread_context): Do not set
              dr->dr_control_mirror.
      a70c6d64
    • GDB Administrator's avatar
      Automatic date update in version.in · a39611f9
      GDB Administrator authored
      a39611f9
  16. 14 Oct, 2014 1 commit
  17. 13 Oct, 2014 1 commit
  18. 12 Oct, 2014 1 commit
  19. 11 Oct, 2014 1 commit
  20. 10 Oct, 2014 1 commit
  21. 09 Oct, 2014 1 commit
  22. 08 Oct, 2014 1 commit
  23. 07 Oct, 2014 1 commit
  24. 06 Oct, 2014 1 commit
  25. 05 Oct, 2014 1 commit
  26. 04 Oct, 2014 1 commit
  27. 03 Oct, 2014 1 commit
  28. 02 Oct, 2014 1 commit
  29. 01 Oct, 2014 2 commits
    • Pedro Alves's avatar
      Aarch64: Make CPSR a 32-bit register again in the target description · 63fcc8bc
      Pedro Alves authored
      This reverts commit a4d9ba85 - 'AARCH64: Change cpsr type to be
      64bit.'.
      
      Even though Linux's ptrace exposes CPSR as 64-bit, CPSR is really
      32-bit, and basing GDB's fundamentals on a particular OS's ptrace(2)
      implementation is a bad idea.
      
      In addition, while that commit intended to fix big endian Aarch64, it
      ended up breaking floating point debugging against GDBserver, for both
      big and little endian, because it changed the CPSR to be 64-bit in the
      features/aarch64-core.xml file, but missed regenerating the
      regformats/aarch64.dat file.  If we generate it now, we see this:
      
        diff --git c/gdb/regformats/aarch64.dat w/gdb/regformats/aarch64.dat
        index afe1028..0d32183 100644
        --- c/gdb/regformats/aarch64.dat
        +++ w/gdb/regformats/aarch64.dat
        @@ -35,7 +35,7 @@ expedite:x29,sp,pc
         64:x30
         64:sp
         64:pc
        -32:cpsr
        +64:cpsr
         128:v0
         128:v1
         128:v2
      
      IOW, that commit left regformats/aarch64.dat still considering CPSR as
      32-bits.  regformats/aarch64.dat is used by GDBserver for its internal
      regcache layout, and for the g/G packet register block.  See the
      generated aarch64.c file in GDBserver's build dir.
      
      So the target description xml file that GDBserver reports to GDB is
      now claiming that CPSR is 64-bit, but what GDBserver actually puts in
      the g/G register packets is 32-bits.  Because GDB thinks CPSR is
      64-bit (because that's what the XML description says), GDB will be
      reading the remaining 32-bit bits of CPSR out of v0 (the register
      immediately afterwards), and then all the registers that follow CPSR
      in the register packet end up wrong in GDB, because they're being read
      from the wrong offsets...
      
      gdb/
      2014-10-01  Pedro Alves  <palves@redhat.com>
      
      	* features/aarch64-core.xml (cpsr): Change back to 32-bit.
      	* features/aarch64.c: Regenerate.
      63fcc8bc
    • GDB Administrator's avatar
      Automatic date update in version.in · e8820d83
      GDB Administrator authored
      e8820d83
  30. 30 Sep, 2014 1 commit