| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This changes skip_hw_watchpoint_tests to invert the sense, and renames
it to allow_hw_watchpoint_tests.
|
|
This changes skip_gdbserver_tests to invert the sense, and renames it
to allow_gdbserver_tests.
|
|
This changes skip_cplus_tests to invert the sense, and renames it to
allow_cplus_tests. This one also converts skip_stl_tests to
allow_stl_tests, as that was convenient to do at the same time.
|
|
This changes skip_btrace_tests to invert the sense, and renames it to
allow_btrace_tests.
|
|
This changes various tests to use "require" for the Python feature.
|
|
mi_skip_python_tests was necessary because skip_python_tests used the
running gdb, and so needed to know what prompt to expect. Now that
skip_python_tests has been rewritten, mi_skip_python_tests is no
longer needed.
|
|
This changes some tests to use "require !skip_gdbserver_tests".
|
|
This changes some tests to use "require can_spawn_for_attach".
|
|
This changes some tests to use "require !use_gdb_stub".
|
|
This changes some tests to use "require support_displaced_stepping".
|
|
This changes some tests to use "require !skip_btrace_tests".
|
|
This changes some tests to use "require !skip_shlib_tests".
|
|
This changes some tests to use "require !skip_cplus_tests".
|
|
This changes some tests to use "require supports_process_record".
|
|
On x86_64-linux, I run into:
...
(gdb) python hbp1 = gdb.Breakpoint("add", type=gdb.BP_HARDWARE_BREAKPOINT)^M
Hardware assisted breakpoint 2 at 0x40072e: add. (7 locations)^M
(gdb) FAIL: gdb.python/py-breakpoint.exp: test_hardware_breakpoints: \
Set hardware breakpoint
...
due to libstdc++ debug info:
...
$ gdb -q -batch outputs/gdb.python/py-breakpoint/py-breakpoint \
-ex start \
-ex "b add" \
-ex "info break"
Temporary breakpoint 1 at 0x40076a: file py-breakpoint.c, line 50.
Temporary breakpoint 1, main (argc=1, argv=$hex) at py-breakpoint.c:50
50 int foo = 5;
Breakpoint 2 at 0x40072e: add. (7 locations)
Num Type Disp Enb Address What
2 breakpoint keep y <MULTIPLE>
2.1 y 0x000000000040072e in add(int) at \
py-breakpoint.c:39
2.2 y 0x00007ffff7b131de in \
(anonymous namespace)::fast_float::bigint::add at \
../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h:1815
...
2.7 y 0x00007ffff7b137e4 in \
(anonymous namespace)::fast_float::bigint::add at \
../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h:1815
...
Fix this by using qualified=True.
Tested on x86_64-linux.
PR testsuite/29910
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29910
|
|
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.
|
|
[ Partial resubmission of an earlier submission by Andrew (
https://sourceware.org/pipermail/gdb-patches/2012-September/096347.html ), so
listing him as co-author. ]
With x86_64-linux and target board unix/-m32, we have:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
^M
Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M
23 throw new int (e);^M
(gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \
check FinishBreakpoint in catch()
...
The following scenario happens:
- set breakpoint in throw_exception_1, a function that throws an exception
- continue
- hit breakpoint, with call stack main.c:38 -> throw_exception_1
- set a finish breakpoint
- continue
- hit the breakpoint again, with call stack main.c:48 -> throw_exception
-> throw_exception_1
Due to the exception, the function call did not properly terminate, and the
finish breakpoint didn't trigger. This is expected behaviour.
However, the intention is that gdb detects this situation at the next stop
and calls the out_of_scope callback, which would result here in this test-case
in a rather confusing "exception did not finish" message. So the problem is
that this message doesn't show up, in other words, the out_of_scope callback
is not called.
[ Note that the fact that the situation is detected only at the next stop
(wherever that happens to be) could be improved upon, and the earlier
submission did that by setting a longjmp breakpoint. But I'm considering this
problem out-of-scope for this patch. ]
Note that the message does show up later, at thread exit:
...
[Inferior 1 (process 20046) exited with code 0236]^M
exception did not finish ...^M
...
The decision on whether to call the out_of_scope call back is taken in
bpfinishpy_detect_out_scope_cb, and the interesting bit is here:
...
if (b->pspace == current_inferior ()->pspace
&& (!target_has_registers ()
|| frame_find_by_id (b->frame_id) == NULL))
bpfinishpy_out_of_scope (finish_bp);
...
In the case of the thread exit, the callback triggers because
target_has_registers () == 0.
So why doesn't the callback trigger in the case of the breakpoint?
Well, the b->frame_id is the frame_id of the frame of main (the frame
in which the finish breakpoint is supposed to trigger), so AFAIU
frame_find_by_id (b->frame_id) == NULL will only be true once we've
left main, at which point I guess we don't stop till thread exit.
Fix this by saving the frame in which the finish breakpoint was created, and
using frame_find_by_id () == NULL on that frame instead, such that we have:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
^M
Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M
23 throw new int (e);^M
exception did not finish ...^M
(gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \
check FinishBreakpoint in catch()
...
Still, the test-case is failing because it's setup to match the behaviour that
we get on x86_64-linux with target board unix/-m64:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
stopped at ExceptionFinishBreakpoint^M
(gdb) PASS: gdb.python/py-finish-breakpoint2.exp: \
check FinishBreakpoint in catch()
...
So what happens here? Again, due to the exception, the function call did not
properly terminate, but the finish breakpoint still triggers. This is somewhat
unexpected. This happens because it just so happens to be that the frame
return address at which the breakpoint is set, is also the first instruction
after the exception has been handled. This is a know problem, filed as
PR29909, so KFAIL it, and modify the test-case to expect the out_of_scope
callback.
Also add a breakpoint after setting the finish breakpoint but before throwing
the exception, to check that we don't call the out_of_scope callback too early.
Tested on x86_64-linux, with target boards unix/-m32.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
PR python/27247
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27247
|
|
When the source program contains a goto label, it turns out it's
actually pretty hard for a user to find out more about that label.
For example:
(gdb) p some_label
No symbol "some_label" in current context.
(gdb) disassemble some_label
No symbol "some_label" in current context.
(gdb) x/10i some_label
No symbol "some_label" in current context.
(gdb) break some_label
Breakpoint 2 at 0x401135: file /tmp/py-label-symbol-value.c, line 35.
In all cases, some_label is a goto label within the current frame.
Only placing a breakpoint on the label worked.
This all seems a little strange to me, it feels like asking about a
goto label would not be an unreasonable thing for a user to do.
This commit doesn't fix any of the above issues, I mention them just
to provide a little context for why the following issue has probably
not been seen before.
It turns out there is one way a user can access the symbol for a goto
label, through the Python API:
python frame = gdb.selected_frame()
python frame_pc = frame.pc()
python block = gdb.current_progspace().block_for_pc(frame_pc)
python symbol,_ = gdb.lookup_symbol('some_label', block, gdb.SYMBOL_LABEL_DOMAIN)
python print(str(symbol.value()))
../../src/gdb/findvar.c:204: internal-error: store_typed_address: Assertion `type->is_pointer_or_reference ()' failed.
The problem is that label symbols are created using the
builtin_core_addr type, which is a pure integer type.
When GDB tries to fetch the value of a label symbol then we end up in
findvar.c, in the function language_defn::read_var_value, in the
LOC_LABEL case. From here store_typed_address is called to store the
address of the label into a value object with builtin_core_addr type.
The problem is that store_typed_address requires that the destination
type be a pointer or reference, which the builtin_core_addr type is
not.
Now it's not clear what type a goto label address should have, but
GCC has an extension that allows users to take the address of a goto
label (using &&), in that case the result is of type 'void *'.
I propose that when we convert the CORE_ADDR value to a GDB value
object, we use builtin_func_ptr type instead of builtin_core_addr,
this means the result will be of type 'void (*) ()'. The benefit of
this approach is that when gdbarch_address_to_pointer is called the
target type will be correctly identified as a pointer to code, which
should mean any architecture specific adjustments are done correctly.
We can then cast the new value to 'void *' type with a call to
value_cast_pointer, this should not change the values bit
representation, but will just update the type.
After this asking for the value of a label symbol works just fine:
(gdb) python print(str(symbol.value()))
0x401135 <main+35>
And the type is maybe what we'd expect:
(gdb) python print(str(symbol.value().type))
void *
|
|
This commit adds a test that creates a Python command that redefines
itself during its execution. This is to test use-after-free in
execute_command ().
This test needs run with ASan enabled in order to fail when it
should.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This commit changes the target_stack class from using a C style array
of 'target_ops *' to using a C++ std::array<target_ops_ref, ...>. The
benefit of this change is that some of the reference counting of
target_ops objects is now done automatically.
This commit fixes a crash in gdb.python/py-inferior.exp where GDB
crashes at exit, leaving a core file behind.
The crash occurs in connpy_connection_dealloc, and is actually
triggered by this assert:
gdb_assert (conn_obj->target == nullptr);
Now a little aside...
... the assert is never actually printed, instead GDB crashes due
to calling a pure virtual function. The backtrace at the point of
crash looks like this:
#7 0x00007fef7e2cf747 in std::terminate() () from /lib64/libstdc++.so.6
#8 0x00007fef7e2d0515 in __cxa_pure_virtual () from /lib64/libstdc++.so.6
#9 0x0000000000de334d in target_stack::find_beneath (this=0x4934d78, t=0x2bda270 <the_dummy_target>) at ../../s>
#10 0x0000000000df4380 in inferior::find_target_beneath (this=0x4934b50, t=0x2bda270 <the_dummy_target>) at ../.>
#11 0x0000000000de2381 in target_ops::beneath (this=0x2bda270 <the_dummy_target>) at ../../src/gdb/target.c:3047
#12 0x0000000000de68aa in target_ops::supports_terminal_ours (this=0x2bda270 <the_dummy_target>) at ../../src/gd>
#13 0x0000000000dde6b9 in target_supports_terminal_ours () at ../../src/gdb/target.c:1112
#14 0x0000000000ee55f1 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_li>
Notice in frame #12 we called target_ops::supports_terminal_ours,
however, this is the_dummy_target, which is of type dummy_target,
and so we should have called dummy_target::supports_terminal_ours.
I believe the reason we ended up in the wrong implementation of
supports_terminal_ours (which is a virtual function) is because we
made the call during GDB's shut-down, and, I suspect, the vtables
were in a weird state.
Anyway, the point of this patch is not to fix GDB's ability to
print an assert during exit, but to address the root cause of the
assert. With that aside out of the way, we can return to the main
story...
Connections are represented in Python with gdb.TargetConnection
objects (or its sub-classes). The assert in question confirms that
when a gdb.TargetConnection is deallocated, the underlying GDB
connection has itself been removed from GDB. If this is not true then
we risk creating multiple different gdb.TargetConnection objects for
the same connection, which would be bad.
To ensure that we have one gdb.TargetConnection object for each
connection, the all_connection_objects map exists, this maps the
process_stratum_target object (the connection) to the
gdb.TargetConnection object that represents the connection.
When a connection is removed in GDB the connection_removed observer
fires, which we catch with connpy_connection_removed, this function
then sets conn_obj->target to nullptr, and removes the corresponding
entry from the all_connection_objects map.
The first issue here is that connpy_connection_dealloc is being called
as part of GDB's exit code, which is run after the Python interpreter
has been shut down. The connpy_connection_dealloc function is used to
deallocate the gdb.TargetConnection Python object. Surely it is
wrong for us to be deallocating Python objects after the interpreter
has been shut down.
The reason why connpy_connection_dealloc is called during GDB's exit
is that the global all_connection_objects map is still holding a
reference to the gdb.TargetConnection object. When the map is
destroyed during GDB's exit, the gdb.TargetConnection objects within
the map can finally be deallocated.
The reason why all_connection_objects has contents when GDB exits, and
the reason the assert fires, is that, when GDB exits, there are still
some connections that have not yet been removed from GDB, that is,
they have a non-zero reference count.
If we take a look at quit_force (top.c) you can see that, for each
inferior, we call pop_all_targets before we (later in the function)
call do_final_cleanups. It is the do_final_cleanups call that is
responsible for shutting down the Python interpreter. The
pop_all_targets calls should, in theory, cause all the connections to
be removed from GDB.
That this isn't working indicates that some targets have a non-zero
reference count even after this final pop_all_targets call, and
indeed, when I debug GDB, that is what I see.
I tracked the problem down to delete_inferior where we do some house
keeping, and then delete the inferior object, which calls
inferior::~inferior.
In neither delete_inferior or inferior::~inferior do we call
pop_all_targets, and it is this missing call that means we leak some
references to the target_ops objects on the inferior's target_stack.
In this commit I will provide a partial fix for the problem. I say
partial fix, but this will actually be enough to resolve the crash.
In a later commit I will provide the final part of the fix.
As mentioned at the start of the commit message, this commit changes
the m_stack in target_stack to hold target_ops_ref objects. This
means that when inferior::~inferior is called, and m_stack is
released, we automatically decrement the target_ops reference count.
With this change in place we no longer leak any references, and now,
in quit_force the final pop_all_targets calls will release the final
references. This means that the targets will be correctly closed at
this point, which means the connections will be removed from GDB and
the Python objects deallocated before the Python interpreter shuts
down.
There's a slight oddity in target_stack::unpush, where we std::move
the reference out of m_stack like this:
auto ref = std::move (m_stack[stratum]);
the `ref' isn't used explicitly, but it serves to hold the
target_ops_ref until the end of the scope while allowing the m_stack
entry to be reset back to nullptr. The alternative would be to
directly set the m_stack entry to nullptr, like this:
m_stack[stratum] = nullptr;
The problem here is that when we set the m_stack entry to nullptr we
first decrement the target_ops reference count, and then set the array
entry to nullptr.
If the decrement means that the target_ops object reaches a zero
reference count then the target_ops object will be closed by calling
target_close. In target_close we ensure that the target being closed
is not in any inferiors target_stack.
As we decrement before clearing, then this check in target_close will
fail, and an assert will trigger.
By using std::move to move the reference out of m_stack, this clears
the m_stack entry, meaning the inferior no longer contains the
target_ops in its target_stack. Now when the REF object goes out of
scope and the reference count is decremented, target_close can run
successfully.
I've made use of the Python connection_removed listener API to add a
test for this issue. The test installs a listener and then causes
delete_inferior to be called, we can then see that the connection is
then correctly removed (because the listener triggers).
|
|
On s390x-linux, I run into:
...
(gdb) disassemble test^M
Dump of assembler code for function test:^M
0x0000000001000638 <+0>: stg %r11,88(%r15)^M
0x000000000100063e <+6>: lgr %r11,%r15^M
0x0000000001000642 <+10>: nop 0^M
=> 0x0000000001000646 <+14>: nop 0^M
0x000000000100064a <+18>: nop 0^M
0x000000000100064e <+22>: lhi %r1,0^M
0x0000000001000652 <+26>: lgfr %r1,%r1^M
0x0000000001000656 <+30>: lgr %r2,%r1^M
0x000000000100065a <+34>: lg %r11,88(%r11)^M
0x0000000001000660 <+40>: br %r14^M
End of assembler dump.^M
(gdb) FAIL: gdb.python/py-disasm.exp: global_disassembler=: disassemble test
...
The problem is that the test-case expects "nop" but on s390x we have instead
"nop\t0".
Fix this by allowing the insn.
Tested on s390x-linux and x86_64-linux.
|
|
I noticed that when running these two tests in sequence:
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/arrayptr.exp ...
ERROR: GDB process no longer exists
ERROR: Couldn't run foo-all
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/assign_1.exp ...
The results in gdb.sum are:
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/arrayptr.exp ...
PASS: gdb.ada/arrayptr.exp: scenario=all: compilation foo.adb
ERROR: GDB process no longer exists
UNRESOLVED: gdb.ada/arrayptr.exp: scenario=all: gdb_breakpoint: set breakpoint at foo.adb:40 (eof)
ERROR: Couldn't run foo-all
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/assign_1.exp ...
UNRESOLVED: gdb.ada/assign_1.exp: changing the language to ada
PASS: gdb.ada/assign_1.exp: set convenience variable $xxx to 1
The UNRESOLVED for arrayptr.exp is fine, as GDB crashes in that test,
while trying to run to main. However, the UNRESOLVED in assign_1.exp
doesn't make sense, GDB behaves as expected in that test:
(gdb) set lang ada^M
(gdb) UNRESOLVED: gdb.ada/assign_1.exp: changing the language to ada
print $xxx := 1^M
$1 = 1^M
(gdb) PASS: gdb.ada/assign_1.exp: set convenience variable $xxx to 1
The problem is that arrayptr.exp calls perror when failing to run to
main, then returns. perror makes it so that the next test (as in
pass/fail) will be recorded as UNRESOLVED. However, here, the next test
(as in pass/fail) is in the next test (as in .exp). Hence the spurious
UNRESOLVED in assign_1.exp.
These perror when failing to run to X are not really useful, especially
since runto records a FAIL on error, by default. Remove all the
perrors on runto failure I could find.
When there wasn't one already, add a return statement when failing to
run, to avoid running the test of the test unnecessarily.
I thought of adding a check ran between test (in gdb_finish
probably) where we would emit a warning if errcnt > 0, meaning a test
quit and left a perror "active". However, reading that variable would
poke into the DejaGNU internals, not sure it's a good idea.
Change-Id: I2203df6d06e199540b36f56470d1c5f1dc988f7b
|
|
In the failure seen by Philippe here:
https://inbox.sourceware.org/gdb-patches/20221120173024.3647464-1-philippe.waroquiers@skynet.be/
gdb_unload crashed GDB, leaving no trace in the test results. Change it
to use gdb_test_multiple, so that it leaves an UNRESOLVED result. I
think it is good practice anyway.
Make it return the result of gdb_test_multiple directly, change
gdb.python/py-objfile.exp accordingly.
Change gdb.base/endian.exp as well to avoid duplicate test names.
Change gdb.base/gnu-debugdata.exp to avoid recording a test result,
since gdb_unload does it already now.
Change-Id: I59a1e4947691330797e6ce23277942547c437a48
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.python/
test script directory.
There should be no changes in what is tested after this commit.
|
|
Currently, FinishBreakpoints are set at the return address of a frame based on
the `finish' command, and are meant to be temporary breakpoints. However, they
are not being cleaned up after use, as reported in PR python/18655. This was
happening because the disposition of the breakpoint was not being set
correctly.
This commit fixes this issue by correctly setting the disposition in the
post-stop hook of the breakpoint. It also adds a test to ensure this feature
isn't regressed in the future.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18655
|
|
While working on another patch I noticed that, when run on an AArch64
target, the test gdb.python/py-send-packet.exp was failing:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/tmp/build/gdb/testsuite/outputs/gdb.python/py-send-packet/py-send-packet.py",
line 106, in run_auxv_send_packet_test
assert string == expected_result
AssertionError
Error while executing Python code.
(gdb) FAIL: gdb.python/py-send-packet.exp: call python run_auxv_send_packet_test function
The test uses 'maint packet ...' to send a packet to gdbserver, and
then captures the output in TCL. This output is then passed through
to a Python function, which performs some actions using the Python
API, and compares the results from the Python API to the results
captured in TCL from 'maint packet ...'.
The problem is that the output captured in TCL contains lots of things
like '\x000', when this is passed through to Python the '\x' causes
this to be treated as an escape code, which isn't what we want - we
want the actual string "\x000".
So, in the TCL part of the test we were expanding '\x' to '\\x', this
seemed to work fine for my testing on x86-64.
However, on AArch64 what I see is that the results from 'maint packet
...' contain a literal '\' character followed by a literal 'x'
character. When GDB prints this in the 'maint packet' output, GDB
escapes the '\' for us, thus we get '\\x' printed by 'maint packet'.
However, now our TCL test script kicks in and tries to "fix" the '\x',
this means we now have '\\\x', which isn't correct.
The problem is that in the TCL script we are too restrictive, we
expand '\x' to '\\x', but really, we should be expanding all '\'
characters, regardless of what follows them. This is what this patch
does.
After this the gdb.python/py-send-packet.exp test passes on AArch64
for me.
|
|
info_frame_command_core
I noticed this crash:
$ ./gdb --data-directory=data-directory -nx -q \
testsuite/outputs/gdb.python/pretty-print-call-by-hand/pretty-print-call-by-hand \
-x testsuite/outputs/gdb.python/pretty-print-call-by-hand/pretty-print-call-by-hand.py \
-ex "b g" -ex r
(gdb) info frame
Stack level 0, frame at 0x7fffffffdd80:
rip = 0x555555555160 in g
(/home/simark/src/binutils-gdb/gdb/testsuite/gdb.python/pretty-print-call-by-hand.c:41); saved rip = 0x5555555551a3
called by frame at 0x7fffffffdda0
source language c.
Arglist at 0x7fffffffdd70, args: mt=mytype is 0x555555556004 "hello world",
depth=10
Fatal signal: Segmentation fault
This is another case of frame_info being invalidated under a function's
feet. The stack trace when the frame_info get invalidated looks like:
... many frames to pretty print the arg, that eventually invalidate the frame_infos ...
#35 0x00005568d0a8ab24 in print_frame_arg (fp_opts=..., arg=0x7ffc3216bcb0) at /home/simark/src/binutils-gdb/gdb/stack.c:489
#36 0x00005568d0a8cc75 in print_frame_args (fp_opts=..., func=0x621000233210, frame=..., num=-1, stream=0x60b000000300)
at /home/simark/src/binutils-gdb/gdb/stack.c:898
#37 0x00005568d0a9536d in info_frame_command_core (fi=..., selected_frame_p=true) at /home/simark/src/binutils-gdb/gdb/stack.c:1682
print_frame_args knows that print_frame_arg can invalidate frame_info
objects, and therefore calls prepare_reinflate/reinflate. However,
info_frame_command_core has a separate frame_info_ptr instance (it is
passed by value / copy). So info_frame_command_core needs to know that
print_frame_args can invalidate frame_info objects, and therefore needs
to prepare_reinflate/reinflate as well. Add those calls, and enhance
the gdb.python/pretty-print-call-by-hand.exp test to test that command.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Change-Id: I9edaae06d62e97ffdb30938d364437737238a960
|
|
I did a gdb build without python support, and during testing ran into FAILs in
test-case gdb.python/tui-window-names.exp.
Fix this by adding the missing skip_python_test.
Tested on x86_64-linux.
|
|
Similarly to booleans and following the fix for PR python/29217 make
`gdb.parameter' accept `None' for `unlimited' with parameters of the
PARAM_UINTEGER, PARAM_INTEGER, and PARAM_ZUINTEGER_UNLIMITED types, as
`None' is already returned by parameters of the two former types, so
one might expect to be able to feed it back. It also makes it possible
to avoid the need to know what the internal integer representation is
for the special setting of `unlimited'.
Expand the testsuite accordingly.
Approved-By: Simon Marchi <simon.marchi@polymtl.ca>
|
|
Also verify PARAM_UINTEGER, PARAM_INTEGER, and PARAM_ZINTEGER parameter
types, in addition to PARAM_ZUINTEGER and PARAM_ZUINTEGER_UNLIMITED
already covered, and verify a choice of existing GDB parameters. Add
verification for reading parameters via `<parameter>.value' in addition
to `gdb.parameter('<parameter>')' as this covers different code paths.
Approved-By: Simon Marchi <simon.marchi@polymtl.ca>
|
|
With test-case gdb.python/py-breakpoint.exp I run into:
...
(gdb) ERROR: tcl error sourcing gdb.python/py-breakpoint.exp.
ERROR: can't read "skip_hw_watchpoint_tests_p": no such variable
while executing
"if {$skip_hw_watchpoint_tests_p} {
gdb_test_no_output "set can-use-hw-watchpoints 0" ""
}"
...
Fix this by adding the missing "global skip_hw_watchpoint_tests_p" in two
procs.
Tested on x86_64-linux.
|
|
The hardware watchpoint check has been updated in a couple of recent
patches. This patch updates the hardware watchpoint test in the remaining
gdb tests.
The issue is the PowerPC processors support hardware watchpoints with the
exception of Power 9. The hardware watchpoint support is disabled on
Power 9. The test skip_hw_watchpoint_tests must be used to correctly
determine if the PowerPC processor supports hardware watchpoints.
This patch fixes 6 test failures in test gdb.threads/watchpoint-fork.exp.
Test gdb.base/watch-vfork.exp runs with can-use-hw-watchpoints set to
true and false. When the test is run with can-use-hw-watchpoints set to
true, gdb just falls back to using software watchpoints. The
patch reduces the number of expected passes by 2 since because it now
only runs once with can-use-hw-watchpoints set to false.
Test gdb.mi/mi-watch.exp runs the test with argument hw and sw. If the
argument is hw and hardware watchpoints are not supported the test exits.
The number of expected passes is cut in half with the patch as it now only
runs the test using software breakpoints. Previously the pass to use
hardware watchpoints was not skipped and the test actually ran using
software watchpoints.
The following tests run the same with and without the patch. The tests
are supposed to execute the gdb command "set can-use-hw-watchpoints 0" if
the processor does not support hardware bwatchpoints. However the command
was not being executed and gdb was falling back to using software
watchpoints since the Power 9 watchpoint resource check fails. With the
patch, the tests now execute the command and the test runs using software
watchpoints as it did previously. The tests are:
gdb.base/commands.exp
gdb.base/cond-eval-mode.exp
gdb.base/display.exp
gdb.base/gdb11531.exp
gdb.base/recurse.exp
gdb.base/value-double-free.exp
gdb.base/watch-bitfields.exp
gdb.base/watch-cond-infcall.exp
gdb.base/watch-cond.exp
gdb.base/watchpoint-solib.exp
gdb.base/watchpoints.exp
The following two tests are not supported on the Power 9 system used to
test the changes. The patch does not change the tests results for these
tests:
gdb.python/py-breakpoint.exp
gdb.mi/mi-watch-nonstop.exp
|
|
The python black formatter was complaining about formatting on the
script gdb.python/pretty-print-call-by-hand.py. This commit changed
the offending lines to make the formatter happy.
|
|
Currently, despite having a smart pointer for frame_infos, GDB may
attempt to use an invalidated frame_info_ptr, which would cause internal
errors to happen. One such example has been documented as PR
python/28856, that happened when printing frame arguments calls an
inferior function.
To avoid failures, the smart wrapper was changed to also cache the frame
id, so the pointer can be reinflated later. For this to work, the
frame-id stuff had to be moved to their own .h file, which is included
by frame-info.h.
Frame_id caching is done explicitly using the prepare_reinflate method.
Caching is done manually so that only the pointers that need to be saved
will be, and reinflating has to be done manually using the reinflate
method because the get method and the -> operator must not change
the internals of the class. Finally, attempting to reinflate when the
pointer is being invalidated causes the following assertion errors:
check_ptrace_stopped_lwp_gone: assertion `lp->stopped` failed.
get_frame_pc: Assertion `frame->next != NULL` failed.
As for performance concerns, my personal testing with `time make
chec-perf GDB_PERFTEST_MODE=run` showed an actual reduction of around
10% of time running.
This commit also adds a testcase that exercises the python/28856 bug with
7 different triggers, run, continue, step, backtrace, finish, up and down.
Some of them can seem to be testing the same thing twice, but since this
test relies on stale pointers, there is always a chance that GDB got lucky
when testing, so better to test extra.
Regression tested on x86_64, using both gcc and clang.
Approved-by: Tom Tomey <tom@tromey.com>
|
|
Within the testsuite, use the keyword 'end' to terminate blocks of
Python code being sent to GDB, rather than sending \004. I could only
find three instances of this, all in tests that I originally wrote. I
have no memory of there being any special reason why I used \004
instead of 'end' - I assume I copied this from somewhere else that has
since changed.
Non of the tests being changed here are specifically about whether
\004 can be used to terminate a Python block, so I think switching to
the more standard 'end' keyword is the right choice.
|
|
Fix some DUPLICATEs that we run into with target board
remote-gdbserver-on-localhost, by using test_with_prefix.
Tested on x86_64-linux, with native and target board
remote-gdbserver-on-localhost.
|
|
I noticed that, from Python, I could register a new TUI window that
had whitespace in its name, like this:
gdb.register_window_type('my window', MyWindowType)
however, it is not possible to then use this window in a new TUI
layout, e.g.:
(gdb) tui new-layout foo my window 1 cmd 1
Unknown window "my"
(gdb) tui new-layout foo "my window" 1 cmd 1
Unknown window ""my"
(gdb) tui new-layout foo my\ window 1 cmd 1
Unknown window "my\"
GDB clearly uses the whitespace to split the incoming command line.
I could fix this by trying to add a mechanism by which we can use
whitespace within a window name, but it seems like an easier solution
if we just forbid whitespace within a window name. Not only is this
easier, but I think this is probably the better solution, identifier
names with spaces in would mean we'd need to audit all the places a
window name could be printed and ensure that the use of a space didn't
make the output ambiguous.
So, having decided to disallow whitespace, I then thought about other
special characters. We currently accept anything as a window name,
and I wondered if this was a good idea.
My concerns were about how special characters used in a window name
might cause confusion, for example, we allow '$' in window names,
which is maybe fine now, but what if one day we wanted to allow
variable expansion when creating new layouts? Or what about starting
a window name with '-'? We already support a '-horizontal' option,
what if we want to add more in the future? Or use of the special
character '{' which has special meaning within a new layout?
In the end I figured it might make sense to place some restrictive
rules in place, and then relax the rules later if/when users complain,
we can consider each relaxation as its requested.
So, I propose that window names should match this regular expression:
[a-zA-Z][-_.a-zA-Z0-9]*
There is a chance that there is user code in the wild which will break
with the addition of this change, but hopefully adapting to the new
restrictions shouldn't be too difficult.
|
|
GDB overwrites Python's sys.stdout and sys.stderr, but does not
properly implement the 'flush' method -- it only ever will flush
stdout. This patch fixes the bug. I couldn't find a straightforward
way to write a test for this.
|
|
I noticed that gdbpy_parse_register_id would assert if passed a Python
object of a type it was not expecting. The included test case shows
this crash. This patch fixes the problem and also changes
gdbpy_parse_register_id to be more "Python-like" -- it always ensures
the Python error is set when it fails, and the callers now simply
propagate the existing exception.
|
|
Correctly report PARAM_ZUINTEGER_UNLIMITED rather than PARAM_ZUINTEGER
in testing a Python parameter of the PARAM_ZUINTEGER_UNLIMITED type.
|
|
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
|
|
After this commit:
commit 81384924cdcc9eb2676dd9084b76845d7d0e0759
Date: Tue Apr 5 11:06:16 2022 +0100
gdb: have gdb_disassemble_info carry 'this' in its stream pointer
The disassemble_info::stream field will no longer be a ui_file*. That
commit failed to update one location in py-disasm.c though.
While running some tests using the Python disassembler API, I
triggered a call to gdbpy_disassembler::print_address_func, and, as I
had compiled GDB with the undefined behaviour sanitizer, GDB crashed
as the code currently (incorrectly) casts the stream field to be a
ui_file*.
In this commit I fix this error.
In order to test this case I had to tweak the existing test case a
little. I also spotted some debug printf statements in py-disasm.py,
which I have removed.
|
|
This patch adds a test case to try to clear an internal python
breakpoint using the clear command.
This was suggested by Pedro during a code review of the following
commit.
commit a5c69b1e49bae4d0dcb20f324cebb310c63495c6
Date: Sun Apr 17 15:09:46 2022 +0800
gdb: fix using clear command to delete non-user breakpoints(PR cli/7161)
Tested on x86_64 openSUSE Tumbleweed.
|
|
Currently, Python code can use event registries to detect when gdb
loads a new objfile, and when gdb clears the objfile list. However,
there's no way to detect the removal of an objfile, say when the
inferior calls dlclose.
This patch adds a gdb.free_objfile event registry and arranges for an
event to be emitted in this case.
|
|
When I rebased and updated the print_options patch, I forgot to update
print_options to add the new 'nibbles' feature to the result. This
patch fixes the oversight. I'm checking this in.
|
|
This adds a 'summary' mode to Value.format_string and to
gdb.print_options. For the former, it lets Python code format values
using this mode. For the latter, it lets a printer potentially detect
if it is being called in a backtrace with 'set print frame-arguments'
set to 'scalars'.
I considered adding a new mode here to let a pretty-printer see
whether it was being called in a 'backtrace' context at all, but I'm
not sure if this is really desirable.
|
|
PR python/17291 asks for access to the current print options. While I
think this need is largely satisfied by the existence of
Value.format_string, it seemed to me that a bit more could be done.
First, while Value.format_string uses the user's settings, it does not
react to temporary settings such as "print/x". This patch changes
this.
Second, there is no good way to examine the current settings (in
particular the temporary ones in effect for just a single "print").
This patch adds this as well.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17291
|
|
Running 'black' on gdb fixed a couple of small issues. This patch is
the result.
|
|
PR python/27000 points out that gdb.block_for_pc will accept a Python
integer, but not a gdb.Value. This patch corrects this oversight.
I looked at all uses of GDB_PY_LLU_ARG and fixed these up to use
get_addr_from_python instead. I also looked at uses of GDB_PY_LL_ARG,
but those seemed relatively unlikely to be useful with a gdb.Value, so
I didn't change them. My thinking here is that a Value will typically
come from inferior memory, and something like a line number is not too
likely to be found this way.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27000
|
|
PR python/29217 points out that gdb.parameter will return bool values,
but gdb.set_parameter will not properly accept them. This patch fixes
the problem by adding a special case to set_parameter.
I looked at a fix involving rewriting set_parameter in C++. However,
this one is simpler.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29217
|
