Calling tui_enable too early in tui_layout_command can leave the tui in
an enabled state if the user has entered an invalid layout name.
Instead postpone the call to tui_enable until later in
tui_set_layout_for_display_command just before the layout is changed.
gdb/ChangeLog:
* tui/tui-layout.c (tui_layout_command): Move call to tui_enable
into ...
(tui_set_layout_for_display_command): ...here, before calling
tui_set_layout. Only set the layout if gdb has not already
entered the TUI_FAILURE state.
Add layout name completion for the layout command.
gdb/ChangeLog:
* tui/tui-layout.c (layout_completer): New function.
(_initialize_tui_layout): Set completer on layout command.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Add test for completion of layout
names.
The layout command supports the layout names $FREGS, $GREGS, $SREGS,
and $REGS. The intention of these layout names was to display the tui
register window with a specific set of registers.
First, these layout names no longer work, and haven't for a while, using
any of them will just result in switching to the general register view.
Second there is already the command 'tui reg GROUP' command to set the
displayed register set to GROUP, so making the layout command also
control the register set feels like unnecessary overloading of the
layout command.
This commit removes all code relating to supporting the register set
specific names from the layout command. Afterwards the user can select
an available layout using the layout command, and control the choice of
register set using the 'tui reg GROUP' command.
gdb/ChangeLog:
* tui/tui-layout.c (tui_set_layout): Remove
tui_register_display_type parameter. Remove all checking of this
parameter, and reindent function. Update header comment.
(tui_set_layout_for_display_command): Rename to...
(tui_set_layout_by_name): ...this, and don't check for different
register class types, don't pass a tui_register_display_type to
tui_set_layout. Update header comment.
(layout_names): Remove register set specific names.
* tui/tui-layout.h (tui_set_layout): Remove
tui_register_display_type parameter.
* tui/tui.c (tui_rl_change_windows): Don't pass a
tui_register_display_type to tui_set_layout.
(tui_rl_delete_other_windows): Likewise.
(tui_enable): Likewise.
* tui/tui-data.h (TUI_FLOAT_REGS_NAME): Remove.
(TUI_FLOAT_REGS_NAME_LOWER): Remove.
(TUI_GENERAL_REGS_NAME): Remove.
(TUI_GENERAL_REGS_NAME_LOWER): Remove.
(TUI_SPECIAL_REGS_NAME): Remove.
(TUI_SPECIAL_REGS_NAME_LOWER): Remove.
(TUI_GENERAL_SPECIAL_REGS_NAME): Remove.
(TUI_GENERAL_SPECIAL_REGS_NAME_LOWER): Remove.
(enum tui_register_display_type): Remove.
(struct tui_layout_def): Remove regs_display_type and
float_regs_display_type fields.
(struct tui_data_info): Remove regs_display_type field.
(tui_layout_command): Use new name for
tui_set_layout_for_display_command.
* tui/tui-data.c (layout_def): Don't initialise removed fields.
(tui_clear_win_detail): Don't initialise removed fields of
win_info.
* tui/tui-regs.c (tui_show_registers): Use new name for
tui_set_layout_for_display_command.
* tui/tui.h (tui_set_layout_for_display_command): Rename
declaration to...
(tui_set_layout_by_name): ...this.
* printcmd.c (display_command): Remove tui related layout call,
and reindent.
Add a new predicate procedure to the gdb.exp library 'skip_tui_tests',
which returns true if the tui is not compiled into gdb.
Make use of this predicate in the gdb.base/tui-layout.exp test as an
example.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (skip_tui_tests): New proc.
* gdb.base/tui-layout.exp: Check skip_tui_tests.
When using a conditional breakpoint where the condition evaluated
to false a large number of times before the program stopped,
a user reported that GDB's memory consumption was growing very
quickly until it ran out of memory.
The problem was tracked down to temporary struct values being created
each time the program stops and handles an inferior event. Because
the breakpoint condition usually evaluates to false, there can be
a fairly large number of such events to be handled before we eventually
return the prompt to the user (which is when we would normally purge
such values).
This patch fixes the issue by making sure that handle_inferior_event
releases all new values created during its execution.
gdb/ChangeLog:
* infrun.c (handle_inferior_event_1): Renames handle_inferior_event.
(handle_inferior_event): New function.
... to avoid a build failure when building with C++ compiler
(when configured with --enable-build-with-cxx). We cannot use
"typename" as it is a C++ reserved keyword.
gdb/ChangeLog:
* ada-lang.c (to_fixed_array_type): Rename local variable
typename into type_name.
(gdb) PASS: gdb.compile/compile.exp: set unwindonsignal on
compile code *(volatile int *) 0 = 0;
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7fba426 in _gdb_expr (__regs=0x7ffff7fb8000) at gdb command line:1
1 gdb command line: No such file or directory.
=================================================================
==10462==ERROR: AddressSanitizer: heap-use-after-free on address 0x621000cf7a3d at pc 0x0000004e46b9 bp 0x7ffdeb0f7a40 sp 0x7ffdeb0f71b8
READ of size 10 at 0x621000cf7a3d thread T0
#0 0x4e46b8 in printf_common(void*, char const*, __va_list_tag*) [clone .isra.6] (/home/jkratoch/redhat/gdb-clean-asan/gdb/gdb+0x4e46
b8)
#1 0x4f645e in vasprintf (/home/jkratoch/redhat/gdb-clean-asan/gdb/gdb+0x4f645e)
#2 0xe5cf00 in xstrvprintf common/common-utils.c:120
#3 0xe74192 in throw_it common/common-exceptions.c:332
#4 0xe742f6 in throw_verror common/common-exceptions.c:361
#5 0xddc89e in verror /home/jkratoch/redhat/gdb-clean-asan/gdb/utils.c:541
#6 0xe734bd in error common/errors.c:43
#7 0xafa1d6 in call_function_by_hand_dummy /home/jkratoch/redhat/gdb-clean-asan/gdb/infcall.c:1031
#8 0xe81858 in compile_object_run compile/compile-object-run.c:119
#9 0xe7733c in eval_compile_command compile/compile.c:577
#10 0xe7541e in compile_code_command compile/compile.c:153
It is obvious why that happens, dummy_frame_pop() will call compile objfile
cleanup which will free that objfile and NAME then becomes a stale pointer.
> Is there any reason we release OBJFILE in the dummy frame dtor? Why
> don't we register a cleanup to release in OBJFILE in compile_object_run?
> together with releasing compile_module? 'struct compile_module' has a
> field objfile, which should be released together with
> 'struct compile_module' instead of dummy_frame.
(gdb) break puts
Breakpoint 2 at 0x3830c6fd30: file ioputs.c, line 34.
(gdb) compile code puts("hello")
Breakpoint 2, _IO_puts (str=0x7ffff7ff8000 "hello") at ioputs.c:34
34 {
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(_gdb_expr) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) bt
(gdb) _
Now compile_object_run() called from line
(gdb) compile code puts("hello")
has finished for a long time. But we still need to have that injected code
OBJFILE valid when GDB is executing it. Therefore OBJFILE is freed only from
destructor of the frame #1.
At the patched line of call_function_by_hand_dummy() the dummy frame
destructor has not yet been run but it will be run before the fetched NAME
will get used.
gdb/ChangeLog
2015-05-19 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix ASAN crash for gdb.compile/compile.exp.
* infcall.c (call_function_by_hand_dummy): Use xstrdup for NAME.
Please send debug output to gdb_stdlog.
OK but gdb/compile/ is using now only gdb_stdout; the error above is due to
a copy-paste. So I will send a follow-up patch to change all the other
gdb/compile/ gdb_stdout strings to gdb_stdlog.
gdb/ChangeLog
2015-05-19 Jan Kratochvil <jan.kratochvil@redhat.com>
* compile/compile-c-symbols.c (convert_symbol_sym, gcc_convert_symbol)
(gcc_symbol_address): Change gdb_stdout to gdb_stdlog.
* compile/compile-object-load.c (setup_sections, compile_object_load):
Likewise.
* compile/compile.c (compile_to_object): Likewise.
Some buildslaves are showing that this test is failing. E.g.,:
https://sourceware.org/ml/gdb-testers/2015-q2/msg04164.html
The issue is that HISTSIZE is set to 1000 in the environment that runs
the tests (that's the default in Fedora, set in /etc/profile).
We can trivially reproduce it with:
$ HISTSIZE=1000 make check RUNTESTFLAGS="gdbinit-history.exp"
(...)
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/gdbinit-history.exp ...
FAIL: gdb.base/gdbinit-history.exp: show history size
FAIL: gdb.base/gdbinit-history.exp: show history size
FAIL: gdb.base/gdbinit-history.exp: show commands
gdb.log shows:
...
(gdb) set height 0
(gdb) set width 0
(gdb) show history size
The size of the command history is 1000.
(gdb) FAIL: gdb.base/gdbinit-history.exp: show history size
gdb/testsuite/ChangeLog:
2015-05-19 Pedro Alves <palves@redhat.com>
* gdb.base/gdbinit-history.exp (test_gdbinit_history_setting):
Save the whole env array instead of just HOME. Unset HISTSIZE in
the environment while testing. Restore whole environment
afterwards.
It is planned the existing GDB command 'print' will be able to evaluate its
expressions using the compiler. There will be some option to choose between
the existing GDB evaluation and the compiler evaluation. But as an
intermediate step this patch provides the expression printing feature as a new
command.
I can imagine it could be also called 'maintenance compile print' as in the
future one should be able to use its functionality by the normal 'print'
command.
There was a discussion with Eli about the command name:
https://sourceware.org/ml/gdb-patches/2015-03/msg00880.html
As there were no other comments yet I haven't renamed it yet, before there is
some confirmation about settlement on the final name.
Support for the GDB '@' operator to create arrays has been submitted for GCC:
[gcc patch] libcc1: '@' GDB array operator
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01451.html
gdb/ChangeLog
2015-05-16 Jan Kratochvil <jan.kratochvil@redhat.com>
Phil Muldoon <pmuldoon@redhat.com>
* NEWS (Changes since GDB 7.9): Add compile print.
* compile/compile-c-support.c (add_code_header, add_code_footer)
(c_compute_program): Add COMPILE_I_PRINT_ADDRESS_SCOPE and
COMPILE_I_PRINT_VALUE_SCOPE.
* compile/compile-internal.h (COMPILE_I_PRINT_OUT_ARG_TYPE)
(COMPILE_I_PRINT_OUT_ARG, COMPILE_I_EXPR_VAL, COMPILE_I_EXPR_PTR_TYPE):
New.
* compile/compile-object-load.c: Include block.h.
(get_out_value_type): New function.
(compile_object_load): Handle COMPILE_I_PRINT_ADDRESS_SCOPE and
COMPILE_I_PRINT_VALUE_SCOPE. Set compile_module's OUT_VALUE_ADDR and
OUT_VALUE_TYPE.
* compile/compile-object-load.h (struct compile_module): Add fields
out_value_addr and out_value_type.
* compile/compile-object-run.c: Include valprint.h and compile.h.
(struct do_module_cleanup): Add fields out_value_addr and
out_value_type.
(do_module_cleanup): Handle COMPILE_I_PRINT_ADDRESS_SCOPE and
COMPILE_I_PRINT_VALUE_SCOPE.
(compile_object_run): Propagate out_value_addr and out_value_type.
Pass OUT_VALUE_ADDR.
* compile/compile.c: Include valprint.h.
(compile_print_value, compile_print_command): New functions.
(eval_compile_command): Handle failed COMPILE_I_PRINT_ADDRESS_SCOPE.
(_initialize_compile): Update compile code help text. Install
compile_print_command.
* compile/compile.h (compile_print_value): New prototype.
* defs.h (enum compile_i_scope_types): Add
COMPILE_I_PRINT_ADDRESS_SCOPE and COMPILE_I_PRINT_VALUE_SCOPE.
gdb/doc/ChangeLog
2015-05-16 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.texinfo (Compiling and Injecting Code): Add compile print.
gdb/testsuite/ChangeLog
2015-05-16 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile-print.c: New file.
* gdb.compile/compile-print.exp: New file.
Currently the code fetches _gdb_expr address/types at multiple places, guessing
its parameters at multiple places etc.
Fetch it once, verify it has expected type and then rely on it.
While the patch tries to clean up the code it is still horrible due to the
missing C++ sub-classing.
gdb/ChangeLog
2015-05-16 Jan Kratochvil <jan.kratochvil@redhat.com>
* compile/compile-object-load.c (get_regs_type): Add parameter func_sym.
Rely on its parameter count.
(compile_object_load): Replace lookup_minimal_symbol_text by
lookup_global_symbol_from_objfile. Verify FUNC_SYM. Set it in the
return value.
* compile/compile-object-load.h (struct compile_module): Replace
func_addr by func_sym.
* compile/compile-object-run.c: Include block.h.
(compile_object_run): Reset module variable after it is freed. Use
FUNC_SYM instead of FUNC_ADDR. Rely on it.
For a reason unknown to me GDB was using -w instead of -Wall for 'compile code'.
The problem is later patch for 'compile printf' really needs some warnings to
be able to catch for example missing format string parameters:
(gdb) compile printf "%d\n"
GCC does not seem to be able to cancel -w (there is nothing like -no-w).
Besides that I think even 'compile code' can benefit from -Wall.
That #ifndef change in print_one_macro() is needed otherwise we get
macro-redefinition warnings for the GCC built-in macros (as -w is no
longer in effect). For example, without the #ifndef/#endif one gets:
compile -r -- void _gdb_expr(){int i = 5;}^M
/tmp/gdbobj-xpU1yB/out4.c:4:0: warning: "__FILE__" redefined [-Wbuiltin-macro-redefined]^M
/tmp/gdbobj-xpU1yB/out4.c:5:0: warning: "__LINE__" redefined^M
...
It makes more sense to pick the inferior's version of the macros, hence
#ifndef instead of #undef.
That new testsuite XFAIL is there as if one changes the struct definition to be
compliant with cv-qualifiers (to prevent the warnings):
struct struct_type {
- struct struct_type *selffield;
+ volatile struct struct_type *selffield;
only then GCC/GDB will hit the crash, described in that GDB PR 18202.
gdb/ChangeLog
2015-05-16 Jan Kratochvil <jan.kratochvil@redhat.com>
* compile/compile-c-support.c (print_one_macro): Use #ifndef.
(generate_register_struct): Use __gdb_uintptr for TYPE_CODE_PTR.
(c_compute_program): Call generate_register_struct after typedefs.
* compile/compile-loc2c.c (push, pushf_register_address)
(pushf_register): Cast to GCC_UINTPTR.
(do_compile_dwarf_expr_to_c): Use unused attribute. Add space after
type. Use GCC_UINTPTR instead of void *. Remove excessive cast.
(compile_dwarf_expr_to_c): Use GCC_UINTPTR instead of void *.
* compile/compile.c (_initialize_compile): Enable warnings for
COMPILE_ARGS.
gdb/testsuite/ChangeLog
2015-05-16 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile-ops.exp: Cast param to void.
* gdb.compile/compile.exp: Complete type for _gdb_expr.
(compile code struct_object.selffield = &struct_object): Add xfail.
Provide a way to access current 'scope' during the do_module_cleanup stage and
associate more data with it.
gdb/ChangeLog
2015-05-16 Jan Kratochvil <jan.kratochvil@redhat.com>
* cli/cli-script.c (execute_control_command): Update
eval_compile_command caller.
* compile/compile-object-load.c (compile_object_load): Add parameters
scope and scope_data. Set them.
* compile/compile-object-load.h (struct compile_module): Add fields
scope and scope_data.
(compile_object_load): Add parameters scope and scope_data.
* compile/compile-object-run.c (struct do_module_cleanup): Add fields
scope and scope_data.
(compile_object_run): Propagate the fields scope and scope_data.
* compile/compile.c (compile_file_command, compile_code_command):
Update eval_compile_command callers.
(eval_compile_command): Add parameter scope_data. Pass it plus scope.
* compile/compile.h (eval_compile_command): Add parameter scope_data.
* defs.h (struct command_line): Add field scope_data.
The later 'compile print' command should share its behavior with the existing
'print' command. Make the needed existing parts of print_command_1 public.
gdb/ChangeLog
2015-05-16 Jan Kratochvil <jan.kratochvil@redhat.com>
* printcmd.c (struct format_data): Move it to valprint.h.
(print_command_parse_format, print_value): New functions from ...
(print_command_1): ... here. Call them.
* valprint.h (struct format_data): Move it here from printcmd.c.
(print_command_parse_format, print_value): New declarations.
In Ada, index types of arrays can be enumeration types, and enumeration
types can be non-contiguous. In which case the address of elements is
not given by the value of the index, but by its position in the enumeration
type.
In other words, in this example:
type Color is (Blue, Red);
for Color use (Blue => 8, Red => 12, Green => 16);
type A is array (Color) of Integer;
type B is array (1 .. 3) of Integer;
Arrays of type A and B will have the same layout in memory, even if
the enumeration Color has a hole in its set of integer value.
Since recently support for such a feature was in ada-lang.c, where the
array was casted to a regular continuous index range. We were losing
the information of index type. And this was not quite working for
subranges in variable-length fields; their bounds are expressed using
the integer value of the bounds, not its position in the enumeration,
and there was some confusion all over ada-lang.c as to whether we had
the position or the integer value was used for indexes.
The idea behind this patch is to clean this up by keeping the real
representation of these array index types and bounds when representing
the value, and only use the position when accessing the elements or
computing the length. This first patch fixes the printing of such
an array.
To the best of my knowledge, this feature only exists in Ada so it
should only affect this language.
gdb/ChangeLog:
Jerome Guitton <guitton@adacore.com>:
* ada-lang.c (ada_value_ptr_subscript): Use enum position of
index to get element instead of enum value.
(ada_value_slice_from_ptr, ada_value_slice): Use enum position
of index to compute length, but enum values to compute bounds.
(ada_array_length): Use enum position of index instead of enum value.
(pos_atr): Move position computation to...
(ada_evaluate_subexp): Use enum values to compute bounds.
* gdbtypes.c (discrete_position): ...this new function.
* gdbtypes.h (discrete_position): New function declaration.
* valprint.c (val_print_array_elements): Call discrete_position
to handle array indexed by non-contiguous enumeration types.
gdb/testsuite/ChangeLog:
* gdb.ada/arr_enum_with_gap: New testcase.
In the case of non bit-packed arrays, GNAT does not generate its
traditional XP encoding; it is not needed. However, it still generates
the so-called "implementation type" with a P suffix. This
implementation type shall be skipped when looking for other
descriptive types such as XA encodings for variable-length
fields.
Note also that there may be an intermediate typedef between the
implementation type and its XA description. It shall be skipped
as well.
gdb/ChangeLog:
Jerome Guitton <guitton@adacore.com>
* ada-lang.c (find_parallel_type_by_descriptive_type):
Go through typedefs during lookup.
(to_fixed_array_type): Add support for non-bit packed arrays
as variable-length fields.
gdb/testsuite/ChangeLog:
* gdb.ada/byte_packed_arr: New testcase.
The PPC64 buildbot has been showing timeouts in mi-nsmoribund.exp,
like this:
(...)
-thread-info
FAIL: gdb.mi/mi-nsmoribund.exp: thread state: all running except the breakpoint thread (timeout)
... and I can reproduce this on gcc110 (PPC64) on the gcc compile
farm.
That is, the test sends "-thread-info" to GDB, but GDB never replies
back.
The problem is that these machines are too fast for gdb. :-)
That test has a few threads running the same tight loop, and
constantly hitting a thread-specific breakpoint that needs to be
stepped over. If threads trip on breakpoints fast enough that
linux-nat.c's event pipe associated with SIGCHLD is constantly being
written to, even if the stdin file descriptor also has an event to
handle, gdb never gets to it. because linux-nat.c's pipe comes first
in the set of descriptors served by the poll/select code in the event
loop.
Fix this by having the event loop serve file event sources in
round-robin-like fashion, similarly to how its done in
gdb_do_one_event.
Unfortunately, the poll and the select variants each need their own
fixing.
Tested on x86_64 Fedora 20 (poll and select variants), and PPC64
Fedora 18. Fixes the timeout in the PPC64 machine in the compile farm
that times out without this, and I won't be surprised if it fixes
other random timeouts in other tests.
(gdbserver's copy of the event-loop doesn't need this (yet), as it
still pushes all ready events to an event queue. That is, it hasn't
had 70b66289 merged yet. We should really merge both event-loop.c
copies into a single shared file, but that's for another day.)
gdb/ChangeLog:
2015-05-15 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@ericsson.com>
* event-loop.c (gdb_notifier) <next_file_handler,
next_poll_fds_index>: New fields.
(get_next_file_handler_to_handle_and_advance): New function.
(delete_file_handler): If deleting the next file handler to
handle, advance to the next file handler.
(gdb_wait_for_event): Bail early if no event fired. Poll file
handlers in round-robin fashion.
Fixes:
In file included from ../../../binutils-gdb/gdb/gdbserver/server.h:61:0,
from ../../../binutils-gdb/gdb/gdbserver/server.c:19:
../../../binutils-gdb/gdb/gdbserver/target.h:442:50: error: second operand to the conditional operator is of type 'void', but the third operand is neither a throw-expression nor of type 'void'
(*the_target->handle_new_gdb_connection) () : 0)
^
Reported by Yuanhui Zhang.
gdb/gdbserver/ChangeLog:
2015-05-15 Pedro Alves <palves@redhat.com>
* target.h (target_handle_new_gdb_connection): Rewrite using if
wrapped in do/while.
Building in C++ mode errors with:
~~~
g++ -fpermissive (...) /home/pedro/gdb/mygit/src/gdb/gdbserver/../nat/x86-linux.c
In file included from /home/pedro/gdb/mygit/src/gdb/gdbserver/../nat/x86-linux.h:23:0,
from /home/pedro/gdb/mygit/src/gdb/gdbserver/../nat/x86-linux.c:21:
/home/pedro/gdb/mygit/src/gdb/gdbserver/../nat/linux-nat.h:74:13: error: use of enum ‘target_stop_reason’ without previous declaration
extern enum target_stop_reason lwp_stop_reason (struct lwp_info *lwp);
^
/home/pedro/gdb/mygit/src/gdb/gdbserver/../nat/linux-nat.h:74:70: error: invalid type in declaration before ‘;’ token
extern enum target_stop_reason lwp_stop_reason (struct lwp_info *lwp);
^
~~~
gdb/ChangeLog:
2015-05-15 Pedro Alves <palves@redhat.com>
* nat/linux-nat.h: Include "target/waitstatus.h".
Building mingw GDB with --enable-build-with-cxx shows:
../../binutils-gdb/gdb/python/py-unwind.c:500:45: error: cannot convert 'cached_frame_info::reg_info*' to 'pyuw_prev_register(frame_info*, void**, int)::reg_info*' in initialization
struct reg_info *reg_info = cached_frame->reg;
^
../../binutils-gdb/gdb/python/py-unwind.c:501:60: error: invalid use of incomplete type 'struct pyuw_prev_register(frame_info*, void**, int)::reg_info'
struct reg_info *reg_info_end = reg_info + cached_frame->reg_count;
^
../../binutils-gdb/gdb/python/py-unwind.c:500:10: error: forward declaration of 'struct pyuw_prev_register(frame_info*, void**, int)::reg_info'
struct reg_info *reg_info = cached_frame->reg;
^
../../binutils-gdb/gdb/python/py-unwind.c:505:37: error: cannot increment a pointer to incomplete type 'pyuw_prev_register(frame_info*, void**, int)::reg_info'
for (; reg_info < reg_info_end; ++reg_info)
^
../../binutils-gdb/gdb/python/py-unwind.c:507:29: error: invalid use of incomplete type 'struct pyuw_prev_register(frame_info*, void**, int)::reg_info'
if (regnum == reg_info->number)
^
../../binutils-gdb/gdb/python/py-unwind.c:500:10: error: forward declaration of 'struct pyuw_prev_register(frame_info*, void**, int)::reg_info'
struct reg_info *reg_info = cached_frame->reg;
^
../../binutils-gdb/gdb/python/py-unwind.c:508:68: error: invalid use of incomplete type 'struct pyuw_prev_register(frame_info*, void**, int)::reg_info'
return frame_unwind_got_bytes (this_frame, regnum, reg_info->data);
^
../../binutils-gdb/gdb/python/py-unwind.c:500:10: error: forward declaration of 'struct pyuw_prev_register(frame_info*, void**, int)::reg_info'
struct reg_info *reg_info = cached_frame->reg;
^
../../binutils-gdb/gdb/python/py-unwind.c: In function 'int pyuw_sniffer(const frame_unwind*, frame_info*, void**)':
../../binutils-gdb/gdb/python/py-unwind.c:574:70: warning: invalid conversion from 'void*' to 'cached_frame_info*' [-fpermissive]
reg_count * sizeof (cached_frame->reg[0]));
^
../../binutils-gdb/gdb/python/py-unwind.c: In function 'void pyuw_on_new_gdbarch(gdbarch*)':
../../binutils-gdb/gdb/python/py-unwind.c:636:47: warning: invalid conversion from 'void*' to 'pyuw_gdbarch_data_type*' [-fpermissive]
gdbarch_data (newarch, pyuw_gdbarch_data);
^
../../binutils-gdb/gdb/python/py-unwind.c:647:29: warning: invalid conversion from 'void*' to 'const frame_data*' [-fpermissive]
unwinder->unwind_data = (void *) newarch;
^
../../binutils-gdb/gdb/python/py-unwind.c: At global scope:
../../binutils-gdb/gdb/python/py-unwind.c:699:21: error: redefinition of 'PyTypeObject pending_frame_object_type'
static PyTypeObject pending_frame_object_type =
^
../../binutils-gdb/gdb/python/py-unwind.c:96:21: error: 'PyTypeObject pending_frame_object_type' previously declared here
static PyTypeObject pending_frame_object_type
^
../../binutils-gdb/gdb/python/py-unwind.c:749:21: error: redefinition of 'PyTypeObject unwind_info_object_type'
static PyTypeObject unwind_info_object_type =
^
../../binutils-gdb/gdb/python/py-unwind.c:99:21: error: 'PyTypeObject unwind_info_object_type' previously declared here
static PyTypeObject unwind_info_object_type
^
The first kind of error is caused by the embedded struct definition,
so move it out of the parent struct.
The second kind of error is caused by forward declaring a static
global variable, which works in C, but not in C++ (or C with
-fno-common). Make it using extern instead, like done in other
similar cases.
gdb/ChangeLog:
2015-05-15 Yuanhui Zhang <asmwarrior@gmail.com>
* python/py-unwind.c (struct reg_info): Move out of ...
(struct cached_frame_info): ... this scope.
(pending_frame_object_type, unwind_info_object_type): Make extern.
Consider the following declarations:
type Signed_Small is new Integer range - (2 ** 5) .. (2 ** 5 - 1);
type Signed_Simple_Array is array (1 .. 4) of Signed_Small;
pragma Pack (Signed_Simple_Array);
SSA : Signed_Simple_Array := (-1, 2, -3, 4);
GDB currently print its value incorrectly for the elements that
are negative:
(gdb) print ssa
$1 = (65535, 2, 1048573, 4)
(gdb) print ssa(1)
$2 = 65535
(gdb) print ssa(2)
$3 = 2
(gdb) print ssa(3)
$4 = 1048573
(gdb) print ssa(4)
$5 = 4
What happens is that the sign-extension is not working because
we're trying to do left shift with a negative count. In
ada_value_primitive_packed_val, we have a loop which populates
the extra bits of the target (unpacked) value, after extraction
of the data from the original (packed) value:
while (ntarg > 0)
{
accum |= sign << accumSize;
unpacked[targ] = accum & ~(~0L << HOST_CHAR_BIT);
!!! -> accumSize -= HOST_CHAR_BIT;
accum >>= HOST_CHAR_BIT;
ntarg -= 1;
targ += delta;
}
At each iteration, accumSize gets decremented by HOST_CHAR_BIT,
which can easily cause it to become negative, particularly on
little endian targets, where accumSize is at most HOST_CHAR_BIT - 1.
This causes us to perform a left-shift operation with a negative
accumSize at the next loop iteration, which is undefined, and
acutally does not produce the effect we wanted (value left untouched)
when the code is compiled with GCC.
This patch fixes the issue by simply setting accumSize to zero
if negative.
gdb/ChangeLog:
* ada-lang.c (ada_value_primitive_packed_val): Make sure
accumSize is never negative.
gdb/testsuite/ChangeLog:
* gdb.ada/pckd_neg: New testcase.
Fix build errors introduced by
https://sourceware.org/ml/gdb-patches/2015-05/msg00281.html, which
didn't account for the change of the name of the struct process_info
field 'private' to 'priv' made in
https://sourceware.org/ml/gdb-patches/2015-02/msg00829.html.
gdb/gdbserver/ChangeLog:
* linux-aarch64-low.c (aarch64_linux_new_fork): Change reference
to process_info.private to process_info.priv.
* linux-arm-low.c (arm_new_fork): Likewise.
* linux-mips-low.c (mips_linux_new_fork): Likewise.
The following patch...
| proc-service, extern "C"
|
| libthread_db.so calls symbols in the client (GDB), through the
| proc-service interface. These routines must have extern "C" linkage
| so their symbol names are not mangled when GDB is built as a C++
| program. On the GDBserver side, we were missing fallback declarations for
| all these symbols.
|
| gdb/ChangeLog:
|
| * gdb_proc_service.h: Wrap with EXTERN_C_PUSH/EXTERN_C_POP.
|
| gdb/gdbserver/ChangeLog:
| 2015-02-27 Pedro Alves <palves@redhat.com>
|
| * gdb_proc_service.h: Wrap with EXTERN_C_PUSH/EXTERN_C_POP.
| [!HAVE_PROC_SERVICE_H] (struct ps_prochandle): Forward declare.
| [!HAVE_PROC_SERVICE_H] (ps_pdread, ps_pdwrite, ps_ptread)
| ps_ptwrite, ps_lgetregs, ps_lsetregs, ps_lgetfpregs)
| (ps_lsetfpregs, ps_getpid)
| (ps_get_thread_area, ps_pglobal_lookup, ps_pstop, ps_pcontinue)
| (ps_lstop, ps_lcontinue, ps_lgetxregsize, ps_lgetxregs)
| (ps_lsetxregs, ps_plog): Declare.
... added a number of declarations which do not compile when cross-
compiling GDBserver on arm-android. The problem comes from type
prfpregset_t not being declared:
/[...]/gdbserver/gdb_proc_service.h:98:47:
error: unknown type name 'prfpregset_t'
After searching through the includes of the install we have,
I could not find that type being declared anywhere. So I did
the same as for prgregset_t, and created the typedef if the
type isn't declared.
gdb/gdbserver/ChangeLog:
* configure.ac: Add prfpregset_t BFD_HAVE_SYS_PROCFS_TYPE check.
* configure, config.in: Regenerate.
* gdb_proc_service.h [HAVE_PRFPREGSET_T] (prfpregset_t):
Declare typedef.
The function tui_dispatch_ctrl_char() has an old workaround (from 1999)
for buggy terminals and/or ncurses library that don't return page
up/down keys as single characters. Because the workaround is so old, I
think the bug it is targetting is no longer relevant anymore.
But more importantly, the workaround is itself buggy: it 1) performs a
blocking call to wgetch() and 2) if the key returned by wgetch() does
not make up a relevant key sequence it throws away the input instead of
pushing it back via ungetch(). And indeed the workaround breaks Alt-key
sequences under TERM=xterm because of bug #2.
So this patch removes the buggy workaround and tidies up the function
accordingly.
I personally tested this change on a recent xterm (with TERM=xterm) in
Fedora 20 and had no problems with having ncurses properly interpret
page up/down keys. And Alt-key sequences now work when TERM=xterm too.
gdb/ChangeLog:
* tui/tui-command.c: Remove include of <ctype.h>.
(tui_dispatch_ctrl_char): Remove workaround for xterm terminals.
regcache_cpy_no_passthrough is no longer used for a standalone call.
gdb/ChangeLog
2015-05-13 Jan Kratochvil <jan.kratochvil@redhat.com>
* regcache.c (regcache_cpy_no_passthrough): New declaration.
(regcache_cpy_no_passthrough): Make it static, add function comment.
* regcache.h (regcache_dup, regcache_cpy): Reduce/update their comment.
(regcache_cpy_no_passthrough): Remove declaration.
Now stop_registers are no longer used and it can be removed.
I am not much sure what 'proceed_to_finish' really means now so I make a wild
guess while updating comments about it.
gdb/ChangeLog
2015-05-13 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdbthread.h (struct thread_control_state): Update comment for
proceed_to_finish.
* infcall.c (run_inferior_call): Update comment about
proceed_to_finish.
* infcmd.c (get_return_value): Update comment about stop_registers.
(finish_forward): Update comment about proceed_to_finish.
* infrun.c (stop_registers): Remove.
(clear_proceed_status, normal_stop): Remove stop_registers handling.
* infrun.h (stop_registers): Remove.
With dummy_frame destructors GDB no longer has to use global stop_registers.
dummy_frame's registers can be now stored associated with their specific
dummy_frame.
gdb/ChangeLog
2015-05-13 Jan Kratochvil <jan.kratochvil@redhat.com>
* infcall.c (struct dummy_frame_context_saver)
(dummy_frame_context_saver_data_free, dummy_frame_context_saver_dtor)
(dummy_frame_context_saver_drop, dummy_frame_context_saver_cleanup)
(dummy_frame_context_saver_get_regs, dummy_frame_context_saver_setup):
New.
(call_function_by_hand_dummy): Move discard_cleanups of
inf_status_cleanup before dummy_frame_push. Call
dummy_frame_context_saver_setup and prepare context_saver_cleanup.
Use dummy_frame_context_saver_get_regs instead of stop_registers.
* infcall.h (struct dummy_frame_context_saver)
(dummy_frame_context_saver_drop, dummy_frame_context_saver_cleanup)
(dummy_frame_context_saver_get_regs, dummy_frame_context_saver_setup):
New declarations.
* infcmd.c: Include infcall.h.
(get_return_value): Add parameter ctx_saver, use it instead of
stop_registers.
(print_return_value): Add parameter ctx_saver, pass it.
(struct finish_command_continuation_args): Add field ctx_saver.
(finish_command_continuation): Update print_return_value caller.
(finish_command_continuation_free_arg): Free also ctx_saver.
(finish_forward): Call dummy_frame_context_saver_setup.
* inferior.h (struct dummy_frame_context_saver): New declaration.
(get_return_value): Add parameter ctx_saver.
* python/py-finishbreakpoint.c (bpfinishpy_pre_stop_hook): Update
get_return_value caller.
Later patch needs two independent destructors for the same dummy_frame.
Therefore the registrar has been extended to an arbitrary number of
destructors.
gdb/ChangeLog
2015-05-13 Jan Kratochvil <jan.kratochvil@redhat.com>
* dummy-frame.c (struct dummy_frame_dtor_list): New.
(struct dummy_frame): Replace dtor and dtor_data by dtor_list.
(remove_dummy_frame): Process dtor_list.
(pop_dummy_frame): Process dtor_list.
(register_dummy_frame_dtor): Maintain dtor_list.
(find_dummy_frame_dtor): Handle dtor_list.
* dummy-frame.h (register_dummy_frame_dtor, find_dummy_frame_dtor):
Update comments.
There was now a leak-like bug that if dummy_frame "disappeared" by
remove_dummy_frame then its destructor was not called. For example in the case
of 'compile code' dummy frames the injected objfile would never get freed after
some inferior longjmp out of the injected code.
gdb/ChangeLog
2015-05-13 Jan Kratochvil <jan.kratochvil@redhat.com>
* compile/compile-object-run.c (do_module_cleanup): Add parameter
registers_valid.
(compile_object_run): Update do_module_cleanup caller.
* dummy-frame.c: Include infcall.h.
(struct dummy_frame): Update dtor comment.
(remove_dummy_frame): Call dtor.
(pop_dummy_frame): Update dtor caller.
* dummy-frame.h (dummy_frame_dtor_ftype): Add parameter
registers_valid.
As this change was ported to GDB 7.9.1, the NEWS entry is moved to
a newly-created "Changes in GDB 7.9.1" section, matching the NEWS
file which is going to be distributed with the GDB 7.9.1 release.
gdb/ChangeLog:
* NEWS: Create "Changes in GDB 7.9.1" section. Move news about
Xmethods now being able to specify a result type to that new
section.
The control variable win_resized must be cleared before responding to
it.
Otherwise there is a small window where another SIGWINCH might occur in
between the handling of an earlier SIGWINCH and the clearing of
win_resized, at which point win_resized would be set (again) by the
signal handler. Shortly thereafter we would clear win_resized even
though we only handled the earlier SIGWINCH but not the latest one.
This chain of events is all avoided if we clear win_resized first.
gdb/ChangeLog:
* tui/tui-win.c (tui_async_resize_screen): Clear win_resized
first before resizing the window.
* tui.c (tui_enable): Likewise.
Both dummy_frame_dtor_ftype and call_function_by_hand_dummy_dtor_ftype
represent the same type, there was some mistake/duplication during check-in.
gdb/ChangeLog
2015-05-08 Jan Kratochvil <jan.kratochvil@redhat.com>
* dummy-frame.c (struct dummy_frame): Use proper typedef for dtor.
* dummy-frame.h (dummy_frame_dtor_ftype): Add its comment.
* infcall.c (call_function_by_hand_dummy): Use proper typedef for
dummy_dtor parameter.
* infcall.h: Include dummy-frame.h.
(call_function_by_hand_dummy_dtor_ftype): Remove.
(call_function_by_hand_dummy): Use proper typedef for dummy_dtor
parameter.
This patch is a comprehensive fix for PR 17820 which reports that
using "set history size unlimited" inside one's gdbinit file doesn't
really work.
There are three small changes in this patch. The most important change
this patch makes is to decode the argument of the "size" subcommand
using add_setshow_zuinteger_unlimited_cmd() instead of using
add_setshow_uinteger_cmd(). The new decoder takes an int * and maps
unlimited to -1 whereas the old decoder takes an unsigned int * and maps
unlimited to UINT_MAX. Using the new decoder simplifies our handling of
unlimited and makes it easier to interface with readline which itself
expects a signed-int history size.
The second change is the factoring of the [stifle|unstifle]_history logic
into a common function which is now used by both init_history() and
set_history_size_command(). This is technically the change that fixes
the PR itself.
Thirdly, this patch initializes history_size_setshow_var to -2 to mean
that the variable has not been set yet. Now init_history() tests for -2
instead of 0 to determine whether to give the variable a default value.
This means that having "set history size 0" in one's gdbinit file will
actually keep the history size at 0 and not reset it to 256.
gdb/ChangeLog:
PR gdb/17820
* top.c (history_size_setshow_var): Change type to signed.
Initialize to -2. Update documentation.
(set_readline_history_size): Define.
(set_history_size_command): Use it. Remove logic for handling
out-of-range sizes.
(init_history): Use set_readline_history_size(). Test for a
value of -2 instead of 0 when determining whether to set a
default history size.
(init_main): Decode the argument of the "size" command as a
zuinteger_unlimited.
gdb/testsuite/ChangeLog:
PR gdb/17820
* gdb.base/gdbinit-history.exp: New test.
* gdb.base/gdbinit-history/unlimited/.gdbinit: New file.
* gdb.base/gdbinit-history/zero/.gdbinit: New file.
This patch contains the accumulated documentation changes for the
rest of the extended-remote follow fork patchset.
gdb/ChangeLog:
* NEWS: Announce fork support in the RSP and support
for fork debugging in extended mode.
gdb/doc/ChangeLog:
* gdb.texinfo (Forks): Note that fork debugging is
supported in extended mode.
(Remote Configuration): Add fork event features to table
of packet settings.
(Stop Reply Packets): Add fork events to list of stop reasons.
(General Query Packets): Add fork events to tables of
'gdbfeatures' and 'stub features' supported in the qSupported
packet, as well as to the list containing stub feature
details.
This patch implements catchpoints for fork events on extended-remote
Linux targets.
Implementation appeared to be straightforward, requiring four new functions
in remote.c to implement insert/remove of fork/vfork catchpoints. These
functions are essentially stubs that just return 0 ('success') if the
required features are enabled. If the fork events are being reported, then
catchpoints are set and hit.
However, there are some extra issues that arise with catchpoints.
1) Thread creation reporting -- fork catchpoints are hit before the
follow_fork has been completed. When stopped at a fork catchpoint
in the native implementation, the new process is not 'reported'
until after the follow is done. It doesn't show up in the inferiors
list or the threads list. However, in the gdbserver case, an
'info threads' while stopped at a fork catchpoint will retrieve the
new thread info from the target and add it to GDB's data structures,
prior to the follow operations. Because of this premature report,
things on the GDB side eventually get very confused.
So in remote.c:remote_update_thread_list, we check to see if there
are any pending fork parent threads. If there are we remove the
related fork child thread from the thread list sent by the target.
2) Kill process before fork is followed -- on the native side in
linux-nat.c:linux_nat_kill, there is some code to handle the case where
a fork has occurred but follow_fork hasn't been called yet. It does
this by using the last status to determine if a follow is pending, and
if it is, to kill the child task. The use of last_status is fragile
in situations like non-stop mode where other events may have occurred
after the fork event. This patch identifies a fork parent
in remote.c:extended_remote_kill in a way similar to that used in
thread creation reporting above. If one is found, it kills the new
child as well.
Tested on x64 Ubuntu Lucid, native, remote, extended-remote. Tested the
case of killing the forking process before the fork has been followed
manually.
gdb/ChangeLog:
* remote.c (remote_insert_fork_catchpoint): New function.
(remote_remove_fork_catchpoint): New function.
(remote_insert_vfork_catchpoint): New function.
(remote_remove_vfork_catchpoint): New function.
(pending_fork_parent_callback): New function.
(remove_new_fork_child): New function.
(remote_update_thread_list): Call remote_notif_get_pending_events
and remove_new_fork_child.
(extended_remote_kill): Kill fork child when killing the
parent before follow_fork completes.
(init_extended_remote_ops): Initialize target vector with
new fork catchpoint functions.
This patch implements follow-fork for vfork on extended-remote Linux targets.
The implementation follows the native implementation as much as possible.
Most of the work is done on the GDB side in the existing code now in
infrun.c. GDBserver just has to report the events and do a little
bookkeeping.
Implementation includes:
* enabling VFORK events by adding ptrace options for VFORK and VFORK_DONE
to linux-low.c:linux_low_ptrace_options.
* handling VFORK and VFORK_DONE events in linux-low.c:handle_extended_wait
and reporting them to GDB.
* including VFORK and VFORK_DONE events in the predicate
linux-low.c:extended_event_reported.
* adding support for VFORK and VFORK_DONE events in RSP by adding stop
reasons "vfork" and "vforkdone" to the 'T' Stop Reply Packet in both
gdbserver/remote-utils.c and gdb/remote.c.
Tested on x64 Ubuntu Lucid, native, remote, extended-remote.
gdb/gdbserver/ChangeLog:
* linux-low.c (handle_extended_wait): Handle PTRACE_EVENT_FORK and
PTRACE_EVENT_VFORK_DONE.
(linux_low_ptrace_options, extended_event_reported): Add vfork
events.
* remote-utils.c (prepare_resume_reply): New stop reasons "vfork"
and "vforkdone" for RSP 'T' Stop Reply Packet.
* server.h (report_vfork_events): Declare
global variable.
gdb/ChangeLog:
* remote.c (remove_vfork_event_p): New function.
(remote_follow_fork): Add vfork event type to event checking.
(remote_parse_stop_reply): New stop reasons "vfork" and
"vforkdone" for RSP 'T' Stop Reply Packet.
This patch implements the architecture-specific pieces of follow-fork
for remote and extended-remote Linux targets, which in the current
implementation copyies the parent's debug register state into the new
child's data structures. This is required for x86, arm, aarch64, and
mips.
This follows the native implementation as closely as possible by
implementing a new linux_target_ops function 'new_fork', which is
analogous to 'linux_nat_new_fork' in linux-nat.c. In gdbserver, the debug
registers are stored in the process list, instead of an
architecture-specific list, so the function arguments are process_info
pointers instead of an lwp_info and a pid as in the native implementation.
In the MIPS implementation the debug register mirror is stored differently
from x86, ARM, and aarch64, so instead of doing a simple structure assignment
I had to clone the list of watchpoint structures.
Tested using gdb.threads/watchpoint-fork.exp on x86, and ran manual tests
on a MIPS board and an ARM board. Aarch64 hasn't been tested.
gdb/gdbserver/ChangeLog:
* linux-aarch64-low.c (aarch64_linux_new_fork): New function.
(the_low_target) <new_fork>: Initialize new member.
* linux-arm-low.c (arm_new_fork): New function.
(the_low_target) <new_fork>: Initialize new member.
* linux-low.c (handle_extended_wait): Call new target function
new_fork.
* linux-low.h (struct linux_target_ops) <new_fork>: New member.
* linux-mips-low.c (mips_add_watchpoint): New function
extracted from mips_insert_point.
(the_low_target) <new_fork>: Initialize new member.
(mips_linux_new_fork): New function.
(mips_insert_point): Call mips_add_watchpoint.
* linux-x86-low.c (x86_linux_new_fork): New function.
(the_low_target) <new_fork>: Initialize new member.
This patch implements basic support for follow-fork and detach-on-fork on
extended-remote Linux targets. Only 'fork' is supported in this patch;
'vfork' support is added n a subsequent patch. This patch depends on
the previous patches in the patch series.
Sufficient extended-remote functionality has been implemented here to pass
gdb.base/multi-forks.exp, as well as gdb.base/foll-fork.exp with the
catchpoint tests commented out. Some other fork tests fail with this
patch because it doesn't provide the architecture support needed for
watchpoint inheritance or fork catchpoints.
The implementation follows the same general structure as for the native
implementation as much as possible.
This implementation includes:
* enabling fork events in linux-low.c in initialize_low and
linux_enable_extended_features
* handling fork events in gdbserver/linux-low.c:handle_extended_wait
- when a fork event occurs in gdbserver, we must do the full creation
of the new process, thread, lwp, and breakpoint lists. This is
required whether or not the new child is destined to be
detached-on-fork, because GDB will make target calls that require all
the structures. In particular we need the breakpoint lists in order
to remove the breakpoints from a detaching child. If we are not
detaching the child we will need all these structures anyway.
- as part of this event handling we store the target_waitstatus in a new
member of the parent lwp_info structure, 'waitstatus'. This
is used to store extended event information for reporting to GDB.
- handle_extended_wait is given a return value, denoting whether the
handled event should be reported to GDB. Previously it had only
handled clone events, which were never reported.
* using a new predicate in gdbserver to control handling of the fork event
(and eventually all extended events) in linux_wait_1. The predicate,
extended_event_reported, checks a target_waitstatus.kind for an
extended ptrace event.
* implementing a new RSP 'T' Stop Reply Packet stop reason: "fork", in
gdbserver/remote-utils.c and remote.c.
* implementing new target and RSP support for target_follow_fork with
target extended-remote. (The RSP components were actually defined in
patch 1, but they see their first use here).
- remote target routine remote_follow_fork, which just sends the 'D;pid'
detach packet to detach the new fork child cleanly. We can't just
call target_detach because the data structures for the forked child
have not been allocated on the host side.
Tested on x64 Ubuntu Lucid, native, remote, extended-remote.
gdb/gdbserver/ChangeLog:
* linux-low.c (handle_extended_wait): Implement return value,
rename argument 'event_child' to 'event_lwp', handle
PTRACE_EVENT_FORK, call internal_error for unrecognized event.
(linux_low_ptrace_options): New function.
(linux_low_filter_event): Call linux_low_ptrace_options,
use different argument fo linux_enable_event_reporting,
use return value from handle_extended_wait.
(extended_event_reported): New function.
(linux_wait_1): Call extended_event_reported and set
status to report fork events.
(linux_write_memory): Add pid to debug message.
(reset_lwp_ptrace_options_callback): New function.
(linux_handle_new_gdb_connection): New function.
(linux_target_ops): Initialize new structure member.
* linux-low.h (struct lwp_info) <waitstatus>: New member.
* lynx-low.c: Initialize new structure member.
* remote-utils.c (prepare_resume_reply): Implement stop reason
"fork" for "T" stop message.
* server.c (handle_query): Call handle_new_gdb_connection.
* server.h (report_fork_events): Declare global flag.
* target.h (struct target_ops) <handle_new_gdb_connection>:
New member.
(target_handle_new_gdb_connection): New macro.
* win32-low.c: Initialize new structure member.
gdb/ChangeLog:
* linux-nat.c (linux_nat_ptrace_options): New function.
(linux_init_ptrace, wait_lwp, linux_nat_filter_event):
Call linux_nat_ptrace_options and use different argument to
linux_enable_event_reporting.
(_initialize_linux_nat): Delete call to
linux_ptrace_set_additional_flags.
* nat/linux-ptrace.c (current_ptrace_options): Rename to
supported_ptrace_options.
(additional_flags): Delete variable.
(linux_check_ptrace_features): Use supported_ptrace_options.
(linux_test_for_tracesysgood, linux_test_for_tracefork):
Likewise, and remove additional_flags check.
(linux_enable_event_reporting): Change 'attached' argument to
'options'. Use supported_ptrace_options.
(ptrace_supports_feature): Change comment. Use
supported_ptrace_options.
(linux_ptrace_set_additional_flags): Delete function.
* nat/linux-ptrace.h (linux_ptrace_set_additional_flags):
Delete function prototype.
* remote.c (remote_fork_event_p): New function.
(remote_detach_pid): New function.
(remote_detach_1): Call remote_detach_pid, don't mourn inferior
if doing detach-on-fork.
(remote_follow_fork): New function.
(remote_parse_stop_reply): Handle new "T" stop reason "fork".
(remote_pid_to_str): Print "process" strings for pid/0/0 ptids.
(init_extended_remote_ops): Initialize to_follow_fork.
This patch implements gdbserver routines to clone the breakpoint lists of a
process, duplicating them for another process. In gdbserver, each process
maintains its own independent breakpoint list. When a fork call creates a
child, all of the breakpoints currently inserted in the parent process are
also inserted in the child process, but there is nothing to describe them
in the data structures related to the child. The child must have a
breakpoint list describing them so that they can be removed (if detaching)
or recognized (if following). Implementation is a mechanical process of
just cloning the lists in several new functions in gdbserver/mem-break.c.
Tested by building, since none of the new functions are called yet. This
was tested with another patch in the series that implements follow-fork.
gdb/gdbserver/ChangeLog:
* mem-break.c (APPEND_TO_LIST): Define macro.
(clone_agent_expr): New function.
(clone_one_breakpoint): New function.
(clone_all_breakpoints): New function.
* mem-break.h: Declare new functions.
This patch implements a mechanism for GDB to determine whether fork
events are supported in gdbserver. This is a preparatory patch for
remote fork and exec event support.
Two new RSP packets are defined to represent fork and vfork event
support. These packets are used just like PACKET_multiprocess_feature
to denote whether the corresponding event is supported. GDB sends
fork-events+ and vfork-events+ to gdbserver to inquire about fork
event support. If the response enables these packets, then GDB
knows that gdbserver supports the corresponding events and will
enable them.
Target functions used to query for support are included along with
each new packet.
In order for gdbserver to know whether the events are supported at the
point where the qSupported packet arrives, the code in nat/linux-ptrace.c
had to be reorganized. Previously it would test for fork/exec event
support, then enable the events using the pid of the inferior. When the
qSupported packet arrives there may not be an inferior. So the mechanism
was split into two parts: a function that checks whether the events are
supported, called when gdbserver starts up, and another that enables the
events when the inferior stops for the first time.
Another gdbserver change was to add some global variables similar to
multi_process, one per new packet. These are used to control whether
the corresponding fork events are enabled. If GDB does not inquire
about the event support in the qSupported packet, then gdbserver will
not set these "report the event" flags. If the flags are not set, the
events are ignored like they were in the past. Thus, gdbserver will
never send fork event notification to an older GDB that doesn't
recognize fork events.
Tested on Ubuntu x64, native/remote/extended-remote, and as part of
subsequent patches in the series.
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_supports_fork_events): New function.
(linux_supports_vfork_events): New function.
(linux_target_ops): Initialize new structure members.
(initialize_low): Call linux_check_ptrace_features.
* lynx-low.c (lynx_target_ops): Initialize new structure
members.
* server.c (report_fork_events, report_vfork_events):
New global flags.
(handle_query): Add new features to qSupported packet and
response.
(captured_main): Initialize new global variables.
* target.h (struct target_ops) <supports_fork_events>:
New member.
<supports_vfork_events>: New member.
(target_supports_fork_events): New macro.
(target_supports_vfork_events): New macro.
* win32-low.c (win32_target_ops): Initialize new structure
members.
gdb/ChangeLog:
* nat/linux-ptrace.c (linux_check_ptrace_features): Change
from static to extern.
* nat/linux-ptrace.h (linux_check_ptrace_features): Declare.
* remote.c (anonymous enum): <PACKET_fork_event_feature,
* PACKET_vfork_event_feature>: New enumeration constants.
(remote_protocol_features): Add table entries for new packets.
(remote_query_supported): Add new feature queries to qSupported
packet.
(_initialize_remote): Exempt new packets from the requirement
to have 'set remote' commands.
This commit allows GDB to determine filenames of main executables
when debugging using remote stubs without multiprocess extensions.
The qXfer:exec-file:read packet is extended to allow an empty
annex, with the meaning that the remote stub should supply the
filename of whatever it thinks is the current process.
gdb/ChangeLog:
* remote.c (remote_add_inferior): Call exec_file_locate_attach
for fake PIDs as well as real ones.
(remote_pid_to_exec_file): Send empty annex if PID is fake.
gdb/doc/ChangeLog:
* gdb.texinfo (General Query Packets): Document
qXfer:exec-file:read with empty annex.
gdb/gdbserver/ChangeLog:
* server.c (handle_qxfer_exec_file): Use current process
if annex is empty.
2015-05-08 Yao Qi <yao@codesourcery.com>
Sandra Loosemore <sandra@codesourcery.com>
gdb/
* dwarf2read.c (setup_type_unit_groups): Do NULL pointer check
to 'lh->include_dirs' before accessing to it.
(psymtab_include_file_name): Likewise.
(dwarf_decode_lines_1): Likewise.
(dwarf_decode_lines): Likewise.
(file_file_name): Likewise.
2015-05-08 Sandra Loosemore <sandra@codesourcery.com>
gdb/gdbserver/
* linux-nios2-low.c: Include elf/common.h. Adjust comments.
Remove HAVE_PTRACE_GETREGS conditionals.
(nios2_regsets): Use PTRACE_GETREGSET and PTRACE_SETREGSET
instead of PTRACE_GETREGS and PTRACE_SETREGS.
2015-05-08 Sandra Loosemore <sandra@codesourcery.com>
gdb/
* nios2-tdep.c (nios2_breakpoint_from_pc): Revert to using
"trap 31" as the breakpoint instruction on all targets.
In my last commit to make gdb.base/coredump-filter.exp be more robust
regarding using arrays in the global namespace, I cleared the
"coredump_var_addr" array like this:
set coredump_var_addr ""
# use coredump_var_addr as an array...
This causes DejaGNU to complain because the variable is first set as
non-array, and the used as an array. The correct way to do this is to
unset the variable using:
unset -nocomplain coredump_var_addr
# use coredump_var_addr as an array...
The "-nocomplain" part is necessary because if the variable doesn't
exist "unset" will not error.
Tested on Fedora 20 x86_64.
gdb/testsuite/ChangeLog:
2015-05-08 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/coredump-filter.exp: Correctly unset
"coredump_var_addr" array.
Sequential test runs are stopping prematurely like this:
$ make check RUNTESTFLAGS="non-existing-program.exp server-exec-info.exp"
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.server/non-existing-program.exp ...
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.server/server-exec-info.exp ...
can not find channel named "exp6"
while executing
"match_max [match_max -d]"
(procedure "default_gdb_init" line 26)
invoked from within
"default_gdb_init $test_file_name"
(procedure "gdb_init" line 83)
invoked from within
"${tool}_init $test_file_name"
(procedure "runtest" line 18)
invoked from within
"runtest $test_name"
("foreach" body line 42)
invoked from within
...
make[2]: *** [check-single] Error 1
make[2]: Leaving directory `/home/pedro/gdb/mygit/build/gdb/testsuite'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/home/pedro/gdb/mygit/build/gdb/testsuite'
make: *** [check] Error 2
default_gdb_init has this:
# Unlike most tests, we have a small number of tests that generate
# a very large amount of output. We therefore increase the expect
# buffer size to be able to contain the entire test output. This
# is especially needed by gdb.base/info-macros.exp.
match_max -d 65536
# Also set this value for the currently running GDB.
match_max [match_max -d]
It's the second match_max that is erroring. As that call does not
specify an explicit channel name with -i, expect defaults to
$spawn_id, which is pointing at a channel that is already gone. (If
the spawn_id variable is not set, match_max defaults to
$user_spawn_id / stdin/out).
gdb/testsuite/ChangeLog:
2015-05-08 Pedro Alves <palves@redhat.com>
* gdb.server/non-existing-program.exp: Unset spawn_id.
Consider the following declarations...
type Obj_T (Selected_Flights_Length : Natural) is
record
Selected_Flights : Flights.List.T (1 .. Selected_Flights_Length);
end record;
Broken : Obj_T;
... which defines a variable named "broken" which is a discrimated
record where broken.Selected_Flights is an array whose upper bound
is stored in the record's Selected_Flights_Length component.
Trying to print the value of that object currently fails:
(gdb) print broken
cannot find reference address for offset property
Looking at the debugging info, we see that variable "Broken" is
a reference...
<1><8e3>: Abbrev Number: 21 (DW_TAG_const_type)
<8e4> DW_AT_type : <0x8e8>
<1><8e8>: Abbrev Number: 22 (DW_TAG_reference_type)
<8e9> DW_AT_byte_size : 8
<8ea> DW_AT_type : <0x7ec>
... to ...
<1><7ec>: Abbrev Number: 12 (DW_TAG_structure_type)
<7ed> DW_AT_name : (indirect string, offset: 0xc6d): reprod__obj_t
<7f1> DW_AT_decl_file : 2
<7f2> DW_AT_decl_line : 15
<7f3> DW_AT_GNAT_descriptive_type: <0x87e>
<7f7> DW_AT_sibling : <0x87e>
... which has 2 members, the first one being the discriminant...
<2><7fb>: Abbrev Number: 9 (DW_TAG_member)
<7fc> DW_AT_name : (indirect string, offset: 0xc98): selected_flights_length
<800> DW_AT_decl_file : 2
<801> DW_AT_decl_line : 15
<802> DW_AT_type : <0x807>
<806> DW_AT_data_member_location: 0
... and the second one being the one that causes trouble...
<2><83d>: Abbrev Number: 9 (DW_TAG_member)
<83e> DW_AT_name : (indirect string, offset: 0xd17): selected_flights
<842> DW_AT_decl_file : 2
<843> DW_AT_decl_line : 17
<844> DW_AT_type : <0x815>
<848> DW_AT_data_member_location: 4
The second field's type is an array....
<2><815>: Abbrev Number: 14 (DW_TAG_array_type)
<816> DW_AT_name : (indirect string, offset: 0xd2f): reprod__obj_t__T5sP
<81a> DW_AT_GNAT_descriptive_type: <0x7e1>
<81e> DW_AT_type : <0x748>
<822> DW_AT_sibling : <0x830>
... whose uppper bound is a reference to <0x7fb>...
<3><826>: Abbrev Number: 15 (DW_TAG_subrange_type)
<827> DW_AT_type : <0x830>
<82b> DW_AT_upper_bound : <0x7fb>
<3><82f>: Abbrev Number: 0
Because the upper bound is dynamic, we try to resolve it.
As it happens, the upper-bound resolution for this range type
works fine. What breaks is when we try to resolve this range
type's target type, which is:
<2><830>: Abbrev Number: 16 (DW_TAG_subrange_type)
<831> DW_AT_upper_bound : <0x7fb>
<835> DW_AT_name : (indirect string, offset: 0xc7b): reprod__obj_t__T4s___XDLU_1__selected_flights_length
<839> DW_AT_type : <0x766>
<83d> DW_AT_artificial : 1
It is actually pretty much the same as the first subrange type,
so you might ask why this is causing trouble, when the resolution
of the previous DIE worked like a charm???
Well, for that, we need to backtrack a bit, and notice that, ahead
of the DW_TAG_structure_type's DIE, there is the following DIE:
<1><7e1>: Abbrev Number: 6 (DW_TAG_typedef)
<7e2> DW_AT_name : (indirect string, offset: 0xbae): reprod__obj_t__T5s
<7e6> DW_AT_decl_file : 2
<7e7> DW_AT_decl_line : 17
<7e8> DW_AT_type : <0x849>
... and that DIE references an array type...
<2><849>: Abbrev Number: 14 (DW_TAG_array_type)
<84a> DW_AT_name : (indirect string, offset: 0xbae): reprod__obj_t__T5s
<84e> DW_AT_GNAT_descriptive_type: <0x864>
<852> DW_AT_type : <0x748>
<856> DW_AT_sibling : <0x864>
... whose subrange is...
<3><85a>: Abbrev Number: 15 (DW_TAG_subrange_type)
<85b> DW_AT_type : <0x830>
<85f> DW_AT_upper_bound : <0x7fb>
... where the subrange's base type is the DW_TAG_subrange_type DIE
that is causing problem.
In summary, we process the typedef first, which causes us to process
the second subrange BEFORE we process the struct DIE itself, and
therefore the struct's discriminent (DW_TAG_member #1). As a result,
while trying to handle the reference to that DW_TAG_member #1 as
the upper bound of the second range type, we do...
case DW_AT_data_member_location:
{
[...]
baton->referenced_type = get_die_type (target_die->parent,
target_cu);
... where target_die->parent (DW_TAG_member #1) hasn't been processed
yet, and thus get_die_type returns NULL.
This is what later causes us problems trying to find the right address
to use as the base address for our field, which then triggers the
error message we are seeing.
This patch fixes the issue by calling read_type_die instead of
get_die_type. If the DIE has already been processed, then this
is the same as get_die_type. If not, the it'll get the parent
die to be read, and then get its type.
gdb/ChangeLog:
* dwarf2read.c (attr_to_dynamic_prop)
<DW_AT_data_member_location>: Use read_type_die isntead of
get_die_type.
Tested on x86_64-linux, no regression.
No testcase, unfortunately, as the reproducer was given to us by
a customer, and it's been otherwise surprisingly difficult to
reproduce the same error outside of that reproducer.
We observed on x86-windows that trying to call a function from
GDB leads to a mysterious "Invalid cast" error. This can be
observed in gdb.ada/float_param.exp:
(gdb) call set_long_double(1, global_small_struct, 4.0)
Invalid cast.
This happens because the 3rd parameter, a Long_Long_Float, is
actually passed wrapped inside a PAD structure. As documented
in GNAT's exp_dbug.ads, PAD types are simple wrappers that GNAT
uses to handle types with size or alignment constraints.
We already support those when printing an object encapsulated
in a PAD type, but not when trying to pass an argument that
is wrapped inside a PAD type. As a result, what happens is that
call_function_by_hand ends up with an argument with a type
that looks incompatible with the expected type of the argument.
The error comes when trying to push the arguments in inferior
memory, while trying to coerce each one of them to their expected
types (in value_arg_coerce).
Note that the problem is not specific to Windows, but so far, this is
the only platform where we've seen this happen.
gdb/ChangeLog:
* ada-lang.c (ada_convert_actual): Add handling of formals
passed inside an aligner type.
Tested on x86-windows (AdaCore testsuite) and x86_64-linux (official
testsuite as well as AdaCore's testsuite).
Now that the erc32 files have been updated to contain an FSF copyright
header, these files should no longer be in the exclude list.
gdb/ChangeLog:
* copyright.py (NOT_FSF_LIST): Remove sim/erc32 entries.
Hi,
We see some fails in gdb.base/coredump-filter.exp when we do remote
gdbserver testing, like what I did for arm/aarch64 linux testing or
run it with board file remote-gdbserver-on-localhost
$ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost coredump-filter.exp'
we find that this line in the test doesn't work as expected,
remote_exec target "sh -c \"echo $filter_flag > /proc/$ipid/coredump_filter\""
although such pattern has been used in gdb testsuite somewhere else,
but the special thing here is that we redirect the output to
/proc/$ipid/coredump_filter on the remote target. DejaGNU will
redirect the output from the remote target to local, and looks tcl
gets confused by these two redirection.
After trying pass different parameters to remote_exec and hacking
remote_exec/rsh_exec/local_exec, I got no success, I decide
to give up, and try to update /proc/$ipid/coredump_filter by the c
code directly.
This patch adds a c function set_coredump_filter to update
coredump_filter, and GDB calls it.
gdb/testsuite:
2015-05-08 Yao Qi <yao.qi@linaro.org>
PR gdb/18208
* gdb.base/coredump-filter.c (set_coredump_filter): New function.
* gdb.base/coredump-filter.exp (do_save_core): Call inferior
function set_coredump_filter, and remove remote_exec call.
Remove argument ipid. Callers update.
(top level): Don't get inferior's PID.
GDBserver steps over breakpoint if the condition is false, but if target
doesn't support hardware single step, the step over is very simple, if
not incorrect, in linux-arm-low.c:
/* We only place breakpoints in empty marker functions, and thread locking
is outside of the function. So rather than importing software single-step,
we can just run until exit. */
static CORE_ADDR
arm_reinsert_addr (void)
{
struct regcache *regcache = get_thread_regcache (current_thread, 1);
unsigned long pc;
collect_register_by_name (regcache, "lr", &pc);
return pc;
}
and linux-mips-low.c does the same. GDBserver sets a breakpoint at the
return address of the current function, resume and wait the program hits
the breakpoint in order to achieve "breakpoint step over". What if
program hits other user breakponits during this "step over"?
It is worse if the arm/thumb interworking is considered. Nowadays,
GDBserver arm backend unconditionally inserts arm breakpoint,
/* Define an ARM-mode breakpoint; we only set breakpoints in the C
library, which is most likely to be ARM. If the kernel supports
clone events, we will never insert a breakpoint, so even a Thumb
C library will work; so will mixing EABI/non-EABI gdbserver and
application. */
(const unsigned char *) &arm_breakpoint,
(const unsigned char *) &arm_eabi_breakpoint,
note that the comments are no longer valid as C library can be compiled
in thumb mode.
When GDBserver steps over a breakpoint in arm mode function, which
returns to thumb mode, GDBserver will insert arm mode breakpoint by
mistake and the program will crash. GDBserver alone is unable to
determine the arm/thumb mode given a PC address. See how GDB does
it in arm-tdep.c:arm_pc_is_thumb.
After thinking about how to teach GDBserver inserting right breakpoint
(arm or thumb) for a while, I reconsider it from a different direction
that it may be unreasonable to run target-side conditional breakpoint for
targets without hardware single step. Pedro also pointed this out here
https://sourceware.org/ml/gdb-patches/2015-04/msg00337.html
This patch is to add a new target_ops hook
supports_conditional_breakpoints, and only reply
";ConditionalBreakpoints+" if it is true. On linux targets,
supports_conditional_breakpoints returns true if target has hardware
single step, on other targets, (win32, lynx, nto, spu), set it to NULL,
because conditional breakpoint is a linux-specific feature.
gdb/gdbserver:
2015-05-08 Yao Qi <yao.qi@linaro.org>
* linux-low.c (linux_supports_conditional_breakpoints): New
function.
(linux_target_ops): Install new target method.
* lynx-low.c (lynx_target_ops): Install NULL hook for
supports_conditional_breakpoints.
* nto-low.c (nto_target_ops): Likewise.
* spu-low.c (spu_target_ops): Likewise.
* win32-low.c (win32_target_ops): Likewise.
* server.c (handle_query): Check
target_supports_conditional_breakpoints.
* target.h (struct target_ops) <supports_conditional_breakpoints>:
New field.
(target_supports_conditional_breakpoints): New macro.
On 64-bit S390 platforms, for programs compiled with -m31, it could
happen that GDB inadvertently cleared the inferior's 31-bit addressing
mode bit and left the inferior running in 24-bit addressing mode. In
particular this occurred with checkpoint.exp, when the "restore"
command needed to create a new regcache copy: At the time when the
PSWM register was copied over, the addressing mode bit was taken from
the PSWA register, which was still zero since it had not been copied
yet. And when the PSWA register was copied, the addressing mode was
not updated again.
The fix affects fill_gregset, where the bits "belonging" to each of
the PSWA and PSWM registers are now carefully separated. The
addressing mode bit is no longer touched when writing PSWM, and --
more importantly -- it *is* written when writing PSWA.
gdb/ChangeLog:
* s390-linux-nat.c (fill_gregset): Avoid relying on the PSWA
register in the regcache when treating the PSWM register, and vice
versa.
Since watch_thread_num.exp was changed to use access watchpoints, the
test case fails on s390 and s390x, since those targets do not support
access watchpoints. This patch skips the test case on such targets.
gdb/testsuite/ChangeLog:
* gdb.base/watch_thread_num.exp: Skip test on targets without
access watchpoints.
linux-thread-db.c initializes td_ta_map_id2thr but never uses it.
This commit removes this dead code.
gdb/ChangeLog:
* linux-thread-db.c (struct thread_db_info)
<td_ta_map_id2thr_p>: Remove field.
(try_thread_db_load_1): Remove initialization for the above.
linux-thread-db.c initializes td_thr_validate but never uses it.
This commit removes this dead code.
gdb/ChangeLog:
* linux-thread-db.c (struct thread_db_info)
<td_thr_validate_p>: Remove field.
(try_thread_db_load_1): Remove initialization for the above.
Calling memcpy() could fail as memcpy() from libc is GNU-IFUNC.
gdb/ChangeLog
2015-05-06 Jan Kratochvil <jan.kratochvil@redhat.com>
* compile/compile-object-load.c (compile_object_load): Support
mst_text_gnu_ifunc.
gdb/ChangeLog
2015-05-06 Jan Kratochvil <jan.kratochvil@redhat.com>
* compile/compile.c (compile_to_object): Make the cmd_string parameter
const. Use new variables for the const compatibility.
(eval_compile_command): Make the cmd_string parameter const.
* compile/compile.h (eval_compile_command): Make the cmd_string
parameter const.
$ ./gdbserver :1234 blah
Process blah created; pid = 16471
Cannot exec blah: No such file or directory.
Child exited with status 127
Killing process(es): 16471
../../../../src/binutils-gdb/gdb/gdbserver/linux-low.c:920: A problem internal to GDBserver has been detected.
kill_wait_lwp: Assertion `res > 0' failed.
GDBserver shouldn't even be trying to kill that process. GDBserver
kills or detaches from all processes on exit, and due to a missing
mourn_inferior call, GDBserver tries to kill the process that it had
already seen exit.
Tested on x86_64 Fedora 20. New test included. I emulated what
Windows outputs by hacking an error call in linux_create_inferior.
gdb/gdbserver/ChangeLog:
2015-05-06 Pedro Alves <palves@redhat.com>
PR server/18081
* server.c (start_inferior): If the process exits, mourn it.
gdb/testsuite/ChangeLog:
2015-05-06 Pedro Alves <palves@redhat.com>
PR server/18081
* gdb.server/non-existing-program.exp: New file.
This hook is no longer used, and can therefore be eliminated.
gdb/ChangeLog:
* defs.h (deprecated_init_ui_hook): Delete. Remove associated
comment.
* top.c (deprecated_init_ui_hook): Delete.
(gdb_init): Remove handling of deprecated_init_ui_hook.
* interps.c (clear_interpreter_hooks): Remove handling of
deprecated_init_ui_hook.
* main.c (captured_main): Update comment.
The "info dll", an alias of the "info sharedlibrary" command, is
currently only defined in windows native versions. This patch makes
it universally available by moving the alias declaration to solib.c,
and adjusts the documentation accordingly.
Making it universally available has two benefits:
- Windows users moving to a Unix platforms are still able to use
the same command for getting the list of shared libraries;
- Unix to Windows cross debuggers now provide that command also.
gdb/ChangeLog:
* solib.c (_initialize_solib): Add "info dll" alias creation.
* windows-nat.c (set_windows_aliases): Delete.
(_initialize_windows_nat): Remove deprecated_init_ui_hook
assignment.
* NEWS: Add news entry about "info dll" now being available
on all platforms.
gdb/doc/ChangeLog:
* gdb.texinfo (Files): Add "info dll" documentation.
(Cygwin Native): Remove "info dll" documentation.
This patch improves the documentation of ada-lang.c's
value_assign_to_component to publish the fact that it also works
with not_lval values.
And touching this area of the code showed that there were a number
of whitespace issues, as well as a formatting issue of the main comment
(no leading '*' on each line). This patch fixes those while at it.
No functional change, however.
gdb/ChangeLog:
* ada-lang.c (value_assign_to_component): Reformat and improve
documentation. Remove all trailing spaces.
This patch improves the handling of out-of-line functions nested
inside functions that have been inlined.
Consider for instance a situation where function Foo_O224_021
has a function Child1 declared in it, which itself has a function
Child2 nested inside Child1. After compiling the program with
optimization on, Child1 gets inlined, but not Child2.
After inserting a breakpoint on Child2, and running the program
until reaching that breakpoint, we get the following backtrace:
% gdb foo_o224_021
(gdb) break foo_o224_021.child1.child2
(gdb) run
[...]
Breakpoint 1, foo_o224_021 () at foo_o224_021.adb:28
28 Child1;
(gdb) bt
#0 0x0000000000402400 in foo_o224_021 () at foo_o224_021.adb:28
#1 0x00000000004027a4 in foo_o224_021.child1 () at foo_o224_021.adb:23
#2 0x00000000004027a4 in foo_o224_021 () at foo_o224_021.adb:28
GDB reports the wrong function name for frame #0. We also get the same
kind of error in the "Breakpoint 1, foo_o224_021 () [...]" message.
In both cases, the function name should be foo_o224_021.child1.child2,
and the parameters should be "s=...".
What happens is that the inlined frame handling does not handle well
the case where an inlined function is calling an out-of-line function
which was declared inside the inlined function's scope.
In particular, looking first at the inlined-frame sniffer when applying
to frame #0:
/* Calculate DEPTH, the number of inlined functions at this
location. */
depth = 0;
cur_block = frame_block;
while (BLOCK_SUPERBLOCK (cur_block))
{
if (block_inlined_p (cur_block))
depth++;
cur_block = BLOCK_SUPERBLOCK (cur_block);
}
What happens is that cur_block starts as the block associated
to child2, which is not inlined. We shoud be stopping here, but
instead, we keep walking the superblock chain, which takes us
all the way to Foo_O224_021's block, via Child2's block. And
since Child1 was inlined, we end up with a depth count of 1,
wrongly making GDB think that frame #0 is an inlined frame.
Same kind of issue inside skip_inline_frames.
The fix is to stop checking for inlined frames as soon as we see
a block corresponding to a function which is not inlined. This is
the behavior we now obtain:
(gdb) run
[...]
Breakpoint 1, foo_o224_021.child1.child2 (s=...) at foo_o224_021.adb:9
9 function Child2 (S : String) return Boolean is
(gdb) bt
#0 0x0000000000402400 in foo_o224_021.child1.child2 (s=...)
at foo_o224_021.adb:9
#1 0x00000000004027a4 in foo_o224_021.child1 () at foo_o224_021.adb:23
#2 0x00000000004027a4 in foo_o224_021 () at foo_o224_021.adb:28
gdb/ChangeLog:
* inline-frame.c (inline_frame_sniffer, skip_inline_frames):
Stop counting inlined frames as soon as an out-of-line function
is found.
gdb/testsuite/ChangeLog:
* gdb.ada/out_of_line_in_inlined.exp: Add run and "bt" tests.
Consider the following code, which defines a function, Child2,
which is itself nested inside Child1:
procedure Foo_O224_021 is
O1 : constant Object_Type := Get_Str ("Foo");
procedure Child1 is
O2 : constant Object_Type := Get_Str ("Foo");
function Child2 (S : String) return Boolean is -- STOP
begin
for C of S loop
Do_Nothing (C);
if C = 'o' then
return True;
end if;
end loop;
return False;
end Child2;
R : Boolean;
begin
R := Child2 ("Foo");
R := Child2 ("Bar");
R := Child2 ("Foobar");
end Child1;
begin
Child1;
end Foo_O224_021;
On x86_64-linux, when compiled at -O2, GDB is unable to insert
a breakpoint on Child2:
% gnatmake -g -O2 foo_o224_021
% gdb foo_o224_021
(gdb) b child2
Function "child2" not defined.
(gdb) b foo_o224_021.child1.child2
Function "foo_o224_021.child1.child2" not defined.
The problem is caused by the fact that GDB did not create a symbol
for Child2, and this, in turn, is caused by the fact that the compiler
decided to inline Child1, but not Child2. The DWARF debugging info
first provides an abstract instance tree for Child1...
<3><1b7b>: Abbrev Number: 29 (DW_TAG_subprogram)
<1b7c> DW_AT_name : (indirect string, offset: 0x23f8): foo_o224_021__child1
<1b82> DW_AT_inline : 1 (inlined)
<1b83> DW_AT_sibling : <0x1c01>
... where that subprogram is given the DW_AT_inline attribute.
Inside that function there is a lexical block which has no PC
range (corresponding to the fact that this is the abstract tree):
<4><1b87>: Abbrev Number: 30 (DW_TAG_lexical_block)
... inside which our subprogram Child2 is described:
<5><1b92>: Abbrev Number: 32 (DW_TAG_subprogram)
<1b93> DW_AT_name : (indirect string, offset: 0x2452): foo_o224_021__child1__child2
<1b99> DW_AT_type : <0x1ab1>
<1b9d> DW_AT_low_pc : 0x402300
<1ba5> DW_AT_high_pc : 0x57
[...]
Then, later on, we get the concrete instance tree, starting at:
<3><1c5e>: Abbrev Number: 41 (DW_TAG_inlined_subroutine)
<1c5f> DW_AT_abstract_origin: <0x1b7b>
<1c63> DW_AT_entry_pc : 0x4025fd
<1c6b> DW_AT_ranges : 0x150
... which refers to Child1. One of that inlined subroutine children
is the concrete instance of the empty lexical block we saw above
(in the abstract instance tree), which gives the actual address
range for this inlined instance:
<5><1c7a>: Abbrev Number: 43 (DW_TAG_lexical_block)
<1c7b> DW_AT_abstract_origin: <0x1b87>
<1c7f> DW_AT_ranges : 0x180
This is the DIE which provides the context inside which we can
record Child2. But unfortunately, GDB does not take the abstract
origin into account when handling lexical blocks, causing it
to miss the fact that this block contains some symbols described
in the abstract instance tree. This is the first half of this patch:
modifying GDB to follow DW_AT_abstract_origin attributes for
lexical blocks.
But this not enough to fix the issue, as we're still unable to
break on Child2 with just that change. The second issue can be
traced to the way inherit_abstract_dies determines the list of
DIEs to inherit from. For that, it iterates over all the DIEs in
the concrete instance tree, and finds the list of DIEs from the
abstract instance tree that are not referenced from the concrete
instance tree. As it happens, there is one type of DIE in the
concrete instance tree which does reference Child2's DIE, but
in fact does otherwise define a concrete instance of the reference
DIE; that's (where <0x1b92> is Child2's DIE):
<6><1d3c>: Abbrev Number: 35 (DW_TAG_GNU_call_site)
<1d3d> DW_AT_low_pc : 0x4026a4
<1d45> DW_AT_abstract_origin: <0x1b92>
So, the second part of the patch is to modify inherit_abstract_dies
to ignore DW_TAG_GNU_call_site DIEs when iterating over the concrete
instance tree.
This patch also includes a testcase which can be used to reproduce
the issue. Unfortunately, for it to actually pass, a smal patch in
GCC is also necessary to make sure that GCC provides lexical blocks'
DW_AT_abstract_origin attributes from the concrete tree back to
the abstract tree. We hope to be able to submit and integrate that
patch in the GCC tree soon. Meanwhile, a setup_xfail has been added.
gdb/ChangeLog:
2014-05-05 Pierre-Marie de Rodat <derodat@adacore.com>
* dwarf2read.c (inherit_abstract_dies): Skip
DW_TAG_GNU_call_site dies while inheriting children of an
abstract DIE into a scope.
(read_lexical_block_scope): Inherit abstract DIE's for
lexical scopes.
gdb/testsuite/ChangeLog:
* gdb.ada/out_of_line_in_inlined: New testcase.
This is an issue which I noticed while working on trying to print
an array of variant records. For instance, trying to print "A1",
an array of elements whose size is variable, defined as follow
(see gdb.ada/var_rec_arr testcase):
subtype Small_Type is Integer range 0 .. 10;
type Record_Type (I : Small_Type := 0) is record
S : String (1 .. I);
end record;
function Ident (R : Record_Type) return Record_Type;
type Array_Type is array (Integer range <>) of Record_Type;
A1 : Array_Type := (1 => (I => 0, S => <>),
2 => (I => 1, S => "A"),
3 => (I => 2, S => "AB"));
The debugger sometimes prints the array as follow:
(gdb) print A1
$1 = ((i => 0, s => ""), (i => 0, s => ""), (i => 0, s => ""))
The problem happens inside the part of the loop printing the array's
elements, while trying to count the number of consecutive elements
that have the same value (in order to replace them by the "<repeats
nnn times>" message when the number exceeds a threshold). In particular,
in ada-valprint.c::val_print_packed_array_elements:
elttype = TYPE_TARGET_TYPE (type);
eltlen = TYPE_LENGTH (check_typedef (elttype));
while (...)
{
if (!value_contents_eq (v0, value_embedded_offset (v0),
v1, value_embedded_offset (v1),
eltlen))
break;
The value comparison is performed using value_contents_eq but makes
the assumption that elttype is not dynamic, which is not always true.
In particular, in the case above, elttype is dynamic and therefore
its TYPE_LENGTH changes from element to element.
As it happens in this case, the eltlen is zero, which causes the call
to value_contents_eq to return true, and therefore GDB thinks all
3 elements of the array are equal.
This patch fixes the issue by making sure that both v0 and v1, which
are values whose type we expect to be resolved, have identical lengths.
If not, then the two elements of the array cannot possibly have the
same value and we do not even need to do the binary comparison.
Unfortunately, this is still not enough to get GDB to print the correct
value for our array, because the assumption that v0 and v1 have a type
which has been resolved is actually not met. So, the second part of
the patch modifies the function that constructed the values to make
sure dynamic types do get resolved.
gdb/ChangeLog:
* ada-valprint.c (val_print_packed_array_elements): Delete
variable "len". Add a type-length check when comparing two
consecutive elements of the array. Use the element's actual
length in call to value_contents_eq.
* ada-lang.c (ada_value_primitive_packed_val): Always return
a value whose type has been resolved.
Consider the following declarations:
subtype Small_Type is Integer range 0 .. 10;
type Record_Type (I : Small_Type := 0) is record
S : String (1 .. I);
end record;
A2 : Array_Type := (1 => (I => 2, S => "AB"),
2 => (I => 1, S => "A"),
3 => (I => 0, S => <>));
Compiled with -fgnat-encodings=minimal, and trying to print
one element of our array, valgrind reports an invalid memory
access. On certain GNU/Linux boxes, malloc even reports it as
well, and causes GDB to crash.
(gdb) print a2(1)
*** glibc detected *** /[...]/gdb:
malloc(): memory corruption: 0x0a30ba48 ***
[crash]
The invalid memory access occurs because of a simple buffer
overflow in ada_value_primitive_packed_val. When this function
is called, it is given a bit_size of 128 (or 16 bytes), which
corresponds to the stride of our array. But the actual size of
each element depends on its value. In particular, A2(1) is a record
whose size is only 6 bytes.
What happens in our example is that we start building a new value
(v) where the element is to be unpacked, with any of its dynamic
properties getting resolved as well. We then unpack the data into
this value's buffer:
unpacked = (unsigned char *) value_contents (v);
[...]
nsrc = len;
[...]
while (nsrc > 0)
{
[...]
unpacked[targ] = accum & ~(~0L << HOST_CHAR_BIT);
[...]
targ += delta;
[...]
nsrc -= 1;
[...]
}
In the loop above, targ starts at zero (for LE architectures),
and len is 16. With delta being +1, we end up iterating 16 times,
writing 16 bytes into a 6-bytes buffer.
This patch fixes the issue by adjusting BIT_SIZE and recomputing
LEN after having resolved our type if the resolved type turns out
to be smaller than bit_size.
gdb/ChangeLog:
* ada-lang.c (ada_value_primitive_packed_val): Recompute
BIT_SIZE and LEN if the size of the resolved type is smaller
than BIT_SIZE * HOST_CHAR_BIT.
Consider the following (Ada) array...
A1 : Array_Type := (1 => (I => 0, S => <>),
2 => (I => 1, S => "A"),
3 => (I => 2, S => "AB"));
... where Array_Type is declared as follow:
subtype Small_Type is Integer range 0 .. 10;
type Record_Type (I : Small_Type := 0) is record
S : String (1 .. I);
end record;
type Array_Type is array (Integer range <>) of Record_Type;
Trying to print the value of each element individually does not
always work. Printing the value of the first one does:
(gdb) p a1(1)
$1 = (i => 0, s => "")
But printing the value of the subsequent ones often does not.
For instance:
(gdb) p a1(2)
$2 = (i => 1, s => "") <<<--- s should be "A"
(gdb) p a1(3)
$3 = (i => 2, s => "") <<<--- s should be "AB"
I traced the problem to ada_value_primitive_packed_val,
which is trying to perform the array subscripting by
extracting the value of the corresponding array element
into a buffer where the contents is now byte-aligned.
The element type that ada_value_primitive_packed_val gets passed
is a dynamic type. As it happens, that dynamic type can get resolved
thanks to:
v = value_at (type, value_address (obj));
type = value_type (v);
However, obj represents the array, so the address given in the call
to value_at represents the value of the first element. As a result,
the solution of component S's upper bound always gets resolved based
on the value of component I in the first element of the array, whose
value is 0, thus leading to GDB mistakely resolving the element type
where S's upper bound is always 0.
The proper fix would be to systematically resolve the element type
first. But, this requires us to extract-and-realign the element's
value so as to be able to pass it as "valaddr" to resolve_dynamic_type.
In the meantime, it's easy to make the situation a little better by
passing "value_address (obj) + offset" as the object address. This
only works when BIT_OFFSET is nul, but that should be the case when
the element type is anything but a scalar, which seems to be the only
situation where it seems important to resolve the type now. And we're
not that worse off otherwise.
But we'll try to find a better solution in a separate patch.
gdb/ChangeLog:
* ada-lang.c (ada_value_primitive_packed_val): Use a more
correct address in call to value_at. Adjust call to
value_address accordingly.
This is another required step towards trying to print the value of
an array of variant records. For instance:
A1 : Array_Type := (1 => (I => 0, S => <>),
2 => (I => 1, S => "A"),
3 => (I => 2, S => "AB"));
... where Array_Type is an array of records whose size is variable:
subtype Small_Type is Integer range 0 .. 10;
type Record_Type (I : Small_Type := 0) is record
S : String (1 .. I);
end record;
type Array_Type is array (Integer range <>) of Record_Type;
What happens is that the ada-valprint modules gets passed an array
whose element type is not resolved yet (since each element of the
array needs to be resolved separately). the module then recurses,
and eventually gets called with the first element of the array.
But because the element hasn't been resolved yet, we end up having
trouble printing its value soon after.
This patch fixes the issue by calling resolve_dynamic_type before
trying to print it.
With this patch, GDB is finally able to print the complete value
for variable "A1":
(gdb) p a1
$1 = ((i => 0, s => ""), (i => 1, s => "A"), (i => 2, s => "AB"))
gdb/ChangeLog:
* ada-valprint.c (ada_val_print_1): Resolve TYPE before trying
to print it.
This is the second part of enhancing the debugger to print the value
of arrays of records whose size is variable when only standard DWARF
info is available (no GNAT encoding). For instance:
subtype Small_Type is Integer range 0 .. 10;
type Record_Type (I : Small_Type := 0) is record
S : String (1 .. I);
end record;
type Array_Type is array (Integer range <>) of Record_Type;
A1 : Array_Type := (1 => (I => 0, S => <>),
2 => (I => 1, S => "A"),
3 => (I => 2, S => "AB"));
Currently, GDB prints the following output:
(gdb) p a1
$1 = (
The error happens while the ada-valprint module is trying to print
the value of an element of our array. Because of the fact that
the array's element (type Record_Type) has a variant size, the DWARF
info for our array provide the array's stride:
<1><749>: Abbrev Number: 10 (DW_TAG_array_type)
<74a> DW_AT_name : (indirect string, offset: 0xb6d): pck__T18s
<74e> DW_AT_byte_stride : 16
<74f> DW_AT_type : <0x6ea>
And because our array has a stride, ada-valprint treats it the same
way as packed arrays (see ada-valprint.c::ada_val_print_array):
if (TYPE_FIELD_BITSIZE (type, 0) > 0)
val_print_packed_array_elements (type, valaddr, offset_aligned,
0, stream, recurse,
original_value, options);
The first thing that we should notice in the call above is that
the "valaddr" buffer and the associated offset (OFFSET_ALIGNED)
is passed, but that the corresponding array's address is not.
This can be explained by looking inside val_print_packed_array_elements,
where we see that the function unpacks each element of our array from
the buffer alone (ada_value_primitive_packed_val), and then prints
the resulting artificial value instead:
v0 = ada_value_primitive_packed_val (NULL, valaddr + offset,
(i0 * bitsize) / HOST_CHAR_BIT,
(i0 * bitsize) % HOST_CHAR_BIT,
bitsize, elttype);
[...]
val_print (elttype, value_contents_for_printing (v0),
value_embedded_offset (v0), 0, stream,
recurse + 1, v0, &opts, current_language);
Of particular interest, here, is the fact that we call val_print
with a null address, which is OK, since we're providing a buffer
instead (value_contents_for_printing). Also, providing an address
might not always possible, since packing could place elements at
boundaries that are not byte-aligned.
Things go south when val_print tries to see if there is a pretty-printer
that could be applied. In particular, one of the first things that
the Python pretty-printer does is to create a value using our buffer,
and the given address, which in this case is null (see call to
value_from_contents_and_address in gdbpy_apply_val_pretty_printer).
value_from_contents_and_address, in turn immediately tries to resolve
the type, using the given address, which is null. But, because our
array element is a record containing an array whose bound is the value
of one of its elements (the "s" component), the debugging info for
the array's upper bound is a reference...
<3><71a>: Abbrev Number: 7 (DW_TAG_subrange_type)
<71b> DW_AT_type : <0x724>
<71f> DW_AT_upper_bound : <0x703>
... to component "i" of our record...
<2><703>: Abbrev Number: 5 (DW_TAG_member)
<704> DW_AT_name : i
<706> DW_AT_decl_file : 2
<707> DW_AT_decl_line : 6
<708> DW_AT_type : <0x6d1>
<70c> DW_AT_data_member_location: 0
... where that component is located at offset 0 of the start
of the record. dwarf2_evaluate_property correctly determines
the offset where to load the value of the bound from, but then
tries to read that value from inferior memory using the address
that was given, which is null. See case PROP_ADDR_OFFSET in
dwarf2_evaluate_property:
val = value_at (baton->offset_info.type,
pinfo->addr + baton->offset_info.offset);
This triggers a memory error, which then causes the printing to terminate.
Since there are going to be situations where providing an address
alone is not going to be sufficient (packed arrays where array elements
are not stored at byte boundaries), this patch fixes the issue by
enhancing the type resolution to take both address and data. This
follows the same principle as the val_print module, where both
address and buffer ("valaddr") can be passed as arguments. If the data
has already been fetched from inferior memory (or provided by the
debugging info in some form -- Eg a constant), then use that data
instead of reading it from inferior memory.
Note that this should also be a good step towards being able to handle
dynamic types whose value is stored outside of inferior memory
(Eg: in a register).
With this patch, GDB isn't able to print all of A1, but does perform
a little better:
(gdb) p a1
$1 = ((i => 0, s => , (i => 1, s => , (i => 2, s => )
There is another issue which is independent of this one, and will
therefore be patched separately.
gdb/ChangeLog:
* dwarf2loc.h (struct property_addr_info): Add "valaddr" field.
* dwarf2loc.c (dwarf2_evaluate_property): Add handling of
pinfo->valaddr.
* gdbtypes.h (resolve_dynamic_type): Add "valaddr" parameter.
* gdbtypes.c (resolve_dynamic_struct): Set pinfo.valaddr.
(resolve_dynamic_type_internal): Set pinfo.valaddr.
Add handling of addr_stack->valaddr.
(resolve_dynamic_type): Add "valaddr" parameter.
Set pinfo.valaddr field.
* ada-lang.c (ada_discrete_type_high_bound): Update call to
resolve_dynamic_type.
(ada_discrete_type_low_bound): Likewise.
* findvar.c (default_read_var_value): Likewise.
* value.c (value_from_contents_and_address): Likewise.
Consider the following (Ada) variable...
A1 : Array_Type := (1 => (I => 0, S => <>),
2 => (I => 1, S => "A"),
3 => (I => 2, S => "AB"));
... where Array_Type is an array of records whose size is variable:
subtype Small_Type is Integer range 0 .. 10;
type Record_Type (I : Small_Type := 0) is record
S : String (1 .. I);
end record;
type Array_Type is array (Integer range <>) of Record_Type;
Trying to print the value of this array currently results in the following
error:
(gdb) p a1
Cannot access memory at address 0x61c000
What happens in this case, is that the compiler describes our array
as an array with a specific stride (and bounds being static 1..3):
<1><749>: Abbrev Number: 10 (DW_TAG_array_type)
<74a> DW_AT_name : (indirect string, offset: 0xb6d): pck__T18s
<74e> DW_AT_byte_stride : 16
<74f> DW_AT_type : <0x6ea>
<2><757>: Abbrev Number: 11 (DW_TAG_subrange_type)
<758> DW_AT_type : <0x75e>
<75c> DW_AT_upper_bound : 3
This is because we cannot use, in this case, the size of the record
to determine that stride, since the size of the record depends on
its contents. So the compiler helps us by providing that stride.
The problems start when trying to resolve that type. Because the elements
contained in that array type are dynamic, the array itself is considered
dynamic, and thus we end up creating a resolved version of that array.
And during that resolution, we were not handling the case where the array
had a stride. See gdbtypes.c::resolve_dynamic_array...
return create_array_type (copy_type (type),
elt_type,
range_type);
As a result, we created an array whose stride was based on the size
of elt_type, which a record whose size isn't static and irrelevant
regardless.
This patch fixes is by calling create_array_type_with_stride instead.
As it happens, there is another issue for us to be able to print
the value of our array, but those are independent of this patch
and will be handled separately. For now, the patch allows us to
get rid of the first error, and the output is now:
(gdb) p a1
$1 = (
gdb/ChangeLog:
* gdbtypes.c (resolve_dynamic_array): Use
create_array_type_with_stride instead of create_array_type.
Hi,
I see this fails below on arm linux native testing and remote testing
with "set remote hardware-watchpoint-limit 1",
rwatch global^M
There are not enough available hardware resources for this watchpoint.^M
(gdb) FAIL: gdb.base/break-idempotent.exp: always-inserted off: rwatch: twice: rwatch global
gdb.base/break-idempotent.exp sets two breakpoints/watchpoints on the
same address. GDB isn't smart enough calculate these two HW
watchpoints can fit in one HW debug register, so the error message
above isn't necessary (there is one HW watchpoint register on arm).
Because target_ops interface can_use_hardware_watchpoint doesn't
pass enough information to the target backend.
Note that if I don't "set remote hardware-watchpoint-limit 1" in
remote testing, this test passes without fails. However without
"set remote hardware-watchpoint-limit 1", many other watchpoint
tests fail.
This patch is to add a check to skip_hw_watchpoint_multi_tests
for rwatch and awatch. We can add such check for watch as well,
but GDB is able to switch to software watchpoint if HW resource
isn't available, it doesn't cause any fail, I decide not to skip.
gdb/testsuite:
2015-04-30 Yao Qi <yao.qi@linaro.org>
* gdb.base/break-idempotent.exp: If
skip_hw_watchpoint_multi_tests returns true, skip the tests
on "rwatch" and "awatch".
Hi,
I see the fail in gdb.base/relativedebug.exp on aarch64 box on which
glibc doesn't have debug info,
bt^M
#0 0x0000002000061a88 in raise () from /lib/aarch64-linux-gnu/libc.so.6^M
#1 0x0000002000064efc in abort () from /lib/aarch64-linux-gnu/libc.so.6^M
#2 0x0000000000400640 in handler (signo=14) at ../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:25^M
#3 <signal handler called>^M
#4 0x00000020000cc478 in ?? () from /lib/aarch64-linux-gnu/libc.so.6^M
#5 0x0000000000400664 in main () at ../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:32^M
(gdb) FAIL: gdb.base/relativedebug.exp: pause found in backtrace
if glibc has debug info, this test doesn't fail.
In sysdeps/unix/sysv/linux/generic/pause.c, __libc_pause calls
__syscall_pause,
static int
__syscall_pause (void)
{
sigset_t set;
int rc =
INLINE_SYSCALL (rt_sigprocmask, 4, SIG_BLOCK, NULL, &set, _NSIG / 8);
if (rc == 0)
rc = INLINE_SYSCALL (rt_sigsuspend, 2, &set, _NSIG / 8);
return rc;
}
int
__libc_pause (void)
{
if (SINGLE_THREAD_P)
return __syscall_pause (); <--- tail call
int oldtype = LIBC_CANCEL_ASYNC ();
int result = __syscall_pause ();
LIBC_CANCEL_RESET (oldtype);
return result;
}
and GDB unwinder is confused by the GCC optimized code,
(gdb) disassemble pause
Dump of assembler code for function pause:
0x0000007fb7f274c4 <+0>: stp x29, x30, [sp,#-32]!
0x0000007fb7f274c8 <+4>: mov x29, sp
0x0000007fb7f274cc <+8>: adrp x0, 0x7fb7fd2000
0x0000007fb7f274d0 <+12>: ldr w0, [x0,#364]
0x0000007fb7f274d4 <+16>: stp x19, x20, [sp,#16]
0x0000007fb7f274d8 <+20>: cbnz w0, 0x7fb7f274e8 <pause+36>
0x0000007fb7f274dc <+24>: ldp x19, x20, [sp,#16]
0x0000007fb7f274e0 <+28>: ldp x29, x30, [sp],#32
0x0000007fb7f274e4 <+32>: b 0x7fb7f27434 <---- __syscall_pause
0x0000007fb7f274e8 <+36>: bl 0x7fb7f5e080
Note that the program stops in __syscall_pause, but its symbol is
stripped in glibc, so GDB doesn't know where the program stops.
__syscall_pause is a tail call in __libc_pause, so it returns to main
instead of __libc_pause. As a result, the backtrace is like,
#0 0x0000007fb7ebca88 in raise () from /lib/aarch64-linux-gnu/libc.so.6
#1 0x0000007fb7ebfefc in abort () from /lib/aarch64-linux-gnu/libc.so.6
#2 0x0000000000400640 in handler (signo=14) at ../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:25
#3 <signal handler called>
#4 0x0000007fb7f27478 in ?? () from /lib/aarch64-linux-gnu/libc.so.6 <-- [in __syscall_pause]
#5 0x0000000000400664 in main () at ../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:32
looks GDB does nothing wrong here. I looked back at the test case
gdb.base/relativedebug.exp, which was added
https://sourceware.org/ml/gdb-patches/2006-10/msg00305.html
This test was indented to test the problem that "backtraces no longer
display some libc functions" after separate debug info is installed.
IOW, it makes few sense to test against libc which doesn't have debug
info at all, such as my case.
This patch is to tweak the test case to catch the output of
"info shared", if "(*)" is found for libc.so, which means libc doesn't
have debug info, then skip the test.
gdb/testsuite:
2015-04-30 Yao Qi <yao.qi@linaro.org>
* gdb.base/relativedebug.exp: Invoke gdb command
"info sharedlibrary", and if libc.so doesn't have debug info,
skip the test.
There are targets GDB thinks support hardware watchpoints, but in reality they
don't. Though it may seem that hardware watchpoint creation was successful,
the actual insertion of such watchpoint will fail when GDB moves the inferior.
(gdb) watch -location q.a^M
Hardware watchpoint 2: -location q.a^M
(gdb) PASS: gdb.base/watch-bitfields.exp: -location watch against bitfields: watch -location q.a
watch -location q.e^M
Hardware watchpoint 3: -location q.e^M
(gdb) PASS: gdb.base/watch-bitfields.exp: -location watch against bitfields: watch -location q.e
print q.a^M
$1 = 0^M
(gdb) PASS: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 0->1: print expression before
continue^M
Continuing.^M
Warning:^M
Could not insert hardware watchpoint 2.^M
Could not insert hardware watchpoint 3.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 0->1: continue
This leads to a number of FAILs:
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 0->1: continue
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 0->1: print expression after
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 0->5: continue
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 0->5: print expression after
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 1->0: print expression before
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 1->0: continue
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 5->4: print expression before
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 5->4: continue
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 5->4: print expression after
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: continue until exit
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 0->4: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 0->4: print expression after
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 4->10: print expression before
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 4->10: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 4->10: print expression after
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 10->3: print expression before
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 10->3: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 10->3: print expression after
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 3->2: print expression before
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 3->2: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 3->2: print expression after
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 2->1: print expression before
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 2->1: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 2->1: print expression after
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 1->0: print expression before
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 1->0: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: continue until exit
We can avoid these errors/FAILs by checking the board data and switching to
software watchpoints if the board does not support hardware watchpoints.
gdb/testsuite/ChangeLog:
2015-04-29 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/watch-bitfields.exp: Switch to software watchpoints if
the target does not support hardware watchpoints.
This is another case of the testcase not handling memory write errors that
happen on some targets (QEMU) when GDB attempts to modify an address that
should contain a breakpoint, for example.
The following patch handles this and prevents spurious failures from
happening. It also adds a foreach loop to avoid duplication of code
and hardcoded patterns.
gdb/testsuite/ChangeLog:
2015-04-29 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/break-always.exp: Abort testing if writing to memory
causes an error.
This commit allows NULL to be passed as the int *fd argument
to exec_file_find and solib_find to simplify use cases where
the caller does not require the file to be opened.
gdb/ChangeLog:
* solib.c (solib_find_1): Allow fd argument to be NULL.
(exec_file_find): Update comment.
(solib_find): Likewise.
* exec.c (exec_file_locate_attach): Use NULL as fd
argument to exec_file_find to avoid having to close
the opened file.
* infrun.c (follow_exec): Likewise.
gdb/ChangeLog:
PR python/18299
* python/lib/gdb/printing.py (register_pretty_printer): Handle
name or __name__ attributes. Handle gdb module as first argument.
gdb/testsuite/ChangeLog:
* gdb.python/py-pp-maint.py: Move "replace" testing to ...
* gdb.python/py-pp-registration.exp: ... here. New file.
* gdb.python/py-pp-registration.c: New file.
* gdb.python/py-pp-registration.py: New file.
gdb/ChangeLog:
PR python/18089
* python/py-prettyprint.c (print_children): Verify result of children
iterator. Provide better error message.
* python/python-internal..h (gdbpy_print_python_errors_p): Declare.
* python/python.c (gdbpy_print_python_errors_p): New function.
gdb/testsuite/ChangeLog:
* gdb.python/py-bad-printers.c: New file.
* gdb.python/py-bad-printers.py: New file.
* gdb.python/py-bad-printers.exp: New file.
We no longer need it as we handle SIGWINCH ourselves. Also move the
call to init_page_info() from initialize_utils() to the latter
function's only caller, gdb_init().
gdb/ChangeLog:
* utils.c (init_page_info): Set rl_catch_sigwinch to zero.
(initialize_utils): Move call of init_page_info() to ...
* top.c (gdb_init): ... here.
When in the CLI, GDB's "width" and "height" variables are not kept in sync
when the underlying terminal gets resized.
This patch fixes this issue by making sure sure to update GDB's "width"
and "height" variables in the !tui_active case of our SIGWINCH handler.
gdb/ChangeLog:
* tui/tui-win.c (tui_sigwinch_handler): Remove now-stale comment.
(tui_sigwinch_handler): Still update our idea of
the terminal's width and height even when TUI is not active.
... to replace the roundabout pattern of
execute_command ("set width %d");
execute_command ("set height %d");
for doing the same thing.
gdb/ChangeLog:
* utils.h (set_screen_width_and_height): Declare.
* utils.c (set_screen_width_and_height): Define.
* tui/tui-win.c (tui_update_gdb_sizes): Use it.
This commit updates follow_exec to use exec_file_find to prefix
the new executable's filename with gdb_sysroot rather than doing
it longhand.
gdb/ChangeLog:
* infrun.c (solist.h): New include.
(follow_exec): Use exec_file_find to prefix execd_pathname
with gdb_sysroot.
gdb/testsuite/ChangeLog:
* gdb.python/py-parameter.exp:
* gdb.guile/scm-parameter.exp: Escape the path that we are
matching against, as it might contain characters that are special
to regular expressions.
In tui_set_source_content(), when offset == 0 the source and destination
pointers of the call to strcpy() are actually the same. In this case
not only is strcpy() unnecessary but it is also UB when the two strings
overlap.
gdb/ChangeLog:
* tui/tui-source.c (tui_set_source_content): Avoid calling
strcpy() when offset is 0.
For no good reason the function tui_free_window() is freeing the locator
window when we pass it an SRC_WIN or a DISASSEM_WIN. This behavior
doesn't make much sense because the locator window is always visible and
its contents do not change when the main window changes.
This behavior triggers the above PR because when we switch from one TUI
window to another (in the PR, from the src window to the asm window) we
call tui_free_window() on the previously active window (in the PR, the
src window). The function then frees the src window along with the
locator window and later we segfault when the now-active asm window
tries to query the locator window about the inferior's PC.
This patch fixes this apparently wrong behavior by changing
tui_free_window() to not free the locator window when we pass it an
SRC_WIN or a DISASSEM_WIN.
gdb/ChangeLog:
PR gdb/18155
* tui/tui-data.c (tui_free_window): Don't free the locator
window when passed an SRC_WIN or a DISASSEM_WIN.
The 'content' field of struct tui_gen_win_info currently has type
void ** but the field always stores an object of type tui_win_content.
Instead of unnecessarily casting to and from void ** we should just give
the field the type tui_win_content in the first place.
This patch does this and also eliminates all now-redundant casts
involving the 'content' struct field that I could find.
gdb/ChangeLog:
* tui/tui-data.h (struct tui_win_element): Forward-declare.
(tui_win_content): Move declaration.
(struct tui_gen_win_info): Give 'content' field the
type tui_win_content.
* tui/tui-data.c (init_content_element): Remove redundant and
erroneous casts.
(tui_add_content_elements): Remove erroneous cast.
* tui/tui-disasm.c (tui_set_disassem_content): Remove redundant
casts.
(tui_get_begin_asm_address): Likewise.
* tui/tui-regs.c (tui_show_registers): Likewise.
(tui_show_register_group): Likewise.
(tui_display_registers_from): Likewise.
(tui_check_register_values): Likewise.
* tui/tui-source.c (tui_set_source_content): Likewise.
(tui_set_source_content_nil): Likewise.
(tui_source_is_displayed): Likewise.
* tui/tui-stack.c (tui_show_locator_content): Likewise.
(tui_set_locator_fullname): Likewise.
(tui_set_locator_info): Likewise.
(tui_show_frame_info): Likewise.
* tui/tui-winsource.c (tui_clear_source_content): Likewise.
(tui_show_source_line): Likewise.
(tui_horizontal_source_scroll): Likewise.
(tui_update_breakpoint_info): Likewise.
(tui_set_exec_info_content): Likewise.
(tui_show_exec_info_content): Likewise.
(tui_alloc_source_buffer): Likewise.
(tui_line_is_displayed): Likewise.
(tui_addr_is_displayed): Likewise.
FreeBSD kernels that support fork tracing always stop a process to
report events for exec. Such a process will have the PL_FLAG_EXEC
flag set in the pl_flags field of the ptrace_lwpinfo struct returned
by PT_LWPINFO. The structure does not include the pathname passed to
exec, so use fbsd_pid_to_exec_file to query the pathname of the
process' executable.
gdb/ChangeLog:
* fbsd-nat.c: (fbsd_wait) [PL_FLAG_EXEC]: Report TARGET_WAITKIND_EXECD
event if PL_FLAG_EXEC is set.
[PL_FLAG_EXEC] (fbsd_insert_exec_catchpoint): New function.
[PL_FLAG_EXEC] (fbsd_remove_exec_catchpoint): New function.
(fbsd_nat_add_target) [PL_FLAG_EXEC]: Set
"to_insert_exec_catchpoint" to "fbsd_insert_exec_catchpoint".
Set "to_remove_exec_catchpoint" to "fbsd_remove_exec_catchpoint".
Enable PT_FOLLOW_FORK on all processes. When this is enabled, both
the parent and child process stop when a fork or vfork occurs.
A target operation for wait uses PT_LWPINFO to fetch more detailed
information about the state of a stopped process. A parent process
sets the PL_FLAG_FORKED flag in the pl_flags field of the structure
returned by PT_LWPINFO as well as the pid of the new child process.
The child process sets the PL_FLAG_CHILD flag in the pl_flags field.
When a fork is detected, the wait hook waits for both processes to
report their respective events. It then reports the fork to GDB as
a single TARGET_WAITKIND_FORKED or TARGET_WAITKIND_VFORKED event.
The kernel does not guarantee the order the events are reported in.
If the parent process' event is reported first, then the wait hook
explicitly waits for the child process. If the child process' event
is reported first, the event is recorded on an internal list of
pending child events and the wait hook waits for another event.
Later when the parent process' event is reported, the parent will
use the previously-recorded child process event instead of explicitly
waiting on the child process.
To distinguish vfork events from fork events, the external process
structure for the child process is extracted from the kernel. The
P_PPWAIT flag is set in the ki_flags field of this structure if the
process was created via vfork, but it is not set for a regular fork.
gdb/ChangeLog:
* fbsd-nat.c: [PT_LWPINFO] New variable super_wait.
[TDP_RFPPWAIT] New variable fbsd_pending_children.
[TDP_RFPPWAIT] (fbsd_remember_child): New function.
[TDP_RFPPWAIT] (fbsd_is_child_pending): New function.
[TDP_RFPPWAIT] (fbsd_fetch_kinfo_proc): New function.
[PT_LWPINFO] (fbsd_wait): New function.
[TDP_RFPPWAIT] (fbsd_follow_fork): New function.
[TDP_RFPPWAIT] (fbsd_insert_fork_catchpoint): New function.
[TDP_RFPPWAIT] (fbsd_remove_fork_catchpoint): New function.
[TDP_RFPPWAIT] (fbsd_insert_vfork_catchpoint): New function.
[TDP_RFPPWAIT] (fbsd_remove_vfork_catchpoint): New function.
[TDP_RFPPWAIT] (fbsd_enable_follow_fork): New function.
[TDP_RFPPWAIT] (fbsd_post_startup_inferior): New function.
[TDP_RFPPWAIT] (fbsd_post_attach): New function.
(fbsd_nat_add_target) [PT_LWPINFO] Set "to_wait" to
"fbsd_wait".
[TDP_RFPPWAIT] Set "to_follow_fork" to "fbsd_follow_fork".
Set "to_insert_fork_catchpoint" to "fbsd_insert_fork_catchpoint".
Set "to_remove_fork_catchpoint" to "fbsd_remove_fork_catchpoint".
Set "to_insert_vfork_catchpoint" to "fbsd_insert_vfork_catchpoint".
Set "to_remove_vfork_catchpoint" to "fbsd_remove_vfork_catchpoint".
Set "to_post_startup_inferior" to "fbsd_post_startup_inferior".
Set "to_post_attach" to "fbsd_post_attach".
Add a wrapper for add_target in fbsd-nat.c to override target operations
common to all native FreeBSD targets.
gdb/ChangeLog:
* fbsd-nat.c (fbsd_pid_to_exec_file): Mark static.
(fbsd_find_memory_regions): Mark static.
(fbsd_nat_add_target): New function.
* fbsd-nat.h: Export fbsd_nat_add_target and remove prototypes for
fbsd_pid_to_exec_file and fbsd_find_memory_regions.
* amd64fbsd-nat.c (_initialize_amd64fbsd_nat): Use fbsd_nat_add_target.
* i386fbsd-nat.c (_initialize_i386fbsd_nat): Likewise.
* ppcfbsd-nat.c (_initialize_ppcfbsd_nat): Likewise.
* sparc64fbsd-nat.c (_initialize_sparc64fbsd_nat): Likewise.
This commit alters two places that manipulate object file filenames
to detect "target:" filenames and to not attempt to manipulate them
as paths on the local filesystem:
- allocate_objfile is updated to not attempt to expand "target:"
filenames with gdb_abspath.
- load_auto_scripts_for_objfile is updated to not attempt to load
auto-load scripts for object files with "target:" filenames.
gdb/ChangeLog:
* objfiles.c (allocate_objfile): Do not attempt to expand name
if name is a "target:" filename.
* auto-load.c (load_auto_scripts_for_objfile): Do not attempt
to load auto-load scripts for objfiles with "target:" filenames.
With the S390 vector ABI, vector registers are used for passing vector
arguments and for returning a vector. Support this ABI in inferior
function calls and when setting or retrieving a function's return
value.
gdb/ChangeLog:
* s390-linux-tdep.c: Include "elf/s390.h" and "elf-bfd.h".
(enum s390_vector_abi_kind): New enum.
(struct gdbarch_tdep)<vector_abi>: New field.
(s390_effective_inner_type): Add parameter min_size. Stop
unwrapping if the inner type is smaller than min_size.
(s390_function_arg_float): Adjust call to
s390_effective_inner_type.
(s390_function_arg_vector): New function.
(s390_function_arg_integer): Adjust comment.
(struct s390_arg_state)<vr>: New field.
(s390_handle_arg): Add parameter 'is_unnamed'. Pass vector
arguments according to vector ABI when appropriate.
(s390_push_dummy_call): Initialize the argument state's field
'vr'. Adjust calls to s390_handle_arg.
(s390_register_return_value): Handle vector return values.
(s390_return_value): Apply the "register" return value convention
to a vector when appropriate.
(s390_gdbarch_init): Initialize tdep->vector_abi.
* NEWS: Announce S390 vector ABI support.
Move related logic in the implementation of s390_return_value closer
together. This makes it easier to read and extend.
gdb/ChangeLog:
* s390-linux-tdep.c (s390_return_value_convention): Remove
function. Inline its logic...
(s390_return_value): ...here. Instead, move the handling of the
"register" return value convention...
(s390_register_return_value): ...here. New function.
Simplify the structure of s390_push_dummy_call and its various helper
functions. This reduces the code and makes it easier to extend. The
new code should be functionally equivalent to the old one, except that
copies created by the caller are now always aligned on an 8-byte
boundary.
gdb/ChangeLog:
* s390-linux-tdep.c
(is_float_singleton): Remove function. Move the "singleton" part
of the logic...
(s390_effective_inner_type): ...here. New function.
(is_float_like): Remove function. Inline its logic...
(s390_function_arg_float): ...here.
(is_pointer_like, is_integer_like, is_struct_like): Remove
functions. Inline their logic...
(s390_function_arg_integer): ...here.
(s390_function_arg_pass_by_reference): Remove function.
(extend_simple_arg): Remove function.
(alignment_of): Remove function.
(struct s390_arg_state): New structure.
(s390_handle_arg): New function.
(s390_push_dummy_call): Move parameter placement logic to the new
function s390_handle_arg. Call it for calculating the stack area
sizes first, and again for actually writing the parameters.
This fixes a minor issue with the helper function is_power_of_two(),
which returned non-zero ("true") if the argument was zero. This led
to a wrong decision when passing a zero-sized struct in an inferior
function call.
gdb/ChangeLog:
* s390-linux-tdep.c (is_power_of_two): Add comment. Return
false if the argument is zero.
Currently, ada-lang.c:template_to_static_fixed_type (working on
structure types only) caches its result into the unused TYPE_TARGET_TYPE
field. This introduces inconsistencies when the input type is
specialized, for instance during type resolution: the cached static
fixed type is copied along with the original type, but it's no longer
adapted to the copy once the copy is modified:
template_to_static_fixed_type has to compute another static fixed type
for it.
This change first introduces a cache reset during type resolution for
structure types so that this inconsistency does not happen anymore. It
also makes template_to_static_fixed_type smarter with respect to types
that do not need static fixed copies so that less computations is done
in general.
This inconsistency was spotted thanks to code reading, not because of
any sort of failure and we did not manage to exhibit a failure yet, so
no testcase for this.
gdb/ChangeLog:
* ada-lang.c (template_to_static_fixed_type): Return input type
when it is already fixed. Cache the input type itself when not
creating a static fixed copy. Make it explicit that we never
molestate the input type.
* gdbtypes.c (resolve_dynamic_struct): Reset the
TYPE_TARGET_TYPE field for resolved copies.
Consider the following declarations:
type Int_Access is access Integer;
type Record_Type is record
IA : Int_Access;
end record;
R : Record_Type;
Printing the type name of "R.IA" yields:
(gdb) whatis r.ia
type = access integer
It should be:
(gdb) whatis r.ia
type = bar.int_access
Looking at the debugging info, field "r.ia" is defined as
a typedef which has the name of the field type:
.uleb128 0x3 # (DIE (0x4e) DW_TAG_typedef)
.long .LASF4 # DW_AT_name: "bar__int_access"
.long 0x8b # DW_AT_type
... with the typedef's target type being an anonymous pointer
type:
.uleb128 0x7 # (DIE (0x8b) DW_TAG_pointer_type)
.byte 0x8 # DW_AT_byte_size
.long 0x91 # DW_AT_type
What happens here is that a couple of function in ada-lang.c
always start by stripping all typedef layers when handling
struct fields, with the effect of making us lose the type name
in this case.
We did not understand this at the time the code was written,
but typedefs should be stripped only when we know we do not
need them. So this patch, adjust the code to avoid the stripping
while handling the fields, and adds it back in the lone place
which handles the result of processing and didn't know how to
handle typedefs struct fields yet.
gdb/ChangeLog:
* ada-lang.c (ada_is_tagged_type): Add call to ada_check_typedef.
(ada_lookup_struct_elt_type): Remove calls to ada_check_typedef.
(template_to_static_fixed_type): Call ada_check_typedef only
when necessary.
gdb/testsuite/ChangeLog:
* gdb.ada/rec_comp: New testcase.
This commit is a continuation of the fix committed on:
commit 8cd8f2f8ac
Author: Sergio Durigan Junior <sergiodj@redhat.com>
Date: Mon Apr 13 02:40:08 2015 -0400
Rename variable "addr" to "coredump_var_addr" in gdb.base/coredump-filter.exp
Pedro pointed out that this fix was not complete, because the
testsuite could be run several times in a row (for example), which
means that it is not enough to just make the variable name unique: it
also needs to be cleared out if it is global.
This commit does that. It is actually just a commit made to make
things totally correct; this specific test does not fail if you run it
several times in a row.
gdb/testsuite/ChangeLog:
2015-04-26 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/coredump-filter.exp: Clear variable "coredump_var_addr"
before using it.
Spotted a few strings that were missing internationalization support.
gdb/ChangeLog:
* cli/cli-dump.c (srec_dump_command): Add internationalization
mark ups.
(ihex_dump_command): Likewise.
(tekhex_dump_command): Likewise.
(binary_dump_command): Likewise.
(binary_append_command): Likewise.
Extend the gdb 'dump' command to allow creating output in verilog hex
format. Add some tests to cover new functionality. As bfd does not
currently support reading in verilog hex formats the tests only cover
the 'dump' command, not the 'restore' command.
gdb/ChangeLog:
* cli/cli-dump.c (verilog_cmdlist): New variable.
(dump_verilog_memory): New function.
(dump_verilog_value): New function.
(verilog_dump_command): New function.
(_initialize_cli_dump): Add new commands to support verilog dump
format.
* NEWS: Add entry for "dump verilog".
gdb/doc/ChangeLog:
* gdb.texinfo (Dump/Restore Files): Add detail about verilog dump
format.
gdb/testsuite/ChangeLog:
* gdb.base/dump.exp: Add *.verilog files to all_files list. Add
new tests for verilog output.
gdb/ChangeLog:
2015-04-24 Pierre-Marie de Rodat <derodat@adacore.com>
* gdbtypes.c (print_gnat_stuff): Do not recurse on the
descriptive type when there is none.
This patch is to add a new board file that does real remote gdbserver
testing on localhost. This board file can be used to reproduce PR 18208.
gdb/testsuite
2015-04-24 Yao Qi <yao.qi@linaro.org>
* boards/remote-gdbserver-on-localhost.exp: New file.
Currently, against gdbserver, interrupt.exp occasionaly fails like
this:
ERROR: Process no longer exists
UNRESOLVED: gdb.base/interrupt.exp: send end of file
The problem is that we see gdbserver exiting before we match gdb's
output:
expect: does "\r\n\r\nChild exited with status 0\r\nGDBserver exiting\r\n" (spawn_id exp8) match regular expression "end of file"? Gate "end of file"? gate=no
expect: read eof
expect: set expect_out(spawn_id) "exp8"
expect: set expect_out(buffer) "\r\n\r\nChild exited with status 0\r\nGDBserver exiting\r\n"
Fix this by removing $inferior_spawn_id from the set of spawn ids
expect is watching as soon as we see the "end of file" string out of
the inferior spawn id, using an indirect spawn id list.
Tested on x86-64 Fedora 20, native and gdbserver (both target remote
and extended-remote).
gdb/testsuite/ChangeLog:
2015-04-23 Pedro Alves <palves@redhat.com>
* gdb.base/interrupt.exp: Use an indirect spawn id list holding
$inferior_spawn_id instead of $inferior_spawn_id directly. On
"end of file", remove $inferior_spawn_id from the indirect list.
To avoid confusion between "end of file" string matching and eof
matching, as in process exit.
gdb/testsuite/ChangeLog:
2015-04-23 Pedro Alves <palves@redhat.com>
* gdb.base/interrupt.exp: Rename saw_eof to saw_end_of_file.
Since silent handling of eof is usually the wrong thing to do, this
patch makes gdb_test_multiple handle it for all $any_spawn_id.
Currently, against gdbserver, interrupt.exp occasionaly fails like
this:
FAIL: gdb.base/interrupt.exp: send end of file
gdb.log with expect debug output enabled shows:
expect: does "\r\n\r\nChild exited with status 0\r\nGDBserver exiting\r\n" (spawn_id exp8) match regular expression "end of file"? Gate "end of file"? gate=no
expect: read eof
expect: set expect_out(spawn_id) "exp8"
expect: set expect_out(buffer) "\r\n\r\nChild exited with status 0\r\nGDBserver exiting\r\n"
FAIL: gdb.base/interrupt.exp: send end of file
Note "expect: read eof" for spawn_id=exp8. exp8 is
inferior_spawn_id/gdbserver_spawn_id. That means
expect/gdb_test_multiple saw gdbserver exit before we got the expected
gdb output. Since there's no explicit pattern for "eof", expect (and
thus gdb_test_multiple) just returns.
After this commit, we get instead:
ERROR: Process no longer exists
UNRESOLVED: gdb.base/interrupt.exp: send end of file
Note that before we still got an FAIL because $saw_inferior_exit is 0
when we get to:
gdb_assert { $saw_eof && $saw_inferior_exit } $msg
Fixing the fail (now unresolved) will be the subject of a separate
patch.
gdb/testsuite/ChangeLog:
2015-04-23 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_test_multiple): Match eof/full_buffer/timeout
on $any_spawn_id instead of only on $gdb_spawn_id.
In readline 6.3, the semantics of SIGWINCH handling has changed.
When a SIGWINCH signal is raised, readline's rl_sigwinch_handler() now
does not immediately call rl_resize_terminal(). Instead it sets a flag
that is checked by RL_CHECK_SIGNALS() at a point where readline has
control, and calls rl_resize_terminal() if said flag is set.
This change is item (c) in https://cnswww.cns.cwru.edu/php/chet/readline/CHANGES
c. Fixed a bug that caused readline to try and run code to modify its idea
of the screen size in a signal handler context upon receiving a SIGWINCH.
This change in behavior is important to us because TUI's
tui_sigwinch_handler() relies on the assumption that by the time it's
called, readline will have updated its knowledge of the terminal
dimensions via rl_resize_terminal(). Since this assumption no longer
holds true, TUI's SIGWINCH handling does not work correctly with
readline 6.3.
To fix this issue this patch makes TUI explicitly call
rl_resize_terminal() in tui_async_resize_screen() at the point where
current terminal dimensions are needed. (We could call it in
tui_sigwinch_handler too, but since readline avoids doing it, we are
probably safer off avoiding to call it in signal handler context as
well.) After this change, SIGWINCH handling continues to work properly
with both readline 6.2 and 6.3.
Since we no longer need it, we could now explicitly disable readline's
SIGWINCH handler by setting rl_catch_sigwinch to zero early on in the
program startup but I can't seem to find a good spot to place this
assignment (the first call to rl_initialize() occurs in
tui_initialize_readline() so the assignment should occur before then),
and the handler is harmless anyway.
gdb/ChangeLog:
* tui/tui-win.c (tui_async_resize_screen): Call
rl_resize_terminal().
Using the 'catch-signal' test from the testsuite, on x86_64 Cygwin:
$ ./gdb testsuite/outputs/gdb.base/catch-signal/catch-signal.exe
[...]
(gdb) catch signal
Catchpoint 1 (standard signals)
(gdb) r
[...]
Catchpoint 1 (signal SIGHUP), main () at
../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
(gdb) c
Continuing.
main () at ../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
Failed to resume program execution (ContinueDebugEvent failed, error 87)
(gdb)
This error occurs because when handle_output_debug_string processes a Cygwin
signal message, it re-writes current_event.dwThreadId to reflect the thread that
the signal will be delivered to, which can be different to the thread reporting
the signal.
Altering current_event.dwThreadId() will cause ContinueDebugEvent() to be
applied to the wrong thread and fail.
So, rather than re-writing the thread id in current_event, use the thread
id by returning it.
With this patch applied this test now yields the expected result:
$ ./gdb testsuite/outputs/gdb.base/catch-signal/catch-signal.exe
[...]
(gdb) catch signal
Catchpoint 1 (standard signals)
(gdb) r
[...]
Catchpoint 1 (signal SIGHUP), main () at
../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
(gdb) c
Continuing.
Catchpoint 1 (signal SIGHUP), main () at
../../../gdb/testsuite/gdb.base/catch-signal.c:42
42 raise (SIGHUP); /* third HUP */
(gdb)
gdb/ChangeLog:
2015-04-22 Jon Turney <jon.turney@dronecode.org.uk>
* windows-nat.c (handle_output_debug_string): Don't change
current_event.dwThreadId.
(get_windows_debug_event): Use thread_id, rather than relying on
current_event.dwThreadId being changed.
Using the 'catch-signal' test from the testsuite, on x86_64 Cygwin:
$ ./gdb testsuite/outputs/gdb.base/catch-signal/catch-signal.exe
[...]
(gdb) catch signal
Catchpoint 1 (standard signals)
(gdb) r
[...]
Catchpoint 1 (signal SIGHUP), main () at
../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
(gdb) c
Continuing.
[hangs]
This is due to a defect in the way Cygwin signals are handled: When
handle_output_debug_string processes a Cygwin signal message, it re-writes
current_event.dwThreadId to reflect the thread that the signal will be delivered
to.
Subsequently, the call to ContinueDebugEvent will fail, because we're trying to
resume the wrong thread. GDB is then stuck waiting forever for another event
that will never come.
This patch doesn't fix the problem, it just adds appropriate error handling.
Using error() seems appropriate here, if ContinueDebugEvent() fails, the
inferior is in an unknown state and we will probably not be debugging it
anymore.
With this patch applied, resuming the execution of the program now yields:
$ ./gdb testsuite/outputs/gdb.base/catch-signal/catch-signal.exe
[...]
(gdb) catch signal
Catchpoint 1 (standard signals)
(gdb) r
[...]
Catchpoint 1 (signal SIGHUP), main () at
../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
(gdb) c
Continuing.
main () at ../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
Failed to resume program execution (ContinueDebugEvent failed, error 87)
(gdb)
gdb/ChangeLog:
2015-04-22 Jon Turney <jon.turney@dronecode.org.uk>
* windows-nat.c (windows_continue): Report an error if
ContinueDebugEvent() fails.
Problem reported as PR pascal/17815
Part 1/3: Remember the case pattern that allowed finding a field of this.
File gdb/p-exp.y modified
This is the fix in the pascal parser (p-exp.y),
to avoid the error that GDB does find normal variables
case insensitively, but not fields of this,
inside a class or object method.
Part 2/3: Add "class" option for pascal compiler
File gdb/testsuite/lib/pascal.exp
This part of the patch series is unchanged.
It adds class option to pascal compiler
which adds the required command line option to
accept pascal class types.
Part 3/3:
New file: gdb/testsuite/gdb.pascal/case-insensitive-symbols.exp
New file: gdb/testsuite/gdb.pascal/case-insensitive-symbols.pas
Here is an updated version of this test, using Pedro's suggestions.
Test to check that PR 17815 is fixed.
This patch extends the rl78 prologue analyzer so that it can recognize
this kind of prologue:
0x119f <main>: movw ax, sp
0x11a1 <main+2>: subw ax, #0x1fa6
0x11a4 <main+5>: movw sp, ax
The test case for gdb.base/miscexprs.exp is now compiled to generate
that sequence instead of a much longer and more inefficient sequence.
gdb/ChangeLog:
* rl78-tdep.c (RL78_SP_ADDR): Define.
(opc_reg_to_gdb_regnum): New static function.
(rl78_analyze_prologue): Recognize instructions forming slightly
more interesting prologues.
This commit fixes three gdb.base/attach.exp failures when using
extended remote targets. The failures occurred because GDB now
locates and loads files when attaching on remote targets if the
remote target supports qXfer:exec-file:read; the filenames were
shown but with "target:" prefixes which the test has been updated
to handle.
gdb/testsuite/ChangeLog:
* gdb.base/attach.exp: Fix three extended remote failures.
Code in update_dprintf_command_list performed a duplicated memory
allocation which caused an obvious memory leak. This removes the
duplication.
gdb/
2015-04-19 Gabriel Krisman Bertazi <gabriel@krisman.be>
* breakpoint.c (update_dprintf_command_list): Remove duplicated
xmalloc.
gdb/
* reply_mig_hack.awk: Don't bother to declare an intermediate
function pointer variable.
... allowing us to simplify the parsing a little bit. And, instead of
"warning: initialization from incompatible pointer type", we now get "warning:
function called through a non-compatible type". Oh well.
gdb/ChangeLog:
* solib-svr4.c (svr4_exec_displacement): Rename outer "displacement"
to "exec_displacement" to avoid confusion with inner use of the name.
xtensa_usrregs_info refers to undefined variables xtensa_num_regs and
xtensa_regmap. Drop xtensa_usrregs_info and replace pointer to usrregs
in regs_info with NULL since all registers are read/set through regsets.
2015-04-17 Max Filippov <jcmvbkbc@gmail.com>
gdb/gdbserver/
* linux-xtensa-low.c (xtensa_usrregs_info): Remove.
(regs_info): Replace usrregs pointer with NULL.
This patch is to cherry-pick part of Pedro's patch here
https://sourceware.org/ml/gdb-patches/2015-04/msg00527.html in which
zero is returned if the HW point isn't supported.
In arm-linux native gdb testing on a board doesn't support HW breakpoint,
without this patch, the output in gdb.base/breakpoint-in-ro-region.exp is like:
(gdb) hbreak *0x83bc^M
Hardware breakpoints used exceeds limit.^M
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: probe hbreak support (support)
with this patch, the output becomes:
(gdb) hbreak *0x83bc^M
No hardware breakpoint support in the target.^M
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: probe hbreak support (no support)
As a result, the following fails are fixed.
-FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: step in ro region (cannot insert hw break)
-FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: thread advanced
-FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: step in ro region (cannot insert hw break)
-FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: thread advanced
gdb:
2015-04-17 Pedro Alves <palves@redhat.com>
* arm-linux-nat.c (arm_linux_can_use_hw_breakpoint): Return zero
if HW point of TYPE isn't supported.
The return value of target_can_use_hardware_watchpoint isn't well
documented, so this patch is to update the comments to reflect the
fact. This patch also removes a trailing ";" which is picked up
from Pedro's patch https://sourceware.org/ml/gdb-patches/2015-04/msg00527.html
gdb:
2015-04-17 Yao Qi <yao.qi@linaro.org>
Pedro Alves <palves@redhat.com>
* target.h (target_can_use_hardware_watchpoint): Update comments.
Remove trailing ";".
This commit modifies remote_add_inferior to take an extra argument
try_open_exec. If this is nonzero, remote_add_inferior will attempt
to open this inferior's executable as the main executable if no main
executable is open already. Callers are updated appropriately.
With this commit, remote debugging can now be initiated using only a
"target remote" or "target extended-remote" command; no "set sysroot"
or "file" commands are required, e.g.
bash$ gdb -q
(gdb) target remote | gdbserver - /bin/sh
Remote debugging using | gdbserver - /bin/sh
Process /bin/sh created; pid = 32166
stdin/stdout redirected
Remote debugging using stdio
Reading symbols from target:/bin/bash...
One testcase required updating as a result of this commit. The test
checked that GDB's "info files" command does not crash if no main
executable is open, and relied on GDB's inability to access the main
executable over the remote protocol. The test was updated to inhibit
this new behavior.
gdb/ChangeLog:
* remote.c (remote_add_inferior): New argument try_open_exec.
If nonzero, attempt to open the inferior's executable file as
the main executable if no main executable is open already.
All callers updated.
* NEWS: Mention that GDB now supports automatic location and
retrieval of executable + files from remote targets.
gdb/doc/ChangeLog:
* gdb.texinfo (Connecting to a Remote Target): Mention that
GDB can access program files from remote targets that support
qXfer:exec-file:read and Host I/O packets.
gdb/testsuite/ChangeLog:
* gdb.server/server-exec-info.exp: Inhibit GDB from accessing
the main executable over the remote protocol.
This commit adds a new packet "qXfer:exec-file:read" to the remote
protocol that can be used to obtain the pathname of the file that
was executed to create a process on the remote system. Support for
this packet is added to GDB and remote_ops.to_pid_to_exec_file is
implemented using it.
gdb/ChangeLog:
* target.h (TARGET_OBJECT_EXEC_FILE): New enum value.
* remote.c (PACKET_qXfer_exec_file): Likewise.
(remote_protocol_features): Register the
"qXfer:exec-file:read" feature.
(remote_xfer_partial): Handle TARGET_OBJECT_EXEC_FILE.
(remote_pid_to_exec_file): New function.
(init_remote_ops): Initialize to_pid_to_exec_file.
(_initialize_remote): Register new "set/show remote
pid-to-exec-file-packet" command.
* NEWS: Announce new qXfer:exec-file:read packet.
gdb/doc/ChangeLog:
* gdb.texinfo (Remote Configuration): Document the "set/show
remote pid-to-exec-file-packet" command.
(General Query Packets): Document the qXfer:exec-file:read
qSupported features. Document the qXfer:exec-file:read packet.
This commit introduces a new function linux_proc_pid_to_exec_file
that shared Linux code can use to discover the filename of the
executable that was run to create a process on the system.
gdb/ChangeLog:
* nat/linux-procfs.h (linux_proc_pid_to_exec_file):
New declaration.
* nat/linux-procfs.c (linux_proc_pid_to_exec_file):
New function, factored out from...
* linux-nat.c (linux_child_pid_to_exec_file): ...here.
