This is to fix a further problem with merging resource sections.  It turns
out that the section is supposed to be page-aligned, but the newly merged
section was not being padded out to a page boundary.  This meant that when
the executable was stripped a badly sized .rsrc section was written out.

	PR ld/16807
	* peXXigen.c (rsrc_process_section): Page align the new contents
	befgore writing out.
User breakpoint ignored if software-single-step at same location

with the following code...

    12    Nested;   -- break #1
    13    return I; -- break #2
    14  end;

(line 12 is a call to function Nested)

... we have noticed the following errorneous behavior on ppc-aix,
where, after having inserted a breakpoint at line 12 and line 13,
and continuing from the breakpoint at line 12, the program never
stops at line 13, running away until the program terminates:

    % gdb -q func
    (gdb) b func.adb:12
    Breakpoint 1 at 0x10000a24: file func.adb, line 12.
    (gdb) b func.adb:13
    Breakpoint 2 at 0x10000a28: file func.adb, line 13.
    (gdb) run
    Starting program: /[...]/func

    Breakpoint 1, func () at func.adb:12
    12        Nested;   -- break #1
    (gdb) c
    Continuing.
    [Inferior 1 (process 4128872) exited with code 02]

When resuming from the first breakpoint, GDB first tries to step out
of that first breakpoint.  We rely on software single-stepping on this
platform, and it just so happens that the address of the first
software single-step breakpoint is the same as the user's breakpoint
#2 (0x10000a28).  So, with infrun and target traces turned on (but
uninteresting traces snip'ed off), the "continue" operation looks like
this:

    (gdb) c
    ### First, we insert the user breakpoints (the second one is an internal
    ### breakpoint on __pthread_init). The first user breakpoint is not
    ### inserted as we need to step out of it first.
    target_insert_breakpoint (0x0000000010000a28, xxx) = 0
    target_insert_breakpoint (0x00000000d03f3800, xxx) = 0
    ### Then we proceed with the step-out-of-breakpoint...
    infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 15335610] at 0x10000a24
    ### That's when we insert the SSS breakpoints...
    target_insert_breakpoint (0x0000000010000a28, xxx) = 0
    target_insert_breakpoint (0x00000000100009ac, xxx) = 0
    ### ... then let the inferior resume...
    target_resume (15335610, continue, 0)
    infrun: wait_for_inferior ()
    target_wait (-1, status, options={}) = 15335610,   status->kind = stopped, signal = GDB_SIGNAL_TRAP
    infrun: target_wait (-1, status) =
    infrun:   15335610 [process 15335610],
    infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
    infrun: infwait_normal_state
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x100009ac
    ### At this point, we stopped at the second SSS breakpoint...
    target_stopped_by_watchpoint () = 0
    ### We remove the SSS breakpoints...
    target_remove_breakpoint (0x0000000010000a28, xxx) = 0
    target_remove_breakpoint (0x00000000100009ac, xxx) = 0
    target_stopped_by_watchpoint () = 0
    ### We find that we're not done, so we resume....
    infrun: no stepping, continue
    ### And thus insert the user breakpoints again, except we're not
    ### inserting the second breakpoint?!?
    target_insert_breakpoint (0x0000000010000a24, xxx) = 0
    infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 15335610] at 0x100009ac
    target_resume (-1, continue, 0)
    infrun: prepare_to_wait
    target_wait (-1, status, options={}) = 15335610,   status->kind = exited, status = 2

What happens is that the removal of the software single-step
breakpoints effectively removed the breakpoint instruction from
inferior memory.  But because such breakpoints are inserted directly
as raw breakpoints rather than through the normal chain of
breakpoints, we fail to notice that one of the user breakpoints points
to the same address and that this user breakpoint is therefore
effectively un-inserted.  When resuming after the single-step, GDB
thinks that the user breakpoint is still inserted and therefore does
not need to insert it again.

This patch teaches the insert and remove routines of both regular and
raw breakpoints to be aware of each other.  Special care needs to be
applied in case the target supports evaluation of breakpoint
conditions or commands.

gdb/ChangeLog:

	PR breakpoints/17000
	* breakpoint.c (find_non_raw_software_breakpoint_inserted_here):
	New function, extracted from software_breakpoint_inserted_here_p.
	(software_breakpoint_inserted_here_p): Replace factored out code
	by call to find_non_raw_software_breakpoint_inserted_here.
	(bp_target_info_copy_insertion_state): New function.
	(bkpt_insert_location): Handle the case of a single-step
	breakpoint already inserted at the same address.
	(bkpt_remove_location): Handle the case of a single-step
	breakpoint still inserted at the same address.
	(deprecated_insert_raw_breakpoint): Handle the case of non-raw
	breakpoint already inserted at the same address.
	(deprecated_remove_raw_breakpoint): Handle the case of a
	non-raw breakpoint still inserted at the same address.
	(find_single_step_breakpoint): New function, extracted from
	single_step_breakpoint_inserted_here_p.
	(find_single_step_breakpoint): New function,
	factored out from single_step_breakpoint_inserted_here_p.
	(single_step_breakpoint_inserted_here_p): Reimplement.

gdb/testsuite/ChangeLog:

	PR breakpoints/17000
	* gdb.base/sss-bp-on-user-bp.exp: Remove kfail.
	* gdb.base/sss-bp-on-user-bp-2.exp: Remove kfail.

Tested on ppc-aix with AdaCore's testsuite.  Tested on x86_64-linux,
(native and gdbserver) with the official testsuite.  Also tested on
x86_64-linux through Pedro's branch enabling software single-stepping
on that platform (native and gdbserver).
Add xmethod interface to the extension language API.

	* defs.h (enum lval_type): New enumerator "lval_xcallable".
	* extension-priv.h (struct extension_language_ops): Add the
	xmethod interface.
	* extension.c (new_xmethod_worker, clone_xmethod_worker,
	get_matching_xmethod_workers, get_xmethod_argtypes,
	invoke_xmethod, free_xmethod_worker,
	free_xmethod_worker_vec): New functions.
	* extension.h: #include "common/vec.h".
	New function declarations.
	(struct xmethod_worker): New struct.
	(VEC (xmethod_worker_ptr)): New vector type.
	(xmethod_worker_ptr): New typedef.
	(xmethod_worker_vec): Likewise.
	* gdbtypes.c (gdbtypes_post_init): Initialize "xmethod" field of
	builtin_type.
	* gdbtypes.h (enum type_code): New enumerator TYPE_CODE_XMETHOD.
	(struct builtin_type): New field "xmethod".
	* valarith.c (value_ptradd): Assert that the value argument is not
	lval_xcallable.
	* valops.c (value_must_coerce_to_target): Return 0 for
	lval_xcallable values.
	* value.c (struct value): New field XM_WORKER in the field
	LOCATION.
	(value_address, value_raw_address): Return 0 for lval_xcallable
	values.
	(set_value_address): Assert that the value is not an
	lval_xcallable.
	(value_free): Free the associated xmethod worker when freeing
	lval_xcallable values.
	(set_value_component_location): Assert that the WHOLE value is not
	lval_xcallable.
	(value_of_xmethod, call_xmethod): New functions.
	* value.h: Declare "struct xmethod_worker".
	Declare new functions value_of_xmethod, call_xmethod.
Lookup and invoke debug methods of C++ classes if they are the best match.

	* eval.c (evaluate_subexp_standard): Call the xmethod if the
	best match method returned by find_overload_match is an xmethod.
	* valarith.c (value_x_binop, value_x_unop): Call the xmethod if
	the best matching operator returned by find_overload_match is an
	xmethod.
	* valops.c: #include "extension.h".
	(find_method_list): Add "fn_list" and "xm_worker_vec" arguments.
	Return void.  The list of matching source methods is returned in
	"fn_list" and a vector of matching debug method workers is
	returned in "xm_worker_vec".  Update all callers.
	(value_find_oload_method_list): Likewise.
	(find_oload_champ): Add "xm_worker_vec" parameter.  If it is
	non-NULL, then the index of the best matching method in this
	vector is returned.  Update all callers.
	(find_overload_match): Include xmethods while performing overload
	resolution.
Missed ChangeLog entry in the previous commit.
Xmethod support in Python.

	* python/py-xmethods.c: New file.
	* python/py-objfile.c (objfile_object): New field 'xmethods'.
	(objfpy_dealloc): XDECREF on the new xmethods field.
	(objfpy_new, objfile_to_objfile_object): Initialize xmethods
	field.
	(objfpy_get_xmethods): New function.
	(objfile_getset): New entry 'xmethods'.
	* python/py-progspace.c (pspace_object): New field 'xmethods'.
	(pspy_dealloc): XDECREF on the new xmethods field.
	(pspy_new, pspace_to_pspace_object): Initialize	xmethods
	field.
	(pspy_get_xmethods): New function.
	(pspace_getset): New entry 'xmethods'.
	* python/python-internal.h: Add declarations for new functions.
	* python/python.c (_initialize_python): Invoke
	gdbpy_initialize_xmethods.
	* python/lib/gdb/__init__.py (xmethods): New
	attribute.
	* python/lib/gdb/xmethod.py: New file.
	* python/lib/gdb/command/xmethods.py: New file.

	testuite/
	* gdb.python/py-xmethods.cc: New testcase to test xmethods.
	* gdb.python/py-xmethods.exp: New tests to test xmethods.
	* gdb.python/py-xmethods.py: Python script supporting the
	new testcase and tests.
Documentation of the xmethod support in GDB Python API.

	* NEWS (Python Scripting): Add entry about the new xmethods
	feature.

	doc/
	*  python.texi (Xmethods In Python, XMethod API)
	(Writing an Xmethod): New nodes.
	(Python API): New menu entries "Xmethods In Python",
	"Xmethod API", "Writing an Xmethod".
gdb/doc/python.texi: Fix reference to "Progspaces In Python".

A recent change broke the documentation build due to a think-o
in a reference.  Fixed thusly.

gdb/doc/ChangeLog:

        * python.texi (Xmethod API): Fix reference to "Progspaces In
        Python".

Tested by rebuilding all documentation formats.