| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Remove FIELD_ENUMVAL, replace its uses with field::loc_enumval.
Change-Id: Id4861cee91a8bb583a9836f1aa5da0a320fbf4d9
|
|
Remove FIELD_BITPOD, replace its uses with field::loc_bitpos.
Change-Id: Idb99297e0170661254276c206383a7e9bf1a935a
|
|
Remove FIELD_LOC_KIND, replace its uses with field::loc_kind or
call_site_target::loc_kind.
Change-Id: I0368d8c3ea269d491bb215aa70e32edbdf55f389
|
|
This adds a new Python function, gdb.Architecture.integer_type, which
can be used to look up an integer type of a given size and
signed-ness. This is useful to avoid dependency on debuginfo when a
particular integer type would be useful.
v2 moves this to be a method on gdb.Architecture and addresses other
review comments.
|
|
I noticed that the only caller of ada_value_print_inner is
valprint.c:do_val_print (via ada_language::value_print_inner), meaning
that the try/catch logic in this function is redundant. This patch
removes the wrapper function.
Regression tested on x86-64 Fedora 34.
|
|
Today I re-learned that resolve_dynamic_type can return a type for
which is_dynamic_type returns true. This can happen for an array
whose elements have dynamic type -- the array is reported as dynamic,
but resolving the elements would be incorrect, because each element
might have a different type after resolution.
You can see the special case in resolve_dynamic_array_or_string:
if (ary_dim != NULL && ary_dim->code () == TYPE_CODE_ARRAY)
...
else
...
I looked into having the TYPE_CODE_ARRAY case in
is_dynamic_type_internal follow this same logic, but that breaks down
on the gdb.fortran/dynamic-ptype-whatis.exp test case. In particular
this code in fortran_undetermined::evaluate:
value *callee = std::get<0> (m_storage)->evaluate (nullptr, exp, noside);
if (noside == EVAL_AVOID_SIDE_EFFECTS
&& is_dynamic_type (value_type (callee)))
callee = std::get<0> (m_storage)->evaluate (nullptr, exp, EVAL_NORMAL);
... relies on is_dynamic_type returning true for such an array.
I wasn't really sure of the best way to fix this, so in the meantime I
wrote this patch, which documents the oddity so that I might have a
chance of remembering this in the future.
|
|
The disassembly tests in "maint selftest" will fail on x86-linux.
This happens because opcodes rejects an attempt to disassemble for an
arch with a 64-bit address size when bfd_vma is 32-bit.
This patch avoids this problem by avoiding the test in this case. I
chose to do it this way because this seems to be the only situation
where opcodes checks the size of bfd_vma.
For v2 of this patch, I've also updated memory_error_test to do the
same thing. This is needed due to the "improve error reporting from
the disassembler" patch.
|
|
A build with --disable-unit-tests currently run into:
...
ld: maint.o: in function \
`maintenance_selftest_completer(cmd_list_element*, completion_tracker&,
char const*, char const*)':
src/gdb/maint.c:1183: undefined reference to \
`selftests::for_each_selftest(
gdb::function_view<
void (std::__cxx11::basic_string<char,std::char_traits<char>,
std::allocator<char> > const&)>)'
...
Fix this by guarding the call to selftests::for_each_selftest in
maintenance_selftest_completer with GDB_SELF_TEST, such that the "-verbose"
completion still works.
Rebuild on x86_64-linux and ran gdb.gdb/unittest.exp.
|
|
* gdb/doc/gdb.texinfo: (Data): Document '-memory-tag-violations'.
(Command Options): Update the example.
|
|
The previous patches added gdbserver and native debugging support
for OpenRISC targets. This patch documents that in the news.
|
|
Needed for single stepping in Linux, this adds the or1k implementation
of or1k_software_single_step. Most of the implementation is borrowed
from the bare metal single step code from or1k_single_step_through_delay
which has been extracted and shared in helper function
or1k_delay_slot_p.
|
|
This patch adds support for running gdb natively on OpenRISC linux.
Debugging support is provided via the linux PTRACE interface which is
mostly handled by GDB genric code. This patch provides the logic of how
to read and write the ptrace registers between linux and GDB.
Single stepping is privided in a separate patch.
|
|
|
|
The old comment was not properly updated from the RISC-V example used.
Update it to match OpenRISC.
|
|
This patch adds gdbserver support for OpenRISC. This has been used for
debugging the glibc port that in being worked on here:
https://github.com/openrisc/or1k-glibc/tree/or1k-port-2
Hence the comment about registers definitions being inline with glibc.
|
|
In debug messages, I think it would be more helpful to print ptid using
the simple "pid.lwp.tid" notation in infrun debug messages. I am
currently debugging some fork issues, and find the pid_to_str output not
so useful, as it doesn't tell which process a thread belongs to.
It currently shows up like this:
[infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=0, current thread [Thread 0x7ffff7d95740 (LWP 892942)] at 0x55555555521f
With the patch, it shows up like this:
[infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [894072.894077.0] at 0x5555555551d9
Change-Id: I130796d7dfb0d8e763b8358d8a6002701d80c4ea
|
|
After the previous commit, it is easy to add completion for selftest
names. Again, this is not particularly high value, but I rarely touched
completion, so it served as a simple example to get some practice.
Change the for_each_selftest_ftype parameter to gdb::function_view, so
that we can pass a lambda that captures things.
Change-Id: I87cac299ddca9ca7eb0ffab78342e850a98d954c
|
|
I saw the new -verbose switch to "maint selftests" and thought it would
be nice for it to use the option framework. For example, that makes
having completion easy. It's not that high value, given this is a
maintenance command, but I had never used the framework myself, so it
was a good way to practice.
This patch also adds the "maint set/show selftest verbose" setting. It
would be possible to use option framework without adding the setting,
but using the framework makes adding the option almost trivial, so I
thought why not.
Change-Id: I6687faa0713ff3da60b398253211777100094144
|
|
I noticed some files in the test-suite have GPLv2 notices.
Update these to GPLv3.
|
|
There's a common pattern to call add_basic_prefix_cmd and
add_show_prefix_cmd to add matching set and show commands. Add the
add_setshow_prefix_cmd function to factor that out and use it at a few
places.
Change-Id: I6e9e90a30e9efb7b255bf839cac27b85d7069cfd
|
|
I came across this when running test-case gdb.server/server-kill-python.exp
with a gdb configured without python:
...
builtin_spawn gdb -nw -nx -data-directory data-directory -iex set height 0 \
-iex set width 0 -quiet -iex set height 0 -iex set width 0 \
-ex source outputs/gdb.server/server-kill-python/file1.py^M
FAIL: gdb.server/server-kill-python.exp: ensure inferior is running
Executing on target: kill -9 28535 (timeout = 300)
builtin_spawn -ignore SIGHUP kill -9 28535^M
file1.py:1: Error in sourced command file:^M
Undefined command: "import". Try "help".^M
...
Fix this by testing for python support in the test-case.
Tested on aarch64-linux (with python support disabled) and x86_64-linux (with
python support enabled).
|
|
On openSUSE Leap 15.2 aarch64 I ran into:
...
clang-debug-names-debug.S:72: \
Error: junk at end of line, first unrecognized character is `#'
...
due to:
...
71 .Ldebug_names_start:
72 .short 5 # Header: version
...
Fix this by using the /* ... */ comment style instead:
...
$ sed -i 's% #\([^"]*\)%/*\1 */%' clang-debug-names.exp.tcl
...
Tested on aarch64-linux and x86_64-linux.
|
|
Consider a fortran routine where a string variable s is modified:
...
subroutine f(s)
character*(*) s
print *, s
s(1:3) = 'oof'
print *, s
end subroutine f
...
When compiling with optimization level -O1 and printing the type of
variable s we get:
...
$ gdb -q -batch outputs/gdb.opt/fortran-string/fortran-string \
-ex "b f" \
-ex run \
-ex "ptype s"
Breakpoint 1 at 0x4006f7: file fortran-string.f90, line 21.
Breakpoint 1, f (s=..., _s=_s@entry=3) at fortran-string.f90:21
21 subroutine f(s)
type = character*1
...
while with -O0 we have instead:
...
type = character (3)
...
The problem is that the type of s is:
...
<1><2d6>: Abbrev Number: 21 (DW_TAG_string_type)
<2d7> DW_AT_string_length: 0xbf (location list)
<2db> DW_AT_byte_size : 4
...
where the DW_AT_string_length is a location list, a case that is not handled
by attr_to_dynamic_prop.
Fix this by handling attr->form_is_section_offset () in attr_to_dynamic_prop.
Tested on x86_64-linux.
The test-case is based on gdb.opt/fortran-string.exp from
https://src.fedoraproject.org/rpms/gdb/raw/f32/f/gdb-archer-vla-tests.patch .
I've updated the copyrights to stretch to 2021.
[ I've tried to create a dwarf assembly test-case for this, but didn't
manage. ]
Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26910
|
|
GDB test fails while running the test case gdb.cp/koenig.exp using
clang compiler:
[...]
p foo (p_union)
No symbol "p_union" in current context.
(gdb) FAIL: gdb.cp/koenig.exp: p foo (p_union)
[...]
In the testcase, "p_union" is an unused/uninitialized variable of
anonymous union type. Clang does not emit symbol for unused anonymous
union/struct variables at any optimization level. Since the compiler
itself is not emitting the symbol for "p_union", debug info is also
not emitted when built with debug option. If the anonymous union is
initialized (or used), then clang emits the symbol "p_union" which
enables emitting debug info for "p_union".
[...]
p foo (p_union)
Cannot resolve function foo to any overloaded instance
(gdb) PASS: gdb.cp/koenig.exp: p foo (p_union)
[...]
|
|
A recent internal change pointed out that watchpoints were not working
on Windows when the inferior was multi-threaded. This happened
because the debug registers were only updated for certain threads --
in particular, those that were being resumed and that were not marked
as suspended. In the case of single-stepping, the need to update the
debug registers in other threads could also be "forgotten".
This patch changes windows-nat.c to mark all threads needing a debug
register update. This brings the code closer to what gdbserver does
(though, unfortunately, it still seems more complicated than needed).
|
|
On OBS I ran into this failure with test-case
gdb.debuginfod/fetch_src_and_symbols.exp:
...
Failed to listen for connections: Address already in use^M
[Thu Oct 21 11:48:49 2021] (559/559): started http server on IPv6 port=8000^M
...
FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: local_url: find port timeout
...
The test-case is trying to start debuginfod on a port to see if it's
available, and it handles either this message:
"started http server on IPv4 IPv6 port=$port"
meaning success, or:
"failed to bind to port"
meaning failure, in which case the debuginfod instance is killed, and we try
the next port.
The test-case only uses the v4 address 127.0.0.1, so fix this by:
- accepting "started http server on IPv4 port=$port"
- rejecting "started http server on IPv6 port=$port"
Tested on x86_64-linux.
|
|
When building on ARM (32-bits), we errors like this:
/home/smarchi/src/binutils-gdb/gdb/value.c: In function 'gdb::array_view<const unsigned char> value_contents_for_printing(value*)':
/home/smarchi/src/binutils-gdb/gdb/value.c:1252:35: error: narrowing conversion of 'length' from 'ULONGEST' {aka 'long long unsigned int'} to 'size_t' {aka 'unsigned int'} [-Werror=narrowing]
1252 | return {value->contents.get (), length};
| ^~~~~~
Fix that by using gdb::make_array_view, which does the appropriate
conversion.
Change-Id: I7d6f2e75d7440d248b8fb18f8272ee92954b404d
|
|
In the docs about print inferior-events we read:
...
By default, these messages will not be printed.
...
That used to be the case, but is no longer so since commit f67c0c91715 "Enable
'set print inferior-events' and improve detach/fork/kill/exit messages".
Fix this by updating the docs.
|
|
The bug fixed by this [1] patch was caused by an out-of-bounds access to
a value's content. The code gets the value's content (just a pointer)
and then indexes it with a non-sensical index.
This made me think of changing functions that return value contents to
return array_views instead of a plain pointer. This has the advantage
that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view
are checked, making bugs more apparent / easier to find.
This patch changes the return types of these functions, and updates
callers to call .data() on the result, meaning it's not changing
anything in practice. Additional work will be needed (which can be done
little by little) to make callers propagate the use of array_view and
reap the benefits.
[1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html
Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3
|
|
With test-case gdb.mi/mi-var-cp.exp I run into this duplicate:
...
PASS: gdb.mi/mi-var-cp.exp: run to mi-var-cp.cc:104 (set breakpoint)
PASS: gdb.mi/mi-var-cp.exp: create varobj for s
PASS: gdb.mi/mi-var-cp.exp: create varobj for s
DUPLICATE: gdb.mi/mi-var-cp.exp: create varobj for s
...
This is due to a duplicate test name here:
...
$ cat -n gdb/testsuite/gdb.mi/mi-var-cp.cc
...
100 int reference_to_struct ()
101 {
102 /*: BEGIN: reference_to_struct :*/
103 S s = {7, 8};
104 S& r = s;
105 /*:
106 mi_create_varobj S s "create varobj for s"
107 mi_create_varobj R r "create varobj for s"
...
Fix this by using "create varobj for r" instead.
Tested on x86_64-linux.
|
|
This adds some missing code to the 'uninstall' targets in gdb and
gdbserver. It also changes gdb's uninstall target so that it no
longer tries to remove any man page -- this is already done (and more
correctly) by doc/Makefile.in.
I tested this with 'make install' followed by 'make uninstall', then
examining the install tree for regular files. Only the 'dir' file
remains, but this appears to just be how 'install-info' is intended to
work.
|
|
On openSUSE Tumbleweed with glibc-debuginfo installed I get:
...
(gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print
where^M
#0 print_philosopher (n=3, left=33 '!', right=33 '!') at linux-dp.c:105^M
#1 0x0000000000401628 in philosopher (data=0x40537c) at linux-dp.c:148^M
#2 0x00007ffff7d56b37 in start_thread (arg=<optimized out>) \
at pthread_create.c:435^M
#3 0x00007ffff7ddb640 in clone3 () \
at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81^M
(gdb) PASS: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit
...
while without debuginfo installed I get instead:
...
(gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print
where^M
#0 print_philosopher (n=3, left=33 '!', right=33 '!') at linux-dp.c:105^M
#1 0x0000000000401628 in philosopher (data=0x40537c) at linux-dp.c:148^M
#2 0x00007ffff7d56b37 in start_thread () from /lib64/libc.so.6^M
#3 0x00007ffff7ddb640 in clone3 () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit
...
The problem is that the regexp used:
...
"\(from .*libpthread\|at pthread_create\|in pthread_create\)"
...
expects the 'from' part to match libpthread, but in glibc 2.34 libpthread has
been merged into libc.
Fix this by updating the regexp.
Tested on x86_64-linux.
|
|
Since commit e36788d1354 "[gdb/testsuite] Fix handling of nr_args < 3 in
mi_gdb_test" we run into:
...
PASS: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: mi runto main
Expecting: ^(-break-insert -f pendfunc1[^M
]+)?((&.*)*.*~"Breakpoint 2 at.*\\n".*=breakpoint-created,\
bkpt=\{number="2",type="breakpoint".*\}.*\n\^done[^M
]+[(]gdb[)] ^M
[ ]*)
-break-insert -f pendfunc1^M
^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",\
addr="0x00007ffff7bd559e",func="pendfunc1",\
file="gdb/testsuite/gdb.mi/pendshr1.c",\
fullname="gdb/testsuite/gdb.mi/pendshr1.c",line="21",thread-groups=["i1"],\
times="0",original-location="pendfunc1"}^M
(gdb) ^M
FAIL: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
-break-insert -f pendfunc1 (unexpected output)
...
The regexp expects a breakpoint-created event, but that's actually suppressed
by the command:
...
DEF_MI_CMD_MI_1 ("break-insert", mi_cmd_break_insert,
&mi_suppress_notification.breakpoint),
...
Fix this by updating the regexp.
Likewise for the following:
...
PASS: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
-break-insert -f pendfunc1
Expecting: ^(-break-enable count 1 2[^M
]+)?(=breakpoint-modified,\
bkpt=\{number="2",type="breakpoint",disp="dis",enabled="y".*\}.*\n\^done[^M
]+[(]gdb[)] ^M
[ ]*)
-break-enable count 1 2^M
^done^M
(gdb) ^M
FAIL: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
-break-enable count 1 2 (unexpected out\
put)
...
Tested on x86_64-linux.
|
|
In a future commit I'm going to be creating gdb.Membuf objects from a
new file within gdb/python/py*.c. Currently all gdb.Membuf objects
are created directly within infpy_read_memory (as a result of calling
gdb.Inferior.read_memory()).
Initially I split out the Membuf creation code into a new function,
and left the new function in gdb/python/py-inferior.c, however, it
felt a little random that the Membuf creation code should live with
the inferior handling code.
So, then I moved all of the Membuf related code out into a new file,
gdb/python/py-membuf.c, the interface is gdbpy_buffer_to_membuf, which
wraps an array of bytes into a gdb.Membuf object.
Most of the code is moved directly from py-inferior.c with only minor
tweaks to layout and replacing NULL with nullptr, hence, I've left the
copyright date on py-membuf.c as 2009-2021 to match py-inferior.c.
Currently, the only user of this code is still py-inferior.c, but in
later commits this will change.
There should be no user visible changes after this commit.
|
|
Add a new function to the Python API, gdb.architecture_names(). This
function returns a list containing all of the supported architecture
names within the current build of GDB.
The values returned in this list are all of the possible values that
can be returned from gdb.Architecture.name().
|
|
The disassemble_info structure has four callbacks, we have three of
them as static member functions within gdb_disassembler, the fourth is
just a global static function.
However, this fourth callback, is still only used from the
disassemble_info struct, so there's no real reason for its special
handling.
This commit makes fprintf_disasm a static method within
gdb_disassembler.
There should be no user visible changes after this commit.
|
|
Commit 183be222907a ("gdb, gdbserver: make target_waitstatus safe")
broke the remote-sim.c build. In fact, it does some wrong changes,
result of a bad sed invocation.
Fix it by adjusting the code to the new target_waitstatus API.
Change-Id: I3236ff7ef7681fc29215f68be210ff4263760e91
|
|
I stumbled on a bug caused by the fact that a code path read
target_waitstatus::value::sig (expecting it to contain a gdb_signal
value) while target_waitstatus::kind was TARGET_WAITKIND_FORKED. This
meant that the active union field was in fact
target_waitstatus::value::related_pid, and contained a ptid. The read
signal value was therefore garbage, and that caused GDB to crash soon
after. Or, since that GDB was built with ubsan, this nice error
message:
/home/simark/src/binutils-gdb/gdb/linux-nat.c:1271:12: runtime error: load of value 2686365, which is not a valid value for type 'gdb_signal'
Despite being a large-ish change, I think it would be nice to make
target_waitstatus safe against that kind of bug. As already done
elsewhere (e.g. dynamic_prop), validate that the type of value read from
the union matches what is supposed to be the active field.
- Make the kind and value of target_waitstatus private.
- Make the kind initialized to TARGET_WAITKIND_IGNORE on
target_waitstatus construction. This is what most users appear to do
explicitly.
- Add setters, one for each kind. Each setter takes as a parameter the
data associated to that kind, if any. This makes it impossible to
forget to attach the associated data.
- Add getters, one for each associated data type. Each getter
validates that the data type fetched by the user matches the wait
status kind.
- Change "integer" to "exit_status", "related_pid" to "child_ptid",
just because that's more precise terminology.
- Fix all users.
That last point is semi-mechanical. There are a lot of obvious changes,
but some less obvious ones. For example, it's not possible to set the
kind at some point and the associated data later, as some users did.
But in any case, the intent of the code should not change in this patch.
This was tested on x86-64 Linux (unix, native-gdbserver and
native-extended-gdbserver boards). It was built-tested on x86-64
FreeBSD, NetBSD, MinGW and macOS. The rest of the changes to native
files was done as a best effort. If I forgot any place to update in
these files, it should be easy to fix (unless the change happens to
reveal an actual bug).
Change-Id: I0ae967df1ff6e28de78abbe3ac9b4b2ff4ad03b7
|
|
Just like my previoius patch for ARMv8.1 and v8.2 (49ecef2a7da2ee9df4),
this adds ARMv8.4 debug arch as being compatible for hw watchpoint
and breakpoints.
|
|
(aarch64_linux_get_debug_reg_capacity)
Since the two locations which check the debug arch are the same code currently, it is
a good idea to factor it out to a new function and just use that function from
aarch64_linux_get_debug_reg_capacity. This is also the first step to support
ARMv8.4 debug arch.
|
|
Update the expected pattern for two of the tests.
Matching pattern \" doesn't work. Use .* to match the \* pattern.
|
|
In commit 81e6b8eb208 "Make tui-winsource not use breakpoint_chain", a loop
body was transformed into a lambda function body:
...
- for (bp = breakpoint_chain;
- bp != NULL;
- bp = bp->next)
+ iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
...
and consequently:
- a continue was replaced by a return, and
- a final return was added.
Then in commit 240edef62f0 "gdb: remove iterate_over_breakpoints function", we
transformed back to a loop body:
...
- iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
+ for (breakpoint *bp : all_breakpoints ())
...
but without reverting the changes that introduced the two returns.
Consequently, breakpoints no longer show up in the tui source window.
Fix this by reverting the changes that introduced the two returns.
Build on x86_64-linux, tested with all .exp test-cases that contain
tuiterm_env.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28483
|
|
The test expect the runto_main to stop at the first line of the function.
Depending on the optimization level, gdb may stop in the prolog or after
the prolog at the first line. To ensure the test stops at the first line
of main, have it explicitly stop at a break point on the first line of the
function.
On PowerPC, the test passes when compiled with no optimization but fails
with all levels of optimization due to gdb stopping in the prolog.
|
|
The "add accessors for field (and call site) location" patch caused a
gdb crash when running the internal AdaCore testsuite. This turned
out to be a latent bug in ada-lang.c.
The immediate cause of the bug is that find_struct_field
unconditionally uses TYPE_FIELD_BITPOS. This causes an assert for a
dynamic type.
This patch fixes the problem by doing two things. First, it changes
find_struct_field to use a dummy value for the field offset in the
situation where the offset is not actually needed by the caller. This
works because the offset isn't used in any other way -- only as a
result.
Second, this patch assures that calls to find_struct_field use a
resolved type when the offset is needed. For
value_tag_from_contents_and_address, this is done by resolving the
type explicitly. In ada_value_struct_elt, this is done by passing
nullptr for the out parameters when they are not needed (the second
call in this function already uses a resolved type).
Note that, while we believe the parent field probably can't occur at a
variable offset, the patch still updates this code path, just in case.
I've updated an existing test case to reproduce the crash.
I'm checking this in.
|
|
This changes print_one_catch_syscall to use std::string, removing a
bit of manual memory management.
|
|
This changes struct breakpoint to use unique_xmalloc_ptr in a couple
of spots, removing a bit of manual memory management.
|
|
This changes struct bp_location to use a unique_xmalloc_ptr, 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 changes struct exec_catchpoint to use a unique_xmalloc_ptr,
removing a bit of manual memory management.
|
|
This changes struct solib_catchpoint to use a unique_xmalloc_ptr,
removing a bit of manual memory management.
|
