This patch adds a progspace property to the gdb.Inferior type, which
allows getting the gdb.Progspace object associated to that inferior.
In conjunction with the following patch, this will allow scripts iterate
on objfiles associated with a particular inferior.
gdb/ChangeLog:
* python/py-inferior.c (infpy_get_progspace): New function.
(inferior_object_getset): Add progspace property.
* NEWS: Mention the new property.
gdb/doc/ChangeLog:
* python.texi (Inferiors In Python): Document
Inferior.progspace.
(Program Spaces In Python): Document that
gdb.current_progspace() is the same as
gdb.selected_inferior().progspace.
gdb/testsuite/ChangeLog:
* gdb.python/py-inferior.exp: Add tests for Inferior.progspace
and a few other Inferior properties when the Inferior is no
longer valid.
Printing a GDB Python object is notoriously not helpful:
>>> print(gdb.selected_inferior())
<gdb.Inferior object at 0x7fea59aed198>
>>> print(gdb.objfiles())
[<gdb.Objfile object at 0x7fea59b57c90>]
This makes printing debug traces more difficult than it should be. This
patch provides some repr() implementation for these two types (more to
come if people agree with the idea, but I want to test the water first).
Here's the same example as above, but with this patch:
>>> print(gdb.selected_inferior())
<gdb.Inferior num=1>
>>> print(gdb.objfiles())
[<gdb.Objfile filename=/home/emaisin/build/binutils-gdb-gcc-git/gdb/test>]
I implemented repr rather than str, because when printing a list (or
another container I suppose), Python calls the repr method of the
elements. This is useful when printing a list of inferiors or objfiles.
The print(gdb.objfiles()) above would not have worked if I had
implemented str.
I found this post useful to understand the difference between repr and
str:
https://stackoverflow.com/questions/1436703/difference-between-str-and-repr
gdb/ChangeLog:
* python/py-inferior.c (infpy_repr): New.
(inferior_object_type): Register infpy_repr.
* python/py-objfile.c (objfpy_repr): New.
(objfile_object_type): Register objfpy_repr.
gdb/testsuite/ChangeLog:
* gdb.python/py-inferior.exp: Test repr() of gdb.Inferior.
* gdb.python/py-objfile.exp: Test repr() of gdb.Objfile.
* gdb.python/py-symtab.exp: Update test printing an objfile.
gdb/doc/ChangeLog:
* python.texi (Basic Python): Mention the string representation
of GDB Python objects.
This patch adds tests for trying to use property or methods on a
gdb.Inferior object that represents an inferior that does not exist
anymore. We expect an exception to be thrown.
gdb/testsuite/ChangeLog:
* gdb.python/py-inferior.exp: Test using an invalid gdb.Inferior
object.
I noticed that the py-prettyprint.exp test names were not unique.
This patch fixes the problem via with_test_prefix.
gdb/testsuite/ChangeLog
2018-09-08 Tom Tromey <tom@tromey.com>
* gdb.python/py-prettyprint.exp: Use with_test_prefix.
PR python/16047 points out that, while the documentation says that the
to_string method is optional for a pretty-printer, the code disagrees
and throws an exception. This patch fixes the problem. varobj is
already ok here.
Tested on x86-64 Fedora 26.
gdb/ChangeLog
2018-09-08 Tom Tromey <tom@tromey.com>
PR python/16047:
* python/py-prettyprint.c (pretty_print_one_value): Check for
to_string method.
gdb/testsuite/ChangeLog
2018-09-08 Tom Tromey <tom@tromey.com>
PR python/16047:
* gdb.python/py-prettyprint.py (pp_int_typedef3): New class.
(register_pretty_printers): Register new printer.
* gdb.python/py-prettyprint.exp (run_lang_tests): Add int_type3
test.
* gdb.python/py-prettyprint.c (int_type3): New typedef.
(an_int_type3): New global.
Commit 6d52907e22 (MI: Print frame architecture when printing frames
on an MI channel) added frame's architecture to MI frame output. However
the frame architecture was not correctly printed in the output of
"-stack-list-frames" with frame filters enabled (via "-enable-frame-filters").
This was because with frame filters enabled, the actual frame printing is
done in "py_print_frame" rather than "print_frame". This issue is now fixed.
gdb/Changelog:
2018-08-27 Jan Vrany <jan.vrany@fit.cvut.cz>
* python/py-framefilter.c (py_print_frame): Print frame architecture
when printing on an MI output.
gdb/testsuite/Changelog:
2018-08-27 Jan Vrany <jan.vrany@fit.cvut.cz>
* gdb.python/py-framefilter-mi.exp: Update regexp to
check for "arch" field in frame output.
This fails for me on openSUSE leap 15.0:
...
FAIL: gdb.python/py-rbreak.exp: check number of returned breakpoints is 11
...
The rbreak "" command expects 11 breaks, but I see two extra for
__libc_csu_fini and __libc_csu_init:
...
Breakpoint 13 at 0x4005b0: file elf-init.c, line 106.^M
Breakpoint 14 at 0x400540: file elf-init.c, line 68.^M
...
This patch fixes the failing test by excluding functions starting with an
underscore.
Tested on x86_64-linux.
2018-08-04 Tom de Vries <tdevries@suse.de>
* gdb.python/py-rbreak.exp: Fix rbreak regexp.
Invoking -var-info-path-expression on a dynamic varobj lead either in wrong
(nonsense) result or to a segmentation fault in cplus_describe_child().
This was caused by the fact that varobj_get_path_expr() called
cplus_path_expr_of_child() ignoring the fact the parent of the variable
is dynamic. Then, cplus_describe_child() accessed the underlaying C type
members by index, causing (i) either wrong (nonsense) expression being
returned (since dynamic child may be completely arbibtrary value)
or (ii) segmentation fault (in case the index higher than number of
underlaying C type members.
This fixes the problem by checking whether a varobj is a child of a dynamic
varobj and, if so, reporting an error as described in documentation.
gdb/ChangeLog:
* varobj.c (varobj_get_path_expr_parent): Report an error if
parent is a dynamic varobj.
gdb/testsuite/Changelog:
* gdb.python/py-mi-var-info-path-expression.c: New file.
* gdb.python/py-mi-var-info-path-expression.py: New file.
* gdb.python/py-mi-var-info-path-expression.exp: New file.
This adds a "continue" response to the pager. If the user types "c"
in response to the pager prompt, pagination will be disabled for the
duration of one command -- but re-enabled afterward. This is handy if
you type a command that produces a lot of output, and you don't want
to baby-sit it by typing "return" each time the prompt comes up.
Tested by the buildbot.
gdb/ChangeLog
2018-06-05 Tom Tromey <tom@tromey.com>
PR cli/12326:
* NEWS: Add entry about pager.
* utils.c (pagination_disabled_for_command): New global.
(prompt_for_continue): Allow "c" response to prompt.
(reinitialize_more_filter): Clear
pagination_disabled_for_command.
(fputs_maybe_filtered): Check pagination_disabled_for_command.
gdb/doc/ChangeLog
2018-06-05 Tom Tromey <tom@tromey.com>
PR cli/12326:
* gdb.texinfo (Screen Size): Document "c" response to pagination
prompt.
gdb/testsuite/ChangeLog
2018-06-05 Tom Tromey <tom@tromey.com>
PR cli/12326:
* gdb.cp/static-print-quit.exp: Update.
* lib/gdb.exp (pagination_prompt): Update.
* gdb.base/page.exp: Use pagination_prompt. Add new tests.
* gdb.python/python.exp: Update.
It's long bothered me that setting a Python parameter from the CLI
will print the "set" help text by default. I think usually "set"
commands should be silent. And, while you can modify this behavior a
bit by providing a "get_set_string" method, if this method returns an
empty string, a blank line will be printed.
This patch removes the "help" behavior and changes the get_set_string
behavior to avoid printing a blank line. The code has a comment about
preserving API behavior, but I don't think this is truly important;
and in any case the workaround -- implementing get_set_string -- is
trivial.
Regression tested on x86-64 Fedora 26.
2018-04-26 Tom Tromey <tom@tromey.com>
* NEWS: Mention new "set" behavior.
* python/py-param.c (get_set_value): Don't print an empty string.
Don't call get_doc_string.
gdb/doc/ChangeLog
2018-04-26 Tom Tromey <tom@tromey.com>
* python.texi (Parameters In Python): Update get_set_string
documentation.
This adds a basic Python API for accessing convenience variables.
With this, convenience variables can be read and set from Python.
Although gdb supports convenience variables whose value changes at
each call, this is not exposed to Python; it could be, but I think
it's just as good to write a convenience function in this situation.
This is PR python/23080.
Tested on x86-64 Fedora 26.
2018-04-22 Tom Tromey <tom@tromey.com>
PR python/23080:
* NEWS: Update for new functions.
* python/py-value.c (gdbpy_set_convenience_variable)
(gdbpy_convenience_variable): New functions.
* python/python-internal.h (gdbpy_convenience_variable)
(gdbpy_set_convenience_variable): Declare.
* python/python.c (python_GdbMethods): Add convenience_variable,
set_convenience_variable.
doc/ChangeLog
2018-04-22 Tom Tromey <tom@tromey.com>
PR python/23080:
* python.texi (Basic Python): Document gdb.convenience_variable,
gdb.set_convenience_variable.
testsuite/ChangeLog
2018-04-22 Tom Tromey <tom@tromey.com>
PR python/23080:
* gdb.python/python.exp: Add convenience variable tests.
This changes the Python API so that breakpoint commands can be set by
writing to the "commands" attribute.
ChangeLog
2018-05-04 Tom Tromey <tom@tromey.com>
PR python/22731:
* NEWS: Mention that breakpoint commands are writable.
* python/py-breakpoint.c (bppy_set_commands): New function.
(breakpoint_object_getset) <"commands">: Use it.
doc/ChangeLog
2018-05-04 Tom Tromey <tom@tromey.com>
PR python/22731:
* python.texi (Breakpoints In Python): Mention that "commands" is
writable.
testsuite/ChangeLog
2018-05-04 Tom Tromey <tom@tromey.com>
PR python/22731:
* gdb.python/py-breakpoint.exp: Test setting breakpoint commands.
Pedro pointed out that a test in py-parameter.exp had an empty
message. This fixes it.
testsuite/ChangeLog
2018-05-02 Tom Tromey <tom@tromey.com>
* gdb.python/py-parameter.exp: Set test message.
PR python/20084 points out that the Python API doesn't handle the
var_zuinteger and var_zuinteger_unlimited parameter types.
This patch adds support for these types.
Regression tested on x86-64 Fedora 26.
ChangeLog
2018-05-02 Tom Tromey <tom@tromey.com>
PR python/20084:
* python/python.c (gdbpy_parameter_value): Handle var_zuinteger
and var_zuinteger_unlimited.
* python/py-param.c (struct parm_constant): Add PARAM_ZUINTEGER
and PARAM_ZUINTEGER_UNLIMITED.
(set_parameter_value): Handle var_zuinteger and
var_zuinteger_unlimited.
(add_setshow_generic): Likewise.
(parmpy_init): Likewise.
doc/ChangeLog
2018-05-02 Tom Tromey <tom@tromey.com>
PR python/20084:
* python.texi (Parameters In Python): Document PARAM_ZUINTEGER and
PARAM_ZUINTEGER_UNLIMITED.
testsuite/ChangeLog
2018-05-02 Tom Tromey <tom@tromey.com>
PR python/20084:
* gdb.python/py-parameter.exp: Add PARAM_ZUINTEGER and
PARAM_ZUINTEGER_UNLIMITED tests.
This adds an "alignof" attribute to gdb.Type in the Python API.
2018-04-30 Tom Tromey <tom@tromey.com>
* NEWS: Mention Type.align.
* python/py-type.c (typy_get_alignof): New function.
(type_object_getset): Add "alignof".
2018-04-30 Tom Tromey <tom@tromey.com>
* python.texi (Types In Python): Document Type.align.
2018-04-30 Tom Tromey <tom@tromey.com>
* gdb.python/py-type.exp: Check align attribute.
* gdb.python/py-type.c: New "aligncheck" global.
If a C-c comes while the Python code for a frame filter is running, it
will be turned into a Python KeyboardException. It seems good for
this to be treated like a GDB quit, so this patch changes
py-framefilter.c to notice this situation and call throw_quit in this
case.
gdb/ChangeLog
2018-03-26 Tom Tromey <tom@tromey.com>
* python/py-framefilter.c (throw_quit_or_print_exception): New
function.
(gdbpy_apply_frame_filter): Use it.
gdb/testsuite/ChangeLog
2018-03-26 Tom Tromey <tom@tromey.com>
* gdb.python/py-framefilter.exp: Add test for KeyboardInterrupt.
* gdb.python/py-framefilter.py (name_error): New global.
(ErrorInName.function): Use name_error.
When a frame filter elides some frames, they are still printed by
"bt", indented a few spaces. PR backtrace/15582 notes that it would
be nice for users if elided frames could simply be dropped. This
patch adds this capability.
gdb/ChangeLog
2018-03-26 Tom Tromey <tom@tromey.com>
PR backtrace/15582:
* stack.c (backtrace_command): Parse "hide" argument.
* python/py-framefilter.c (py_print_frame): Handle PRINT_HIDE.
* extension.h (enum frame_filter_flags) <PRINT_HIDE>: New
constant.
gdb/doc/ChangeLog
2018-03-26 Tom Tromey <tom@tromey.com>
PR backtrace/15582:
* gdb.texinfo (Backtrace): Mention "hide" argument.
gdb/testsuite/ChangeLog
2018-03-26 Tom Tromey <tom@tromey.com>
PR backtrace/15582:
* gdb.python/py-framefilter.exp: Add "bt hide" test.
PR python/16497 notes that using "bt" with a positive argument prints
the wrong number of frames when a frame filter is in use. Also, in this
case, the non-frame-filter path will print a message about "More stack
frames" when there are more; but this is not done in the frame-filter
case.
The first problem is that backtrace_command_1 passes the wrong value
to apply_ext_lang_frame_filter -- that function takes the final
frame's number as an argument, but backtrace_command_1 passes the
count, which is off by one.
The solution to the second problem is to have the C stack-printing
code stop at the correct number of frames and then print the message.
Tested using the buildbot.
ChangeLog
2018-02-26 Tom Tromey <tom@tromey.com>
PR python/16497:
* stack.c (backtrace_command_1): Set PRINT_MORE_FRAMES flag. Fix
off-by-one in py_end computation.
* python/py-framefilter.c (gdbpy_apply_frame_filter): Handle
PRINT_MORE_FRAMES.
* extension.h (enum frame_filter_flags) <PRINT_MORE_FRAMES>: New
constant.
2018-02-26 Tom Tromey <tom@tromey.com>
PR python/16497:
* gdb.python/py-framefilter.exp: Update test.
Make the MI variable object expression evaluation, with the
-var-evaluate-expression command, recursively call pretty printers, to
match the output of normal expression printing.
Consider the following code:
struct Foo { int val; };
struct Wrapper { Foo foo; };
int main() {
Wrapper w;
w.foo.val = 23;
}
and this pretty printer file:
import gdb.printing
class FooPrinter:
def __init__(self, val):
self.val = val
def to_string(self):
return "Foo" + str(self.val["val"])
class WrapperPrinter:
def __init__(self, val):
self.val = val
def to_string(self):
return self.val["foo"]
test_printer = gdb.printing.RegexpCollectionPrettyPrinter("test")
test_printer.add_printer('Foo', '^Foo$', FooPrinter)
test_printer.add_printer('Wrapper', '^Wrapper$', WrapperPrinter)
gdb.printing.register_pretty_printer(None, test_printer)
Setting a breakpoint at the end of the function, we call the following commands:
-enable-pretty-printing
^done
-var-create var_w @ w
^done,name="var_w",numchild="0",value="{val = 23}",type="Wrapper",dynamic="1",has_more="0"
-var-create var_w_foo @ w.foo
^done,name="var_w_foo",numchild="0",value="Foo23",type="Foo",dynamic="1",has_more="0"
-var-evaluate-expression var_w
^done,value="{val = 23}"
-var-evaluate-expression var_w_foo
^done,value="Foo23"
-data-evaluate-expression w
^done,value="Foo23"
-data-evaluate-expression w.foo
^done,value="Foo23"
So, in the -var-evaluate-expression var_w case, we print the "raw" value
of w.foo, while in the -data-evaluate-expression w case, we print the
pretty printed w.foo value. After this patch, all of the above print
"Foo23".
gdb/ChangeLog:
* varobj.c (varobj_formatted_print_options): Allow recursive
pretty printing if pretty printing is enabled.
gdb/testsuite/ChangeLog:
* gdb.python/py-prettyprint.c
(struct to_string_returns_value_inner,
struct to_string_returns_value_wrapper): New.
(main): Add tsrvw variable.
* gdb.python/py-prettyprint.py (ToStringReturnsValueInner,
ToStringReturnsValueWrapper): New classes.
(register_pretty_printers): Register new pretty-printers.
* gdb.python/py-prettyprint.exp (run_lang_tests): Test printing
recursive pretty printer.
* gdb.python/py-mi.exp: Likewise.
When creating a varobj with -var-create a user can create either fixed
varobj, or floating varobj.
A fixed varobj will always be evaluated within the thread/frame/block in
which the varobj was created, if that thread/frame/block is no longer
available then the varobj is considered out of scope.
A floating varobj will always be evaluated within the current
thread/frame/block.
Despite never using them GDB was storing the thread/frame/block into a
floating varobj, and the thread-id would then be displayed when GDB
reported on the state of the varobj, this could confuse a user into
thinking that the thread-id was relevant.
This commit prevents GDB storing the thread/frame/block onto floating
varobj, and updates the few tests where this impacts the results.
gdb/ChangeLog:
* varobj.c (varobj_create): Don't set valid_block when creating a
floating varobj.
gdb/testsuite/ChangeLog:
* gdb.python/py-mi.exp: Don't expect a thread-id for floating
varobj.
* gdb.mi/mi-var-create-rtti.exp: Likewise.
This patch adds the possibility to pass a qualified=True|False parameter
when creating a breakpoint in Python. It is equivalent to using
-qualified in a linespec. The parameter actually accepts any Python
value, and converts it to boolean using Python's standard rules for
that (https://docs.python.org/3/library/stdtypes.html#truth).
Unlike the -source/-line/-function/-label parameters, it is possible to
use -qualified with a "normal" (non-explicit) linespec. Therefore, it
is possible (unlike these other parameters) to use this new parameter
along with the spec parameter.
I updated the py-breakpoint.exp test. To be able to test multiple
locations using a namespace, I had to switch the test case to compile as
C++. If we really wanted to, we could run it as both C and C++, but
omit the C++-specific parts when running it as C.
gdb/ChangeLog:
* location.h (string_to_event_location): Add match_type
parameter.
* location.c (string_to_event_location): Likewise.
* python/py-breakpoint.c (bppy_init): Handle qualified
parameter.
gdb/doc/ChangeLog:
* python.texi (Manipulating breakpoints using Python): Document
qualified parameter to gdb.Breakpoint.
gdb/testsuite/ChangeLog:
* gdb.python/py-breakpoint.c (foo_ns::multiply): New function.
* gdb.python/py-breakpoint.exp: Compile the test case as c++,
call test_bkpt_qualified.
(test_bkpt_qualified): New proc.
The prefix in test_bkpt_explicit_loc is wrong. Instead of using
with_test_prefix directly, define test_bkpt_explicit_loc with
proc_with_prefix.
gdb/testsuite/ChangeLog:
* gdb.python/py-breakpoint.exp (test_bkpt_explicit_loc): Define
with proc_with_prefix, don't use with_test_prefix.
This introduces several new keywords to the bppy_init constructor.
The spec parameter is now optional but mutually exclusive to the
explicit keywords source, label, function and line.
gdb/ChangeLog
2017-12-07 Phil Muldoon <pmuldoon@redhat.com>
* python/py-breakpoint.c (bppy_init): Use string_to_event_location
over basic location code. Implement explicit location keywords.
(bppy_init_validate_args): New function.
* NEWS: Document Python explicit breakpoint locations.
doc/ChangeLog
2017-12-07 Phil Muldoon <pmuldoon@redhat.com>
* python.texi (Breakpoints In Python): Add text relating
to allowed explicit locations and keywords in gdb.Breakpoints.
testsuite/ChangeLog
2017-12-07 Phil Muldoon <pmuldoon@redhat.com>
* gdb.python/py-breakpoint.exp (test_bkpt_explicit_loc): Add new
tests for explicit locations.
thpy_get_inferior function should return a new reference to the
existing inferior object, and therefore should increment its refcount.
Fixed bug looks like this.
If multiple time call gdb.selected_thread ().inferior, gdb throws exception:
(gdb) pi gdb.selected_thread().inferior
<gdb.Inferior object at 0x7f1952bea698>
(gdb) pi gdb.selected_thread().inferior
Python Exception <type 'exceptions.AttributeError'> 'NoneType' object
has no attribute 'inferior':
Error while executing Python code.
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7f54f0474740 (LWP 584) "mc" 0x00007f54ef055c33 in
Use proc_with_prefix to avoid having to call with_test_prefix with a
duplicate of the proc name. The diff is mostly lines being re-indented.
gdb/testsuite/ChangeLog:
* gdb.python/py-breakpoint.exp (test_bkpt_basic,
test_bkpt_deletion, test_bkpt_cond_and_cmds,
test_bkpt_invisible, test_watchpoints, test_bkpt_internal,
test_bkpt_eval_funcs, test_bkpt_temporary, test_bkpt_address,
test_bkpt_pending, test_bkpt_events): Use proc_with_prefix,
remove with_test_prefix.
This testcase works fine with gdbserver nowadays. So remove the
kfail.
gdb/testsuite/ChangeLog:
2017-10-13 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@polymtl.ca>
PR python/12966
* gdb.python/py-evthreads.exp: Remove is_remote target kfail.
Fixes:
Running ..../src/gdb/testsuite/gdb.python/py-evthreads.exp ...
FAIL: gdb.python/py-evthreads.exp: run to breakpoint 1
FAIL: gdb.python/py-evthreads.exp: reached breakpoint 2
FAIL: gdb.python/py-evthreads.exp: thread 2
FAIL: gdb.python/py-evthreads.exp: reached breakpoint 3
FAIL: gdb.python/py-evthreads.exp: thread 3
FAIL: gdb.python/py-evthreads.exp: continue thread 1
[... cascading time outs ...]
By following the usual pattern that makes sure that non-stop is enabled
before connecting to gdbserver.
gdb/testsuite/ChangeLog:
2017-10-13 Pedro Alves <palves@redhat.com>
* gdb.python/py-evthreads.exp: Start GDB with "set non-stop on"
already.
As the title says, this is a test case for
Inferior.thread_from_thread_handle, a python method which will,
given a thread library dependent thread handle, find the GDB thread
which corresponds to that thread handle (in the inferior under
consideration).
The C file for this test case causes the thread handles for the
main thread and two child threads to be placed into an array. The
test case runs to one of the functions (do_something()) at which point,
it retrieves the thread handles from the array and attempts to find the
corresponding thread in GDB's internal thread list.
I use barriers to make sure that both threads have actually started;
execution will stop when one of the threads breaks at do_something.
Thanks to Simon Marchi for suggestions for forcing the thread
numbering to be stable.
gdb/testsuite/ChangeLog:
* gdb.python/py-thrhandle.c, gdb.python/py-thrhandle.exp: New
files.
This adds a few new events to gdb's Python layer: new_inferior,
inferior_deleted, and new_thread. I wanted to be able to add a
combined inferior/thread display window to my GUI, and I needed a few
events to make this work. This is PR python/15622.
ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
PR python/15622:
* NEWS: Add entry.
* python/python.c (do_start_initialization): Initialize new event
types.
* python/python-internal.h (gdbpy_initialize_new_inferior_event)
(gdbpy_initialize_inferior_deleted_event)
(gdbpy_initialize_new_thread_event): Declare.
* python/py-threadevent.c (create_thread_event_object): Add option
"thread" parameter.
* python/py-inferior.c (new_thread_event_object_type)
(new_inferior_event_object_type)
(inferior_deleted_event_object_type): Declare.
(python_new_inferior, python_inferior_deleted): New functions.
(add_thread_object): Emit new_thread event.
(gdbpy_initialize_inferior): Attach new functions to corresponding
observers.
(new_thread, new_inferior, inferior_deleted): Define new event
types.
* python/py-evts.c (gdbpy_initialize_py_events): Add new
registries.
* python/py-events.h (events_object) <new_inferior,
inferior_deleted, new_thread>: New fields.
* python/py-event.h (create_thread_event_breakpoint): Add optional
"thread" parameter.
doc/ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
* python.texi (Events In Python): Document new events.
testsuite/ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
* gdb.python/py-infthread.exp: Add tests for new_thread event.
* gdb.python/py-inferior.exp: Add tests for new inferior events.
(Ref: https://sourceware.org/ml/gdb/2017-06/msg00020.html)
Assuming int_t is a typedef to int:
typedef int int_t;
gdb currently loses this expression's typedef:
(gdb) p (int_t) 0
$1 = 0
(gdb) whatis $1
type = int
or:
(gdb) whatis (int_t) 0
type = int
or, to get "whatis" out of the way:
(gdb) maint print type (int_t) 0
...
name 'int'
code 0x8 (TYPE_CODE_INT)
...
This prevents a type printer for "int_t" kicking in, with e.g.:
(gdb) p (int_t) 0
From the manual, we can see that that "whatis (int_t) 0" command
invocation should have printed "type = int_t":
If @var{arg} is a variable or an expression, @code{whatis} prints its
literal type as it is used in the source code. If the type was
defined using a @code{typedef}, @code{whatis} will @emph{not} print
the data type underlying the @code{typedef}.
(...)
If @var{arg} is a type name that was defined using @code{typedef},
@code{whatis} @dfn{unrolls} only one level of that @code{typedef}.
That one-level stripping is currently done here, in
gdb/eval.c:evaluate_subexp_standard, handling OP_TYPE:
...
else if (noside == EVAL_AVOID_SIDE_EFFECTS)
{
struct type *type = exp->elts[pc + 1].type;
/* If this is a typedef, then find its immediate target. We
use check_typedef to resolve stubs, but we ignore its
result because we do not want to dig past all
typedefs. */
check_typedef (type);
if (TYPE_CODE (type) == TYPE_CODE_TYPEDEF)
type = TYPE_TARGET_TYPE (type);
return allocate_value (type);
}
However, this stripping is reachable in both:
#1 - (gdb) whatis (int_t)0 # ARG is an expression with a cast to
# typedef type.
#2 - (gdb) whatis int_t # ARG is a type name.
while only case #2 should strip the typedef. Removing that code from
evaluate_subexp_standard is part of the fix. Instead, we make the
"whatis" command implementation itself strip one level of typedefs
when the command argument is a type name.
We then run into another problem, also fixed by this commit:
value_cast always drops any typedefs of the destination type.
With all that fixed, "whatis (int_t) 0" now works as expected:
(gdb) whatis int_t
type = int
(gdb) whatis (int_t)0
type = int_t
value_cast has many different exit/convertion paths, for handling many
different kinds of casts/conversions, and most of them had to be
tweaked to construct the value of the right "to" type. The new tests
try to exercise most of it, by trying castin of many different
combinations of types. With:
$ make check TESTS="*/whatis-ptype*.exp */gnu_vector.exp */dfp-test.exp"
... due to combinatorial explosion, the testsuite results for the
tests above alone grow like:
- # of expected passes 246
+ # of expected passes 3811
You'll note that the tests exposed one GCC buglet, filed here:
Missing DW_AT_type in DW_TAG_typedef of "typedef of typedef of void"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81267
gdb/ChangeLog:
2017-08-21 Pedro Alves <palves@redhat.com>
* eval.c (evaluate_subexp_standard) <OP_TYPE>: Don't dig past
typedefs.
* typeprint.c (whatis_exp): If handling "whatis", and expression
is OP_TYPE, strip one typedef level. Otherwise don't strip
typedefs here.
* valops.c (value_cast): Save "to" type before resolving
stubs/typedefs. Use that type as resulting value's type.
gdb/testsuite/ChangeLog:
2017-08-21 Pedro Alves <palves@redhat.com>
* gdb.base/dfp-test.c
(d32_t, d64_t, d128_t, d32_t2, d64_t2, d128_t2, v_d32_t, v_d64_t)
(v_d128_t, v_d32_t2, v_d64_t2, v_d128_t2): New.
* gdb.base/dfp-test.exp: Add whatis/ptype/cast tests.
* gdb.base/gnu_vector.exp: Add whatis/ptype/cast tests.
* gdb.base/whatis-ptype-typedefs.c: New.
* gdb.base/whatis-ptype-typedefs.exp: New.
* gdb.python/py-prettyprint.c (int_type, int_type2): New typedefs.
(an_int, an_int_type, an_int_type2): New globals.
* gdb.python/py-prettyprint.exp (run_lang_tests): Add tests
involving typedefs and cast expressions.
* gdb.python/py-prettyprint.py (class pp_int_typedef): New.
(lookup_typedefs_function): New.
(typedefs_pretty_printers_dict): New.
(top level): Register lookup_typedefs_function in
gdb.pretty_printers.
[I made some typo fixes but forgot to amend my commit before sending the patch,
hence this v2.]
I see the following failure on Ubuntu 16.04's gcc 5.4.0:
Running /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.python/py-unwind.exp ...
FAIL: gdb.python/py-unwind.exp: continue to breakpoint: break backtrace-broken
FAIL: gdb.python/py-unwind.exp: Backtrace restored by unwinder (pattern 1)
The problem is that the test expects a very particular stack layout.
When stack protection is enabled, it adds a canary value which looks
like an additional local variable. This makes the test complain about
a bad stack layout and fail.
The simple solution is to disable stack protection for that test using
-fno-stack-protector. I checked older compilers (gcc 4.4, clang 3.5)
and they support that flag, so I don't think it's necessary to probe for
whether the compiler supports it.
Maybe a better solution would be to change the test to make it cope with
different stack layouts (perhaps it could save addresses of stuff in
some global variables which GDB/the unwinder would read). I'll go with
the simple solution for now though.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind.exp: Disable stack protection when
building test file.
The gdb.python/py-unwind.exp test is crashing GDB / leaving core dumps
in the test dir, even though it all passes cleanly. The crash is not
visible in gdb.sum/gdb.log because it happens as side effect of the
"quit" command, while flushing the frame cache.
The problem is simply a typo in a 'for' loop's condition, introduced
by a recent change [4fa847d78e ("Remove MAX_REGISTER_SIZE from
py-unwind.c")], resulting in infinite loop / double-free.
The new test exposes the crash, like:
Running src/gdb/testsuite/gdb.python/py-unwind.exp ...
ERROR: Process no longer exists
gdb/ChangeLog:
2017-07-06 Pedro Alves <palves@redhat.com>
* python/py-unwind.c (pyuw_dealloc_cache): Fix for loop condition.
gdb/testsuite/ChangeLog:
2017-07-06 Pedro Alves <palves@redhat.com>
* gdb.python/py-unwind.exp: Test flushregs.
My last commit fixed a regression that happened when using
inline/multi-line commands for Python/Compile/Guile, but introduced
another regression: it is now not possible to use aliases for the
commands mentioned above. The fix is to almost revert the change I've
made and go back to using the 'struct cmd_list_element *', but at the
same time make sure that we advance the 'cmd_name' variable past all
the whitespace characters after the command name. If, after skipping
the whitespace, we encounter a '\0', it means that the command is not
inline. Otherwise, it is.
This patch also expands the testcase in order to check for aliases and
for trailing whitespace after the command name.
gdb/ChangeLog:
2017-06-30 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
PR cli/21688
* cli/cli-script.c (command_name_equals_not_inline): Remove function.
(process_next_line): New variable 'inline_cmd'.
Adjust 'if' clauses for "python", "compile" and "guile" to use
'command_name_equals' and check for '!inline_cmd'.
gdb/testsuite/ChangeLog:
2017-06-30 Sergio Durigan Junior <sergiodj@redhat.com>
PR cli/21688
* gdb.python/py-cmd.exp (test_python_inline_or_multiline): Add new
tests for alias commands and trailing whitespace.
This bug is a regression caused by the following commit:
604c4576fd is the first bad commit
commit 604c4576fd
Author: Jerome Guitton <guitton@adacore.com>
Date: Tue Jan 10 15:15:53 2017 +0100
The problem happens because, on cli/cli-script.c:process_next_line,
GDB is not using the command line string to identify which command to
run, but it instead using the 'struct cmd_list_element *' that is
obtained by using the mentioned string. The problem with that is that
the 'struct cmd_list_element *' doesn't have any information on
whether the command issued by the user is a multi-line or inline one.
A multi-line command is a command that will necessarily be composed of
more than 1 line. For example:
(gdb) if 1
>python
>print ('hello')
>end
>end
As can be seen in the example above, the 'python' command actually
"opens" a new command line (represented by the change in the
indentation) that will then be used to enter Python code. OTOH, an
inline command is a command that is "self-contained" in a single line,
for example:
(gdb) if 1
>python print ('hello')
>end
This Python command is a one-liner, and therefore there is no other
Python code that can be entered for this same block. There is also no
change in the indentation.
So, the fix is somewhat simple: we have to revert the change and use
the full command line string passed to process_next_line in order to
identify whether we're dealing with a multi-line or an inline command.
This commit does just that. As can be seen, this regression also
affects other languages, like guile or the compile framework. To make
things clearer, I decided to create a new helper function responsible
for identifying a non-inline command.
Testcase is attached.
gdb/ChangeLog:
2017-06-30 Sergio Durigan Junior <sergiodj@redhat.com>
PR cli/21688
* cli/cli-script.c (command_name_equals_not_inline): New function.
(process_next_line): Adjust 'if' clauses for "python", "compile"
and "guile" to use command_name_equals_not_inline.
gdb/testsuite/ChangeLog:
2017-06-30 Sergio Durigan Junior <sergiodj@redhat.com>
PR cli/21688
* gdb.python/py-cmd.exp (test_python_inline_or_multiline): New
procedure. Call it.
The test suite contains multiple instances of determining the target's
endianness with GDB's "show endian" command. This patch replaces these by
an invocation of a new convenience proc 'get_endianness'.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (get_endianness): New proc.
* gdb.arch/aarch64-fp.exp: Use it.
* gdb.arch/altivec-regs.exp: Likewise.
* gdb.arch/e500-regs.exp: Likewise.
* gdb.arch/vsx-regs.exp: Likewise.
* gdb.base/dump.exp: Likewise.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/gnu_vector.exp: Likewise.
* gdb.dwarf2/formdata16.exp: Likewise.
* gdb.dwarf2/implptrpiece.exp: Likewise.
* gdb.dwarf2/nonvar-access.exp: Likewise.
* gdb.python/py-inferior.exp: Likewise.
* gdb.trace/unavailable-dwarf-piece.exp: Likewise.
As discussed here: https://sourceware.org/ml/gdb-patches/2017-04/msg00157.html
A gap is not an instruction and it should not pretend to be one.
gdb.Record.instruction_history is now a list of gdb.RecordInstruction and
gdb.RecordGap objects. This allows the user to deal with Gaps in the record
in a more sane way.
The user would always get the instruction_history and function_call_history
objects of the current thread, not the thread for which the gdb.Record object
was created.
The attached testcase fails without this patch and passes with the patch.
$ gdb rustc
Reading symbols from rustc...Reading symbols from /usr/lib/debug/usr/bin/rustc.debug...done.
done.
warning: Invalid entry in .debug_gdb_scripts section
/usr/bin/rustc
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[15] .debug_gdb_scripts PROGBITS 00000000000008ed 0008ed 000022 00 AMS 0 0 1
/usr/lib/debug/usr/bin/rustc.debug
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[15] .debug_gdb_scripts NOBITS 00000000000008ed 000280 000022 00 AMS 0 0 1
There remains questionable whether bfd_get_section_by_name() should not return
an error for !SEC_LOAD but I haven't investigated that.
gdb/ChangeLog
2017-03-29 Jan Kratochvil <jan.kratochvil@redhat.com>
* auto-load.c (auto_load_section_scripts): Check SEC_HAS_CONTENTS.
gdb/testsuite/ChangeLog
2017-03-29 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.python/py-section-script.exp (sepdebug): New testcases.
This changes the return type of "gdb.BtraceInstruction.data ()" from
"memoryview" to "buffer" on Python 2.7 and below, similar to what
"gdb.Inferior.read_memory ()" does.
This patch adds tests for the initial rvalue reference support patchset. All
of the new tests are practically mirrored regular references tests and, except
for the demangler ones, are introduced in new files, which are set to be
compiled with -std=gnu++11. Tested are printing of rvalue reference types and
values, rvalue reference parameters in function overloading, demangling of
function names containing rvalue reference parameters, casts to rvalue
reference types, application of the sizeof operator to rvalue reference types
and values, and support for rvalue references within the gdb python module.
gdb/ChnageLog
PR gdb/14441
* NEWS: Mention support for rvalue references in GDB and python.
* doc/gdb.texinfo (C Plus Plus Expressions): Mention that GDB
supports both lvalue and rvalue references.
gdb/testsuite/ChangeLog
PR gdb/14441
* gdb.cp/demangle.exp: Add rvalue reference tests.
* gdb.cp/rvalue-ref-casts.cc: New file.
* gdb.cp/rvalue-ref-casts.exp: New file.
* gdb.cp/rvalue-ref-overload.cc: New file.
* gdb.cp/rvalue-ref-overload.exp: New file.
* gdb.cp/rvalue-ref-params.cc: New file.
* gdb.cp/rvalue-ref-params.exp: New file.
* gdb.cp/rvalue-ref-sizeof.cc: New file.
* gdb.cp/rvalue-ref-sizeof.exp: New file.
* gdb.cp/rvalue-ref-types.cc: New file.
* gdb.cp/rvalue-ref-types.exp: New file.
* gdb.python/py-rvalue-ref-value-cc.cc: New file.
* gdb.python/py-rvalue-ref-value-cc.exp: New file.
