Restrict matching add/sub sp, #imm

Currently, GDB matches both add/sub sp, #imm in prologue and epilogue,
which is not very precise.  On the instruction level, the immediate
number in both instruction can't be negative, so 'sub sp, #imm' only
appears in prologue while 'add sp, #imm' only appears in epilogue.
Note that on assembly level, we can write 'add sp, -8', but gas will
translate to 'sub sp, 8' instruction.

This patch is to only match 'sub sp, #imm' in prologue and match
'add sp, #immm' in epilogue.  It paves the way for the following
patch.

gdb:

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

	* arm-tdep.c (thumb_analyze_prologue): Don't match instruction
	'add sp, #imm'.
	(thumb_in_function_epilogue_p): Don't match 'sub sp, #imm'.
Match instruction adjusts SP in thumb

This is a refactor patch, that moves matching instructions adjusting
SP into a new function, thumb_instruction_restores_sp.  The second
call to thumb_instruction_restores_sp in thumb_in_function_epilogue_p
is a little different from the original.  The original code matches
'POP <registers> without PC', but thumb_in_function_epilogue_p matches
'POP <registers> (with and without PC)'.  However, GDB found one
instruction about return and is scanning the previous instruction,
which should be an instruction about return too, so the code change
doesn't affect the functionality.

gdb:

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

	* arm-tdep.c (thumb_instruction_restores_sp): New function.
	(thumb_in_function_epilogue_p): Call
	thumb_instruction_restores_sp.
Stop prologue analysis when past the epilogue

We see a fail in gdb.trace/entry-values.exp on armv4t thumb,

bt^M
 #0  0x000086fc in foo (i=0, i@entry=<optimized out>, j=2, j@entry=<optimized out>)^M
 #1  0x00000002 in ?? ()^M
Backtrace stopped: previous frame identical to this frame (corrupt stack?)^M
(gdb) FAIL: gdb.trace/entry-values.exp: bt (1) (pattern 1)

The fail is caused by incorrect prologue analysis, which can be illustrated by
setting a breakpoint on function foo,

(gdb) disassemble foo
Dump of assembler code for function foo:
   0x000086e8 <+0>:	push	{r7, lr}
   0x000086ea <+2>:	sub	sp, #8
   0x000086ec <+4>:	add	r7, sp, #0
   0x000086ee <+6>:	str	r0, [r7, #4]
   0x000086f0 <+8>:	str	r1, [r7, #0]
   0x000086f2 <+10>:	movs	r3, #0
   0x000086f4 <+12>:	adds	r0, r3, #0
   0x000086f6 <+14>:	mov	sp, r7
   0x000086f8 <+16>:	add	sp, #8
   0x000086fa <+18>:	pop	{r7}
   0x000086fc <+20>:	pop	{r1}
   0x000086fe <+22>:	bx	r1
End of assembler dump.
(gdb) b foo
Breakpoint 1 at 0x86fc

As we can see, GDB analyzes the prologue and skip the prologue to the last
instruction but one.  The breakpoint is set within the epilogue, and GDB
skips too many instruction for prologue.  This patch teaches GDB to stop
prologue analysis when goes into the epilogue.  With this patch applied,
GDB is able to unwind correctly,

(gdb) bt
 #0  0x000086f6 in foo (i=0, i@entry=2, j=2, j@entry=3)
 #1  0x00008718 in bar (i=<optimized out>)
 #2  0x00008758 in main ()

gdb:

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

	* arm-tdep.c (thumb_analyze_prologue): Break the loop if
	thumb_instruction_restores_sp return true.
Fix typo in _bfd_elf_strtab_add

	PR 17141
	* elf.c (_bfd_elf_strtab_add): Check strtab name for failure.
Fix false argv0-symlink.exp FAIL running under a very long directory name

Starting program: /home/jkratoch/redhat/gdb-test-fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff/gdb/testsuite/gdb.base/argv0-symlink-filelink ^M
[...]
(gdb) print argv[0]^M
$1 = 0x7fffffffda39 "/home/jkratoch/redhat/gdb-test-", 'f' <repeats 169 times>...^M
(gdb) FAIL: gdb.base/argv0-symlink.exp: kept file symbolic link name

after "set print repeats 10000":

print argv[0]^M
$1 = 0x7fffffffda39 "/home/jkratoch/redhat/gdb-test-fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"...^M
(gdb) FAIL: gdb.base/argv0-symlink.exp: kept file symbolic link name

after "set print elements 10000":

print argv[0]^M
$1 = 0x7fffffffda39 "/home/jkratoch/redhat/gdb-test-fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff/gdb/testsuite/gdb.base/argv0-symlink-filelink"^M
(gdb) PASS: gdb.base/argv0-symlink.exp: kept file symbolic link name

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

	Fix false FAIL running under a very long directory name.
	* gdb.base/argv0-symlink.exp: Add "set print repeats 10000"
	and "set print elements 10000".  Twice.
daily update
gdb/testsuite: Add a way to send multiple init commands

Right now we provide a board info entry, `gdb_init_command', that allows
one to send a single command to GDB before the program to be debugged is
started.  This is useful e.g. for slow remote targets to change the
default "remotetimeout" setting.  Occasionally I found a need to send
multiple commands instead, however this cannot be achieved with
`gdb_init_command'.

This change therefore extends the mechanism by adding a TCL list of GDB
commands to send, via a board info entry called `gdb_init_commands'.
There is no limit as to the number of commands put there.  The old
`gdb_init_command' mechanism remains supported for compatibility with
existing people's environments.

	* lib/gdb-utils.exp: New file.
	* lib/gdb.exp (gdb_run_cmd): Call gdb_init_commands, replacing
	inline `gdb_init_command' processing.
	(gdb_start_cmd): Likewise.
	* lib/mi-support.exp (mi_run_cmd): Likewise.
	* README: Document `gdb_init_command' and `gdb_init_commands'.
Don't force "set" symbols local for PE

gas/
	* read.c (assign_symbol): Don't force "set" symbols local for PE.
gas/testsuite/
	* gas/pe/set.s, * gas/pe/set.d: New test.
	* gas/pe/pe.exp: Run it.
daily update
daily update
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.
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.
Garbage collect value_contents_equal.

Hasn't been used in years.

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

	* value.c (value_contents_equal): Delete function.
	* value.h (value_contents_equal): Delete declaration.
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.
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.
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.
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.
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.
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.
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.