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

  1. 15 Jan, 2015 1 commit
  2. 14 Jan, 2015 2 commits
    • Pedro Alves's avatar
      PR17525 - breakpoint commands not executed when program run from -x script · d2c8f4be
      Pedro Alves authored
      Executing a gdb script that runs the inferior (from the command line
      with -x), and has it hit breakpoints with breakpoint commands that
      themselves run the target, is currently broken on async targets
      (Linux, remote).
      
      While we're executing a command list or a script, we force the
      interpreter to be sync, which results in some functions nesting an
      event loop and waiting for the target to stop, instead of returning
      immediately and having the top level event loop handle the stop.
      
      The issue with this bug is simply that bpstat_do_actions misses
      checking whether the interpreter is sync.  When we get here, in the
      case of executing a script (or, when the interpreter is sync), the
      program has already advanced to the next breakpoint, through
      maybe_wait_sync_command_done.  We need to process its breakpoints
      immediately, just like with a sync target.
      
      Tested on x86_64 Fedora 20.
      
      gdb/
      2015-01-14  Pedro Alves  <palves@redhat.com>
      
      	PR gdb/17525
      	* breakpoint.c: Include "interps.h".
      	(bpstat_do_actions_1): Also check whether the interpreter is
      	async.
      
      gdb/testsuite/
      2015-01-14  Pedro Alves  <palves@redhat.com>
      	    Joel Brobecker  <brobecker@adacore.com>
      
      	PR gdb/17525
      	* gdb.base/bp-cmds-execution-x-script.c: New file.
      	* gdb.base/bp-cmds-execution-x-script.exp: New file.
      	* gdb.base/bp-cmds-execution-x-script.gdb: New file.
      d2c8f4be
    • Pedro Alves's avatar
      PR cli/17828: -batch -ex r breaks terminal · e6da5aef
      Pedro Alves authored
      Commit d3d4baed (PR python/17372 - Python hangs when displaying
      help()) had the side effect of causing 'gdb -batch' to leave the
      terminal in the wrong state if the program was run.  E.g,.
      
       $ echo 'main(){*(int*)0=0;}' | gcc -x c -; ./gdb/gdb -batch -ex r ./a.out
       Program received signal SIGSEGV, Segmentation fault.
       0x00000000004004ff in main ()
       $
      
      If you start typing the next command, seemingly nothing happens - GDB
      left the terminal with echo disabled.
      
      The issue is that that "r" ends up in fetch_inferior_event, which
      calls reinstall_readline_callback_handler_cleanup, which causes
      readline to prep the terminal (raw, echo disabled).  But "-batch"
      causes GDB to exit before the top level event loop is first started,
      and then nothing de-preps the terminal.
      
      The reinstall_readline_callback_handler_cleanup function's intro
      comment mentions:
      
       "Need to do this as we go back to the event loop, ready to process
       further input."
      
      but the implementation forgets the case of when the interpreter is
      sync, which indicates we won't return to the event loop yet, or as in
      the case of -batch, we have not started it yet.
      
      The fix is to not install the readline callback in that case.
      
      For the test, in this case, checking that command echo still works is
      sufficient.  Comparing stty output before/after running GDB is even
      better.  Because stty may not be available, the test tries both ways.
      In any case, since expect's spawn (what we use to start gdb) creates a
      new pseudo tty, another expect spawn or tcl exec after GDB exits would
      not see the wrong terminal settings.  So instead, the test spawns a
      shell and runs stty and GDB in it.
      
      Tested on x86_64 Fedora 20.
      
      gdb/
      2015-01-14  Pedro Alves  <palves@redhat.com>
      
      	PR cli/17828
      	* infrun.c (reinstall_readline_callback_handler_cleanup): Don't
      	reinstall if the interpreter is sync.
      
      gdb/testsuite/
      2015-01-14  Pedro Alves  <palves@redhat.com>
      
      	PR cli/17828
      	* gdb.base/batch-preserve-term-settings.c: New file.
      	* gdb.base/batch-preserve-term-settings.exp: New file.
      e6da5aef
  3. 13 Jan, 2015 1 commit
  4. 12 Jan, 2015 1 commit
  5. 11 Jan, 2015 1 commit
  6. 10 Jan, 2015 1 commit
  7. 09 Jan, 2015 1 commit
  8. 08 Jan, 2015 1 commit
  9. 07 Jan, 2015 1 commit
  10. 06 Jan, 2015 1 commit
  11. 05 Jan, 2015 1 commit
  12. 04 Jan, 2015 1 commit
  13. 03 Jan, 2015 1 commit
  14. 02 Jan, 2015 1 commit
  15. 01 Jan, 2015 1 commit
  16. 31 Dec, 2014 2 commits
    • Joel Brobecker's avatar
      Lift DWARF unwinder restriction in dwarf2-frame.c::dwarf2_frame_cfa · ec95c61a
      Joel Brobecker authored
      GDB is currently broken on all SPARC targets when using GCC 4.9.
      When trying to print any local variable:
      
          (gdb) p x
          can't compute CFA for this frame
      
      This is related to the fact that the compiler now generates DWARF 4
      debugging info by default, and in particular that it now emits
      DW_OP_call_frame_cfa, which triggers a limitation in dwarf2_frame_cfa:
      
         /* This restriction could be lifted if other unwinders are known to
            compute the frame base in a way compatible with the DWARF
            unwinder.  */
         if (!frame_unwinder_is (this_frame, &dwarf2_frame_unwind)
             && !frame_unwinder_is (this_frame, &dwarf2_tailcall_frame_unwind))
           error (_("can't compute CFA for this frame"));
      
      We couldn't append the dwarf2 unwinder to all SPARC targets because
      it does not work properly with StackGhost:
          https://www.sourceware.org/ml/gdb-patches/2014-07/msg00012.html
      
      We also later discovered that using the DWARF2 unwinder means
      using it for computing the function's return address, which
      is buggy when it comes to functions returning a struct (where
      the return address is saved-pc+12 instead of saved-pc+8).
      This is because GCC is emitting the info about the return address
      as %o7/%i7 instead of the actual return address.  For functions
      that have debugging info, we compensate by looking at the function's
      return type and add the extra +4, but for function without debug
      info, we're stuck.
      
      EricB and I twisted the issue in all the directions we could think of,
      and unfortunately couldn't find a way to make it work without
      introduction one regression or another.
      
      But, stepping back a little, just removing the restriction seems to work
      well for us on all both sparc-elf and {sparc,sparc64}-solaris.
      After reviewing the previous discussions about this test, I could
      not figure out whether some unwinders were already known to have
      incompatible CFAs or if the concern was purely theoretical:
          https://www.sourceware.org/ml/gdb-patches/2009-06/msg00191.html
          https://www.sourceware.org/ml/gdb-patches/2009-07/msg00570.html
          https://www.sourceware.org/ml/gdb-patches/2009-09/msg00027.html
      
      At the moment, we took the approach of trying it out, and see what
      happens...
      
      gdb/ChangeLog:
      
              PR backtrace/16215:
              * dwarf2-frame.c (dwarf2_frame_cfa): Remove the restriction
              the frame unwinder must either be the dwarf2_frame_unwind
              or the dwarf2_tailcall_frame_unwind.  Verify that this_frame's
              stack_addr is valid before calling get_frame_base.  Throw
              an error if not valid.
      
      Tested on sparc-solaris and sparc-elf with AdaCore's testsuite
      (the FSF testsuite crashes all of AdaCore's solaris machines).
      ec95c61a
    • GDB Administrator's avatar
      Automatic date update in version.in · f0df25af
      GDB Administrator authored
      f0df25af
  17. 30 Dec, 2014 2 commits
  18. 29 Dec, 2014 1 commit
  19. 28 Dec, 2014 1 commit
  20. 27 Dec, 2014 1 commit
  21. 26 Dec, 2014 1 commit
  22. 25 Dec, 2014 1 commit
  23. 24 Dec, 2014 1 commit
  24. 23 Dec, 2014 1 commit
  25. 22 Dec, 2014 1 commit
  26. 21 Dec, 2014 1 commit
  27. 20 Dec, 2014 1 commit
  28. 19 Dec, 2014 1 commit
  29. 18 Dec, 2014 1 commit
  30. 17 Dec, 2014 1 commit
  31. 16 Dec, 2014 1 commit
  32. 15 Dec, 2014 4 commits
    • H.J. Lu's avatar
      Add _bfd_elf_ifunc_get_synthetic_symtab · cd4294b2
      H.J. Lu authored
      In i386 and x86-64 binaries with ifunc, relocations against .got.plt
      section may not be in the same order as entries in PLT section.  This
      patch adds _bfd_elf_ifunc_get_synthetic_symtab.  It takes a function
      pointer which returns an array of PLT entry symbol values.  It calls
      the function pointer to get the PLT entry symbol value array indexed
      by relocation index, instead of calling plt_sym_val on each relocation
      index.
      
      	PR binutils/17677
      	* elf-bfd.h (_bfd_elf_ifunc_get_synthetic_symtab): New prototype.
      	* elf-ifunc.c (_bfd_elf_ifunc_get_synthetic_symtab): New
      	function.
      	* elf32-i386.c (elf_i386_plt_sym_val): Removed.
      	(elf_backend_plt_sym_val): Likewise.
      	(elf_i386_get_plt_sym_val): New.
      	(elf_i386_get_synthetic_symtab): Likewise.
      	(bfd_elf32_get_synthetic_symtab): Likewise.
      	* elf64-x86-64.c (elf_x86_64_plt_sym_val): Removed.
      	(elf_x86_64_plt_sym_val_offset_plt_bnd): Likewise.
      	(elf_backend_plt_sym_val): Likewise.
      	(elf_x86_64_get_plt_sym_val): New.
      	(bfd_elf32_get_synthetic_symtab): Likewise.
      	(elf_x86_64_get_synthetic_symtab): Use
      	_bfd_elf_ifunc_get_synthetic_symtab.
      	(bfd_elf64_get_synthetic_symtab): Don't undefine for NaCl.
      cd4294b2
    • Jan Kratochvil's avatar
      Fix 7.8 regression: resolve_dynamic_struct: Assertion `TYPE_NFIELDS (type) > 0' (PR 17642) · dbdc8a04
      Jan Kratochvil authored
      https://sourceware.org/bugzilla/show_bug.cgi?id=17642
      
      Regression since:
      commit 012370f6
      Author: Tom Tromey <tromey@redhat.com>
      Date:   Thu May 8 11:26:44 2014 -0600
          handle VLA in a struct or union
      
      Bugreport:
      Regression with gdb scripts for Linux kernel
      https://sourceware.org/ml/gdb/2014-08/msg00127.html
      
      That big change after "else" is just reindentation.
      
      gdb/ChangeLog
      2014-12-15  Jan Kratochvil  <jan.kratochvil@redhat.com>
      
      	PR symtab/17642
      	* gdbtypes.c (resolve_dynamic_type_internal): Apply check_typedef to
      	TYPE if not TYPE_CODE_TYPEDEF.
      
      gdb/testsuite/ChangeLog
      2014-12-15  Jan Kratochvil  <jan.kratochvil@redhat.com>
      
      	PR symtab/17642
      	* gdb.base/vla-stub-define.c: New file.
      	* gdb.base/vla-stub.c: New file.
      	* gdb.base/vla-stub.exp: New file.
      dbdc8a04
    • Jan Kratochvil's avatar
      Reindent code (resolve_dynamic_type_internal). · c644a857
      Jan Kratochvil authored
      gdb/ChangeLog
      2014-12-15  Jan Kratochvil  <jan.kratochvil@redhat.com>
      
      	* gdbtypes.c (resolve_dynamic_type_internal): Reindent the code.
      c644a857
    • GDB Administrator's avatar
      Automatic date update in version.in · 20d3bf4f
      GDB Administrator authored
      20d3bf4f
  33. 14 Dec, 2014 1 commit
  34. 13 Dec, 2014 1 commit