Set GDB version number to 7.8.

gdb/ChangeLog:

* version.in: Set GDB version number to 7.8.

Update gdb/NEWS in preparation for GDB 7.8 release.

gdb/ChangeLog:

* NEWS: Change "Changes since GDB 7.7" into "Changes in GDB 7.8".

Fix PR 17206

As reported in PR 17206, an internal error is triggered when command
until is executed.  In infcmd.c:until_next_command, step_range_end is
set to 'pc',

  if (!func)
    {
      struct bound_minimal_symbol msymbol = lookup_minimal_symbol_by_pc (pc);

      if (msymbol.minsym == NULL)
error (_("Execution is not within a known function."));

      tp->control.step_range_start = BMSYMBOL_VALUE_ADDRESS (msymbol);
      tp->control.step_range_end = pc;
    }

and later in infrun.c:resume, the assert below is triggered in PR
17206.

  if (tp->control.may_range_step)
    {
      /* If we're resuming a thread with the PC out of the step
 range, then we're doing some nested/finer run control
 operation, like stepping the thread out of the dynamic
 linker or the displaced stepping scratch pad.  We
 shouldn't have allowed a range step then.  */
      gdb_assert (pc_in_thread_step_range (pc, tp));
    }

In until_next_command, we set step range to [XXX, pc), so pc isn't
within the range.  pc_in_thread_step_range returns false and the
assert is triggered.  AFAICS, the range we want in until_next_command
is [XXX, pc] instead of [XXX, pc), because we want to program step
until greater than pc.  This patch is to set step_range_end to
'pc + 1'.  Running until-nodebug.exp with unpatched GDB will get the
following fail,

FAIL: gdb.base/until-nodebug.exp: until 2 (GDB internal error)

and the fail goes away when the fix is applied.

gdb:

2014-07-29  Yao Qi  <yao@codesourcery.com>

PR gdb/17206
* infcmd.c (until_next_command): Set step_range_end to PC + 1.

gdb/testsuite:

2014-07-29  Yao Qi  <yao@codesourcery.com>

PR gdb/17206
* gdb.base/until-nodebug.exp: New.

PR guile/17203

* guile/scm-param.c (pascm_parameter_defined_p): New function.
(gdbscm_register_parameter_x): Call it.  Raise error for pre-existing
parameters.

testsuite/
* gdb.guile/scm-parameter.exp: Add tests for trying to create
previously existing parameter, and previously ambiguously spelled
parameter.

Automatic date update in version.in

2014-07-28  Edjunior Barbosa Machado  <emachado@linux.vnet.ibm.com>

    * ppc-linux-nat.c (ppc_linux_can_use_hw_breakpoint): Report no hardware
    breakpoint support correctly.

watchpoint-reuse-slot.exp: Correctly skip unsupported commands.

The test case "watchpoint-reuse-slot.exp" yields a lot of failures on
s390/s390x: all instances of awatch, rwatch, and hbreak are performed
even though they aren't supported on these targets.  This is because
the test case ignores non-support error messages when probing for
support of these commands, like:

    (gdb) rwatch buf.byte[0]
    Target does not support this type of hardware watchpoint.

The patch adds handling for this case in the appropriate
gdb_test_multiple invocations.

gdb/testsuite/
    * gdb.base/watchpoint-reuse-slot.exp: Handle the case that the
    target lacks support for awatch, rwatch, or hbreak.

Match PLT entry only for ELFOSABI_GNU input

* elf32-i386.c (elf_i386_plt_sym_val): Match PLT entry only for
ELFOSABI_GNU input.
* elf64-x86-64.c (elf_x86_64_plt_sym_val): Likewise.
(elf_x86_64_plt_sym_val_offset_plt_bnd): Likewise.

Properly match PLT entry against .got.plt relocation

Relocations against .got.plt section may not be in the same order as
entries in PLT section.  It is incorrect to assume that the Ith reloction
index against .got.plt section always maps to the (I + 1)th entry in PLT
section.  This patch matches the .got.plt relocation offset/index in PLT
entry against the index in .got.plt relocation table.  It only checks
R_*_JUMP_SLOT and R_*_IRELATIVE relocations.  It ignores R_*_TLS_DESC
and R_*_TLSDESC relocations since they have different PLT entries.

bfd/

PR binutils/17154
* elf32-i386.c (elf_i386_plt_sym_val): Only match R_*_JUMP_SLOT
and R_*_IRELATIVE relocation offset with PLT entry.
* elf64-x86-64.c (elf_x86_64_plt_sym_val): Likewise.
(elf_x86_64_plt_sym_val_offset_plt_bnd): New.
(elf_x86_64_get_synthetic_symtab): Use it.

ld/testsuite/

PR binutils/17154
* ld-ifunc/pr17154-i386.d: New file.
* ld-ifunc/pr17154-x86-64.d: Likewise.
* ld-ifunc/pr17154-x86.s: Likewise.
* ld-x86-64/bnd-ifunc-2.d: Likewise.
* ld-x86-64/bnd-ifunc-2.s: Likewise.
* ld-x86-64/mpx.exp: Run bnd-ifunc-2.
* ld-x86-64/tlsdesc-nacl.pd: Updated.
* ld-x86-64/tlsdesc.pd: Likewise.

Automatic date update in version.in

PR guile/17146

* acinclude.m4 (GDB_GUILE_PROGRAM_NAMES): New macro.
(GDB_GUILD_TARGET_FLAG, GDB_TRY_GUILD): New macros.
* configure.ac: Try to use guild to compile an scm file, if it fails
then disable guile support.
* configure: Regenerate.
* data-directory/Makefile.in (GUILE_SOURCE_FILES): Renamed from
GUILE_FILE_LIST.
(GUILE_COMPILED_FILES): New variable.
(GUILE_FILES) Update.
(GUILD, GUILD_TARGET_FLAG, GUILD_COMPILE_FLAGS): New variables.
(stamp-guile): Compile scm files.
* guile/guile.c (boot_guile_support): New function.
(standard_throw_args_p): New function.
(print_standard_throw_error, print_throw_error): New functions.
(handle_boot_error): New function.
(initialize_scheme_side): Rewrite to call boot_guile_support.
* guile/lib/gdb/boot.scm: Update %load-compiled-path.  Load gdb.go.
* guile/lib/gdb/init.scm (%silence-compiler-warnings%): New function.

PR guile/17146 preparatory work.

* data-directory/Makefile.in (GUILE_FILES): Add support.scm.
* guile/lib/gdb/support.scm: New file.
* guile/guile.c (gdbscm_init_module_name): Change to "gdb".
* guile/lib/gdb.scm: Load gdb/init.scm as an include file.
All uses updated.
* guile/lib/gdb/init.scm (SCM_ARG1, SCM_ARG2): Moved to support.scm.
All uses updated.
(%assert-type): Ditto, and renamed to assert-type.
(%exception-print-style): Delete.

testsuite/
* gdb.guile/types-module.exp: Add tests for wrong type arguments.

PR build/17105.

Tested with/without guile,python on amd64-linux.

I'm not sure we still have to deal with shells that can't
handle empty for lists, but I played it safe.
Otherwise this patch would be a lot smaller (though a diff -b
will still show the real changes).

PR build/17105
* configure.ac: Add AM_CONDITIONALs for HAVE_PYTHON, HAVE_GUILE.
* configure: Regenerate.
* data-directory/Makefile.in (PYTHON_FILE_LIST): Renamed from
PYTHON_FILES.
(PYTHON_FILES): New variable.
(GUILE_FILE_LIST): Renamed from GUILE_FILES.
(GUILE_FILES): New variable.
(stamp-python, install-python, uninstall-python): Handle empty
file list.
(stamp-guile, install-guile, uninstall-guile): Ditto.

PR guile/17177

* guile/lib/gdb.scm (pretty-printers): Export.
(set-pretty-printers!): Export.
* guile/lib/gdb/printing.scm (gdb module): Update.
(prepend-pretty-printer!, append-pretty-printer!): Update.
* guile/scm-pretty-print.c (pretty_printer_list_name): Delete.
(pretty_printer_list_var): Delete.
(pretty_printer_list): New static global.
(gdbscm_pretty_printers): New function.
(gdbscm_set_pretty_printers_x): New function.
(ppscm_find_pretty_printer_from_gdb): Update.
(pretty_printer_functions): Add pretty-printers, set-pretty-printers!.
(gdbscm_initialize_pretty_printers): Update.

doc/
* guile.texi (Guile Pretty Printing API): Fix typo.
Document set-pretty-printers!, pretty-printers.
(Selecting Guile Pretty-Printers): Update.
Mention program-space based pretty-printers.

PR 17185

PR 17185 describes a problem with using gdb+guile with libgc 7.4.0.
The symptom is a hang in sigsuspend.
[The thread referenced in the PR has the details.]
It's not clear what the right fix is, or even where the bug is yet.
This patch applies the same workaround Guile has applied.
There is no functionality or real performance loss with this,
and Guile has been using it for awhile.

     * configure.ac: Add check for header gc/gc.h.
     Add check for function setenv.
     * configure: Regenerate.
     * config.in: Regenerate.
     * guile/guile.c (_initialize_guile): Add workaround for libgc 7.4.0.

Automatic date update in version.in

Automatic date update in version.in

Fix paginate-*.exp races

Jan pointed out in
<https://sourceware.org/ml/gdb-patches/2014-07/msg00553.html> that
these testcases have racy results:

  gdb.base/double-prompt-target-event-error.exp
  gdb.base/paginate-after-ctrl-c-running.exp
  gdb.base/paginate-bg-execution.exp
  gdb.base/paginate-execution-startup.exp
  gdb.base/paginate-inferior-exit.exp

This is easily reproducible with "read1" from:

  [reproducer for races of expect incomplete reads]
  http://sourceware.org/bugzilla/show_bug.cgi?id=12649

The '-notransfer -re "<return>" { exp_continue }' trick in the current
tests doesn't actually work.

The issue that led to the -notransfer trick was that

  "---Type <return> to continue, or q <return> to quit---"

has two "<return>"s.  If one wants gdb_test_multiple to not hit the
built-in "<return>" match that results in FAIL, one has to expect the
pagination prompt in chunks, first up to the first "<return>", then
again, up to the second.  Something around these lines:

  gdb_test_multiple "" $test {
      -re "<return>" {
  exp_continue
      }
      -re "to quit ---" {
  pass $test
      }
  }

The intent was for -notransfer+exp_continue to make expect fetch more
input, and rerun the matches against the now potentially fuller
buffer, and then eventually the -re that includes the full pagination
prompt regex would match instead (because it's listed higher up, it
would match first).  But, once that "<return>" -notransfer -re
matches, it keeps re-matching forever.  It seems like with
exp_continue, expect immediately retries matching, instead of first
reading in more data into the buffer, if available.

Fix this like I should have done in the first place.  There's actually
no good reason for gdb_test_multiple to only match "<return>".  We can
make gdb_test_multiple expect the whole pagination prompt text
instead, which is store in the 'pagination_prompt' global (similar to
'gdb_prompt').  Then a gdb_test_multiple caller that doesn't want the
default match to trigger, because it wants to see one pagination
prompt, does simply:

  gdb_test_multiple "" $test {
      -re "$pagination_prompt$" {
  pass $test
      }
  }

which is just like when we don't want the default $gdb_prompt match
within gdb_test_multiple to trigger, like:

  gdb_test_multiple "" $test {
      -re "$gdb_prompt $" {
  pass $test
      }
  }

Tested on x86_64 Fedora 20.  In addition, I've let the racy tests run
all in parallel in a loop for 30 minutes, and they never failed.

[gdb 7.8: lib/gdb-utils.exp didn't exist in the branch yet, so this patch adds it.]

gdb/testsuite/
2014-07-25  Pedro Alves  <palves@redhat.com>

* gdb.base/double-prompt-target-event-error.exp
(cancel_pagination_in_target_event): Remove '-notransfer <return>'
match.
(cancel_pagination_in_target_event): Rework double prompt
detection.
* gdb.base/paginate-after-ctrl-c-running.exp
(test_ctrlc_while_target_running_paginates): Remove '-notransfer
<return>' match.
* gdb.base/paginate-bg-execution.exp
(test_bg_execution_pagination_return)
(test_bg_execution_pagination_cancel): Remove '-notransfer
<return>' matches.
* gdb.base/paginate-execution-startup.exp
(test_fg_execution_pagination_return)
(test_fg_execution_pagination_cancel): Remove '-notransfer
<return>' matches.
* gdb.base/paginate-inferior-exit.exp
(test_paginate_inferior_exited): Remove '-notransfer <return>'
match.
* lib/gdb-utils.exp: New file.
* lib/gdb.exp: Load gdb-utils.exp.
(pagination_prompt): Run text through string_to_regexp.
(gdb_test_multiple): Match $pagination_prompt instead of
"<return>".
(string_to_regexp): Move to lib/gdb-utils.exp.

Automatic date update in version.in

Fix pagination crash when the TUI is active

The TUI currently crashes when the user types <return> in response to
a pagination prompt:

  $ gdb --tui ...
  *the TUI is now active*
  (gdb) set height 2
  (gdb) help
  List of classes of commands:

  Program received signal SIGSEGV, Segmentation fault.
  strlen () at ../sysdeps/x86_64/strlen.S:106
  106             movdqu  (%rax), %xmm12

  (top-gdb) bt
  #0  strlen () at ../sysdeps/x86_64/strlen.S:106
  #1  0x000000000086be5f in xstrdup (s=0x0) at ../src/libiberty/xstrdup.c:33
  #2  0x00000000005163f9 in tui_prep_terminal (notused1=1) at ../src/gdb/tui/tui-io.c:296
  #3  0x000000000077a7ee in _rl_callback_newline () at ../src/readline/callback.c:82
  #4  0x000000000077a853 in rl_callback_handler_install (prompt=0x0, linefunc=0x618b60 <command_line_handler>) at ../src/readline/callback.c:102
  #5  0x0000000000718a5c in gdb_readline_wrapper_cleanup (arg=0xfd14d0) at ../src/gdb/top.c:788
  #6  0x0000000000596d08 in do_my_cleanups (pmy_chain=0xcf0b38 <cleanup_chain>, old_chain=0x1043d10) at ../src/gdb/cleanups.c:155
  #7  0x0000000000596d75 in do_cleanups (old_chain=0x1043d10) at ../src/gdb/cleanups.c:177
  #8  0x0000000000718bd9 in gdb_readline_wrapper (prompt=0x7fffffffcfa0 "---Type <return> to continue, or q <return> to quit---")
      at ../src/gdb/top.c:835
  #9  0x000000000071cf74 in prompt_for_continue () at ../src/gdb/utils.c:1894
  #10 0x000000000071d434 in fputs_maybe_filtered (linebuffer=0x1043db0 "List of classes of commands:\n\n", stream=0xf72e20, filter=1)
      at ../src/gdb/utils.c:2111
  #11 0x000000000071da0f in vfprintf_maybe_filtered (stream=0xf72e20, format=0x89aef8 "List of classes of %scommands:\n\n", args=0x7fffffffd118, filter=1)
      at ../src/gdb/utils.c:2339
  #12 0x000000000071da4a in vfprintf_filtered (stream=0xf72e20, format=0x89aef8 "List of classes of %scommands:\n\n", args=0x7fffffffd118)
      at ../src/gdb/utils.c:2347
  #13 0x000000000071dc72 in fprintf_filtered (stream=0xf72e20, format=0x89aef8 "List of classes of %scommands:\n\n") at ../src/gdb/utils.c:2399
  #14 0x00000000004f90ab in help_list (list=0xe6d100, cmdtype=0x89ad8c "", class=all_classes, stream=0xf72e20)
      at ../src/gdb/cli/cli-decode.c:1038
  #15 0x00000000004f8dba in help_cmd (arg=0x0, stream=0xf72e20) at ../src/gdb/cli/cli-decode.c:946

Git 0017922 added:

    @@ -776,6 +777,12 @@ gdb_readline_wrapper_cleanup (void *arg)

     gdb_assert (input_handler == gdb_readline_wrapper_line);
     input_handler = cleanup->handler_orig;
  +
  +  /* Reinstall INPUT_HANDLER in readline, without displaying a
  +     prompt.  */
  +  if (async_command_editing_p)
  +    rl_callback_handler_install (NULL, input_handler);

and tui_prep_terminal simply misses handling the case of a NULL
rl_prompt.

I also checked that readline's sources do similar checks.

gdb/
2014-07-24  Pedro Alves  <palves@redhat.com>

* tui/tui-io.c (tui_prep_terminal): Handle NULL rl_prompt.

Automatic date update in version.in

Automatic date update in version.in

Fix read_frame_arg for optimized-out entry values.

gdb/
2014-07-22  Jan Kratochvil  <jan.kratochvil@redhat.com>

* stack.c (read_frame_arg): Verify value_optimized_out before calling
value_available_contents_eq.

gdb/testsuite/
2014-07-22  Jan Kratochvil  <jan.kratochvil@redhat.com>

* gdb.arch/amd64-entry-value-paramref.S: New file.
* gdb.arch/amd64-entry-value-paramref.cc: New file.
* gdb.arch/amd64-entry-value-paramref.exp: New file.
* gdb.arch/amd64-optimout-repeat.S: New file.
* gdb.arch/amd64-optimout-repeat.c: New file.
* gdb.arch/amd64-optimout-repeat.exp: New file.

Message-ID: <20140720150727.GA18488@host2.jankratochvil.net>
Message-ID: <20140711153757.GA452@host2.jankratochvil.net>

Fix crash on optimized-out entry data values

The tests at
<https://sourceware.org/ml/gdb-patches/2014-07/msg00277.html> show
that comparing a fully optimized out value's contents with a value
that has not been optimized out, or is partially optimized out crashes
GDB:

 (gdb) bt
 #0  __memcmp_sse4_1 () at ../sysdeps/x86_64/multiarch/memcmp-sse4.S:816
 #1  0x00000000005a1914 in memcmp_with_bit_offsets (ptr1=0x202b2f0 "\n", offset1_bits=0, ptr2=0x0, offset2_bits=0, length_bits=32)
     at /home/pedro/gdb/mygit/build/../src/gdb/value.c:678
 #2  0x00000000005a1a05 in value_available_contents_bits_eq (val1=0x2361ad0, offset1=0, val2=0x23683b0, offset2=0, length=32)
     at /home/pedro/gdb/mygit/build/../src/gdb/value.c:717
 #3  0x00000000005a1c09 in value_available_contents_eq (val1=0x2361ad0, offset1=0, val2=0x23683b0, offset2=0, length=4)
     at /home/pedro/gdb/mygit/build/../src/gdb/value.c:769
 #4  0x00000000006033ed in read_frame_arg (sym=0x1b78d20, frame=0x19bca50, argp=0x7fff4aba82b0, entryargp=0x7fff4aba82d0)
     at /home/pedro/gdb/mygit/build/../src/gdb/stack.c:416
 #5  0x0000000000603abb in print_frame_args (func=0x1b78cb0, frame=0x19bca50, num=-1, stream=0x1aea450) at /home/pedro/gdb/mygit/build/../src/gdb/stack.c:671
 #6  0x0000000000604ae8 in print_frame (frame=0x19bca50, print_level=0, print_what=SRC_AND_LOC, print_args=1, sal=...)
     at /home/pedro/gdb/mygit/build/../src/gdb/stack.c:1205
 #7  0x0000000000604050 in print_frame_info (frame=0x19bca50, print_level=0, print_what=SRC_AND_LOC, print_args=1, set_current_sal=1)
     at /home/pedro/gdb/mygit/build/../src/gdb/stack.c:857
 #8  0x00000000006029b3 in print_stack_frame (frame=0x19bca50, print_level=0, print_what=SRC_AND_LOC, set_current_sal=1)
     at /home/pedro/gdb/mygit/build/../src/gdb/stack.c:169
 #9  0x00000000005fc4b8 in print_stop_event (ws=0x7fff4aba8790) at /home/pedro/gdb/mygit/build/../src/gdb/infrun.c:6068
 #10 0x00000000005fc830 in normal_stop () at /home/pedro/gdb/mygit/build/../src/gdb/infrun.c:6214

The 'ptr2=0x0' in frame #1 is val2->contents, and since git 4f14910f:

    gdb/ChangeLog
    2013-11-26  Andrew Burgess  <aburgess@broadcom.com>

        * value.c (allocate_optimized_out_value): Mark value as non-lazy.

... a fully optimized-out value can have it's value contents buffer
NULL.

As a spotgap fix, revert 4f14910f, with a comment.  A full fix would
be too invasive for 7.8.

gdb/
2014-07-22  Pedro Alves  <palves@redhat.com>

* value.c (allocate_optimized_out_value): Don't mark value as
non-lazy.

Automatic date update in version.in

Automatic date update in version.in

Improve error message to cope with pr 17147.

PR server/17147
* remote.c (putpkt_binary): Add text to error message.

Automatic date update in version.in

Automatic date update in version.in

Bump GDB version number to 7.7.91.DATE-cvs.

gdb/ChangeLog:

* version.in: Set GDB version number to 7.7.91.DATE-cvs.

Document the GDB 7.7.91 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 7.7.91 released.

Set GDB version number to 7.7.91.

gdb/ChangeLog:

* version.in: Set GDB version number to 7.7.91.

Automatic date update in version.in

PR 17170 - testcase for GDB global --statistics regression.

gdb/testsuite/
2014-07-17  Jan Kratochvil  <jan.kratochvil@redhat.com>

PR gdb/17170
* gdb.base/statistics.exp: New file.

Message-ID: <20140712174217.GA1478@host2.jankratochvil.net>

Fix PR gdb/17170.

* maint.c (count_symtabs_and_blocks): Handle NULL
current_program_space.
(report_command_stats): Check global enabled flag in addition to
recorded enabled flag.
(make_command_stats_cleanup): Handle msg_type == 0, startup.

testsuite/
* gdb.base/maint.exp: Update testing of per-command stats.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Put GDB's terminal settings into effect when paginating

When the target is resumed in the foreground, we put the inferior's
terminal settings into effect, and remove stdin from the event loop.
When the target stops, we put GDB's terminal settings into effect
again, and re-register stdin in the event loop, ready for user input.
The former is done by target_terminal_inferior, and the latter by
target_terminal_ours.

There's an intermediate -- target_terminal_ours_for_output -- that is
called when printing output related to target events, and we don't
know yet whether we'll stop the program.  That puts our terminal
settings into effect, enough to get proper results from our output,
but leaves input wired into the inferior.

If such output paginates, then we need the full target_terminal_ours
in order for the user to be able to provide input to answer the
pagination query.

The test in this commit hangs in async-capable targets without the fix
(as the user/test can't answer the pagination query).  It doesn't hang
on sync targets because on those we don't unregister stdin from the
event loop while the target is running (because we block in
target_wait instead of in the event loop in that case).

gdb/
2014-07-14  Pedro Alves  <palves@redhat.com>

* utils.c (prompt_for_continue): Call target_terminal_ours.

gdb/testsuite/
2014-07-14  Pedro Alves  <palves@redhat.com>

* gdb.base/paginate-after-ctrl-c-running.c: New file.
  * gdb.base/paginate-after-ctrl-c-running.exp: New file.

Fix double prompt

If an error is thrown while handling a target event (within
fetch_inferior_event), and, the interpreter is not async (but the
target is), then GDB prints the prompt twice.

One way to see that in action is throw a QUIT while in a pagination
prompt issued from within fetch_inferior_event (or one of its
callees).  E.g. from the test:

 ---Type <return> to continue, or q <return> to quit---
 ^CQuit
 (gdb) (gdb) p 1
 ^^^^^^^^^^^
 $1 = 1
 (gdb)

The issue is that inferior_event_handler swallows errors and notifies
the observers (the interpreters) about the command error, even if the
interpreter is forced sync while we're handling a nested event loop
(for execute_command).  The observers print a prompt, and then when we
get back to the top event loop, we print another (in
start_event_loop).

I see no reason the error should be swallowed here.  Just cancel the
execution related bits and let the error propagate to the top level
(start_event_loop), which re-enables stdin and notifies observers.

gdb/
2014-07-14  Pedro Alves  <palves@redhat.com>

* inf-loop.c (inferior_event_handler): Use TRY_CATCH instead of
catch_errors.  Don't re-enable stdin or notify observers where,
and rethrow error.
(fetch_inferior_event_wrapper): Delete.

gdb/testsuite/
2014-07-14  Pedro Alves  <palves@redhat.com>

* gdb.base/double-prompt-target-event-error.c: New file.
* gdb.base/double-prompt-target-event-error.exp: New file.

Remove the target from the event loop while in secondary prompts

If a pagination prompt triggers while the target is running, and the
target exits before the user responded to the pagination query, this
happens:

  Starting program: foo
  ---Type <return> to continue, or q <return> to quit---No unwaited-for children left.
  Couldn't get registers: No such process.
  Couldn't get registers: No such process.
  Couldn't get registers: No such process.
  (gdb) Couldn't get registers: No such process.
  (gdb)

To reiterate, the user hasn't replied to the pagination prompt above.

A pagination query nests an event loop (in gdb_readline_wrapper).  In
async mode, in addition to stdin and signal handlers, we'll have the
target also installed in the event loop still.  So if the target
reports an event, that wakes up the nested event loop, which calls
into fetch_inferior_event etc. to handle the event which generates
further output, all while we should be waiting for pagination
confirmation...

(TBC, any target event that generates output ends up spuriously waking
up the pagination, though exits seem to be the worse kind.)

I've played with a couple different approaches to fixing this, while
at the same time trying to avoid being invasive.  Both revolve around
not listening to target events while in a pagination prompt (doing
anything else I think would be a much bigger change).

The approach taken just removes the target from the event loop while
within gdb_readline_wrapper.  The other approach used gdb_select
directly, with only input_fd installed, but that had the issue that it
didn't handle the async signal handlers, and turned out to be a bit
more code than the first version.

gdb/
2014-07-14  Pedro Alves  <palves@redhat.com>

PR gdb/17072
* top.c: Include "inf-loop.h".
(struct gdb_readline_wrapper_cleanup) <target_is_async_orig>: New
field.
(gdb_readline_wrapper_cleanup): Make the target async again, if it
was async before.
(gdb_readline_wrapper): Store whether the target is async, and
make it sync.

gdb/testsuite/
2014-07-14  Pedro Alves  <palves@redhat.com>

PR gdb/17072
* gdb.base/paginate-inferior-exit.c: New file.
* gdb.base/paginate-inferior-exit.exp: New file.

Background execution + pagination aborts readline/gdb

If pagination occurs as result of output sent as response to a target
event while the target is executing in the background, subsequent
input aborts readline/gdb:

 $ gdb program
 ...
 (gdb) continue&
 Continuing.
 (gdb)
 ---Type <return> to continue, or q <return> to quit---
 *return*
 ---Type <return> to continue, or q <return> to quit---
 Breakpoint 2, after_sleep () at paginate-bg-execution.c:21
 ---Type <return> to continue, or q <return> to quit---
 21        return; /* after sleep */
 p 1
 readline: readline_callback_read_char() called with no handler!
 *abort/SIGABRT*
 $

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.

We should do better with the prompt handling while the target is
running (I think we should coordinate with readline, and
hide/redisplay it around output), but that's a more invasive change
better done post 7.8, so this patch is conservative and just
reinstalls the handler as soon as we're out of the readline line
callback.

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.

gdb/testsuite/
2014-07-14  Pedro Alves  <palves@redhat.com>

PR gdb/17072
* gdb.base/paginate-bg-execution.c: New file.
* gdb.base/paginate-bg-execution.exp: New file.

Canceling pagination caused by execution command from command line aborts readline/gdb

This fixes:

 $ ./gdb program -ex "set height 2" -ex "start"
 ...
 Reading symbols from /home/pedro/gdb/tests/threads...done.
 ---Type <return> to continue, or q <return> to quit---^CQuit  << ctrl-c triggers a Quit

 *type something*
 readline: readline_callback_read_char() called with no handler!
 Aborted
 $

Usually, if an error propagates all the way to the top level, we'll
re-enable stdin, in case the command that was running was a
synchronous command.  That's done in the event loop's actual loop
(event-loop.c:start_event_loop).  However, if a foreground execution
command is run before the event loop starts and throws, nothing is
presently reenabling stdin, which leaves sync_execution set.

When we do start the event loop, because sync_execution is still
(mistakenly) set, display_gdb_prompt removes the readline input
callback, even though stdin is registered in the event loop.  Any
input from here on results in readline aborting.

Such commands are run through catch_command_errors,
catch_command_errors_const, so add the tweak there.

gdb/
2014-07-14  Pedro Alves  <palves@redhat.com>

PR gdb/17072
* main.c: Include event-top.h.
(handle_command_errors): New function.
(catch_command_errors, catch_command_errors_const): Use it.

gdb/testsuite/
2014-07-14  Pedro Alves  <palves@redhat.com>

PR gdb/17072
* gdb.base/paginate-execution-startup.c: New file.
* gdb.base/paginate-execution-startup.exp: New file.
* lib/gdb.exp (pagination_prompt): New global.
(default_gdb_spawn): New procedure, factored out from
default_gdb_spawn.
(default_gdb_start): Adjust to call default_gdb_spawn.
(gdb_spawn): New procedure.

testsuite: Introduce gdb_assert

Often we'll do something like:

    if {$ok} {
fail "whatever"
    } else {
pass "whatever"
    }

This adds a helper procedure for that, and converts one random place
to use it, as an example.

2014-07-14  Pedro Alves  <palves@redhat.com>

* lib/gdb.exp (gdb_assert): New procedure.
* gdb.trace/backtrace.exp (gdb_backtrace_tdp_4): Use it.

Move catch_command_errors and catch_command_errors_const to main.c

We'll need to add error handling code to commands run before the event
loop starts (commands in .gdbinit, -ex commands, etc.).  Turns out
those are run through catch_command_errors, and, catch_command_errors
is used nowhere else.  Move it (and the _const variant) to main.c, so
that we can further specialize it freely.

gdb/
2014-07-14  Pedro Alves  <palves@redhat.com>

* exceptions.c (catch_command_errors, catch_command_errors_const):
Moved to main.c.
* exceptions.h (catch_command_errors_ftype)
(catch_command_errors_const_ftype): Moved to main.c.
(catch_command_errors, catch_command_errors_const): Delete
declarations.
* main.c (catch_command_errors_ftype)
(catch_command_errors_const_ftype): Moved here from exceptions.h.
(catch_command_errors, catch_command_errors_const)): Moved here
from exceptions.c and make static.

Eliminate exceptions.c:print_any_exception.

exception_print and exception_fprintf call print_flush, which does all the
same flushing and annotation things that print_any_exception does, and more.

gdb/
2014-07-14  Pedro Alves  <palves@redhat.com>

* exceptions.c (print_any_exception): Delete.
(catch_exceptions_with_msg): Use exception_print instead of
print_any_exception.
(catch_errors): Use exception_fprintf instead of
print_any_exception.
(catch_command_errors, catch_command_errors_const): Use
exception_print instead of print_any_exception.

Put the inferior's terminal settings in effect while running (fg) infcalls

The "call" and "print" commands presently always run synchronously, in
the foreground, but GDB currently forgets to put the inferior's
terminal settings into effect while running them, on async-capable
targets, resulting in:

 (gdb) print func ()
 hello world

 Program received signal SIGTTOU, Stopped (tty output).
 0x000000373bceb8d0 in __libc_tcdrain (fd=1) at ../sysdeps/unix/sysv/linux/tcdrain.c:29
 29          return INLINE_SYSCALL (ioctl, 3, fd, TCSBRK, 1);
 The program being debugged was signaled while in a function called from GDB.
 GDB remains in the frame where the signal was received.
 To change this behavior use "set unwindonsignal on".
 Evaluation of the expression containing the function
 (func) will be abandoned.
 When the function is done executing, GDB will silently stop.
 (gdb)

That's because target_terminal_inferior skips actually doing anything
if running in the background, and, nothing is setting sync_execution
while running infcalls:

 void
 target_terminal_inferior (void)
 {
   /* A background resume (``run&'') should leave GDB in control of the
      terminal.  Use target_can_async_p, not target_is_async_p, since at
      this point the target is not async yet.  However, if sync_execution
      is not set, we know it will become async prior to resume.  */
   if (target_can_async_p () && !sync_execution)
     return;

This would best be all cleaned up by making GDB not even call
target_terminal_inferior and try to pass the terminal to the inferior
if running in the background, but that's a more invasive fix that is
better done post-7.8.

This was originally caught by a patch later in this series that makes
catch_command_errors use exception_print instead of
print_any_exception.  Note that print_flush calls serial_drain_output
while print_any_exception doesnt't have that bit.  And,
gdb.gdb/python-selftest.exp does:

 gdb_test "call catch_command_errors(execute_command, \"python print 5\", 0, RETURN_MASK_ALL)" \
   "Python not initialized.* = 0"

which without this fix results in SIGTTOU...

gdb/
2014-07-14  Pedro Alves  <palves@redhat.com>

* infcall.c (run_inferior_call): Set 'sync_execution' while
running the inferior call.

gdb/testsuite/
2014-07-14  Pedro Alves  <palves@redhat.com>

* gdb.base/execution-termios.c: New file.
* gdb.base/execution-termios.exp: New file.

fix PR 17106

This fixes PR 17106, a regression in printing.

The bug is that resolve_dynamic_type follows struct members and
references, but doesn't consider the possibility of infinite
recursion.

This patch fixes the problem by limiting reference following to the
topmost layer of calls -- that is, reference-typed struct members are
never considered as being VLAs.

Built and regtested on x86-64 Fedora 20.
New test case included.

2014-07-14  Tom Tromey  <tromey@redhat.com>

PR exp/17106:
* gdbtypes.c (is_dynamic_type_internal): New function, from
is_dynamic_type.
(is_dynamic_type): Rewrite.
(resolve_dynamic_union): Use resolve_dynamic_type_internal.
(resolve_dynamic_struct): Likewise.
(resolve_dynamic_type_internal): New function, from
resolve_dynamic_type.
(resolve_dynamic_type): Rewrite.

2014-07-14  Tom Tromey  <tromey@redhat.com>

* gdb.cp/vla-cxx.cc: New file.
* gdb.cp/vla-cxx.exp: New file.

fix record "run" regression

This fixes the record "run" regression pointed out by Marc Khouzam:

    https://sourceware.org/ml/gdb/2014-06/msg00096.html

The bug is that target_require_runnable must agree with the handling
of the "run" target, but currently it is out of sync.  This patch
fixes the problem by changing target_require_runnable to also ignore
the record_stratum.

Built and regtested on x86-64 Fedora 20.
New test case included.

2014-07-14  Tom Tromey  <tromey@redhat.com>

* target.c (target_require_runnable): Also check record_stratum.
Update comment.

2014-07-14  Tom Tromey  <tromey@redhat.com>

* gdb.reverse/rerun-prec.c: New file.
* gdb.reverse/rerun-prec.exp: New file.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

GDBserver crashes when killing a multi-thread process

Here's an example, with the new test:

 gdbserver :9999 gdb.threads/kill
 gdb gdb.threads/kill
 (gdb) b 52
 Breakpoint 1 at 0x4007f4: file kill.c, line 52.
 Continuing.

 Breakpoint 1, main () at kill.c:52
 52        return 0; /* set break here */
 (gdb) k
 Kill the program being debugged? (y or n) y

 gdbserver :9999 gdb.threads/kill
 Process gdb.base/watch_thread_num created; pid = 9719
 Listening on port 1234
 Remote debugging from host 127.0.0.1
 Killing all inferiors
 Segmentation fault (core dumped)

Backtrace:

 (gdb) bt
 #0  0x00000000004068a0 in find_inferior (list=0x66b060 <all_threads>, func=0x427637 <kill_one_lwp_callback>, arg=0x7fffffffd3fc) at src/gdb/gdbserver/inferiors.c:199
 #1  0x00000000004277b6 in linux_kill (pid=15708) at src/gdb/gdbserver/linux-low.c:966
 #2  0x000000000041354d in kill_inferior (pid=15708) at src/gdb/gdbserver/target.c:163
 #3  0x00000000004107e9 in kill_inferior_callback (entry=0x6704f0) at src/gdb/gdbserver/server.c:2934
 #4  0x0000000000406522 in for_each_inferior (list=0x66b050 <all_processes>, action=0x4107a6 <kill_inferior_callback>) at src/gdb/gdbserver/inferiors.c:57
 #5  0x0000000000412377 in process_serial_event () at src/gdb/gdbserver/server.c:3767
 #6  0x000000000041267c in handle_serial_event (err=0, client_data=0x0) at src/gdb/gdbserver/server.c:3880
 #7  0x00000000004189ff in handle_file_event (event_file_desc=4) at src/gdb/gdbserver/event-loop.c:434
 #8  0x00000000004181c6 in process_event () at src/gdb/gdbserver/event-loop.c:189
 #9  0x0000000000418f45 in start_event_loop () at src/gdb/gdbserver/event-loop.c:552
 #10 0x0000000000411272 in main (argc=3, argv=0x7fffffffd8d8) at src/gdb/gdbserver/server.c:3283

The problem is that linux_wait_for_event deletes lwps that have exited
(even those not passed in as lwps of interest), while the lwp/thread
list is being walked on with find_inferior.  find_inferior can handle
the current iterated inferior being deleted, but not others.

When killing lwps, we don't really care about any of the pending
status handling of linux_wait_for_event.  We can just waitpid the lwps
directly, which is also what GDB does (see
linux-nat.c:kill_wait_callback).  This way the lwps are not deleted
while we're walking the list.  They'll be deleted by linux_mourn
afterwards.

This crash triggers several times when running the testsuite against
GDBserver with the native-gdbserver board (target remote), but as GDB
can't distinguish between GDBserver crashing and "kill" being
sucessful, as in both cases the connection is closed (the 'k' packet
doesn't require a reply), and the inferior is gone, that results in no
FAIL.

The patch adds a generic test that catches the issue with
extended-remote mode (and works fine with native testing too).  Here's
how it fails with the native-extended-gdbserver board without the fix:

 (gdb) info threads
   Id   Target Id         Frame
   6    Thread 15367.15374 0x000000373bcbc98d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
   5    Thread 15367.15373 0x000000373bcbc98d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
   4    Thread 15367.15372 0x000000373bcbc98d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
   3    Thread 15367.15371 0x000000373bcbc98d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
   2    Thread 15367.15370 0x000000373bcbc98d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
 * 1    Thread 15367.15367 main () at .../gdb.threads/kill.c:52
 (gdb) kill
 Kill the program being debugged? (y or n) y
 Remote connection closed
 ^^^^^^^^^^^^^^^^^^^^^^^^
 (gdb) FAIL: gdb.threads/kill.exp: kill

Extended remote should remain connected after the kill.

gdb/gdbserver/
2014-07-11  Pedro Alves  <palves@redhat.com>

* linux-low.c (kill_wait_lwp): New function, based on
kill_one_lwp_callback, but use my_waitpid directly.
(kill_one_lwp_callback, linux_kill): Use it.

gdb/testsuite/
2014-07-11  Pedro Alves  <palves@redhat.com>

* gdb.threads/kill.c: New file.
* gdb.threads/kill.exp: New file.

Automatic date update in version.in

Automatic date update in version.in

Fix "attach" command vs user input race

On async targets, a synchronous attach is done like this:

   #1 - target_attach is called (PTRACE_ATTACH is issued)
   #2 - a continuation is installed
   #3 - we go back to the event loop
   #4 - target reports stop (SIGSTOP), event loop wakes up, and
        attach continuation is called
   #5 - among other things, the continuation calls
        target_terminal_inferior, which removes stdin from the event
        loop

Note that in #3, GDB is still processing user input.  If the user is
fast enough, e.g., with something like:

  echo -e "attach PID\nset xxx=1" | gdb

... then the "set" command is processed before the attach completes.

We get worse behavior even, if input is a tty and therefore
readline/editing is enabled, with e.g.,:

 (gdb) attach PID\nset xxx=1

we then crash readline/gdb, with:

 Attaching to program: attach-wait-input, process 14537
 readline: readline_callback_read_char() called with no handler!
 Aborted
 $

Fix this by calling target_terminal_inferior before #3 above.

The test covers both scenarios by running with editing/readline forced
to both on and off.

gdb/
2014-07-09  Pedro Alves  <palves@redhat.com>

* infcmd.c (attach_command_post_wait): Don't call
target_terminal_inferior here.
(attach_command): Call it here instead.

gdb/testsuite/
2014-07-09  Pedro Alves  <palves@redhat.com>

* gdb.base/attach-wait-input.exp: New file.
* gdb.base/attach-wait-input.c: New file.

Automatic date update in version.in

Automatic date update in version.in

PR gdb/17096: async support breaks remote debugging on Windows

On Windows, with "maint set target-async on" (the default since
a09dd441), Ctrl-C fails to stop a remote target.

With maint target-async on, the SIGINT signal handler doesn't send the
remote interrupt request immediately.  Instead, it marks an async
handler as ready, and then the main event loop wakes up and notices
that the SIGINT async signal handler token was set, and calls the
corresponding event handler, which sends the remote interrupt request.

On POSIX-like systems, the SIGINT signal makes the select/poll in the
main event loop wake up / return with EINTR.  However, on Windows,
signal handlers run on a separate thread, and Windows doesn't really
have a concept of EINTR.  So, just marking the async handler
(effectively just setting a flag) does not wake up gdb_select.
Instead, we need to call gdb_call_async_signal_handler from the signal
handler.  The Windows version (in mingw-hdep.c) sets a Windows event
that gdb_select's WaitForMultipleObjects is waiting for.

Confirmed that with this, Ctrl-C interrupts the remote target on
Windows.  Also regression tested on x86_64 Fedora 20 against
GDBserver.

gdb/
2014-07-07  Pedro Alves  <palves@redhat.com>

gdb/17096
* remote.c (async_handle_remote_sigint)
(async_handle_remote_sigint_twice): Call
gdb_call_async_signal_handler instead of
mark_async_signal_handler.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

fix memory errors with demangled name hash

This fixes a regression that Jan pointed out.

The bug is that some names were allocated by dwarf2read on the objfile
obstack, but then passed to SYMBOL_SET_NAMES with copy_name=0.  This
violates the invariant that the names must have a lifetime tied to the
lifetime of the BFD.

The fix is to allocate names on the per-BFD obstack.

I looked at all callers, direct or indirect, of SYMBOL_SET_NAMES that
pass copy_name=0.  Note that only the ELF and DWARF readers do this;
other symbol readers were never updated (and perhaps cannot be,
depending on the details of the formats).  This is why the patch is
relatively small.

Built and regtested on x86-64 Fedora 20.

2014-06-26  Tom Tromey  <tromey@redhat.com>

PR symtab/16902:
* dwarf2read.c (fixup_go_packaging, dwarf2_compute_name)
(dwarf2_physname, read_partial_die)
(guess_partial_die_structure_name, fixup_partial_die)
(guess_full_die_structure_name, anonymous_struct_prefix)
(dwarf2_name): Use per-BFD obstack.

Automatic date update in version.in

Automatic date update in version.in

Minor improvements in manual indexing.

* doc/gdb.texinfo (Screen Size): Add more index entries.

(cherry picked from commit f179cf97a071940bfce6879aa59dbac66ffca391)

Fix fallout from 6d00b590

bfd/ChangeLog:

* targets.c (_bfd_target_vector): Add missing #ifdef BFD64 for
a number of targets.

Align behavior of xmethod commands with that of pretty-printer commands.

Currently, the xmethod commands lookup xmethod matchers in the current
progspace even if the locus regular expression matches the progspace's
filename.  Pretty printer commands do not match the current progspace's
filename.

gdb/

* python/lib/gdb/command/xmethods.py
(get_method_matchers_in_loci):  Lookup xmethod matchers in the
current progspace only if the string "progspace" matches LOCUS_RE.

gdb/testsuite

* gdb.python/py-xmethods.exp: Use "progspace" instead of the
progspace's filename in 'info', 'enable' and 'disable' command
tests.

Automatic date update in version.in

x86 Linux watchpoints: Couldn't write debug register: Invalid argument.

This patch fixes this on x86 Linux:

 (gdb) watch *buf@2
 Hardware watchpoint 8: *buf@2
 (gdb) si
 0x00000000004005a7      34        for (i = 0; i < 100000; i++); /* stepi line */
 (gdb) del
 Delete all breakpoints? (y or n) y
 (gdb) watch *(buf+1)@1
 Hardware watchpoint 9: *(buf+1)@1
 (gdb) si
 0x00000000004005a7 in main () at ../../../src/gdb/testsuite/gdb.base/watchpoint-reuse-slot.c:34
 34        for (i = 0; i < 100000; i++); /* stepi line */
 Couldn't write debug register: Invalid argument.
 (gdb)

In the example above the debug registers are being switched from this
state:

        CONTROL (DR7): 0000000000050101          STATUS (DR6): 0000000000000000
        DR0: addr=0x0000000000601040, ref.count=1  DR1: addr=0x0000000000000000, ref.count=0
        DR2: addr=0x0000000000000000, ref.count=0  DR3: addr=0x0000000000000000, ref.count=0

to this:

        CONTROL (DR7): 0000000000010101          STATUS (DR6): 0000000000000000
        DR0: addr=0x0000000000601041, ref.count=1  DR1: addr=0x0000000000000000, ref.count=0
        DR2: addr=0x0000000000000000, ref.count=0  DR3: addr=0x0000000000000000, ref.count=0

That is, before, DR7 was setup for watching a 2 byte region starting
at what's in DR0 (0x601040).

And after, DR7 is setup for watching a 1 byte region starting at
what's in DR0 (0x601041).

We always write DR0..DR3 before DR7, because if we enable a slot's
bits in DR7, you need to have already written the corresponding
DR0..DR3 registers -- the kernel rejects the DR7 write with EINVAL
otherwise.

The error shown above is the opposite scenario.  When we try to write
0x601041 to DR0, DR7's bits still indicate intent of watching a 2-byte
region.  That DR0/DR7 combination is invalid, because 0x601041 is
unaligned.  To watch two bytes, we'd have to use two slots.  So the
kernel errors out with EINVAL.

Fix this by always first clearing DR7, then writing DR0..DR3, and then
setting DR7's bits.

A little optimization -- if we're disabling the last watchpoint, then
we can clear DR7 just once.  The changes to nat/i386-dregs.c make that
easier to detect, and as bonus, they make it a little easier to make
sense of DR7 in the debug logs, as we no longer need to remember we're
seeing stale bits.

Tested on x86_64 Fedora 20, native and GDBserver.

This adds an exhaustive test that switches between many different
combinations of watchpoint types and addresses and widths.

gdb/
2014-06-23  Pedro Alves  <palves@redhat.com>

* amd64-linux-nat.c (amd64_linux_prepare_to_resume): Clear
DR_CONTROL before setting DR0..DR3.
* i386-linux-nat.c (i386_linux_prepare_to_resume): Likewise.
* i386-nat.c (i386_remove_aligned_watchpoint): Clear all bits of
DR_CONTROL related to the debug register slot being disabled.  If
all slots are vacant, clear local slowdown as well, and assert
DR_CONTROL is 0.

gdb/gdbserver/
2014-06-23  Pedro Alves  <palves@redhat.com>

* linux-x86-low.c (x86_linux_prepare_to_resume): Clear DR_CONTROL
before setting DR0..DR3.
* i386-low.c (i386_remove_aligned_watchpoint): Clear all bits of
DR_CONTROL related to the debug register slot being disabled.  If
all slots are vacant, clear local slowdown as well, and assert
DR_CONTROL is 0.

gdb/testsuite/
2014-06-23  Pedro Alves  <palves@redhat.com>

* gdb.base/watchpoint-reuse-slot.c: New file.
* gdb.base/watchpoint-reuse-slot.exp: New file.

testsuite: Use istarget and is_lp64_target for 3 testcases.

On x86_64 with -m32 or on i686 it will:

Running ./gdb.arch/amd64-stap-special-operands.exp ...
gdb compile failed, amd64-stap-triplet.c: Assembler messages:
amd64-stap-triplet.c:35: Error: bad register name `%rbp'
amd64-stap-triplet.c:38: Error: bad register name `%rsp'
amd64-stap-triplet.c:40: Error: bad register name `%rbp)'
amd64-stap-triplet.c:41: Error: bad register name `%rsi'
amd64-stap-triplet.c:42: Error: bad register name `%rbp)'
/tmp/ccjOdmpl.s:63: Error: bad register name `%rbp'

2014-06-23  Jan Kratochvil  <jan.kratochvil@redhat.com>

* gdb.arch/amd64-stap-special-operands.exp: Use is_lp64_target.
* gdb.arch/amd64-stap-optional-prefix.exp: Likewise.
* gdb.dwarf2/dw2-error.exp: Use istarget and is_lp64_target.

Message-ID: <20140622211401.GA3716@host2.jankratochvil.net>

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Fix next over threaded execl with "set scheduler-locking step".

Running gdb.threads/thread-execl.exp with scheduler-locking set to
"step" reveals a problem:

 (gdb) next^M
 [Thread 0x7ffff7fda700 (LWP 27168) exited]^M
 [New LWP 27168]^M
 [Thread 0x7ffff74ee700 (LWP 27174) exited]^M
 process 27168 is executing new program: /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.threads/thread-execl^M
 [Thread debugging using libthread_db enabled]^M
 Using host libthread_db library "/lib64/libthread_db.so.1".^M
 infrun.c:5225: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed.^M
 A problem internal to GDB has been detected,^M
 further debugging may prove unreliable.^M
 Quit this debugging session? (y or n) FAIL: gdb.threads/thread-execl.exp: schedlock step: get to main in new image (GDB internal error)

The assertion is correct.  The issue is that GDB is mistakenly trying
to switch back to an exited thread, that was previously stepping when
it exited.  This is exactly the sort of thing the test wants to make
sure doesn't happen:

# Now set a breakpoint at `main', and step over the execl call.  The
# breakpoint at main should be reached.  GDB should not try to revert
# back to the old thread from the old image and resume stepping it

We don't see this bug with schedlock off only because a different
sequence of events makes GDB manage to delete the thread instead of
marking it exited.

This particular internal error can be fixed by making the loop over
all threads in switch_back_to_stepped_thread skip exited threads.
But, looking over other ALL_THREADS users, all either can or should be
skipping exited threads too.  So for simplicity, this patch replaces
ALL_THREADS with a new macro that skips exited threads itself, and
updates everything to use it.

Tested on x86_64 Fedora 20.

gdb/
2014-06-19  Pedro Alves  <palves@redhat.com>

* gdbthread.h (ALL_THREADS): Delete.
(ALL_NON_EXITED_THREADS): New macro.
* btrace.c (btrace_free_objfile): Use ALL_NON_EXITED_THREADS
instead of ALL_THREADS.
* infrun.c (find_thread_needs_step_over)
(switch_back_to_stepped_thread): Use ALL_NON_EXITED_THREADS
instead of ALL_THREADS.
* record-btrace.c (record_btrace_open)
(record_btrace_stop_recording, record_btrace_close)
(record_btrace_is_replaying, record_btrace_resume)
(record_btrace_find_thread_to_move, record_btrace_wait): Likewise.
* remote.c (append_pending_thread_resumptions): Likewise.
* thread.c (thread_apply_all_command): Likewise.

gdb/testsuite/
2014-06-19  Pedro Alves  <palves@redhat.com>

* gdb.threads/thread-execl.exp (do_test): New procedure, factored
out from ...
(top level): ... here.  Iterate running tests under different
scheduler-locking settings.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

"$ gdb PROGRAM" vs "(gdb) file PROGRAM" difference; warn on failure to remove breakpoint.

Turns out there's a difference between loading the program with "gdb
PROGRAM", vs loading it with "(gdb) file PROGRAM".  The latter results
in the objfile ending up with OBJF_USERLOADED set, while not with the
former.  (That difference seems bogus, but still that's not the point
of this patch.  We can revisit that afterwards.)

The new code that suppresses breakpoint removal errors for
add-symbol-file objects ends up being too greedy:

      /* In some cases, we might not be able to remove a breakpoint in
         a shared library that has already been removed, but we have
         not yet processed the shlib unload event.  Similarly for an
         unloaded add-symbol-file object - the user might not yet have
         had the chance to remove-symbol-file it.  shlib_disabled will
         be set if the library/object has already been removed, but
         the breakpoint hasn't been uninserted yet, e.g., after
         "nosharedlibrary" or "remove-symbol-file" with breakpoints
         always-inserted mode.  */
      if (val
          && (bl->loc_type == bp_loc_software_breakpoint
              && (bl->shlib_disabled
                  || solib_name_from_address (bl->pspace, bl->address)
                  || userloaded_objfile_contains_address_p (bl->pspace,
                                                            bl->address))))
        val = 0;

as it turns out that OBJF_USERLOADED can be set for objfiles loaded by
some other means not add-symbol-file.  In this case, symbol-file (or
"file", which is really just "exec-file"+"symbol-file").

Recall that add-symbol-file is documented as:

 (gdb) help add-symbol-file
 Load symbols from FILE, assuming FILE has been dynamically loaded.
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

And it's the "dynamically loaded" aspect that the breakpoint.c code
cares about.  So make add-symbol-file set OBJF_SHARED on its objfiles
too, and tweak the breakpoint.c code to look for OBJF_SHARED instead
of OBJF_USERLOADED.

This restores back the missing breakpoint removal warning when we let
sss-bp-on-user-bp-2.exp run on native GNU/Linux
(https://sourceware.org/ml/gdb-patches/2014-06/msg00335.html):

 (gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: define stepi_del_break
 stepi_del_break
 warning: Error removing breakpoint 3
 (gdb) FAIL: gdb.base/sss-bp-on-user-bp-2.exp: stepi_del_break

I say "restores" because this was GDB's behavior in 7.7 and earlier.

And, likewise, "file" with no arguments only started turning
breakpoints set in the main executable to "<pending>" with the
remote-symbol-file patch (63644780).  The old behavior is now
restored, and we break-unload-file.exp test now exercizes both "gdb;
file PROGRAM" and "gdb PROGRAM".

gdb/
2014-06-16  Pedro Alves  <palves@redhat.com>

* breakpoint.c (insert_bp_location, remove_breakpoint_1): Adjust.
(disable_breakpoints_in_freed_objfile): Skip objfiles that don't
have OBJF_SHARED set.
* objfiles.c (userloaded_objfile_contains_address_p): Rename to...
(shared_objfile_contains_address_p): ... this.  Check OBJF_SHARED
instead of OBJF_USERLOADED.
* objfiles.h (OBJF_SHARED): Update comment.
(userloaded_objfile_contains_address_p): Rename to ...
(shared_objfile_contains_address_p): ... this, and update
comments.
* symfile.c (add_symbol_file_command): Also set OBJF_SHARED in the
new objfile.
(remove_symbol_file_command): Skip objfiles that don't have
OBJF_SHARED set.

gdb/testsuite/
2014-06-16  Pedro Alves  <palves@redhat.com>

* gdb.base/break-main-file-remove-fail.c: New file.
* gdb.base/break-main-file-remove-fail.exp: New file.
* gdb.base/break-unload-file.exp: Use build_executable instead of
prepare_for_testing.
(test_break): New parameter "initial_load".  Handle it.
(top level): Add initial_load cmdline/file axis.

Automatic date update in version.in

Automatic date update in version.in

Include --with-guile in 'show configuration's output.

* top.c (print_gdb_configuration) [HAVE_GUILE]: Print --with-guile
or --without-guile, according to how GDB was built.

(cherry picked from commit 97d66cc602ec5abfcb6fc6baaf3d6edbde4fcbfb)

Automatic date update in version.in

Automatic date update in version.in

Move ChangeLog entry to proper place.

gdb/
2014-06-09  Pedro Alves  <palves@redhat.com>

* linux-nat.c (linux_child_follow_fork): Initialize status with
W_STOPCODE (0) instead of 0.  Remove shodowing 'status' local from
inner block.  Only pass the signal to PTRACE_DETACH if in pass
state.

Automatic date update in version.in

Bump GDB version number to 7.7.90.DATE-cvs.

gdb/ChangeLog:

* version.in: Set GDB version number to 7.7.90.DATE-cvs.

Document the GDB 7.7.90 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 7.7.90 released.

Set GDB version number to 7.7.90.

gdb/ChangeLog:

* version.in: Set GDB version number to 7.7.90.

Set development mode to "off" by default.

bfd/ChangeLog:

* development.sh (development): Set to false.

Bump version to 7.7.90.DATE-cvs.

Now that the GDB 7.8 branch has been created, we can
bump the version number.

gdb/ChangeLog:

GDB 7.8 branch created (173373c6f6388171d1d62a217fae90a052395be2):
* version.in: Bump version to 7.7.90.DATE-cvs.