Background
----------

When a thread-specific breakpoint is deleted as a result of the
specific thread exiting the function remove_threaded_breakpoints is
called which sets the disposition of the breakpoint to
disp_del_at_next_stop and sets the breakpoint number to 0.  Setting
the breakpoint number to zero has the effect of hiding the breakpoint
from the user.  We also print a message indicating that the breakpoint
has been deleted.

It was brought to my attention during a review of another patch[1]
that setting a breakpoints number to zero will suppress the MI
breakpoint-deleted notification for that breakpoint, and indeed, this
can be seen to be true, in delete_breakpoint, if the breakpoint number
is zero, then GDB will not notify the breakpoint_deleted observer.

It seems wrong that a user created, thread-specific breakpoint, will
have a =breakpoint-created notification, but will not have a
=breakpoint-deleted notification.  I suspect that this is a bug.

[1] https://sourceware.org/pipermail/gdb-patches/2023-February/196560.html

The First Problem
-----------------

During my initial testing I wanted to see how GDB handled the
breakpoint after it's number was set to zero.  To do this I created
the testcase gdb.threads/thread-bp-deleted.exp.  This test creates a
worker thread, which immediately exits.  After the worker thread has
exited the main thread spins in a loop.

In GDB I break once the worker thread has been created and place a
thread-specific breakpoint, then use 'continue&' to resume the
inferior in non-stop mode.  The worker thread then exits, but the main
thread never stops - instead it sits in the spin.  I then tried to use
'maint info breakpoints' to see what GDB thought of the
thread-specific breakpoint.

Unfortunately, GDB crashed like this:

  (gdb) continue&
  Continuing.
  (gdb) [Thread 0x7ffff7c5d700 (LWP 1202458) exited]
  Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.
  maint info breakpoints
  ... snip some output ...

  Fatal signal: Segmentation fault
  ----- Backtrace -----
  0x5ffb62 gdb_internal_backtrace_1
          ../../src/gdb/bt-utils.c:122
  0x5ffc05 _Z22gdb_internal_backtracev
          ../../src/gdb/bt-utils.c:168
  0x89965e handle_fatal_signal
          ../../src/gdb/event-top.c:964
  0x8997ca handle_sigsegv
          ../../src/gdb/event-top.c:1037
  0x7f96f5971b1f ???
          /usr/src/debug/glibc-2.30-2-gd74461fa34/nptl/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
  0xe602b0 _Z15print_thread_idP11thread_info
          ../../src/gdb/thread.c:1439
  0x5b3d05 print_one_breakpoint_location
          ../../src/gdb/breakpoint.c:6542
  0x5b462e print_one_breakpoint
          ../../src/gdb/breakpoint.c:6702
  0x5b5354 breakpoint_1
          ../../src/gdb/breakpoint.c:6924
  0x5b58b8 maintenance_info_breakpoints
          ../../src/gdb/breakpoint.c:7009
  ... etc ...

As the thread-specific breakpoint is set to disp_del_at_next_stop, and
GDB hasn't stopped yet, then the breakpoint still exists in the global
breakpoint list.

The breakpoint will not show in 'info breakpoints' as its number is
zero, but it will show in 'maint info breakpoints'.

As GDB prints the breakpoint, the thread-id for the breakpoint is
printed as part of the 'stop only in thread ...' line.  Printing the
thread-id involves calling find_thread_global_id to convert the global
thread-id into a thread_info*.  Then calling print_thread_id to
convert the thread_info* into a string.

The problem is that find_thread_global_id returns nullptr as the
thread for the thread-specific breakpoint has exited.  The
print_thread_id assumes it will be passed a non-nullptr.  As a result
GDB crashes.

In this commit I've added an assert to print_thread_id (gdb/thread.c)
to check that the pointed passed in is not nullptr.  This assert would
have triggered in the above case before GDB crashed.

MI Notifications: The Dangers Of Changing A Breakpoint's Number
---------------------------------------------------------------

Currently the delete_breakpoint function doesn't trigger the
breakpoint_deleted observer for any breakpoint with the number zero.

There is a comment explaining why this is the case in the code; it's
something about watchpoints.  But I did consider just removing the 'is
the number zero' guard and always triggering the breakpoint_deleted
observer, figuring that I'd then fix the watchpoint issue some other
way.

But I realised this wasn't going to be good enough.  When the MI
notification was delivered the number would be zero, so any frontend
parsing the notifications would not be able to match
=breakpoint-deleted notification to the earlier =breakpoint-created
notification.

What this means is that, at the point the breakpoint_deleted observer
is called, the breakpoint's number must be correct.

MI Notifications: The Dangers Of Delaying Deletion
--------------------------------------------------

The test I used to expose the above crash also brought another problem
to my attention.  In the above test we used 'continue&' to resume,
after which a thread exited, but the inferior didn't stop.  Recreating
the same test in the MI looks like this:

  -break-insert -p 2 main
  ^done,bkpt={number="2",type="breakpoint",disp="keep",...<snip>...}
  (gdb)
  -exec-continue
  ^running
  *running,thread-id="all"
  (gdb)
  ~"[Thread 0x7ffff7c5d700 (LWP 987038) exited]\n"
  =thread-exited,id="2",group-id="i1"
  ~"Thread-specific breakpoint 2 deleted - thread 2 no longer in the thread list.\n"

At this point the we have a single thread left, which is still
running:

  -thread-info
  ^done,threads=[{id="1",target-id="Thread 0x7ffff7c5eb80 (LWP 987035)",name="thread-bp-delet",state="running",core="4"}],current-thread-id="1"
  (gdb)

Notice that we got the =thread-exited notification from GDB as soon as
the thread exited.  We also saw the CLI line from GDB, the line
explaining that breakpoint 2 was deleted.  But, as expected, we didn't
see the =breakpoint-deleted notification.

I say "as expected" because the number was set to zero.  But, even if
the number was not set to zero we still wouldn't see the
notification.  The MI notification is driven by the breakpoint_deleted
observer, which is only called when we actually delete the breakpoint,
which is only done the next time GDB stops.

Now, maybe this is fine.  The notification is delivered a little
late.  But remember, by setting the number to zero the breakpoint will
be hidden from the user, for example, the breakpoint is removed from
the MI's -break-info command output.

This means that GDB is in a position where the breakpoint doesn't show
up in the breakpoint table, but a =breakpoint-deleted notification has
not yet been sent out.  This doesn't seem right to me.

What this means is that, when the thread exits, we should immediately
be sending out the =breakpoint-deleted notification.  We should not
wait for GDB to next stop before sending the notification.

The Solution
------------

My proposed solution is this; in remove_threaded_breakpoints, instead
of setting the disposition to disp_del_at_next_stop and setting the
number to zero, we now just call delete_breakpoint directly.

The notification will now be sent out immediately; as soon as the
thread exits.

As the number has not changed when delete_breakpoint is called, the
notification will have the correct number.

And as the breakpoint is immediately removed from the breakpoint list,
we no longer need to worry about 'maint info breakpoints' trying to
print the thread-id for an exited thread.

My only concern is that calling delete_breakpoint directly seems so
obvious that I wonder why the original patch (that added
remove_threaded_breakpoints) didn't take this approach.  This code was
added in commit 49fa26b0, but the commit message offers no clues
to why this approach was taken, and the original email thread offers
no insights either[2].  There are no test regressions after making
this change, so I'm hopeful that this is going to be fine.

[2] https://sourceware.org/pipermail/gdb-patches/2013-September/106493.html



The Complication
----------------

Of course, it couldn't be that simple.

The script gdb.python/py-finish-breakpoint.exp had some regressions
during testing.

The problem was with the FinishBreakpoint.out_of_scope callback
implementation.  This callback is supposed to trigger whenever the
FinishBreakpoint goes out of scope; and this includes when the thread
for the breakpoint exits.

The problem I ran into is the Python FinishBreakpoint implementation.
Specifically, after this change I was loosing some of the out_of_scope
calls.

The problem is that the out_of_scope call (of which I'm interested) is
triggered from the inferior_exit observer.  Before my change the
observers were called in this order:

  thread_exit
  inferior_exit
  breakpoint_deleted

The inferior_exit would trigger the out_of_scope call.

After my change the breakpoint_deleted notification (for
thread-specific breakpoints) occurs earlier, as soon as the
thread-exits, so now the order is:

  thread_exit
  breakpoint_deleted
  inferior_exit

Currently, after the breakpoint_deleted call the Python object
associated with the breakpoint is released, so, when we get to the
inferior_exit observer, there's no longer a Python object to call the
out_of_scope method on.

My solution is to follow the model for how bpfinishpy_pre_stop_hook
and bpfinishpy_post_stop_hook are called, this is done from
gdbpy_breakpoint_cond_says_stop in py-breakpoint.c.

I've now added a new bpfinishpy_pre_delete_hook
gdbpy_breakpoint_deleted in py-breakpoint.c, and from this new hook
function I check and where needed call the out_of_scope method.

With this fix in place I now see the
gdb.python/py-finish-breakpoint.exp test fully passing again.

Testing
-------

Tested on x86-64/Linux with unix, native-gdbserver, and
native-extended-gdbserver boards.

New tests added to covers all the cases I've discussed above.

Approved-By: Pedro Alves <pedro@palves.net>

Within the breakpoint struct we have two fields ::thread and ::task
which are used for thread or task specific breakpoints.  When a
breakpoint doesn't have a specific thread or task then these fields
have the values -1 and 0 respectively.

There's no particular reason (as far as I can tell) why these two
"default" values are different, and I find the difference a little
confusing.  Long term I'd like to potentially fold these two fields
into a single field, but that isn't what this commit does.

What this commit does is switch to using -1 as the "default" value for
both fields, this means that the default for breakpoint::task has
changed from 0 to -1.   I've updated all the code I can find that
relied on the value of 0, and I see no test regressions, especially in
gdb.ada/tasks.exp, which still fully passes.

There should be no user visible changes after this commit.

Approved-By: Pedro Alves <pedro@palves.net>

After this mailing list posting:

  https://sourceware.org/pipermail/gdb-patches/2023-February/196607.html



it seems to me that in practice an Ada task maps 1:1 with a GDB
thread, and so it doesn't really make sense to allow uses to give both
a thread and a task within a single breakpoint or watchpoint
condition.

This commit updates GDB so that the user will get an error if both
are specified.

I've added new tests to cover the CLI as well as the Python and Guile
APIs.  For the Python and Guile testing, as far as I can tell, this
was the first testing for this corner of the APIs, so I ended up
adding more than just a single test.

For documentation I've added a NEWS entry, but I've not added anything
to the docs themselves.  Currently we document the commands with a
thread-id or task-id as distinct command, e.g.:

  'break LOCSPEC task TASKNO'
  'break LOCSPEC task TASKNO if ...'
  'break LOCSPEC thread THREAD-ID'
  'break LOCSPEC thread THREAD-ID if ...'

As such, I don't believe there is any indication that combining 'task'
and 'thread' would be expected to work; it seems clear to me in the
above that those four options are all distinct commands.

I think the NEWS entry is enough that if someone is combining these
keywords (it's not clear what the expected behaviour would be in this
case) then they can figure out that this was a deliberate change in
GDB, but for a new user, the manual doesn't suggest combining them is
OK, and any future attempt to combine them will give an error.

Approved-By: Pedro Alves <pedro@palves.net>

This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.

[I sent this earlier today, but I don't see it in the archives.
Resending it through a different computer / SMTP.]

The use of the static buffer in command_line_input is becoming
problematic, as explained here [1].  In short, with this patch [2] that
attempt to fix a post-hook bug, when running gdb.base/commands.exp, we
hit a case where we read a "define" command line from a script file
using command_command_line_input.  The command line is stored in
command_line_input's static buffer.  Inside the define command's
execution, we read the lines inside the define using command_line_input,
which overwrites the define command, in command_line_input's static
buffer.  After the execution of the define command, execute_command does
a command look up to see if a post-hook is registered.  For that, it
uses a now stale pointer that used to point to the define command, in
the static buffer, causing a use-after-free.  Note that the pointer in
execute_command points to the dynamically-allocated buffer help by the
static buffer in command_line_input, not to the static object itself,
hence why we see a use-after-free.

Fix that by removing the static buffer.  I initially changed
command_line_input and other related functions to return an std::string,
which is the obvious but naive solution.  The thing is that some callees
don't need to return an allocated string, so this this an unnecessary
pessimization.  I changed it to passing in a reference to an std::string
buffer, which the callee can use if it needs to return
dynamically-allocated content.  It fills the buffer and returns a
pointers to the C string inside.  The callees that don't need to return
dynamically-allocated content simply don't use it.

So, it started with modifying command_line_input as described above, all
the other changes derive directly from that.

One slightly shady thing is in handle_line_of_input, where we now pass a
pointer to an std::string's internal buffer to readline's history_value
function, which takes a `char *`.  I'm pretty sure that this function
does not modify the input string, because I was able to change it (with
enough massaging) to take a `const char *`.

A subtle change is that we now clear a UI's line buffer using a
SCOPE_EXIT in command_line_handler, after executing the command.
This was previously done by this line in handle_line_of_input:

  /* We have a complete command line now.  Prepare for the next
     command, but leave ownership of memory to the buffer .  */
  cmd_line_buffer->used_size = 0;

I think the new way is clearer.

[1] https://inbox.sourceware.org/gdb-patches/becb8438-81ef-8ad8-cc42-fcbfaea8cddd@simark.ca/
[2] https://inbox.sourceware.org/gdb-patches/20221213112241.621889-1-jan.vrany@labware.com/



Change-Id: I8fc89b1c69870c7fc7ad9c1705724bd493596300
Reviewed-By: Tom Tromey <tom@tromey.com>

I saw that bppy_init used a non-const "char *".  Fixing this revealed
that the xstrdup here was also unnecessary, so this patch removes it.

In a later commit in this series I will propose removing all of the
explicit gdbpy_initialize_* calls from python.c and replace these
calls with a more generic mechanism.

One of the side effects of this generic mechanism is that the order in
which the various Python sub-systems within GDB are initialized is no
longer guaranteed.

On the whole I don't think this matters, most of the sub-systems are
independent of each other, though testing did reveal a few places
where we did have dependencies, though I don't think those
dependencies were explicitly documented in comment anywhere.

This commit is similar to the previous one, and fixes the second
dependency issue that I found.

In this case the finish_breakpoint_object_type uses the
breakpoint_object_type as its tp_base, this means that
breakpoint_object_type must have been initialized with a call to
PyType_Ready before finish_breakpoint_object_type can be initialized.

Previously we depended on the ordering of calls to
gdbpy_initialize_breakpoints and gdbpy_initialize_finishbreakpoints in
python.c.

After this commit a new function gdbpy_breakpoint_init_breakpoint_type
exists, this function ensures that breakpoint_object_type has been
initialized, and can be called from any gdbpy_initialize_* function.

I feel that this change makes the dependency explicit, which I think
is a good thing.

There should be no user visible changes after this commit.

This changes ui_out_redirect_pop to also perform the redirection, and
then updates several sites to use this, rather than explicit
redirects.

PR python/18385

v7:
This version addresses the issues pointed out by Tom.

Added nullchecks for Python object creations.

Changed from using PyLong_FromLong to the gdb_py-versions.

Re-factored some code to make it look more cohesive.

Also added the more safe Python reference count decrement PY_XDECREF,
even though the BreakpointLocation type is never instantiated by the
user (explicitly documented in the docs) decrementing < 0 is made
impossible with the safe call.

Tom pointed out that using the policy class explicitly to decrement a
reference counted object was not the way to go, so this has instead been
wrapped in a ref_ptr that handles that for us in blocpy_dealloc.

Moved macro from py-internal to py-breakpoint.c.

Renamed section at the bottom of commit message "Patch Description".

v6:
This version addresses the points Pedro gave in review to this patch.

Added the attributes `function`, `fullname` and `thread_groups`
as per request by Pedro with the argument that it more resembles the
output of the MI-command "-break-list".  Added documentation for these attributes.

Cleaned up left overs from copy+paste in test suite, removed hard coding
of line numbers where possible.

Refactored some code to use more c++-y style range for loops
wrt to breakpoint locations.

Changed terminology, naming was very inconsistent. Used a variety of "parent",
"owner". Now "owner" is the only term used, and the field in the
gdb_breakpoint_location_object now also called "owner".

v5:

Changes in response to review by Tom Tromey:
- Replaced manual INCREF/DECREF calls with
  gdbpy_ref ptrs in places where possible.
- Fixed non-gdb style conforming formatting
- Get parent of bploc increases ref count of parent.
- moved bploc Python definition to py-breakpoint.c

The INCREF of self in bppy_get_locations is due
to the individual locations holding a reference to
it's owner. This is decremented at de-alloc time.

The reason why this needs to be here is, if the user writes
for instance;

py loc = gdb.breakpoints()[X].locations[Y]

The breakpoint owner object is immediately going
out of scope (GC'd/dealloced), and the location
object requires it to be alive for as long as it is alive.

Thanks for your review, Tom!

v4:
Fixed remaining doc issues as per request
by Eli.

v3:
Rewritten commit message, shortened + reworded,
added tests.

Patch Description

Currently, the Python API lacks the ability to
query breakpoints for their installed locations,
and subsequently, can't query any information about them, or
enable/disable individual locations.

This patch solves this by adding Python type gdb.BreakpointLocation.
The type is never instantiated by the user of the Python API directly,
but is produced by the gdb.Breakpoint.locations attribute returning
a list of gdb.BreakpointLocation.

gdb.Breakpoint.locations:
The attribute for retrieving the currently installed breakpoint
locations for gdb.Breakpoint. Matches behavior of
the "info breakpoints" command in that it only
returns the last known or currently inserted breakpoint locations.

BreakpointLocation contains 7 attributes

6 read-only attributes:
owner: location owner's Python companion object
source: file path and line number tuple: (string, long) / None
address: installed address of the location
function: function name where location was set
fullname: fullname where location was set
thread_groups: thread groups (inferiors) where location was set.

1 writeable attribute:
enabled: get/set enable/disable this location (bool)

Access/calls to these, can all throw Python exceptions (documented in
the online documentation), and that's due to the nature
of how breakpoint locations can be invalidated
"behind the scenes", either by them being removed
from the original breakpoint or changed,
like for instance when a new symbol file is loaded, at
which point all breakpoint locations are re-created by GDB.
Therefore this patch has chosen to be non-intrusive:
it's up to the Python user to re-request the locations if
they become invalid.

Also there's event handlers that handle new object files etc, if a Python
user is storing breakpoint locations in some larger state they've
built up, refreshing the locations is easy and it only comes
with runtime overhead when the Python user wants to use them.

gdb.BreakpointLocation Python type
struct "gdbpy_breakpoint_location_object" is found in python-internal.h

Its definition, layout, methods and functions
are found in the same file as gdb.Breakpoint (py-breakpoint.c)

1 change was also made to breakpoint.h/c to make it possible
to enable and disable a bp_location* specifically,
without having its LOC_NUM, as this number
also can change arbitrarily behind the scenes.

Updated docs & news file as per request.

Testsuite: tests the .source attribute and the disabling of
individual locations.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18385


Change-Id: I302c1c50a557ad59d5d18c88ca19014731d736b0

This converts location_spec_to_string to a method of location_spec,
simplifying the code using it, as it no longer has to use
std::unique_ptr::get().

Change-Id: I621bdad8ea084470a2724163f614578caf8f2dd5

Currently, there's the location_spec hierarchy, and then some
location_spec subclasses have their own struct type holding all their
data fields.

I.e., there is this:

 location_spec
   explicit_location_spec
   linespec_location_spec
   address_location_spec
   probe_location_spec

and then these separate types:

  explicit_location
  linespec_location

where:

  explicit_location_spec
     has-a explicit_location
  linespec_location_spec
     has-a linespec_location

This patch eliminates explicit_location and linespec_location,
inlining their members in the corresponding location_spec type.

The location_spec subclasses were the ones currently defined in
location.c, so they are moved to the header.  Since the definitions of
the classes are now visible, we no longer need location_spec_deleter.

Some constructors that are used for cloning location_specs, like:

  explicit explicit_location_spec (const struct explicit_location *loc)

... were converted to proper copy ctors.

In the process, initialize_explicit_location is eliminated, and some
functions that returned the "data type behind a locspec", like
get_linespec_location are converted to downcast functions, like
as_linespec_location_spec.

Change-Id: Ia31ccef9382b25a52b00fa878c8df9b8cf2a6c5a

Currently, GDB internally uses the term "location" for both the
location specification the user input (linespec, explicit location, or
an address location), and for actual resolved locations, like the
breakpoint locations, or the result of decoding a location spec to
SaLs.  This is expecially confusing in the breakpoints module, as
struct breakpoint has these two fields:

  breakpoint::location;
  breakpoint::loc;

"location" is the location spec, and "loc" is the resolved locations.

And then, we have a method called "locations()", which returns the
resolved locations as range...

The location spec type is presently called event_location:

  /* Location we used to set the breakpoint.  */
  event_location_up location;

and it is described like this:

  /* The base class for all an event locations used to set a stop event
     in the inferior.  */

  struct event_location
  {

and even that is incorrect...  Location specs are used for finding
actual locations in the program in scenarios that have nothing to do
with stop events.  E.g., "list" works with location specs.

To clean all this confusion up, this patch renames "event_location" to
"location_spec" throughout, and then all the variables that hold a
location spec, they are renamed to include "spec" in their name, like
e.g., "location" -> "locspec".  Similarly, functions that work with
location specs, and currently have just "location" in their name are
renamed to include "spec" in their name too.

Change-Id: I5814124798aa2b2003e79496e78f95c74e5eddca

Now that filtered and unfiltered output can be treated identically, we
can unify the printf family of functions.  This is done under the name
"gdb_printf".  Most of this patch was written by script.

New in this version:

 - Rebase on master, fix a few more issues that appeared.

python-internal.h contains a number of macros that helped make the code
work with both Python 2 and 3.  Remove them and adjust the code to use
the Python 3 functions.

Change-Id: I99a3d80067fb2d65de4f69f6473ba6ffd16efb2d

Currently, gdb's Python layer captures the current architecture and
language when "entering" Python code.  This has some undesirable
effects, and so this series changes how this is handled.

First, there is code like this:

  gdbpy_enter enter_py (python_gdbarch, python_language);

This is incorrect, because both of these are NULL when not otherwise
assigned.  This can cause crashes in some cases -- I've added one to
the test suite.  (Note that this crasher is just an example, other
ones along the same lines are possible.)

Second, when the language is captured in this way, it means that
Python code cannot affect the current language for its own purposes.
It's reasonable to want to write code like this:

    gdb.execute('set language mumble')
    ... stuff using the current language
    gdb.execute('set language previous-value')

However, this won't actually work, because the language is captured on
entry.  I've added a test to show this as well.

This patch changes gdb to try to avoid capturing the current values.
The Python concept of the current gdbarch is only set in those few
cases where a non-default value is computed or needed; and the
language is not captured at all -- instead, in the cases where it's
required, the current language is temporarily changed.

This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.

For the avoidance of doubt, all changes in this commits were
performed by the script.

The motivation is to reduce the number of places where unmanaged
pointers are returned from allocation type routines.  All of the
callers are updated.

There should be no user visible changes after this commit.

This changes struct breakpoint to use unique_xmalloc_ptr in a couple
of spots, removing a bit of manual memory management.

This changes struct watchpoint to use unique_xmalloc_ptr in a couple
of places, removing a bit of manual memory management.

This commit adds initial support for catchpoints to the python
breakpoint API.

This commit adds a BP_CATCHPOINT constant which corresponds to
GDB's internal bp_catchpoint.  The new constant is documented in the
manual.

The user can't create breakpoints with type BP_CATCHPOINT after this
commit, but breakpoints that already exist, obtained with the
`gdb.breakpoints` function, can now have this type.  Additionally,
when a stop event is reported for hitting a catchpoint, GDB will now
report a BreakpointEvent with the attached breakpoint being of type
BP_CATCHPOINT - previously GDB would report a generic StopEvent in
this situation.

gdb/ChangeLog:

	* NEWS: Mention Python BP_CATCHPOINT feature.
	* python/py-breakpoint.c (pybp_codes): Add bp_catchpoint support.
	(bppy_init): Likewise.
	(gdbpy_breakpoint_created): Likewise.

gdb/doc/ChangeLog:

	* python.texinfo (Breakpoints In Python): Add BP_CATCHPOINT
	description.

gdb/testsuite/ChangeLog:

	* gdb.python/py-breakpoint.c (do_throw): New function.
	(main): Call do_throw.
	* gdb.python/py-breakpoint.exp (test_catchpoints): New proc.

Now that we have range functions that let us use ranged for loops, we
can remove iterate_over_breakpoints in favor of those, which are easier
to read and write.  This requires exposing the declaration of
all_breakpoints and all_breakpoints_safe in breakpoint.h, as well as the
supporting types.

Change some users of iterate_over_breakpoints to use all_breakpoints,
when they don't need to delete the breakpoint, and all_breakpoints_safe
otherwise.

gdb/ChangeLog:

	* breakpoint.h (iterate_over_breakpoints): Remove.  Update
	callers to use all_breakpoints or all_breakpoints_safe.
	(breakpoint_range, all_breakpoints, breakpoint_safe_range,
	all_breakpoints_safe): Move here.
	* breakpoint.c (all_breakpoints, all_breakpoints_safe): Make
	non-static.
	(iterate_over_breakpoints): Remove.
	* python/py-finishbreakpoint.c (bpfinishpy_detect_out_scope_cb):
	Return void.
	* python/py-breakpoint.c (build_bp_list): Add comment, reverse
	return value logic.
	* guile/scm-breakpoint.c (bpscm_build_bp_list): Return void.

Change-Id: Idde764a1f577de0423e4f2444a7d5cdb01ba5e48

Adds some new debugging to python/py-breakpoint.c.

gdb/ChangeLog:

	* python/py-breakpoint.c (pybp_debug): New static global.
	(show_pybp_debug): New function.
	(pybp_debug_printf): Define.
	(PYBP_SCOPED_DEBUG_ENTER_EXIT): Define.
	(gdbpy_breakpoint_created): Add some debugging.
	(gdbpy_breakpoint_deleted): Likewise.
	(gdbpy_breakpoint_modified): Likewise.
	(_initialize_py_breakpoint): New function.

gdb/doc/ChangeLog:

	* python.texinfo (Python Commands): Document 'set debug
	py-breakpoint' and 'show debug py-breakpoint'.

Give a name to each observer, this will help produce more meaningful
debug message.

gdbsupport/ChangeLog:

	* observable.h (class observable) <struct observer> <observer>:
	Add name parameter.
	<name>: New field.
	<attach>: Add name parameter, update all callers.

Change-Id: Ie0cc4664925215b8d2b09e026011b7803549fba0

The 'create_breakpoint' function takes a 'parse_extra' argument that
determines whether the condition, thread, and force-condition
specifiers should be parsed from the extra string or be used from the
function arguments.  However, for the case when 'parse_extra' is
false, there is no way to pass the force-condition specifier.  This
patch adds it as a new argument.

Also, in the case when parse_extra is false, the current behavior is
as if the condition is being forced.  This is a bug.  The default
behavior should reject the breakpoint.  See below for a demo of this
incorrect behavior.  (The MI command '-break-insert' uses the
'create_breakpoint' function with parse_extra=0.)

  $ gdb -q --interpreter=mi3 /tmp/simple
  =thread-group-added,id="i1"
  =cmd-param-changed,param="history save",value="on"
  =cmd-param-changed,param="auto-load safe-path",value="/"
  ~"Reading symbols from /tmp/simple...\n"
  (gdb)
  -break-insert -c junk -f main
  &"warning: failed to validate condition at location 1, disabling:\n  "
  &"No symbol \"junk\" in current context.\n"
  ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",cond="junk",times="0",original-location="main",locations=[{number="1.1",enabled="N",addr="0x000000000000114e",func="main",file="/tmp/simple.c",fullname="/tmp/simple.c",line="2",thread-groups=["i1"]}]}
  (gdb)
  break main if junk
  &"break main if junk\n"
  &"No symbol \"junk\" in current context.\n"
  ^error,msg="No symbol \"junk\" in current context."
  (gdb)
  break main -force-condition if junk
  &"break main -force-condition if junk\n"
  ~"Note: breakpoint 1 also set at pc 0x114e.\n"
  &"warning: failed to validate condition at location 1, disabling:\n  "
  &"No symbol \"junk\" in current context.\n"
  ~"Breakpoint 2 at 0x114e: file /tmp/simple.c, line 2.\n"
  =breakpoint-created,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",cond="junk",times="0",original-location="main",locations=[{number="2.1",enabled="N",addr="0x000000000000114e",func="main",file="/tmp/simple.c",fullname="/tmp/simple.c",line="2",thread-groups=["i1"]}]}
  ^done
  (gdb)

After applying this patch, we get the behavior below:

  (gdb)
  -break-insert -c junk -f main
  ^error,msg="No symbol \"junk\" in current context."

This restores the behavior that is present in the existing releases.

gdb/ChangeLog:
2021-04-21  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* breakpoint.h (create_breakpoint): Add a new parameter,
	'force_condition'.
	* breakpoint.c (create_breakpoint): Use the 'force_condition'
	argument when 'parse_extra' is false to check if the condition
	is invalid at all of the breakpoint locations.
	Update the users below.
	(break_command_1)
	(dprintf_command)
	(trace_command)
	(ftrace_command)
	(strace_command)
	(create_tracepoint_from_upload): Update.
	* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Update.
	* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Update.
	* python/py-breakpoint.c (bppy_init): Update.
	* python/py-finishbreakpoint.c (bpfinishpy_init): Update.

gdb/testsuite/ChangeLog:
2021-04-21  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* gdb.mi/mi-break.exp: Extend with checks for invalid breakpoint
	conditions.

This allows the creation of hardware breakpoints in Python with
gdb.Breakpoint(type=gdb.BP_HARDWARE_BREAKPOINT)
And they are included in the sequence returned by gdb.breakpoints().

gdb/ChangeLog:

2021-01-21  Hannes Domani  <ssbssa@yahoo.de>

	PR python/19151
	* python/py-breakpoint.c (bppy_get_location): Handle
	bp_hardware_breakpoint.
	(bppy_init): Likewise.
	(gdbpy_breakpoint_created): Likewise.

gdb/doc/ChangeLog:

2021-01-21  Hannes Domani  <ssbssa@yahoo.de>

	PR python/19151
	* python.texi (Breakpoints In Python): Document
	gdb.BP_HARDWARE_BREAKPOINT.

gdb/testsuite/ChangeLog:

2021-01-21  Hannes Domani  <ssbssa@yahoo.de>

	PR python/19151
	* gdb.python/py-breakpoint.exp: Add tests for hardware breakpoints.

This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...

gdb/ChangeLog

        Update copyright year range in copyright header of all GDB files.

The previous patch made it possible to define a condition if it's
valid at some locations.  If the condition is invalid at all of the
locations, it's rejected.  However, there may be cases where the user
knows the condition *will* be valid at a location in the future,
e.g. due to a shared library load.

To make it possible that such condition can be defined, this patch
adds an optional '-force' flag to the 'condition' command, and,
respectively, a '-force-condition' flag to the 'break'command.  When
the force flag is passed, the condition is not rejected even when it
is invalid for all the current locations (note that all the locations
would be internally disabled in this case).

For instance:

  (gdb) break test.c:5
  Breakpoint 1 at 0x1155: file test.c, line 5.
  (gdb) cond 1 foo == 42
  No symbol "foo" in current context.

Defining the condition was not possible because 'foo' is not
available.  The user can override this behavior with the '-force'
flag:

  (gdb) cond -force 1 foo == 42
  warning: failed to validate condition at location 1.1, disabling:
    No symbol "foo" in current context.
  (gdb) info breakpoints
  Num     Type           Disp Enb Address            What
  1       breakpoint     keep y   <MULTIPLE>
          stop only if foo == 42
  1.1                         N   0x0000000000001155 in main at test.c:5

Now the condition is accepted, but the location is automatically
disabled.  If a future location has a context in which 'foo' is
available, that location would be enabled.

For the 'break' command, -force-condition has the same result:

  (gdb) break test.c:5 -force-condition if foo == 42
  warning: failed to validate condition at location 0x1169, disabling:
    No symbol "foo" in current context.
  Breakpoint 1 at 0x1169: file test.c, line 5.

gdb/ChangeLog:
2020-10-27  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* breakpoint.h (set_breakpoint_condition): Add a new bool parameter.
	* breakpoint.c: Update the help text of the 'condition' and 'break'
	commands.
	(set_breakpoint_condition): Take a new bool parameter
	to control whether condition definition should be forced even when
	the condition expression is invalid in all of the current locations.
	(condition_command): Update the call to 'set_breakpoint_condition'.
	(find_condition_and_thread): Take the "-force-condition" flag into
	account.
        * linespec.c (linespec_keywords): Add "-force-condition" as an
	element.
        (FORCE_KEYWORD_INDEX): New #define.
        (linespec_lexer_lex_keyword): Update to consider "-force-condition"
	as a keyword.
	* ada-lang.c (create_ada_exception_catchpoint): Ditto.
	* guile/scm-breakpoint.c (gdbscm_set_breakpoint_condition_x): Ditto.
	* python/py-breakpoint.c (bppy_set_condition): Ditto.
	* NEWS: Mention the changes to the 'break' and 'condition' commands.

gdb/testsuite/ChangeLog:
2020-10-27  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* gdb.base/condbreak-multi-context.exp: Expand to test forcing
	the condition.
	* gdb.linespec/cpcompletion.exp: Update to consider the
	'-force-condition' keyword.
	* gdb.linespec/explicit.exp: Ditto.
	* lib/completion-support.exp: Ditto.

gdb/doc/ChangeLog:
2020-10-27  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* gdb.texinfo (Set Breaks): Document the '-force-condition' flag
	of the 'break'command.
	* gdb.texinfo (Conditions): Document the '-force' flag of the
	'condition' command.

Avoid the use of PyInt_FromLong, preferring gdb_py_object_from_longest
instead.  I found found another spot that was incorrectly handling
errors (see gdbpy_create_ptid_object) while writing this patch; it is
fixed here.

gdb/ChangeLog
2020-09-15  Tom Tromey  <tromey@adacore.com>

	* python/python-internal.h (PyInt_FromLong): Remove define.
	* python/py-value.c (convert_value_from_python): Use
	gdb_py_object_from_longest.
	* python/py-type.c (typy_get_code): Use
	gdb_py_object_from_longest.
	* python/py-symtab.c (salpy_get_line): Use
	gdb_py_object_from_longest.
	* python/py-symbol.c (sympy_get_addr_class, sympy_line): Use
	gdb_py_object_from_longest.
	* python/py-record.c (recpy_gap_reason_code): Use
	gdb_py_object_from_longest.
	* python/py-record-btrace.c (recpy_bt_insn_size)
	(recpy_bt_func_level, btpy_list_count): Use
	gdb_py_object_from_longest.
	* python/py-infthread.c (gdbpy_create_ptid_object): Use
	gdb_py_object_from_longest.  Fix error handling.
	* python/py-framefilter.c (bootstrap_python_frame_filters): Use
	gdb_py_object_from_longest.
	* python/py-frame.c (frapy_type, frapy_unwind_stop_reason): Use
	gdb_py_object_from_longest.
	* python/py-breakpoint.c (bppy_get_type, bppy_get_number)
	(bppy_get_thread, bppy_get_task, bppy_get_hit_count)
	(bppy_get_ignore_count): Use gdb_py_object_from_longest.

gdb/ChangeLog:

        Update copyright year range in all GDB files.

The documentation for make-breakpoint from the Guile API and the `spec'
variant of the gdb.Breakpoint constructor from the Python API state that
the format acceptable for location strings is the same as that accepted
by the break command. However, using the -probe qualifier at the
beginning of the location string causes a GDB internal error as it
attempts to decode a probe location in the wrong code path. Without this
functionality, there doesn't appear to be another way to set breakpoints
on probe points from Python or Guile scripts.

This patch introduces a new helper function that returns a
breakpoint_ops instance appropriate for a parsed location and updates
the Guile and Python bindings to use said function, rather than the
current hard-coded use of bkpt_breakpoint_ops. Since this logic is
duplicated in the handling of the `break' and `trace' commands, those
are also updated to call into the new helper function.

gdb/ChangeLog:
2019-12-10  George Barrett  <bob@bob131.so>

	Fix scripted probe breakpoints.
	* breakpoint.c (tracepoint_probe_breakpoint_ops): Move
	declaration forward.
	(breakpoint_ops_for_event_location_type)
	(breakpoint_ops_for_event_location): Add function definitions.
	(break_command_1, trace_command): Use
	breakpoint_ops_for_event_location.
	* breakpoint.h (breakpoint_ops_for_event_location): Add function
	declarations.
	* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Use
	breakpoint_ops_for_event_location.
	* python/py-breakpoint.c (bppy_init): Use
	breakpoint_ops_for_event_location.

gdb/testsuite/ChangeLog:
2019-12-10  George Barrett  <bob@bob131.so>

	Test scripted probe breakpoints.
	* gdb.guile/scm-breakpoint.c (main): Add probe point.
	* gdb.python/py-breakpoint.c (main): Likewise.
	* gdb.guile/scm-breakpoint.exp (test_bkpt_probe): Add probe
	specifier test.
	* gdb.python/py-breakpoint.exp (test_bkpt_probe): Likewise.

valgrind reports a leak when a breakpoint is created then deleted:

==1313== 40 bytes in 1 blocks are definitely lost in loss record 1,115 of 8,596
==1313==    at 0x4835753: malloc (vg_replace_malloc.c:307)
==1313==    by 0x6E05BC: _PyObject_New (object.c:255)
==1313==    by 0x470E4B: gdbpy_breakpoint_created(breakpoint*) (py-breakpoint.c:1023)
==1313==    by 0x2946D9: operator() (std_function.h:687)
==1313==    by 0x2946D9: notify (observable.h:106)
==1313==    by 0x2946D9: install_breakpoint(int, std::unique_ptr<breakpoint, std::default_delete<breakpoint> >&&, int) (breakpoint.c:8136)
==1313==    by 0x295BCA: create_breakpoint_sal (breakpoint.c:8878)
==1313==    by 0x295BCA: create_breakpoints_sal (breakpoint.c:8919)
==1313==    by 0x295BCA: create_breakpoints_sal_default (breakpoint.c:13671)
...

The leak is due to a superfluous Py_INCREF when the python object
is allocated inside gdbpy_breakpoint_created, when the python object
is allocated locally: this object has already a refcount of 1, and
the only reference is the reference from the C breakpoint object.
The Py_INCREF is however needed when the python object was created from
python: the python object was stored in bppy_pending_object, and
gdbpy_breakpoint_created creates a new reference to this object.

Solve the leak by calling 'Py_INCREF (newbp);' only in the bppy_pending_object
case.

Regression tested on debian/amd64 natively and under valgrind on centos/amd64.
Before the patch, 795 tests have a definite leak.
After the patch, 197 have a definite leak.

Thanks to Tom, that helped on irc with the python refcount logic.

gdb/ChangeLog
2019-11-14  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

	* python/py-finishbreakpoint.c (gdbpy_breakpoint_created):
	only call Py_INCREF (newbp) in the bppy_pending_object case.

This allows callers to pass in capturing lambdas.  Also changes the return
type to bool.

gdb/ChangeLog:

2019-10-15  Christian Biesinger  <cbiesinger@google.com>

	* breakpoint.c (iterate_over_breakpoints): Change function pointer
	to a gdb::function_view and return value to bool.
	* breakpoint.h (iterate_over_breakpoints): Likewise.
	* dummy-frame.c (pop_dummy_frame_bpt): Update.
	(pop_dummy_frame): Update.
	* guile/scm-breakpoint.c (bpscm_build_bp_list): Update.
	(gdbscm_breakpoints): Update.
	* python/py-breakpoint.c (build_bp_list): Update.
	(gdbpy_breakpoints): Update.
	* python/py-finishbreakpoint.c (bpfinishpy_detect_out_scope_cb):
	Update.
	(bpfinishpy_handle_stop): Update.
	(bpfinishpy_handle_exit): Update.
	* solib-svr4.c (svr4_update_solib_event_breakpoint): Update.
	(svr4_update_solib_event_breakpoints): Update.

Change-Id: Ia9de4deecae562a70a40f5cd49f5a74d64570251

Currently, with:

 (gdb) catch catch
 Catchpoint 1 (catch)
 (gdb) catch throw
 Catchpoint 2 (throw)
 (gdb) catch rethrow
 Catchpoint 3 (rethrow)

You get:

(gdb) info breakpoints
 Num     Type           Disp Enb Address            What
 1       breakpoint     keep y   0x0000000000b122af exception catch
 2       breakpoint     keep y   0x0000000000b1288d exception throw
 3       breakpoint     keep y   0x0000000000b12931 exception rethrow

I think it doesn't make much sense usability-wise, to show a
catchpoint as a breakpoint.  The fact that GDB sets a breakpoint at
some magic address in the C++ run time is an implementation detail,
IMO.  And as seen in the previous patch, such a catchpoint can end up
with more than one location/address even, so showing a single address
isn't entirely accurate.

This commit hides the addresses from view, and makes GDB show
"catchpoint" for type as well:

  (gdb) info breakpoints
  Num     Type           Disp Enb Address            What
  1       catchpoint     keep y                      exception catch
  2       catchpoint     keep y                      exception throw
  3       catchpoint     keep y                      exception rethrow

This comment in the code seems telling:

  /* We need to reset 'type' in order for code in breakpoint.c to do
     the right thing.  */
  cp->type = bp_breakpoint;

It kind of suggests that the reason catchpoints end up shown as
breakpoints was that it was easier to implement them that way, rather
than a desired property.

This commit fixes things up to make it possible to have bp_catch
breakpoints have software/hardware breakpoint locations, thus
eliminating the need for that hack:

 - redo breakpoint_address_is_meaningful in terms of the location's
   type rather than breakpoint type.
 - teach bpstat_what about stepping over the catchpoint locations.
 - install a allocate_location method for "catch catch/throw/rethrow",
   one that forces the location type.

Note that this also reverts the gdb hunk from:

  commit 2a8be203
  Commit:     Tom Tromey <tom@tromey.com>
  CommitDate: Sat Oct 6 22:17:45 2018 -0600

      Fix Python gdb.Breakpoint.location crash

because now "catch throw" catchpoints hit the

   if (obj->bp->type != bp_breakpoint)
     Py_RETURN_NONE;

check above, and, adjusts the testcase to no longer expect to see the
catchpoint in the gdb.breakpoints() list.

(Note: might make sense to do the same to Ada exception catchpoints.)

gdb/ChangeLog:
2019-07-09  Pedro Alves  <palves@redhat.com>

	* break-catch-throw.c (print_one_exception_catchpoint): Skip the
	"addr" field.
	(allocate_location_exception_catchpoint): New.
	(handle_gnu_v3_exceptions): Don't reset 'type' to bp_breakpoint.
	(initialize_throw_catchpoint_ops): Install
	allocate_location_exception_catchpoint as allocate_location
	method.
	* breakpoint.c (bpstat_what) <bp_catch>: Set action to
	BPSTAT_WHAT_SINGLE if not stopping and the location's type is not
	bp_loc_other.
	(breakpoint_address_is_meaningful): Delete.
	(bl_address_is_meaningful): New.
	(breakpoint_locations_match): Adjust comment.
	(bp_location_from_bp_type): New, factored out of...
	(bp_location::bp_location(breakpoint *)): ... this.
	(bp_location::bp_location(breakpoint *, bp_loc_type)): New,
	factored out of...
	(bp_location::bp_location(breakpoint *)): ... this.  Reimplement.
	(bp_loc_is_permanent): Use bl_address_is_meaningful instead of
	breakpoint_address_is_meaningful.
	(bp_locations_compare): Adjust comment.
	(update_global_location_list): Use bl_address_is_meaningful
	instead of breakpoint_address_is_meaningful.
	* breakpoint.h (bp_location::bp_location(breakpoint *)): New
	explicit.
	(bp_location::bp_location(breakpoint *, bp_loc_type)): Declare.
	* python/py-breakpoint.c (bppy_get_location): No longer check
	whether location is null.

gdb/doc/ChangeLog:
2019-07-09  Pedro Alves  <palves@redhat.com>

	* gdb.texinfo (C++ Exception GDB/MI Catchpoint Commands): Adjust
	examples to show type=catchpoint instead of type=breakpoint and an
	address.

gdb/testsuite/ChangeLog:
2019-07-09  Pedro Alves  <palves@redhat.com>

	* gdb.cp/catch-multi-stdlib.exp: Adjust expected "info
	breakpoints" output.
	* gdb.cp/exception.exp: Adjust expected "info breakpoints" output.
	* gdb.python/py-breakpoint.exp: No longer expect that "catch
	throw" creates breakpoint.
	* gdb.mi/mi-catch-cpp-exceptions.exp (setup_catchpoint): Expect
	'type="catchpoint"'.

A few spots in py-breakpoint.c acquire the GIL manually.  However,
because these spots generate events, and because events are expected
to be arbitrary gdb-flavored Python code, it's important to use
gdbpy_enter instead, in order to ensure that the other gdb-related
Python globals are set correctly.

This patch makes this change.  Tested on x86-64 Fedora 29.

gdb/ChangeLog
2019-06-10  Tom Tromey  <tom@tromey.com>

	* python/py-breakpoint.c (gdbpy_breakpoint_created)
	(gdbpy_breakpoint_deleted, gdbpy_breakpoint_modified): Use
	gdbpy_enter.

This makes exception handling more efficient in a few spots, through
the use of const- and rvalue-references.

I wrote this patch by commenting out the gdb_exception copy
constructor and then examining the resulting error messages one by
one, introducing the use of std::move where appropriate.

gdb/ChangeLog
2019-04-25  Tom Tromey  <tromey@adacore.com>

	* xml-support.c (struct gdb_xml_parser) <set_error>: Take an
	rvalue reference.
	(gdb_xml_start_element_wrapper, gdb_xml_end_element_wrapper)
	(gdb_xml_parser::parse): Use std::move.
	* python/python-internal.h (gdbpy_convert_exception): Take a const
	reference.
	* python/py-value.c (valpy_getitem, valpy_nonzero): Use
	std::move.
	* python/py-utils.c (gdbpy_convert_exception): Take a const
	reference.
	* python/py-inferior.c (infpy_write_memory, infpy_search_memory):
	Use std::move.
	* python/py-breakpoint.c (bppy_set_condition, bppy_set_commands):
	Use std::move.
	* mi/mi-main.c (mi_print_exception): Take a const reference.
	* main.c (handle_command_errors): Take a const reference.
	* linespec.c (parse_linespec): Use std::move.
	* infcall.c (run_inferior_call): Use std::move.
	(call_function_by_hand_dummy): Use std::move.
	* exec.c (try_open_exec_file): Use std::move.
	* exceptions.h (exception_print, exception_fprintf)
	(exception_print_same): Update.
	* exceptions.c (print_exception, exception_print)
	(exception_fprintf, exception_print_same): Change parameters to
	const reference.
	* event-top.c (gdb_rl_callback_read_char_wrapper): Update.
	* common/new-op.c: Use std::move.
	* common/common-exceptions.h (struct gdb_exception): Add move
	constructor.
	(struct gdb_exception_error, struct gdb_exception_quit, struct
	gdb_quit_bad_alloc): Change constructor to move constructor.
	(throw_exception): Change parameter to rvalue reference.
	* common/common-exceptions.c (throw_exception): Take rvalue
	reference.
	* cli/cli-interp.c (safe_execute_command): Use std::move.
	* breakpoint.c (insert_bp_location, location_to_sals): Use
	std::move.

Now that gdb_exception has a constructor, there's no need for
exception_none.  This patch removes it.

gdb/ChangeLog
2019-04-25  Tom Tromey  <tromey@adacore.com>

	* xml-support.c (gdb_xml_parser::gdb_xml_parser): Update.
	* python/py-value.c (valpy_getitem, valpy_nonzero): Update.
	* python/py-inferior.c (infpy_write_memory, infpy_search_memory):
	Update.
	* python/py-breakpoint.c (bppy_set_condition, bppy_set_commands):
	Update.
	* mi/mi-interp.c (mi_interp::exec): Update.
	* linespec.c (parse_linespec): Update.
	* infcall.c (run_inferior_call): Update.
	* guile/scm-value.c (gdbscm_value_to_lazy_string): Update.
	* guile/scm-symbol.c (gdbscm_lookup_symbol)
	(gdbscm_lookup_global_symbol): Update.
	* guile/scm-param.c (gdbscm_parameter_value): Update.
	* guile/scm-frame.c (gdbscm_frame_read_register)
	(gdbscm_frame_read_var): Update.
	* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Update.
	* exec.c (try_open_exec_file): Update.
	* event-top.c (gdb_rl_callback_read_char_wrapper_noexcept)
	(gdb_rl_callback_handler): Update.
	* common/common-exceptions.h (exception_none): Don't declare.
	* common/common-exceptions.c (exception_none): Don't define.
	(struct catcher) <exception>: Update.
	* cli/cli-interp.c (safe_execute_command): Update.
	* breakpoint.c (insert_bp_location, location_to_sals): Update.

This renames the gdb exception types.  The old types were only needed
due to the macros in common-exception.h that are now gone.

The intermediate layer of gdb_exception_RETURN_MASK_ALL did not seem
needed, so this patch removes it entirely.

gdb/ChangeLog
2019-04-08  Tom Tromey  <tom@tromey.com>

	* common/common-exceptions.h (gdb_exception_RETURN_MASK_ALL):
	Remove.
	(gdb_exception_error): Rename from
	gdb_exception_RETURN_MASK_ERROR.
	(gdb_exception_quit): Rename from gdb_exception_RETURN_MASK_QUIT.
	(gdb_quit_bad_alloc): Update.
	* aarch64-tdep.c: Update.
	* ada-lang.c: Update.
	* ada-typeprint.c: Update.
	* ada-valprint.c: Update.
	* amd64-tdep.c: Update.
	* arch-utils.c: Update.
	* break-catch-throw.c: Update.
	* breakpoint.c: Update.
	* btrace.c: Update.
	* c-varobj.c: Update.
	* cli/cli-cmds.c: Update.
	* cli/cli-interp.c: Update.
	* cli/cli-script.c: Update.
	* common/common-exceptions.c: Update.
	* common/new-op.c: Update.
	* common/selftest.c: Update.
	* compile/compile-c-symbols.c: Update.
	* compile/compile-cplus-symbols.c: Update.
	* compile/compile-object-load.c: Update.
	* compile/compile-object-run.c: Update.
	* completer.c: Update.
	* corelow.c: Update.
	* cp-abi.c: Update.
	* cp-support.c: Update.
	* cp-valprint.c: Update.
	* darwin-nat.c: Update.
	* disasm-selftests.c: Update.
	* dtrace-probe.c: Update.
	* dwarf-index-cache.c: Update.
	* dwarf-index-write.c: Update.
	* dwarf2-frame-tailcall.c: Update.
	* dwarf2-frame.c: Update.
	* dwarf2loc.c: Update.
	* dwarf2read.c: Update.
	* eval.c: Update.
	* event-loop.c: Update.
	* event-top.c: Update.
	* exec.c: Update.
	* f-valprint.c: Update.
	* fbsd-tdep.c: Update.
	* frame-unwind.c: Update.
	* frame.c: Update.
	* gdbtypes.c: Update.
	* gnu-v3-abi.c: Update.
	* guile/guile-internal.h: Update.
	* guile/scm-block.c: Update.
	* guile/scm-breakpoint.c: Update.
	* guile/scm-cmd.c: Update.
	* guile/scm-disasm.c: Update.
	* guile/scm-frame.c: Update.
	* guile/scm-lazy-string.c: Update.
	* guile/scm-math.c: Update.
	* guile/scm-param.c: Update.
	* guile/scm-ports.c: Update.
	* guile/scm-pretty-print.c: Update.
	* guile/scm-symbol.c: Update.
	* guile/scm-symtab.c: Update.
	* guile/scm-type.c: Update.
	* guile/scm-value.c: Update.
	* i386-linux-tdep.c: Update.
	* i386-tdep.c: Update.
	* inf-loop.c: Update.
	* infcall.c: Update.
	* infcmd.c: Update.
	* infrun.c: Update.
	* jit.c: Update.
	* language.c: Update.
	* linespec.c: Update.
	* linux-fork.c: Update.
	* linux-nat.c: Update.
	* linux-tdep.c: Update.
	* linux-thread-db.c: Update.
	* main.c: Update.
	* mi/mi-cmd-break.c: Update.
	* mi/mi-cmd-stack.c: Update.
	* mi/mi-interp.c: Update.
	* mi/mi-main.c: Update.
	* objc-lang.c: Update.
	* p-valprint.c: Update.
	* parse.c: Update.
	* ppc-linux-tdep.c: Update.
	* printcmd.c: Update.
	* python/py-arch.c: Update.
	* python/py-breakpoint.c: Update.
	* python/py-cmd.c: Update.
	* python/py-finishbreakpoint.c: Update.
	* python/py-frame.c: Update.
	* python/py-framefilter.c: Update.
	* python/py-gdb-readline.c: Update.
	* python/py-inferior.c: Update.
	* python/py-infthread.c: Update.
	* python/py-lazy-string.c: Update.
	* python/py-linetable.c: Update.
	* python/py-objfile.c: Update.
	* python/py-param.c: Update.
	* python/py-prettyprint.c: Update.
	* python/py-progspace.c: Update.
	* python/py-record-btrace.c: Update.
	* python/py-record.c: Update.
	* python/py-symbol.c: Update.
	* python/py-type.c: Update.
	* python/py-unwind.c: Update.
	* python/py-utils.c: Update.
	* python/py-value.c: Update.
	* python/python.c: Update.
	* record-btrace.c: Update.
	* record-full.c: Update.
	* remote-fileio.c: Update.
	* remote.c: Update.
	* riscv-tdep.c: Update.
	* rs6000-aix-tdep.c: Update.
	* rs6000-tdep.c: Update.
	* rust-exp.y: Update.
	* rust-lang.c: Update.
	* s390-tdep.c: Update.
	* selftest-arch.c: Update.
	* solib-dsbt.c: Update.
	* solib-frv.c: Update.
	* solib-spu.c: Update.
	* solib-svr4.c: Update.
	* solib.c: Update.
	* sparc64-linux-tdep.c: Update.
	* stack.c: Update.
	* symfile-mem.c: Update.
	* symmisc.c: Update.
	* target.c: Update.
	* thread.c: Update.
	* top.c: Update.
	* tracefile-tfile.c: Update.
	* tui/tui.c: Update.
	* typeprint.c: Update.
	* unittests/cli-utils-selftests.c: Update.
	* unittests/parse-connection-spec-selftests.c: Update.
	* valops.c: Update.
	* valprint.c: Update.
	* value.c: Update.
	* varobj.c: Update.
	* windows-nat.c: Update.
	* x86-linux-nat.c: Update.
	* xml-support.c: Update.

gdb/gdbserver/ChangeLog
2019-04-08  Tom Tromey  <tom@tromey.com>

	* gdbreplay.c: Update.
	* linux-low.c: Update.
	* server.c: Update.

This rewrites gdb's TRY/CATCH to plain C++ try/catch.  The patch was
largely written by script, though one change (to a comment in
common-exceptions.h) was reverted by hand.

gdb/ChangeLog
2019-04-08  Tom Tromey  <tom@tromey.com>

	* xml-support.c: Use C++ exception handling.
	* x86-linux-nat.c: Use C++ exception handling.
	* windows-nat.c: Use C++ exception handling.
	* varobj.c: Use C++ exception handling.
	* value.c: Use C++ exception handling.
	* valprint.c: Use C++ exception handling.
	* valops.c: Use C++ exception handling.
	* unittests/parse-connection-spec-selftests.c: Use C++ exception
	handling.
	* unittests/cli-utils-selftests.c: Use C++ exception handling.
	* typeprint.c: Use C++ exception handling.
	* tui/tui.c: Use C++ exception handling.
	* tracefile-tfile.c: Use C++ exception handling.
	* top.c: Use C++ exception handling.
	* thread.c: Use C++ exception handling.
	* target.c: Use C++ exception handling.
	* symmisc.c: Use C++ exception handling.
	* symfile-mem.c: Use C++ exception handling.
	* stack.c: Use C++ exception handling.
	* sparc64-linux-tdep.c: Use C++ exception handling.
	* solib.c: Use C++ exception handling.
	* solib-svr4.c: Use C++ exception handling.
	* solib-spu.c: Use C++ exception handling.
	* solib-frv.c: Use C++ exception handling.
	* solib-dsbt.c: Use C++ exception handling.
	* selftest-arch.c: Use C++ exception handling.
	* s390-tdep.c: Use C++ exception handling.
	* rust-lang.c: Use C++ exception handling.
	* rust-exp.y: Use C++ exception handling.
	* rs6000-tdep.c: Use C++ exception handling.
	* rs6000-aix-tdep.c: Use C++ exception handling.
	* riscv-tdep.c: Use C++ exception handling.
	* remote.c: Use C++ exception handling.
	* remote-fileio.c: Use C++ exception handling.
	* record-full.c: Use C++ exception handling.
	* record-btrace.c: Use C++ exception handling.
	* python/python.c: Use C++ exception handling.
	* python/py-value.c: Use C++ exception handling.
	* python/py-utils.c: Use C++ exception handling.
	* python/py-unwind.c: Use C++ exception handling.
	* python/py-type.c: Use C++ exception handling.
	* python/py-symbol.c: Use C++ exception handling.
	* python/py-record.c: Use C++ exception handling.
	* python/py-record-btrace.c: Use C++ exception handling.
	* python/py-progspace.c: Use C++ exception handling.
	* python/py-prettyprint.c: Use C++ exception handling.
	* python/py-param.c: Use C++ exception handling.
	* python/py-objfile.c: Use C++ exception handling.
	* python/py-linetable.c: Use C++ exception handling.
	* python/py-lazy-string.c: Use C++ exception handling.
	* python/py-infthread.c: Use C++ exception handling.
	* python/py-inferior.c: Use C++ exception handling.
	* python/py-gdb-readline.c: Use C++ exception handling.
	* python/py-framefilter.c: Use C++ exception handling.
	* python/py-frame.c: Use C++ exception handling.
	* python/py-finishbreakpoint.c: Use C++ exception handling.
	* python/py-cmd.c: Use C++ exception handling.
	* python/py-breakpoint.c: Use C++ exception handling.
	* python/py-arch.c: Use C++ exception handling.
	* printcmd.c: Use C++ exception handling.
	* ppc-linux-tdep.c: Use C++ exception handling.
	* parse.c: Use C++ exception handling.
	* p-valprint.c: Use C++ exception handling.
	* objc-lang.c: Use C++ exception handling.
	* mi/mi-main.c: Use C++ exception handling.
	* mi/mi-interp.c: Use C++ exception handling.
	* mi/mi-cmd-stack.c: Use C++ exception handling.
	* mi/mi-cmd-break.c: Use C++ exception handling.
	* main.c: Use C++ exception handling.
	* linux-thread-db.c: Use C++ exception handling.
	* linux-tdep.c: Use C++ exception handling.
	* linux-nat.c: Use C++ exception handling.
	* linux-fork.c: Use C++ exception handling.
	* linespec.c: Use C++ exception handling.
	* language.c: Use C++ exception handling.
	* jit.c: Use C++ exception handling.
	* infrun.c: Use C++ exception handling.
	* infcmd.c: Use C++ exception handling.
	* infcall.c: Use C++ exception handling.
	* inf-loop.c: Use C++ exception handling.
	* i386-tdep.c: Use C++ exception handling.
	* i386-linux-tdep.c: Use C++ exception handling.
	* guile/scm-value.c: Use C++ exception handling.
	* guile/scm-type.c: Use C++ exception handling.
	* guile/scm-symtab.c: Use C++ exception handling.
	* guile/scm-symbol.c: Use C++ exception handling.
	* guile/scm-pretty-print.c: Use C++ exception handling.
	* guile/scm-ports.c: Use C++ exception handling.
	* guile/scm-param.c: Use C++ exception handling.
	* guile/scm-math.c: Use C++ exception handling.
	* guile/scm-lazy-string.c: Use C++ exception handling.
	* guile/scm-frame.c: Use C++ exception handling.
	* guile/scm-disasm.c: Use C++ exception handling.
	* guile/scm-cmd.c: Use C++ exception handling.
	* guile/scm-breakpoint.c: Use C++ exception handling.
	* guile/scm-block.c: Use C++ exception handling.
	* guile/guile-internal.h: Use C++ exception handling.
	* gnu-v3-abi.c: Use C++ exception handling.
	* gdbtypes.c: Use C++ exception handling.
	* frame.c: Use C++ exception handling.
	* frame-unwind.c: Use C++ exception handling.
	* fbsd-tdep.c: Use C++ exception handling.
	* f-valprint.c: Use C++ exception handling.
	* exec.c: Use C++ exception handling.
	* event-top.c: Use C++ exception handling.
	* event-loop.c: Use C++ exception handling.
	* eval.c: Use C++ exception handling.
	* dwarf2read.c: Use C++ exception handling.
	* dwarf2loc.c: Use C++ exception handling.
	* dwarf2-frame.c: Use C++ exception handling.
	* dwarf2-frame-tailcall.c: Use C++ exception handling.
	* dwarf-index-write.c: Use C++ exception handling.
	* dwarf-index-cache.c: Use C++ exception handling.
	* dtrace-probe.c: Use C++ exception handling.
	* disasm-selftests.c: Use C++ exception handling.
	* darwin-nat.c: Use C++ exception handling.
	* cp-valprint.c: Use C++ exception handling.
	* cp-support.c: Use C++ exception handling.
	* cp-abi.c: Use C++ exception handling.
	* corelow.c: Use C++ exception handling.
	* completer.c: Use C++ exception handling.
	* compile/compile-object-run.c: Use C++ exception handling.
	* compile/compile-object-load.c: Use C++ exception handling.
	* compile/compile-cplus-symbols.c: Use C++ exception handling.
	* compile/compile-c-symbols.c: Use C++ exception handling.
	* common/selftest.c: Use C++ exception handling.
	* common/new-op.c: Use C++ exception handling.
	* cli/cli-script.c: Use C++ exception handling.
	* cli/cli-interp.c: Use C++ exception handling.
	* cli/cli-cmds.c: Use C++ exception handling.
	* c-varobj.c: Use C++ exception handling.
	* btrace.c: Use C++ exception handling.
	* breakpoint.c: Use C++ exception handling.
	* break-catch-throw.c: Use C++ exception handling.
	* arch-utils.c: Use C++ exception handling.
	* amd64-tdep.c: Use C++ exception handling.
	* ada-valprint.c: Use C++ exception handling.
	* ada-typeprint.c: Use C++ exception handling.
	* ada-lang.c: Use C++ exception handling.
	* aarch64-tdep.c: Use C++ exception handling.

gdb/gdbserver/ChangeLog
2019-04-08  Tom Tromey  <tom@tromey.com>

	* server.c: Use C++ exception handling.
	* linux-low.c: Use C++ exception handling.
	* gdbreplay.c: Use C++ exception handling.

This removes all the remainings spots I could find that work around
issues in Python 2.4 and 2.5.

I don't have a good way to test that Python 2.6 still works.

Tested by the buildbot.

gdb/ChangeLog
2019-02-27  Tom Tromey  <tromey@adacore.com>

	* config.in, configure: Rebuild.
	* configure.ac (HAVE_LIBPYTHON2_4, HAVE_LIBPYTHON2_5): Never
	define.
	* python/py-value.c: Remove Python 2.4 workaround.
	* python/py-utils.c (gdb_pymodule_addobject): Remove Python 2.4
	workaround.
	* python/py-type.c (convert_field, gdbpy_initialize_types): Remove
	Python 2.4 workaround.
	* python/python-internal.h: Remove Python 2.4 comment.
	(Py_ssize_t): Don't define.
	(PyVarObject_HEAD_INIT, Py_TYPE): Don't define.
	(gdb_Py_DECREF): Remove Python 2.4 workaround.
	(gdb_PyObject_GetAttrString, PyObject_GetAttrString): Remove.
	(gdb_PyObject_HasAttrString, PyObject_HasAttrString): Remove.
	* python/python.c (do_start_initialization): Remove Python 2.4
	workaround.
	* python/py-prettyprint.c (class dummy_python_frame): Remove.
	(print_children): Remove Python 2.4 workaround.
	* python/py-inferior.c (buffer_procs): Remove Python 2.4
	workaround.
	(CHARBUFFERPROC_NAME): Remove.
	* python/py-breakpoint.c (gdbpy_initialize_breakpoints): Remove
	Python 2.4 workaround.

gdb/testsuite/ChangeLog
2019-02-27  Tom Tromey  <tromey@adacore.com>

	* lib/gdb.exp (skip_python_tests_prompt): Don't check for Python
	2.4.
	* gdb.python/py-finish-breakpoint.exp: Remove Python 2.4
	workaround.

gdb/ChangeLog
2019-02-27  Tom Tromey  <tromey@adacore.com>

	* config.in, configure: Rebuild.
	* configure.ac (HAVE_LIBPYTHON2_4, HAVE_LIBPYTHON2_5): Never
	define.
	* python/py-value.c: Remove Python 2.4 workaround.
	* python/py-utils.c (gdb_pymodule_addobject): Remove Python 2.4
	workaround.
	* python/py-type.c (convert_field, gdbpy_initialize_types): Remove
	Python 2.4 workaround.
	* python/python-internal.h: Remove Python 2.4 comment.
	(Py_ssize_t): Don't define.
	(PyVarObject_HEAD_INIT, Py_TYPE): Don't define.
	(gdb_Py_DECREF): Remove Python 2.4 workaround.
	(gdb_PyObject_GetAttrString, PyObject_GetAttrString): Remove.
	(gdb_PyObject_HasAttrString, PyObject_HasAttrString): Remove.
	* python/python.c (do_start_initialization): Remove Python 2.4
	workaround.
	* python/py-prettyprint.c (class dummy_python_frame): Remove.
	(print_children): Remove Python 2.4 workaround.
	* python/py-inferior.c (buffer_procs): Remove Python 2.4
	workaround.
	(CHARBUFFERPROC_NAME): Remove.
	* python/py-breakpoint.c (gdbpy_initialize_breakpoints): Remove
	Python 2.4 workaround.

This fixes a few minor style issues I found in gdb/python: some
unnecessary casts, the removal of an unnecessary local variable, and
one instance of incorrect formatting.

Tested by rebuilding and re-running gdb.python.

gdb/ChangeLog
2019-01-02  Tom Tromey  <tom@tromey.com>

	* python/py-inferior.c (gdbpy_initialize_inferior): Fix
	indentation.
	* python/py-frame.c (frapy_older): Remove cast.
	(frapy_newer): Likewise.
	* python/py-breakpoint.c (local_setattro): Remove cast.
	* python/py-arch.c (archpy_name): Remove local variable.
	* python/py-type.c (gdbpy_lookup_type): Remove cast.