Unwrap symbols for debug information

Fixes issues with dwz multi-file (-m) and ld's -wrap option.
Symbols referenced from DWARF debug info in a separate file, eg. to
specify low and high pc, must use the real symbol.  The DWARF info
is specifying attributes of the real function, not one interposed
with --wrap.

include/
	* bfdlink.h (unwrap_hash_lookup): Declare.
bfd/
	* linker.c (unwrap_hash_lookup): New function.
	* elf-bfd (RELOC_FOR_GLOBAL_SYMBOL): Call unwrap_hash_lookup.
	* elf32-i370.c (i370_elf_relocate_section): Likewise.
	* elf32-m32c.c (m32c_elf_relocate_section): Likewise.
	* elf32-m32r.c (m32r_elf_relocate_section): Likewise.
	* elf32-score.c (s3_bfd_score_elf_relocate_section): Likewise.
	* elf32-score7.c (s7_bfd_score_elf_relocate_section): Likewise.
	* elf32-spu.c (spu_elf_relocate_section): Likewise.
	* elf64-hppa.c (elf64_hppa_relocate_section): Likewise.
missing changelog entries for 8a5da09b9
add pr number to changelog
Only print prefixes before fwait

gas/testsuite/

	* gas/i386/prefix.s: Add another fwait test.
	* gas/i386/prefix.d: Updated.

opcodes/

	* i386-dis.c (fwait_prefix): New.
	(ckprefix): Set fwait_prefix.
	(print_insn): Properly print prefixes before fwait.
Wrap PyObject_Get/HasAttrString in a function with second arg having const qualifier.

This is done to avoid errors when compiled with -Werror against Python-2.4
which did not have the const qualifier for the second argument of these
functions.

gdb/
	* python/python-internal.h (gdb_PyObject_GetAttrString)
	(gdb_PyObject_HasAttrString): New inline function definitions.
	* py-value.c (get_field_flag): Remove the now unnecessary cast to
	char * of the second argument to PyObject_GetAttrString.
daily update
	* libcoff-in.h (coff_tdata): Make relocbase member unsigned.
	* libcoff.h: Regenerated.
	* libcoff-in.h (coff_tdata): Make relocbase member unsigned.
	* libcoff.h: Regenerated.
Fix silly thinko

	* linker.c (unwrap_hash_lookup): Add missing parens.
PR remote/17028: GDB+GDBserver hangs on Windows

Since target-async was turned on by default, debugging on Windows
using GDB+GDBserver sometimes hangs while waiting for a RSP reply.

The problem is a race in the gdb_select machinery.

This is what we see for a faulty next on the GDB side:

    (gdb) n
    infrun: clear_proceed_status_thread (Thread 4424)
    infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
    (...)
    infrun: resume (step=1, signal=GDB_SIGNAL_0), ...
    Sending packet: $vCont;s:1148;c#5e...
    *hang*

At this point, attaching a debugger to the hanging GDB confirms that
it is blocked, waiting for a socket event:

    #6  0x757841d8 in WaitForMultipleObjects ()
       from C:\Windows\syswow64\kernel32.dll
    #7  0x004708e7 in gdb_select (n=469, readfds=0x88ca50 <gdb_notifier+784>,
        writefds=0x88cb54 <gdb_notifier+1044>,
        exceptfds=0x88cc58 <gdb_notifier+1304>, timeout=0x0)
        at /[...]/gdb/mingw-hdep.c:172
    #8  0x00527926 in gdb_wait_for_event (block=1)
        at /[...]/gdb/event-loop.c:831
    #9  0x00526ff1 in gdb_do_one_event ()
        at /[...]/gdb/event-loop.c:403

However, on the GDBserver side, we see that GDBserver already sent a
T05 packet reply:

    gdbserver: kernel event EXCEPTION_DEBUG_EVENT for pid=4968 tid=1148
    EXCEPTION_SINGLE_STEP
    Child Stopped with signal = 5
    Writing resume reply for LWP 4968.4424:1
    DEBUG: write_prim ($T0505:c8fe2800;04:a0fe2800;08:38164000;thread:1148;#f0)
           -> 55

To recap, on Windows, 'select' only works with sockets, so we have a
wrapper, gdb_select, that uses the GDB serial abstraction to handle
sockets, consoles, pipes, and serial ports.  Each serial descriptor
has a thread associated (we call those the select threads), and those
threads communicate with the main thread by means of standard Windows
events.

It basically goes like this: gdb_select first loops through all fds of
interest, calling their wait_handle hooks, which returns an event that
WaitForMultipleObjects can wait on.  gdb_select then blocks in
WaitForMultipleObjects with all those event handles.  The wait_handle
hook is responsible for arranging for the returned event to become set
once data is available.  This is done by setting the descriptor's
helper thread running, which itself knows how to wait for data from
the type of handle it manages (sockets, pipes, consoles, files, etc.).
Once data arrives, the select thread sets the corresponding event
which unblocks WaitForMultipleObjects within gdb_select.  However, the
wait_handle hook can also apply an optimization: if data is already
pending, then there's no need to set the thread running, and the
descriptors event can be set immediately.  It's around this latter
aspect that lies the bug/race.

Adding some ad hoc debug logs to ser-mingw.c and mingw-hdep.c, we see
the following sequence of events, right after sending
"$vCont;s:1148;c#5e".  Thread 1 is the main thread, and thread 2 is
the socket's helper/select thread.  gdb_select was only passed one
descriptor to wait on, the remote target's socket.
net_windows_select_thread is the entry point of the select threads for
sockets.

 #1 - thread 1: gdb_select: enter
 #2 - thread 2: net_windows_select_thread: WaitForMultipleObjects blocking

gdb_select walked over the wait_handle hooks, and woke up the socket's
helper thread.  The helper thread is now blocked waiting for socket
events.

 #3 - thread 1: gdb_select: WaitForMultipleObjects polling (timeout=0ms)
 #4 - thread 1: gdb_select: WaitForMultipleObjects returned 102 (WAIT_TIMEOUT)

There was no pending data available yet, and gdb_select was passed
timeout==0ms, and so WaitForMultipleObjects times out immediately.

 #5 - thread 2: net_windows_select_thread: WaitForMultipleObjects returned 1

Just afterwards, socket data arrives, and thread 2 wakes up.  Thread 2
calls WSAEnumNetworkEvents, which clears state->sock_event, and marks
the serial's read_event event, telling the main thread that data is
available.

 #6 - thread 1: gdb_select: call serial_done_wait_handle on each serial

gdb_select stops all the helper/select threads.

 #7 - thread 1: gdb_select: return 0 (WAIT_TIMEOUT)

gdb_select in the main thread returns to the caller.

Note that at this point, data is pending on the socket, the serial's
read_event is set, but the socket's sock_event event is not set, until
_further_ data arrives.

Now GDB does its thing and goes back to the event loop.  That calls
gdb_select, but with timeout==INFINITE.

Again, gdb_select calls the socket serial's wait_handle hook.  It
first clears its events, starting from a clean slate:

  ResetEvent (state->base.read_event);
  ResetEvent (state->base.except_event);
  ResetEvent (state->base.stop_select);

That cleared read_event, which was previously set in #5 above.  And
then it checks for pending events, in the sock_event event:

  /* Check any pending events.  This both avoids starting the thread
     unnecessarily, and handles stray FD_READ events (see below).  */
  if (WaitForSingleObject (state->sock_event, 0) == WAIT_OBJECT_0)
    {

That also fails because state->sock_event was cleared in #5 too...

So the wait_handle hook erroneously decides that it needs to start the
helper thread to wait for input:

 #8 - thread 2: net_windows_select_thread: WaitForMultipleObjects blocking
 #9 - thread 1: gdb_select: WaitForMultipleObjects blocking (INFINITE)

But, GDBserver already sent all it had to send, so both threads waits
forever...

At first I thought that net_windows_wait_handle shouldn't be resetting
state->base.read_event or state->base.except_event, but looking
deeper, the pipe and console wait_handle hooks reset all events too.
It actually makes sense that way -- consuming an event from different
threads is bad practice, and, we should always be able to query
pending state without looking at the state->sock_event from within
net_windows_wait_handle.  The end result is much simpler, and makes
net_windows_select_thread look a lot like console_select_thread,
actually.

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

	PR remote/17028
	* ser-mingw.c (net_windows_socket_check_pending): New function.
	(net_windows_select_thread): Ignore spurious wakeups.  Use
	net_windows_socket_check_pending.
	(net_windows_wait_handle): Check for pending events with
	ioctlsocket, through net_windows_socket_check_pending, instead of
	checking the socket's event.
Delete temporary string within demangler even in failure cases.

A call to demangle_template might allocate storage within a temporary
string even if the call to demangle_template eventually returns
failure.

This will never cause the demangler to crash, but does leak memory, as
a result I've not added any tests for this.

Calling string_delete is safe, even if nothing is allocated into the
string, the string is initialised with string_init, so we know the
internal pointers are NULL.

libiberty/ChangeLog

	* cplus-dem.c (do_type): Call string_delete even if the call to
	demangle_template fails.
Bump version to 7.8.50.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.8.50.DATE-cvs.
Update NEWS post GDB 7.8 branch creation.

gdb/ChangeLog:

	* NEWS: Create a new section for the next release branch.
	Rename the section of the current branch, now that it has
	been cut.
daily update
Whitespace fixes for cpu/or1k.opc

	* or1k.opc: Whitespace fixes.
Use 'struct varobj_item' to represent name and value pair

Hi,
name and value pair is widely used in varobj.c.  This patch is to add
a new struct varobj_item to represent them, so that the number of
function arguments can be reduced.  Finally, the iteration is done on
'struct varobj_item' instead of PyObject after this patch series.

 V2:
 - Fix changelog entry.
 - Fix one grammatical mistake.

gdb:

2014-06-12  Yao Qi  <yao@codesourcery.com>

	* varobj.c (struct varobj_item): New structure.
	(create_child_with_value): Update declaration.
	(varobj_add_child): Replace arguments 'name' and 'value' with
	'item'.  All callers updated.
	(install_dynamic_child): Likewise.
	(update_dynamic_varobj_children): Likewise.
	(varobj_add_child): Likewise.
	(create_child_with_value): Likewise.
Generalize varobj iterator

This patch generalizes varobj iterator, in a python-independent way.
Note varobj_item is still a typedef of PyObject, we can only focus on
API changes, and leave the data type changes to the next patch.  As a
result, we include "varobj-iter.h" after the typedef of PyObject in
varobj.c, but it is an intermediate state.  Finally, varobj-iter.h is
independent of PyObject.

This change is helpful to move some python-related code out of
varobj.c.

 V2:
  - Fix a missing cleanup.
  - Fix typos.
  - Use XNEW.
  - Check against NULL explicitly.
  - Update copyright year for new added files.

 V3:
  - Call PyGILState_Ensure before Py_XDECREF.
  - Use CPYCHECKER_STEALS_REFERENCE_TO_ARG.
  - Code indentation.

 V4:
  - use varobj_ensure_python_env instead of PyGILState_Ensure.

gdb:

2014-06-12  Pedro Alves  <pedro@codesourcery.com>
	    Yao Qi  <yao@codesourcery.com>

	* Makefile.in (SUBDIR_PYTHON_OBS): Add "py-varobj.o".
	(SUBDIR_PYTHON_SRCS): Add "python/py-varobj.c".
	(HFILES_NO_SRCDIR): Add "varobj-iter.h".
	(py-varobj.o): New rule.
	* python/py-varobj.c: New file.
	* python/python-internal.h (py_varobj_get_iterator): Declare.
	* varobj-iter.h: New file.
	* varobj.c: Include "varobj-iter.h"
	(struct varobj) <child_iter>: Change its type from "PyObject *"
	to "struct varobj_iter *".
	<saved_item>: Likewise.
	[HAVE_PYTHON] (varobj_ensure_python_env): Make it extern.
	[HAVE_PYTHON] (varobj_get_iterator): New function.
	(update_dynamic_varobj_children) [HAVE_PYTHON]: Move
	python-specific code to python/py-varobj.c.
	(install_visualizer): Call varobj_iter_delete instead of
	Py_XDECREF.
	* varobj.h (varobj_ensure_python_env): Declare.
Iterate over 'struct varobj_item' instead of PyObject

In previous patch, "saved_item" is still a PyOjbect and iteration is
still performed over PyObject.  This patch continues to decouple
iteration from python code, so it changes its type to "struct
varobj_item *", so that the iterator itself is independent of python.

 V2:
 - Call varobj_delete_iter in free_variable.
 - Fix changelog entries.
 - Use XNEW.

 V3:
 - Return NULL early in py_varobj_iter_next if gdb_python_initialized
   is false.

gdb:

2014-06-12  Pedro Alves  <pedro@codesourcery.com>
	    Yao Qi  <yao@codesourcery.com>

	* python/py-varobj.c (py_varobj_iter_next): Return NULL if
	gdb_python_initialized is false.  Move some code from varobj.c.
	* varobj-iter.h (struct varobj_item): Moved from varobj.c.
	* varobj.c: Move "varobj-iter.h" inclusion earlier.
	(struct varobj_item): Moved to varobj-iter.h".
	(varobj_clear_saved_item): New function.
	(update_dynamic_varobj_children): Move python-related code to
	py-varobj.c.
	(free_variable): Call varobj_clear_saved_item and
	varobj_iter_delete.
Remove #if HAVE_PYTHON

This patch removes some unnecessary "#if HAVE_PYTHON" so that more
code is generalized.

gdb:

2014-06-12  Pedro Alves  <pedro@codesourcery.com>
	    Yao Qi  <yao@codesourcery.com>

	* varobj.c: Remove "#if HAVE_PYTHON" and "#endif".
	(varobj_get_iterator): Wrap up code for pretty-printer by
	"#if HAVE_PYTHON" and "#endif".
	(update_dynamic_varobj_children): Likewise.
Rename varobj_pretty_printed_p to varobj_is_dynamic_p

We think varobj with --available-children-only behaves like a dynamic
varobj, so dyanmic varobj is not pretty-printer specific.  We rename
varobj_pretty_printed_p to varobj_is_dynamic_p, so that we can handle
available-children-only checking in varobj_is_dynamic_p in the next
patch.

gdb:

2014-06-12  Yao Qi  <yao@codesourcery.com>

	* varobj.c (varobj_pretty_printed_p): Rename to ...
	(varobj_is_dynamic_p): ... this.  New function.
	* varobj.h (varobj_pretty_printed_p): Remove declaration.
	(varobj_is_dynamic_p): Declare.
	* mi/mi-cmd-var.c (print_varobj): All callers updated.
	(mi_print_value_p, varobj_update_one): Likewise.