Fix skipping stack protector on arm

This patch fixes the bug in my patch skipping stack protector
https://www.sourceware.org/ml/gdb-patches/2010-12/msg00110.html

In my skipping stack protector patch, I misunderstood the constant vs.
immediate on instruction encodings, and treated immediate as constant
by mistake.  The instruction 'ldr Rd, [PC, #immed]' loads the
address of __stack_chk_guard to Rd, and #immed is an offset from PC.
We should get the __stack_chk_guard from *(pc + #immed).

As a result of this mistake, arm_analyze_load_stack_chk_guard returns
the wrong address of __stack_chk_guard, and the symbol
__stack_chk_guard can't be found.  However, we continue to match the
following instructions when symbol isn't found, so the code still
works.  In other words, the code just matches the instruction pattern
without checking __stack_chk_guard symbol correctly.

Joel's patch <https://sourceware.org/ml/gdb-patches/2014-10/msg00605.html>
makes the heuristics stricter that we stop matching instructions if
symbol __stack_chk_guard isn't found.  Then the bug is exposed.  This
patch is to correct the load address computation for ldr instruction,
and it fixes some fails in gdb.mi/gdb792.exp on armv4t both arm and
thumb mode.

Regression tested on arm-linux-gnueabi target with
{armv4t, armv7-a} x {marm, mthumb} x {-fstack-protector,-fno-stack-protector}

gdb:

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

	* arm-tdep.c (arm_analyze_load_stack_chk_guard): Compute the
	loaded address correctly of ldr instruction.
ARM: stricter __stack_chk_guard check during prologue analysis

We are trying to insert a breakpoint on line 4 for the following
Ada code.

  3 procedure STR is
  4    XX : String (1 .. Blocks.Sz) := (others => 'X'); -- STOP
  5    K : Integer;
  6 begin
  7    K := 13;

The code generated on ARM (-march=armv7-m) starts like this:

    (gdb) disass str'address
    Dump of assembler code for function _ada_str:
       --# Line str.adb:3
       0x08000014 <+0>:     push    {r4, r7, lr}
       0x08000016 <+2>:     sub     sp, #28
       0x08000018 <+4>:     add     r7, sp, #0
       0x0800001a <+6>:     mov     r3, sp
       0x0800001c <+8>:     mov     r4, r3
       --# Line str.adb:4
       0x0800001e <+10>:    ldr     r3, [pc, #84]   ; (0x8000074 <_ada_str+96>)
       0x08000020 <+12>:    ldr     r3, [r3, #0]
       0x08000022 <+14>:    str     r3, [r7, #20]
       0x08000024 <+16>:    ldr     r3, [r7, #20]
       [...]

When computing the address related to str.adb:4, GDB correctly
resolves it to 0x0800001e first, but then considers the next
3 instructions as being part of the prologue because it thinks
they are part of stack-protector code. As a result, instead
of inserting the breakpoint at line 4, it skips those instruction
and consequently the rest of the instructions until the start
of the next line, which his line 7.

The stack-protector code is expected to start like this...

        ldr     Rn, .Label
        ....
        .Lable:
        .word   __stack_chk_guard

... but the implementation actually accepts a sequence where
the ldr location points to an address for which there is no symbol.
It only aborts if the address points to a symbol which is not
__stack_chk_guard.

Since the __stack_chk_guard symbol is always expected to exist
when used (it lives in .dynsym), this patch fixes the issue by
requiring that the ldr gets the address of the __stack_chk_guard
symbol. If the address could not be resolved, then it rejects
the sequence as being stack-protector code.

gdb/ChangeLog:

        * arm-tdep.c (arm_skip_stack_protector): Return early if
        address loaded by first "ldr" instruction does not have
        a corresponding minimal symbol.  Update comment.

Tested on arm-eabi using AdaCore's testsuite.
Tested on arm-linux-gnueabi by Yao as well.
Close the file in fileio.exp test

I see the following fail in fileio.exp on mingw32 host gdb,

rename 1: ret = -1, errno = 13^M
^M
Breakpoint 2, stop () at fileio.c:76^M
76      static void stop () {}^M
(gdb) FAIL: gdb.base/fileio.exp: Rename a file

the test fails to rename a file which is not expected.  The previous
test test_write doesn't close the file, so the rename fails as a
result on Windows.  This patch fixes it by closing file in test_write,
and the fail goes away.

rename 1: ret = 0, errno = 0 OK^M
^M
Breakpoint 2, stop () at fileio.c:76^M
76      static void stop () {}^M
(gdb) PASS: gdb.base/fileio.exp: Rename a file

gdb/testsuite:

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

	* gdb.base/fileio.c (test_write): Close the file.
Prepare directory in case test_system fails

In gdb.base/fileio.c, some functions may depend on others.  For
example, test_rename renames a file to one directory which is created
in test_system.  That is means, if test_system fails, test_rename
fails too, which is not a good practise, IMO.

In test_system, system ("mkdir -p XX") is used to create directories
needed for test_rename.  In this patch, we use dejagnu remote_exec
proc to create these directories on host.

In my gdb testing, mingw32 host and arm-none-eabi target, system
("mkdir -p XX") doesn't work properly (this issue can be addressed
separately), and this patch fixes the following fails.

FAIL: gdb.base/fileio.exp: Renaming a directory to a non-empty directory returns ENOTEMPTY or EEXIST
FAIL: gdb.base/fileio.exp: Unlink a file
FAIL: gdb.base/fileio.exp: Unlinking a file in a directory w/o write access returns EACCES

gdb/testsuite:

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

	* gdb.base/fileio.exp: Make directories on host.
PR tui/16138, PR tui/17519, and misc failures to initialize the terminal

PR tui/16138 is about failure to initialize curses resulting in GDB
exiting instead of throwing an error.  E.g.:

 $ TERM=foo gdb
 (gdb) layout asm
 Error opening terminal: foo.
 $

The problem is that we're calling initscr to initialize the screen.
As mentioned in
http://pubs.opengroup.org/onlinepubs/7908799/xcurses/initscr.html:

 If errors occur, initscr() writes an appropriate error message to
 standard error and exits.
                    ^^^^^

Instead, we should use newterm:

 "A program that needs an indication of error conditions, so it can
 continue to run in a line-oriented mode if the terminal cannot support
 a screen-oriented program, would also use this function."

After the patch:

 $ TERM=foo gdb -q -nx
 (gdb) layout asm
 Cannot enable the TUI: error opening terminal [TERM=foo]
 (gdb)

And then PR tui/17519 is about GDB not validating whether the terminal
has the necessary capabilities when enabling the TUI.  If one tries to
enable the TUI with TERM=dumb (and e.g., from a shell within emacs),
GDB ends up with a clear screen, the cursor is placed at the
bottom/right corner of the screen, there's no prompt, typing shows no
echo, and there's no indication of what's going on.  c-x,a gets you
out of the TUI, but it's completely non-obvious.

After the patch, we get:

 $ TERM=dumb gdb -q -nx
 (gdb) layout asm
 Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
 (gdb)

While at it, I've moved all the tui_allowed_p validation to
tui_enable, and expanded the error messages.  Previously we'd get:

 $ gdb -q -nx -i=mi
 (gdb)
 layout asm
 &"layout asm\n"
 &"TUI mode not allowed\n"
 ^error,msg="TUI mode not allowed"

and:

 $ gdb -q -nx -ex "layout asm" > foo
 TUI mode not allowed

While now we get:

 $ gdb -q -nx -i=mi
 (gdb)
 layout asm
 &"layout asm\n"
 &"Cannot enable the TUI when the interpreter is 'mi'\n"
 ^error,msg="Cannot enable the TUI when the interpreter is 'mi'"
 (gdb)

and:

 $ gdb -q -nx -ex "layout asm" > foo
 Cannot enable the TUI when output is not a terminal

Tested on x86_64 Fedora 20.

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

	PR tui/16138
	PR tui/17519
	* tui/tui-interp.c (tui_is_toplevel): Delete global.
	(tui_allowed_p): Delete function.
	* tui/tui.c: Include "interps.h".
	(tui_enable): Don't use tui_allowed_p.  Error out here with
	detailed error messages if the TUI is the top level interpreter,
	or if output is not a terminal.  Use newterm instead of initscr,
	and error out if initializing the terminal fails.  Also error out if
	the terminal doesn't support cursor addressing.
	* tui/tui.h (tui_allowed_p): Delete declaration.
TUI: don't let exceptions escape while handling readline key bindings

I noticed that with:

 $ TERM=dumb ./gdb -q -nx
 <c-x,a>
 Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
 (gdb)

The next key the user types is silently eaten.

The problem is that we're throwing an exception while in a readline
callback that isn't prepared for that:

(top-gdb) bt
#0  tui_enable () at /home/pedro/gdb/mygit/build/../src/gdb/tui/tui.c:388
#1  0x000000000051f47b in tui_rl_switch_mode (notused1=1, notused2=1) at /home/pedro/gdb/mygit/build/../src/gdb/tui/tui.c:101
#2  0x0000000000768d6f in _rl_dispatch_subseq (key=1, map=0xd069c0 <emacs_ctlx_keymap>, got_subseq=0) at /home/pedro/gdb/mygit/build/../src/readline/readline.c:774
#3  0x0000000000768acb in _rl_dispatch_callback (cxt=0x1ce6190) at /home/pedro/gdb/mygit/build/../src/readline/readline.c:686
#4  0x000000000078120b in rl_callback_read_char () at /home/pedro/gdb/mygit/build/../src/readline/callback.c:170
#5  0x0000000000619445 in rl_callback_read_char_wrapper (client_data=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/event-top.c:166
#6  0x000000000061981b in stdin_event_handler (error=0, client_data=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/event-top.c:372
#7  0x000000000061840e in handle_file_event (data=...) at /home/pedro/gdb/mygit/build/../src/gdb/event-loop.c:762
#8  0x00000000006178f5 in process_event () at /home/pedro/gdb/mygit/build/../src/gdb/event-loop.c:339
#9  0x00000000006179bc in gdb_do_one_event () at /home/pedro/gdb/mygit/build/../src/gdb/event-loop.c:403
#10 0x0000000000617a0c in start_event_loop () at /home/pedro/gdb/mygit/build/../src/gdb/event-loop.c:428

Here, in _rl_dispatch_subseq:

769
770               rl_executing_keymap = map;
771
772               rl_dispatching = 1;
773               RL_SETSTATE(RL_STATE_DISPATCHING);
774               (*map[key].function)(rl_numeric_arg * rl_arg_sign, key);
775               RL_UNSETSTATE(RL_STATE_DISPATCHING);
776               rl_dispatching = 0;
777
778               /* If we have input pending, then the last command was a prefix
779                  command.  Don't change the state of rl_last_func.  Otherwise,

GDB is called from line 774, but longjmp'ing at that point leaves
rl_dispatching and RL_STATE_DISPATCHING set.

Fix this by wrapping tui_rl_switch_mode in a TRY_CATCH.

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

	* tui/tui.c (tui_rl_switch_mode): Wrap tui_enable/tui_disable in
	TRY_CATCH.
PR tui/16138 is about failure to initialize curses resulting in GDB
exiting instead of throwing an error.  E.g.:

 $ TERM=foo gdb
 (gdb) layout asm
 Error opening terminal: foo.
 $

The problem is that we're calling initscr to initialize the screen.
As mentioned in
http://pubs.opengroup.org/onlinepubs/7908799/xcurses/initscr.html:

 If errors occur, initscr() writes an appropriate error message to
 standard error and exits.
                    ^^^^^

Instead, we should use newterm:

 "A program that needs an indication of error conditions, so it can
 continue to run in a line-oriented mode if the terminal cannot support
 a screen-oriented program, would also use this function."

After the patch:

 $ TERM=foo gdb -q -nx
 (gdb) layout asm
 Cannot enable the TUI: error opening terminal [TERM=foo]
 (gdb)

And then PR tui/17519 is about GDB not validating whether the terminal
has the necessary capabilities when enabling the TUI.  If one tries to
enable the TUI with TERM=dumb (and e.g., from a shell within emacs),
GDB ends up with a clear screen, the cursor is placed at the
bottom/right corner of the screen, there's no prompt, typing shows no
echo, and there's no indication of what's going on.  c-x,a gets you
out of the TUI, but it's completely non-obvious.

After the patch, we get:

 $ TERM=dumb gdb -q -nx
 (gdb) layout asm
 Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
 (gdb)

While at it, I've moved all the tui_allowed_p validation to
tui_enable, and expanded the error messages.  Previously we'd get:

 $ gdb -q -nx -i=mi
 (gdb)
 layout asm
 &"layout asm\n"
 &"TUI mode not allowed\n"
 ^error,msg="TUI mode not allowed"

and:

 $ gdb -q -nx -ex "layout asm" > foo
 TUI mode not allowed

While now we get:

 $ gdb -q -nx -i=mi
 (gdb)
 layout asm
 &"layout asm\n"
 &"Cannot enable the TUI when the interpreter is 'mi'\n"
 ^error,msg="Cannot enable the TUI when the interpreter is 'mi'"
 (gdb)

and:

 $ gdb -q -nx -ex "layout asm" > foo
 Cannot enable the TUI when output is not a terminal

Tested on x86_64 Fedora 20.

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

	PR tui/16138
	PR tui/17519
	* tui/tui-interp.c (tui_is_toplevel): Delete global.
	(tui_allowed_p): Delete function.
	* tui/tui.c: Include "interps.h".
	(tui_enable): Don't use tui_allowed_p.  Error out here with
	detailed error messages if the TUI is the top level interpreter,
	or if output is not a terminal.  Use newterm instead of initscr,
	and error out if initializing the terminal fails.  Also error out if
	the terminal doesn't support cursor addressing.
	* tui/tui.h (tui_allowed_p): Delete declaration.
Fix uninitialized value access when very first GDB command entered is <RET>

While running GDB under Valgrind, I noticed that if the very first
command entered is just <RET>, GDB accesses an uninitialized value:

 $ valgrind ./gdb -q -nx
 ==26790== Memcheck, a memory error detector
 ==26790== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
 ==26790== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
 ==26790== Command: ./gdb -q -nx
 ==26790==

 (gdb)
 ==26790== Conditional jump or move depends on uninitialised value(s)
 ==26790==    at 0x619DFC: command_line_handler (event-top.c:588)
 ==26790==    by 0x7813D5: rl_callback_read_char (callback.c:220)
 ==26790==    by 0x6194B4: rl_callback_read_char_wrapper (event-top.c:166)
 ==26790==    by 0x61988A: stdin_event_handler (event-top.c:372)
 ==26790==    by 0x61847D: handle_file_event (event-loop.c:762)
 ==26790==    by 0x617964: process_event (event-loop.c:339)
 ==26790==    by 0x617A2B: gdb_do_one_event (event-loop.c:403)
 ==26790==    by 0x617A7B: start_event_loop (event-loop.c:428)
 ==26790==    by 0x6194E6: cli_command_loop (event-top.c:181)
 ==26790==    by 0x60F86B: current_interp_command_loop (interps.c:317)
 ==26790==    by 0x610A34: captured_command_loop (main.c:321)
 ==26790==    by 0x60C728: catch_errors (exceptions.c:237)
 ==26790==
 (gdb)

It's this check here:

  /* If we just got an empty line, and that is supposed to repeat the
     previous command, return the value in the global buffer.  */
  if (repeat && p == linebuffer && *p != '\\')
    {

The problem is that linebuffer's contents were never initialized at
this point.

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

	* event-top.c (command_line_handler): Clear the first byte of
	linebuffer, when it is first allocated.
Updated/new translations provided by the Translations Project.
Thix fixes an obvious coding error that led to a GDB crash on AIX or HPUX.

	* elf.c (elfcore_write_lwpstatus): fix typo in call to memcpy
PR python/17372 - Python hangs when displaying help()

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 0017922d0292d8c374584f6100874580659c9973
 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.
PR 17408 - assertion failure in switch_back_to_stepped_thread

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.
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.
Misc about gold for aarch64 backend.

The patch does the following things:
  -- Add support for ifunc.
  -- Enable safe icf
  -- Add support for TLSLD relocations
     R_AARCH64_TLSLD_ADR_PAGE21,
     R_AARCH64_TLSLD_ADD_LO12_NC,
     R_AARCH64_TLSLD_MOVW_DTPREL_G1,
     R_AARCH64_TLSLD_MOVW_DTPREL_G0_NC.
     (R_AARCH64_TLSLD_MOVW_* are used by LLVM.)
  -- Add support for TLSLD->TLSLE relaxation.
  -- Add support for R_AARCH64_LD_PREL_LO19, R_AARCH64_ADR_PREL_LO21.
  -- Fix 2 encoding bugs in AArch64_relocate_functions::update_movnz.
  -- Correct TLS relocation properties in gold/aarch64-reloc.def.
  -- Update testsuite/icf_safe_so_test.cc, testsuite/icf_safe_test.sh.

gold/
2014-10-29  Han Shen  <shenhan@google.com>
            Jing Yu   <jingyu@google.com>

	* aarch64-reloc.def: Add LD_PREL_LO12, ADR_PREL_LO21,
	TLSLD_ADR_PAGE21, TLSLD_ADD_LO12_NC, TLSLD_MOVW_DTPREL_G1,
	TLSLD_MOVW_DTPREL_G0_NC. Change property of TLS relocations to
	Symbol::TLS_REF.
	* aarch64.cc (Target_aarch64::do_can_check_for_function_pointers): New
	method.
	(Target_aarch64::reloc_needs_plt_for_ifunc): New method.
	(Target_aarch64::tls_ld_to_le): New method.
	(Target_aarch64::aarch64_info): Enable can_icf_inline_merge_sections
	for 64bit targets.
	(Output_data_plt_aarch64::irelative_rel_): New data member.
	(Output_data_plt_aarch64::add_entry): Add irelative entries to plt.
	(Output_data_plt_aarch64::add_local_ifunc_entry): New method.
	(Output_data_plt_aarch64::add_relocation): New method.
	(Output_data_plt_aarch64::do_write): Add gold_assert on got_irelative
	offset. Add got_irelative size to got size.
	(AArch64_relocate_functions): Typedef AArch64_valtype. Replace long
	type string with the new typename.
	(AArch64_relocate_functions::update_adr): Replace parameter x with
	immed.
	(AArch64_relocate_functions::update_movnz): Correct wrong val mask.
	(AArch64_relocate_functions::reloc_common): New method.
	(AArch64_relocate_funcsions::rela_general): Extract common part out
	into reloc_common method.
	(AArch64_relocate_functions::rela_general): Likewise.
	(AArch64_relocate_functions::pcrela_general): Likewise.
	(AArch64_relocate_functions::adr): New method.
	(AArch64_relocate_functions::adrp): Calculate immed before calling
	update_adr.
	(AArch64_relocate_functions::adrp): Likewise.
	(AArch64_relocate_functions::movnz): Cast x to SignedW type when
	comparing x to 0. Calculate immed from ~x when x < 0.
	(Target_aarch64::optimize_tls_reloc): Add new cases for
	TLSLD_ADR_PAGE21, TLSLD_ADD_LO12_NC, TLSLD_MOVW_DTPREL_G1,
	TLSLD_MOVW_DTPREL_G0_NC.
	(Target_aarch64::possible_function_pointer_reloc): Implement this
	method.
	(Target_aarch64::Scan::local_reloc_may_be_function_pointer): Update
	comment.
	(Target_aarch64::Scan::local): Add codes to handle STT_GNU_IFUNC
	symbol. Add cases for TLSLD_ADR_PAGE21, TLSLD_ADD_LO12_NC,
	TLSLD_MOVW_DTPREL_G1, TLSLD_MOVW_DTPREL_G0_NC.
	(Target_aarch64::Scan::global): Add codes to handle STT_GNU_IFUNC
	symbol. Add cases for TLSLD_ADR_PAGE21, TLSLD_ADD_LO12_NC,
	TLSLD_MOVW_DTPREL_G1, TLSLD_MOVW_DTPREL_G0_NC.
	(Target_aarch64::make_plt_entry): Call add_entry with two more
	parameters.
	(Target_aarch64::make_local_ifunc_plt_entry): New method.
	(Target_aarch64::Relocate::relocate): Add cases for LD_PREL_LO19,
	ADR_PREL_LO21, TLSLD_ADR_PAGE21, TLSLD_ADD_LO12_NC,
	TLSLD_MOVW_DTPREL_G1, TLSLD_MOVW_DTPREL_G0_NC.
	(Target_aarch64::Relocate::relocate_tls): Add cases for
	TLSLD_ADR_PAGE21, TLSLD_ADD_LO12_NC, TLSLD_MOVW_DTPREL_G1,
	TLSLD_MOVW_DTPREL_G0_NC.
	* testsuite/icf_safe_so_test.cc: Correct test comment.
	* testsuite/icf_safe_test.sh: Add AArch64 arch.
Document the GDB 7.8.1 release in gdb/ChangeLog

gdb/ChangeLog:

	GDB 7.8.1 released.
Fixes another memory corruption bug introduced by patches for PR 17512.

	* elf.c (bfd_section_from_shdr): Fix heap use after free memory
	leak.
daily update
Don't replace '\' with '\\' in before_prompt_hook

In gdb/command/prompt.py:before_prompt_hook, the '\' in the new prompt
is replaced with '\\', shown as below,

>     def before_prompt_hook(self, current):
>         if self.value is not '':
>             newprompt = gdb.prompt.substitute_prompt(self.value)
>             return newprompt.replace('\\', '\\\\')
>         else:
>             return None

I don't see any explanations on this in comments nor email.  As doc
said, "set extended-prompt \w" substitute the current working
directory, but it prints something different from what pwd or
os.getcwdu() prints on mingw32 host.

(gdb) python print os.getcwdu()^M
\\build2-lucid-cs\yqi\yqi\arm-none-eabi

(gdb) pwd^M
Working directory \\build2-lucid-cs\yqi\yqi\arm-none-eabi

(gdb) set extended-prompt \w
\\\\build2-lucid-cs\\yqi\\yqi\\arm-none-eabi

This makes me think whether the substitution in before_prompt_hook is
necessary or not.  This patch is to remove this substitution.

Run gdb.python on x86_64-linux and arm-none-eabi on mingw32 host.  No
regressions.

gdb:

2014-10-30  Yao Qi  <yao@codesourcery.com>

	* python/lib/gdb/command/prompt.py (before_prompt_hook): Don't
	replace '\\' with '\\\\'.