Remove native-only core file handling on GNU Hurd. Instead, enable the
x86 target generic core regset logic on the Hurd by providing an
appropriate register offset map.
Thanks to Samuel Thibault for testing!
gdb/
* config/i386/i386gnu.mh (NATDEPFILES): Remove core-regset.o.
* i386gnu-nat.c: Do not include <sys/procfs.h> or "gregset.h".
(CREG_OFFSET, creg_offset, CREG_ADDR): Remove.
(supply_gregset, supply_fpregset): Remove.
* i386gnu-tdep.c (i386gnu_gregset_reg_offset): New variable.
(i386gnu_init_abi): Set tdep->gregset_reg_offset, gregset_num_regs,
and sizeof_gregset.
There is already "add-auto-load-safe-path" which works
like "set auto-load safe-path" but in append mode.
There was missing an append equivalent for "set auto-load scripts-directory".
ABRT has directory /var/cache/abrt-di/ as an alternative one
to /usr/lib/debug/ . Therefore ABRT needs to use -iex parameters to add this
/var/cache/abrt-di/ directory as a first-class debuginfo directory.
Using absolute "set auto-load scripts-directory" would hard-code the path
possibly overriding local system directory additions; besides it would not be
nice anyway.
gdb/ChangeLog
2014-11-30 Jan Kratochvil <jan.kratochvil@redhat.com>
Add add-auto-load-scripts-directory.
* NEWS (Changes since GDB 7.8): Add add-auto-load-scripts-directory.
* auto-load.c (add_auto_load_dir): New function.
(_initialize_auto_load): Install it.
gdb/doc/ChangeLog
2014-11-30 Jan Kratochvil <jan.kratochvil@redhat.com>
Add add-auto-load-scripts-directory.
* gdb.texinfo (Auto-loading): Add add-auto-load-scripts-directory link.
(objfile-gdbdotext file): Add add-auto-load-scripts-directory.
I noticed in frame_id_eq() we were checking for the "l" frame_id being
invalid twice instead of checking both "l" and "r", so this patch
corrects it.
gdb/ChangeLog:
* frame.c (frame_id_eq): Fix the check for FID_STACK_INVALID.
This fixes a regression introduced by 6c659fc2c7.
gdb/ChangeLog:
* eval.c (evaluate_subexp): Check that thread stack temporaries
are not already enabled before enabling them.
I find local variables framereg and framesize is only used when cache
isn't NULL. This patch to move the code into "if (cache)" block.
gdb:
2014-11-29 Yao Qi <yao@codesourcery.com>
* arm-tdep.c (arm_analyze_prologue): Move local variables
'framereg' and 'framesize' to inner block. Move code to
inner block too.
gdb/ChangeLog:
* eval.c: Include gdbthread.h.
(evaluate_subexp): Enable thread stack temporaries before
evaluating a complete expression and clean them up after the
evaluation is complete.
* gdbthread.h: Include common/vec.h.
(value_ptr): New typedef.
(VEC (value_ptr)): New vector type.
(value_vec): New typedef.
(struct thread_info): Add new fields stack_temporaries_enabled
and stack_temporaries.
(enable_thread_stack_temporaries)
(thread_stack_temporaries_enabled_p, push_thread_stack_temporary)
(get_last_thread_stack_temporary)
(value_in_thread_stack_temporaries): Declare.
* gdbtypes.c (class_or_union_p): New function.
* gdbtypes.h (class_or_union_p): Declare.
* infcall.c (call_function_by_hand): Store return values of class
type as temporaries on stack.
* thread.c (enable_thread_stack_temporaries): New function.
(thread_stack_temporaries_enabled_p, push_thread_stack_temporary)
(get_last_thread_stack_temporary): Likewise.
(value_in_thread_stack_temporaries): Likewise.
* value.c (value_force_lval): New function.
* value.h (value_force_lval): Declare.
gdb/testsuite/ChangeLog:
* gdb.cp/chained-calls.cc: New file.
* gdb.cp/chained-calls.exp: New file.
* gdb.cp/smartp.exp: Remove KFAIL for "p c2->inta".
Dwarf register numbers are defined in "System V Application Binary
Interface AMD64 Architecture Processor Supplement Draft Version 0.99.6"
The amd64_dwarf_regmap array is missing the 8 MMX registers in Figure
3.36: DWARF Register Number Mapping page 57. This leads to a wrong
value for the registers past this point.
gdb/ChangeLog:
Pushed by Joel Brobecker <brobecker@adacore.com>.
* amd64-tdep.c (amd64_dwarf_regmap array): Add missing MMX
registers.
Tested on x86_64-linux.
Since Andreas Arnez' recent patch series, all Linux targets install
gdbarch_iterate_over_regset_sections routines. This means that on
Linux native targets, old-style core sniffers are never used.
Most Linux targets haven't been using such sniffers for a long time
anyway, but a couple remain: ia64 and sparc use core-regset.o, and
m68k installs its own core_fns. All this is now dead code, which
this commit removes.
gdb/
2014-11-28 Ulrich Weigand <uweigand@de.ibm.com>
* config/ia64/linux.mh (NATDEPFILES): Remove core-regset.o.
* config/sparc/linux.mh (NATDEPFILES): Likewise.
* config/sparc/linux64.mh (NATDEPFILES): Likewise.
* m68klinux-nat.c (fetch_core_registers): Remove.
(linux_elf_core_fns): Remove.
(_initialize_m68k_linux_nat): Do not call deprecated_add_core_fns.
Rework the comment to explain why we're still relying on GetFullPathName
even though gnulib ensures that canonicalize_file_name is now available
on all platforms, including Windows.
gdb/ChangeLog:
* utils.c (gdb_realpath): Rework comment about handling on
Windows.
Since lstat gnulib module is imported, we can use it unconditionally.
lstat usage was introduced by this patch
https://sourceware.org/ml/gdb-patches/2012-01/msg00390.html
during the review, it was suggested to import gnulib lstat module, but
we didn't do that.
gdb:
2014-11-28 Yao Qi <yao@codesourcery.com>
* configure.ac (AC_CHECK_FUNCS): Remove lstat.
* config.in, configure: Regenerate.
* symfile.c (find_separate_debug_file_by_debuglink): Remove
code checking HAVE_LSTAT is defined.
Since readlink module is imported, we can use it unconditionally.
This patch is to remove configure checks and HAVE_READLINK checks in
code. It was mentioned in the patch below
[RFA/commit] gdbserver: return ENOSYS if readlink not supported.
https://sourceware.org/ml/gdb-patches/2012-02/msg00148.html
to use readlink in gdbserver, but we chose something simple at that
moment.
gdb:
2014-11-28 Yao Qi <yao@codesourcery.com>
* configure.ac (AC_CHECK_FUNCS): Remove readlink.
* config.in, configure: Re-generate.
* inf-child.c (inf_child_fileio_readlink): Don't check
HAVE_READLINK is defined.
gdb/gdbserver:
2014-11-28 Yao Qi <yao@codesourcery.com>
* configure.ac(AC_CHECK_FUNCS): Remove readlink.
* config.in, configure: Re-generate.
* hostio.c (handle_unlink): Remove code checking HAVE_READLINK
is defined.
This patch is to import readlink gnulib module. stat module is imported
too, but it isn't used by gdb.
gdb:
2014-11-28 Yao Qi <yao@codesourcery.com>
* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add readlink.
* gnulib/aclocal.m4: Re-generated.
* gnulib/config.in: Likewise.
* gnulib/configure: Likewise.
* gnulib/import/Makefile.am: Likewise.
* gnulib/import/Makefile.in: Likewise.
* gnulib/import/m4/gnulib-cache.m4: Likewise.
* gnulib/import/m4/gnulib-comp.m4: Likewise.
* gnulib/import/dosname.h: New file
* gnulib/import/m4/largefile.m4: New file.
* gnulib/import/m4/readlink.m4: New file.
* gnulib/import/m4/stat.m4: New file.
* gnulib/import/readlink.c: New file.
* gnulib/import/stat.c: New file.
2014-11-25 Sandra Loosemore <sandra@codesourcery.com>
gdb/
* nios2-tdep.c (nios2_analyze_prologue): Replace restriction
that there can be only one stack adjustment in the prologue
with tests to detect specific disallowed stack adjustments.
instruction matching.
2014-11-25 Sandra Loosemore <sandra@codesourcery.com>
gdb/
* nios2-tdep.c (nios2_fetch_insn): Move up in file. Disassemble
the instruction as well as reading it from memory.
(nios2_match_add): New.
(nios2_match_sub): New.
(nios2_match_addi): New.
(nios2_match_orhi): New.
(nios2_match_stw): New.
(nios2_match_ldw): New.
(nios2_match_rdctl): New.
(enum branch_condition): New.
(nios2_match_branch): New.
(nios2_match_jmpi): New.
(nios2_match_calli): New.
(nios2_match_jmpr): New.
(nios2_match_callr): New.
(nios2_match_break): New.
(nios2_match_trap): New.
(nios2_in_epilogue_p): Rewrite to use new functions.
(nios2_analyze_prologue): Likewise.
(nios2_skip_prologue): Delete unused local limit_pc.
(nios2_breakpoint_from_pc): Make R1-specific encodings explicit.
(nios2_get_next_pc): Rewrite to use new functions.
2014-11-24 Samuel Thibault <samuel.thibault@ens-lyon.org>
* gdb/gnu-nat.c (inf_validate_procinfo): Multiply the number of
elements pi_len by the size of the elements before calling
vm_deallocate.
(inf_validate_task_sc): Likewise, and properly deallocate the
noise array.
gdb/ChangeLog:
* gdbtypes.c (print_args): Renamed from print_arg_types. Print arg
number and name if present. All callers updated.
(dump_fn_fieldlists): Fix indentation of args.
A recent change...
commit 1a853c5224
Date: Wed Nov 12 10:10:49 2014 +0000
Subject: make "permanent breakpoints" per location and disableable
... broke function calls on sparc-elf when running over QEMU. Any
function call should demonstrate the problem.
For instance, seen from the debugger:
(gdb) call pn(1234)
[Inferior 1 (Remote target) exited normally]
The program being debugged exited while in a function called from GDB.
Evaluation of the expression containing the function
And seen from QEMU:
qemu: fatal: Trap 0x02 while interrupts disabled, Error state
[register dump removed]
What happens in this case is that GDB sets the inferior function call
by not only creating the dummy frame, but also writing a breakpoint
instruction at the return address for our function call. See infcall.c:
/* Write a legitimate instruction at the point where the infcall
breakpoint is going to be inserted. While this instruction
is never going to be executed, a user investigating the
memory from GDB would see this instruction instead of random
uninitialized bytes. We chose the breakpoint instruction
as it may look as the most logical one to the user and also
valgrind 3.7.0 needs it for proper vgdb inferior calls.
If software breakpoints are unsupported for this target we
leave the user visible memory content uninitialized. */
bp_addr_as_address = bp_addr;
bp_bytes = gdbarch_breakpoint_from_pc (gdbarch, &bp_addr_as_address,
&bp_size);
if (bp_bytes != NULL)
write_memory (bp_addr_as_address, bp_bytes, bp_size);
This instruction triggers a change introduced by the commit above,
where we consider bp locations as being permanent breakpoints
if there is already a breakpoint instruction at that address:
+ if (bp_loc_is_permanent (loc))
+ {
+ loc->inserted = 1;
+ loc->permanent = 1;
+ }
As a result, when resuming the program's execution for the inferior
function call, GDB decides that it does not need to insert a breakpoint
at this address, expecting the target to just report a SIGTRAP when
trying to execute that instruction.
But unfortunately for us, at least some versions of QEMU for SPARC
just terminate the execution entirely instead of reporting a breakpoint,
thus producing the behavior reported here.
Although it appears like QEMU might be misbehaving and should therefore
be fixed (to be verified) from the user's point of view, the recent
change does introduce a regression. So this patch tries to mitigate
a bit the damage by handling such infcall breakpoints as special and
making sure that they are never considered permanent, thus restoring
the previous behavior specifically for those breakpoints.
The option of not writing the breakpoint instructions in the first
place was considered, and would probably work also. But the comment
associated to it seems to indicate that there is still reason to
keep it.
gdb/ChangeLog:
* breakpoint.c (bp_loc_is_permanent): Return 0 if LOC corresponds
to a bp_call_dummy breakpoint type.
Tested on x86_64-linux. Also testing on sparc-elf/QEMU using
AdaCore's testsuite.
SA_RESTART allows system calls to be restarted across a signal handler.
By specifying this flag we fix the issue where if the user is being
prompted to answer yes or no, and the terminal gets resized in the
meantime, the prompt will think that the user sent an EOF and so it will
take the default action for that prompt (in the case of the quit prompt,
it will quit GDB).
gdb/ChangeLog:
* tui/tui-win.c (tui_initialize_win): Specify SA_RESTART when
registering the signal handler.
This patch fixes the annoying bug where key sequences such as Alt_F or
Alt_B (go forward or backwards by a word) do not behave promptly in TUI.
You have to press a third key in order for the key sequence to register.
This is mostly ncurses' fault. Calling wgetch() normally causes ncurses
to read only a single key from stdin. However if the key read is the
start-sequence key (^[ a.k.a. ESC) then wgetch() reads TWO keys from
stdin, storing the 2nd key into an internal FIFO buffer and returning
the start-sequence key. The extraneous read of the 2nd key makes us
miss its corresponding stdin event, so the event loop blocks until a
third key is pressed. This explains why such key sequences do not
behave promptly in TUI.
To fix this issue, we must somehow compensate for the missed stdin event
corresponding to the 2nd byte of a key sequence. This patch achieves
this by hacking up the stdin event handler to conditionally execute the
readline callback multiple times in a row. This is done via a new
global variable, call_stdin_event_handler_again_p, which is set from
tui_getc() when we receive a start-sequence key and notice extra pending
input in the ncurses buffer.
Tested on x86_64-unknown-linux-gnu.
gdb/ChangeLog:
* event-top.h (call_stdin_event_handler_again_p): Declare.
* event-top.c (call_stdin_event_handler_again_p): Define.
(stdin_event_handler): Use it.
* tui/tui-io.c (tui_getc): Prepare to call the stdin event
handler again if there is pending input following a
start sequence.
This way the user can know the index of the latest checkpoint without
having to run "info checkpoints" afterwards.
gdb/ChangeLog:
* linux-fork.c (checkpoint_command): Print index of new
checkpoint in response message.
In read_string, we have this line
chunksize = (len == -1 ? min (8, fetchlimit) : fetchlimit);
but chunksize is only used in the block that lne == -1, so IWBN to
move chunksize to the block in which it is used, and simplify the
condition setting chunksize. This patch also moves 'found_nul' to
inner block. This patch also splits a paragraph of comment into two,
and move them to different condition blocks (len > 0 and len == -1)
respectively.
gdb:
2014-11-23 Yao Qi <yao@codesourcery.com>
* valprint.c (read_string): Move local variables 'found_nul',
'chunksize' and 'limit' to inner scope. Update comments.
errno.h is included in common/common-defs.h, and gnulib errno module
was imported to gdb. This patch is to import it explicitly.
gdb:
* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add
errno.
* gnulib/import/Makefile.am: Re-generated.
* gnulib/import/Makefile.in: Likewise.
* gnulib/import/m4/gnulib-cache.m4: Likewise.
As gnulib modules wchar and wctype is imported, we can include wchar.h
and wctype.h unconditionally. This patch is also to remove HAVE_WCHAR_H
check.
gdb:
2014-11-21 Yao Qi <yao@codesourcery.com>
* gdb_wchar.h: Include wchar.h and wctype.h.
[HAVE_ICONV && HAVE_BTOWC]: Don't check HAVE_WCHAR_T and don't
include wchar.h and wctype.h.
Don't check HAVE_WCHAR_H.
gnulib module wchar and wctype-h was imported as a dependency, but
they are used by gdb_wchar.h too. This patch is to import them
explicitly.
gdb:
* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add wchar
and wctype-h.
* gnulib/import/Makefile.am: Re-generated.
* gnulib/import/Makefile.in: Likewise.
* gnulib/import/m4/gnulib-cache.m4: Likewise.
memchr has been used in gdb source and gnulib memchr module was
imported as a dependency. This patch is to import it explicitly.
gdb:
* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add
memchr.
* gnulib/import/Makefile.am: Re-generated.
* gnulib/import/Makefile.in: Likewise.
* gnulib/import/m4/gnulib-cache.m4: Likewise.
Since gnulib alloca module was imported, we can include alloca.h in
both gdb and gdbserver unconditionally, so this patch adds inclusion
of alloca.h in common-defs.h. This patch also removes AC_FUNC_ALLOCA
in configure.ac because we don't need to check alloca any more.
This patch below is removed in fact.
[RFA/commit] include alloca.h if available.
https://www.sourceware.org/ml/gdb-patches/2010-08/msg00566.html
Since alloca.h is from gnulib now, we don't have to check malloc.h in
configure and include malloc.h in code. This patch also remove them
too.
gdb:
2014-11-21 Yao Qi <yao@codesourcery.com>
* common/common-defs.h: Include alloca.h
* configure.ac: Don't invoke AC_FUNC_ALLOCA.
* configure: Re-generated.
* defs.h: Remove code handling alloca.
* utils.c (gdb_realpath): Don't check HAVE_ALLOCA is defined
or not.
gdb/gdbserver:
2014-11-21 Yao Qi <yao@codesourcery.com>
* configure.ac: Don't invoke AC_FUNC_ALLOCA.
(AC_CHECK_HEADERS): Remove malloc.h.
* configure: Re-generated.
* config.in: Re-generated.
* server.h: Don't include alloca.h and malloc.h.
* gdbreplay.c: Don't check HAVE_ALLOCA_H is defined.
Don't include malloc.h.
gnulib's alloca module was imported to gdb, and alloca is used. This
patch is to explicitly import it.
gdb:
* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULE): Add
alloca.
* gnulib/import/Makefile.am: Re-generated.
* gnulib/import/Makefile.in: Likewise..
* gnulib/import/m4/gnulib-cache.m4: Likewise.
Since we'll add more modules in this list, better to keep them in
alphabetical order.
gdb:
* gnulib/update-gnulib.sh: Make IMPORTED_GNULIB_MODULES in
alphabetical order.
Consider the following variable declaration:
type Array_Type is array (Integer range <>) of Integer;
Var: Array_Type (0 .. -1);
"ptype var" prints the wrong upper bound for that array:
(gdb) ptype var
type = array (0 .. 4294967295) of integer
The debugging info for the type of variable "Var" is as follow:
<2><cf>: Abbrev Number: 13 (DW_TAG_structure_type)
<d0> DW_AT_name : foo__var___PAD
<3><db>: Abbrev Number: 14 (DW_TAG_member)
<dc> DW_AT_name : F
<e0> DW_AT_type : <0xa5>
This is just an artifact from code generation, which is just
a wrapper that we should ignore. The real type is the type of
field "F" in that PAD type, which is described as:
<2><a5>: Abbrev Number: 10 (DW_TAG_array_type)
<a6> DW_AT_name : foo__TvarS
<3><b6>: Abbrev Number: 11 (DW_TAG_subrange_type)
<b7> DW_AT_type : <0xc1>
<bb> DW_AT_lower_bound : 0
<bc> DW_AT_upper_bound : 0xffffffff
Trouble occurs because DW_AT_upper_bound is encoded using
a DW_FORM_data4, which is ambiguous regarding signedness.
In that case, dwarf2read.c::dwarf2_get_attr_constant_value
reads the value as unsigned, which is not what we want
in this case.
As it happens, we already have code dealing with this situation
in dwarf2read.c::read_subrange_type which checks whether
the subrange's type is signed or not, and if it is, fixes
the bound's value by sign-extending it:
if (high.kind == PROP_CONST
&& !TYPE_UNSIGNED (base_type) && (high.data.const_val & negative_mask))
high.data.const_val |= negative_mask;
Unfortunately, what happens in our case is that the base type
of the array's subrange type is marked as being unsigned, and
so we never get to apply the sign extension. Following the DWARF
trail, the range's base type is described as another subrange type...
<2><c1>: Abbrev Number: 12 (DW_TAG_subrange_type)
<c7> DW_AT_name : foo__TTvarSP1___XDLU_0__1m
<cb> DW_AT_type : <0x2d>
... whose base type is, (finally), a basic type (signed):
<1><2d>: Abbrev Number: 2 (DW_TAG_base_type)
<2e> DW_AT_byte_size : 4
<2f> DW_AT_encoding : 5 (signed)
<30> DW_AT_name : integer
The reason why GDB thinks that foo__TTvarSP1___XDLU_0__1m
(the base type of the array's range type) is an unsigned type
is found in gdbtypes.c::create_range_type. We consider that
a range type is unsigned iff its lower bound is >= 0:
if (low_bound->kind == PROP_CONST && low_bound->data.const_val >= 0)
TYPE_UNSIGNED (result_type) = 1;
That is normally sufficient, as one would expect the upper bound to
always be greater or equal to the lower bound. But Ada actually
allows the declaration of empty range types where the upper bound
is less than the lower bound. In this case, the upper bound is
negative, so we should not be marking the type as unsigned.
This patch fixes the issue by simply checking the upper bound as well
as the lower bound, and clears the range type's unsigned flag when
it is found to be constant and negative.
gdb/ChangeLog:
* gdbtypes.c (create_range_type): Unset RESULT_TYPE's
flag_unsigned if HIGH_BOUND is constant and negative.
gdb/testsuite/ChangeLog:
* gdb.ada/n_arr_bound: New testcase.
Tested on x86_64-linux.
In the previous commit, I forgot to adjust the prototypes of the
functions inside gdb/xml-syscall.c for the case when GDB is compiled
without XML support.
gdb/
2014-11-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/10737
* xml-syscall.c (set_xml_syscall_file_name): Remove "const"
modifier from "struct gdbarch" when compiling without Expat (XML)
support.
(get_syscall_by_number): Likewise.
(get_syscall_by_name): Likewise.
(get_syscall_names): Likewise.
This patch intends to partially fix PR breakpoints/10737, which is
about making the syscall information (for the "catch syscall" command)
be per-arch, instead of global. This is not a full fix because of the
other issues pointed by Pedro here:
<https://sourceware.org/bugzilla/show_bug.cgi?id=10737#c5>
However, I consider it a good step towards the real fix. It will also
help me fix <https://sourceware.org/bugzilla/show_bug.cgi?id=17402>.
What this patch does, basically, is move the "syscalls_info"
struct to gdbarch. Currently, the syscall information is stored in a
global variable inside gdb/xml-syscall.c, which means that there is no
easy way to correlate this info with the current target or
architecture being used, for example. This causes strange behaviors,
because the syscall info is not re-read when the arch changes. For
example, if you put a syscall catchpoint in syscall 5 on i386 (syscall
open), and then load a x86_64 program on GDB and put the same syscall
5 there (fstat on x86_64), you will still see that GDB tells you that
it is catching "open", even though it is not. With this patch, GDB
correctly says that it will be catching fstat syscalls.
(gdb) set architecture i386
The target architecture is assumed to be i386
(gdb) catch syscall 5
Catchpoint 1 (syscall 'open' [5])
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) catch syscall 5
Catchpoint 2 (syscall 'open' [5])
But with the patch:
(gdb) set architecture i386
The target architecture is assumed to be i386
(gdb) catch syscall 5
Catchpoint 1 (syscall 'open' [5])
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) catch syscall 5
Catchpoint 2 (syscall 'fstat' [5])
As I said, there are still some problems on the "catch syscall"
mechanism, because (for example) the user should be able to "catch
syscall open" on i386, and then expect "open" to be caught also on
x86_64. Currently, it doesn't work. I intend to work on this later.
gdb/
2014-11-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/10737
* amd64-linux-tdep.c (amd64_linux_init_abi_common): Adjust call to
set_xml_syscall_file_name to provide gdbarch.
* arm-linux-tdep.c (arm_linux_init_abi): Likewise.
* bfin-linux-tdep.c (bfin_linux_init_abi): Likewise.
* breakpoint.c (print_it_catch_syscall): Adjust call to
get_syscall_by_number to provide gdbarch.
(print_one_catch_syscall): Likewise.
(print_mention_catch_syscall): Likewise.
(print_recreate_catch_syscall): Likewise.
(catch_syscall_split_args): Adjust calls to get_syscall_by_number
and get_syscall_by_name to provide gdbarch.
(catch_syscall_completer): Adjust call to get_syscall_names to
provide gdbarch.
* gdbarch.c: Regenerate.
* gdbarch.h: Likewise.
* gdbarch.sh: Forward declare "struct syscalls_info".
(xml_syscall_file): New variable.
(syscalls_info): Likewise.
* i386-linux-tdep.c (i386_linux_init_abi): Adjust call to
set_xml_syscall_file_name to provide gdbarch.
* mips-linux-tdep.c (mips_linux_init_abi): Likewise.
* ppc-linux-tdep.c (ppc_linux_init_abi): Likewise.
* s390-linux-tdep.c (s390_gdbarch_init): Likewise.
* sparc-linux-tdep.c (sparc32_linux_init_abi): Likewise.
* sparc64-linux-tdep.c (sparc64_linux_init_abi): Likewise.
* xml-syscall.c: Include gdbarch.h.
(set_xml_syscall_file_name): Accept gdbarch parameter.
(get_syscall_by_number): Likewise.
(get_syscall_by_name): Likewise.
(get_syscall_names): Likewise.
(my_gdb_datadir): Delete global variable.
(struct syscalls_info) <my_gdb_datadir>: New variable.
(struct syscalls_info) <sysinfo>: Rename variable to
"syscalls_info".
(sysinfo): Delete global variable.
(have_initialized_sysinfo): Likewise.
(xml_syscall_file): Likewise.
(sysinfo_free_syscalls_desc): Rename to...
(syscalls_info_free_syscalls_desc): ... this.
(free_syscalls_info): Rename "sysinfo" to "syscalls_info". Adjust
code to the new layout of "struct syscalls_info".
(make_cleanup_free_syscalls_info): Rename parameter "sysinfo" to
"syscalls_info".
(syscall_create_syscall_desc): Likewise.
(syscall_start_syscall): Likewise.
(syscall_parse_xml): Likewise.
(xml_init_syscalls_info): Likewise. Drop "const" from return value.
(init_sysinfo): Rename to...
(init_syscalls_info): ...this. Add gdbarch as a parameter.
Adjust function to deal with gdbarch.
(xml_get_syscall_number): Delete parameter sysinfo. Accept
gdbarch as a parameter. Adjust code.
(xml_get_syscall_name): Likewise.
(xml_list_of_syscalls): Likewise.
(set_xml_syscall_file_name): Accept gdbarch as parameter.
(get_syscall_by_number): Likewise.
(get_syscall_by_name): Likewise.
(get_syscall_names): Likewise.
* xml-syscall.h (set_xml_syscall_file_name): Likewise.
(get_syscall_by_number): Likewise.
(get_syscall_by_name): Likewise.
(get_syscall_names): Likewise.
gdb/testsuite/
2014-11-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/10737
* gdb.base/catch-syscall.exp (do_syscall_tests): Call
test_catch_syscall_multi_arch.
(test_catch_syscall_multi_arch): New function.
Currently "symtabs" in gdb are stored as a single linked list of
struct symtab that contains both symbol symtabs (the blockvectors)
and file symtabs (the linetables).
This has led to confusion, bugs, and performance issues.
This patch is conceptually very simple: split struct symtab into
two pieces: one part containing things common across the entire
compilation unit, and one part containing things specific to each
source file.
Example.
For the case of a program built out of these files:
foo.c
foo1.h
foo2.h
bar.c
foo1.h
bar.h
Today we have a single list of struct symtabs:
objfile -> foo.c -> foo1.h -> foo2.h -> bar.c -> foo1.h -> bar.h -> NULL
where "->" means the "next" pointer in struct symtab.
With this patch, that turns into:
objfile -> foo.c(cu) -> bar.c(cu) -> NULL
| |
v v
foo.c bar.c
| |
v v
foo1.h foo1.h
| |
v v
foo2.h bar.h
| |
v v
NULL NULL
where "foo.c(cu)" and "bar.c(cu)" are struct compunit_symtab objects,
and the files foo.c, etc. are struct symtab objects.
So now, for example, when we want to iterate over all blockvectors
we can now just iterate over the compunit_symtab list.
Plus a lot of the data that was either unused or replicated for each
symtab in a compilation unit now lives in struct compunit_symtab.
E.g., the objfile pointer, the producer string, etc.
I thought of moving "language" out of struct symtab but there is
logic to try to compute the language based on previously seen files,
and I think that's best left as is for now.
With my standard monster benchmark with -readnow (which I can't actually
do, but based on my calculations), whereas today the list requires
77MB to store all the struct symtabs, it now only requires 37MB.
A modest space savings given the gigabytes needed for all the debug info,
etc. Still, it's nice. Plus, whereas today we create a copy of dirname
for each source file symtab in a compilation unit, we now only create one
for the compunit.
So this patch is basically just a data structure reorg,
I don't expect significant performance improvements from it.
Notes:
1) A followup patch can do a similar split for struct partial_symtab.
I have left that until after I get the changes I want in to
better utilize .gdb_index (it may affect how we do partial syms).
2) Another followup patch *could* rename struct symtab.
The term "symtab" is ambiguous and has been a source of confusion.
In this patch I'm leaving it alone, calling it the "historical" name
of "filetabs", which is what they are now: just the file-name + line-table.
gdb/ChangeLog:
Split struct symtab into two: struct symtab and compunit_symtab.
* amd64-tdep.c (amd64_skip_xmm_prologue): Fetch producer from compunit.
* block.c (blockvector_for_pc_sect): Change "struct symtab *" argument
to "struct compunit_symtab *". All callers updated.
(set_block_compunit_symtab): Renamed from set_block_symtab. Change
"struct symtab *" argument to "struct compunit_symtab *".
All callers updated.
(get_block_compunit_symtab): Renamed from get_block_symtab. Change
result to "struct compunit_symtab *". All callers updated.
(find_iterator_compunit_symtab): Renamed from find_iterator_symtab.
Change result to "struct compunit_symtab *". All callers updated.
* block.h (struct global_block) <compunit_symtab>: Renamed from symtab.
hange type to "struct compunit_symtab *". All uses updated.
(struct block_iterator) <d.compunit_symtab>: Renamed from "d.symtab".
Change type to "struct compunit_symtab *". All uses updated.
* buildsym.c (struct buildsym_compunit): New struct.
(subfiles, buildsym_compdir, buildsym_objfile, main_subfile): Delete.
(buildsym_compunit): New static global.
(finish_block_internal): Update to fetch objfile from
buildsym_compunit.
(make_blockvector): Delete objfile argument.
(start_subfile): Rewrite to use buildsym_compunit. Don't initialize
debugformat, producer.
(start_buildsym_compunit): New function.
(free_buildsym_compunit): Renamed from free_subfiles_list.
All callers updated.
(patch_subfile_names): Rewrite to use buildsym_compunit.
(get_compunit_symtab): New function.
(get_macro_table): Delete argument comp_dir. All callers updated.
(start_symtab): Change result to "struct compunit_symtab *".
All callers updated. Create the subfile of the main source file.
(watch_main_source_file_lossage): Rewrite to use buildsym_compunit.
(reset_symtab_globals): Update.
(end_symtab_get_static_block): Update to use buildsym_compunit.
(end_symtab_without_blockvector): Rewrite.
(end_symtab_with_blockvector): Change result to
"struct compunit_symtab *". All callers updated.
Update to use buildsym_compunit. Don't set symtab->dirname,
instead set it in the compunit.
Explicitly make sure main symtab is first in its list.
Set debugformat, producer, blockvector, block_line_section, and
macrotable in the compunit.
(end_symtab_from_static_block): Change result to
"struct compunit_symtab *". All callers updated.
(end_symtab, end_expandable_symtab): Ditto.
(set_missing_symtab): Change symtab argument to
"struct compunit_symtab *". All callers updated.
(augment_type_symtab): Ditto.
(record_debugformat): Update to use buildsym_compunit.
(record_producer): Update to use buildsym_compunit.
* buildsym.h (struct subfile) <dirname>: Delete.
<producer, debugformat>: Delete.
<buildsym_compunit>: New member.
(get_compunit_symtab): Declare.
* dwarf2read.c (struct type_unit_group) <compunit_symtab>: Renamed
from primary_symtab. Change type to "struct compunit_symtab *".
All uses updated.
(dwarf2_start_symtab): Change result to "struct compunit_symtab *".
All callers updated.
(dwarf_decode_macros): Delete comp_dir argument. All callers updated.
(struct dwarf2_per_cu_quick_data) <compunit_symtab>: Renamed from
symtab. Change type to "struct compunit_symtab *". All uses updated.
(dw2_instantiate_symtab): Change result to "struct compunit_symtab *".
All callers updated.
(dw2_find_last_source_symtab): Ditto.
(dw2_lookup_symbol): Ditto.
(recursively_find_pc_sect_compunit_symtab): Renamed from
recursively_find_pc_sect_symtab. Change result to
"struct compunit_symtab *". All callers updated.
(dw2_find_pc_sect_compunit_symtab): Renamed from
dw2_find_pc_sect_symtab. Change result to
"struct compunit_symtab *". All callers updated.
(get_compunit_symtab): Renamed from get_symtab. Change result to
"struct compunit_symtab *". All callers updated.
(recursively_compute_inclusions): Change type of immediate_parent
argument to "struct compunit_symtab *". All callers updated.
(compute_compunit_symtab_includes): Renamed from
compute_symtab_includes. All callers updated. Rewrite to compute
includes of compunit_symtabs and not symtabs.
(process_full_comp_unit): Update to work with struct compunit_symtab.
(process_full_type_unit): Ditto.
(dwarf_decode_lines_1): Delete argument comp_dir. All callers updated.
(dwarf_decode_lines): Remove special case handling of main subfile.
(macro_start_file): Delete argument comp_dir. All callers updated.
(dwarf_decode_macro_bytes): Ditto.
* guile/scm-block.c (bkscm_print_block_syms_progress_smob): Update to
use struct compunit_symtab.
* i386-tdep.c (i386_skip_prologue): Fetch producer from compunit.
* jit.c (finalize_symtab): Build compunit_symtab.
* jv-lang.c (get_java_class_symtab): Change result to
"struct compunit_symtab *". All callers updated.
* macroscope.c (sal_macro_scope): Fetch macro table from compunit.
* macrotab.c (struct macro_table) <compunit_symtab>: Renamed from
comp_dir. Change type to "struct compunit_symtab *".
All uses updated.
(new_macro_table): Change comp_dir argument to cust,
"struct compunit_symtab *". All callers updated.
* maint.c (struct cmd_stats) <nr_compunit_symtabs>: Renamed from
nr_primary_symtabs. All uses updated.
(count_symtabs_and_blocks): Update to handle compunits.
(report_command_stats): Update output, "primary symtabs" renamed to
"compunits".
* mdebugread.c (new_symtab): Change result to
"struct compunit_symtab *". All callers updated.
(parse_procedure): Change type of search_symtab argument to
"struct compunit_symtab *". All callers updated.
* objfiles.c (objfile_relocate1): Loop over blockvectors in a
separate loop.
* objfiles.h (struct objfile) <compunit_symtabs>: Renamed from
symtabs. Change type to "struct compunit_symtab *". All uses updated.
(ALL_OBJFILE_FILETABS): Renamed from ALL_OBJFILE_SYMTABS.
All uses updated.
(ALL_OBJFILE_COMPUNITS): Renamed from ALL_OBJFILE_PRIMARY_SYMTABS.
All uses updated.
(ALL_FILETABS): Renamed from ALL_SYMTABS. All uses updated.
(ALL_COMPUNITS): Renamed from ALL_PRIMARY_SYMTABS. All uses updated.
* psympriv.h (struct partial_symtab) <compunit_symtab>: Renamed from
symtab. Change type to "struct compunit_symtab *". All uses updated.
* psymtab.c (psymtab_to_symtab): Change result type to
"struct compunit_symtab *". All callers updated.
(find_pc_sect_compunit_symtab_from_partial): Renamed from
find_pc_sect_symtab_from_partial. Change result type to
"struct compunit_symtab *". All callers updated.
(lookup_symbol_aux_psymtabs): Change result type to
"struct compunit_symtab *". All callers updated.
(find_last_source_symtab_from_partial): Ditto.
* python/py-symtab.c (stpy_get_producer): Fetch producer from compunit.
* source.c (forget_cached_source_info_for_objfile): Fetch debugformat
and macro_table from compunit.
* symfile-debug.c (debug_qf_find_last_source_symtab): Change result
type to "struct compunit_symtab *". All callers updated.
(debug_qf_lookup_symbol): Ditto.
(debug_qf_find_pc_sect_compunit_symtab): Renamed from
debug_qf_find_pc_sect_symtab, change result type to
"struct compunit_symtab *". All callers updated.
* symfile.c (allocate_symtab): Delete objfile argument.
New argument cust.
(allocate_compunit_symtab): New function.
(add_compunit_symtab_to_objfile): New function.
* symfile.h (struct quick_symbol_functions) <lookup_symbol>:
Change result type to "struct compunit_symtab *". All uses updated.
<find_pc_sect_compunit_symtab>: Renamed from find_pc_sect_symtab.
Change result type to "struct compunit_symtab *". All uses updated.
* symmisc.c (print_objfile_statistics): Compute blockvector count in
separate loop.
(dump_symtab_1): Update test for primary source symtab.
(maintenance_info_symtabs): Update to handle compunit symtabs.
(maintenance_check_symtabs): Ditto.
* symtab.c (set_primary_symtab): Delete.
(compunit_primary_filetab): New function.
(compunit_language): New function.
(iterate_over_some_symtabs): Change type of arguments "first",
"after_last" to "struct compunit_symtab *". All callers updated.
Update to loop over symtabs in each compunit.
(error_in_psymtab_expansion): Rename symtab argument to cust,
and change type to "struct compunit_symtab *". All callers updated.
(find_pc_sect_compunit_symtab): Renamed from find_pc_sect_symtab.
Change result type to "struct compunit_symtab *". All callers updated.
(find_pc_compunit_symtab): Renamed from find_pc_symtab.
Change result type to "struct compunit_symtab *". All callers updated.
(find_pc_sect_line): Only loop over symtabs within selected compunit
instead of all symtabs in the objfile.
* symtab.h (struct symtab) <blockvector>: Moved to compunit_symtab.
<compunit_symtab> New member.
<block_line_section>: Moved to compunit_symtab.
<locations_valid>: Ditto.
<epilogue_unwind_valid>: Ditto.
<macro_table>: Ditto.
<dirname>: Ditto.
<debugformat>: Ditto.
<producer>: Ditto.
<objfile>: Ditto.
<call_site_htab>: Ditto.
<includes>: Ditto.
<user>: Ditto.
<primary>: Delete
(SYMTAB_COMPUNIT): New macro.
(SYMTAB_BLOCKVECTOR): Update definition.
(SYMTAB_OBJFILE): Update definition.
(SYMTAB_DIRNAME): Update definition.
(struct compunit_symtab): New type. Common members among all source
symtabs within a compilation unit moved here. All uses updated.
(COMPUNIT_OBJFILE): New macro.
(COMPUNIT_FILETABS): New macro.
(COMPUNIT_DEBUGFORMAT): New macro.
(COMPUNIT_PRODUCER): New macro.
(COMPUNIT_DIRNAME): New macro.
(COMPUNIT_BLOCKVECTOR): New macro.
(COMPUNIT_BLOCK_LINE_SECTION): New macro.
(COMPUNIT_LOCATIONS_VALID): New macro.
(COMPUNIT_EPILOGUE_UNWIND_VALID): New macro.
(COMPUNIT_CALL_SITE_HTAB): New macro.
(COMPUNIT_MACRO_TABLE): New macro.
(ALL_COMPUNIT_FILETABS): New macro.
(compunit_symtab_ptr): New typedef.
(DEF_VEC_P (compunit_symtab_ptr)): New vector type.
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp: Update expected output.
Jan noticed that gdb.ada/arrayidx.exp regressed after I applied
the following patch:
commit 8908fca577
Author: Joel Brobecker <brobecker@adacore.com>
Date: Sat Sep 27 09:09:34 2014 -0700
Subject: [Ada] Ignore __XA types when redundant.
What happens is that we're trying to print the value of
r_two_three, which is defined as follow:
type Index is (One, Two, Three);
type RTable is array (Index range Two .. Three) of Integer;
R_Two_Three : RTable := (2, 3);
The expected output is:
(gdb) p r_two_three
$1 = (two => 2, 3)
But after the patch above was applied, with the program program
compiled using gcc-gnat-4.9.2-1.fc21.x86_64 (x86_64-linux),
the output becomes:
(gdb) p r_two_three
$1 = (2, 3)
(the name of the first bound is missing). The problem comes from
the fact that the compiler described the array's index type as
a plain base type, instead of as a subrange of the enumerated type.
More particularly, this is what gcc-gnat-4.9.2-1.fc21.x86_64
generated:
<3><7ce>: Abbrev Number: 9 (DW_TAG_array_type)
<7cf> DW_AT_name : (indirect string, offset: 0xc13): p__rtable
[...]
<7d7> DW_AT_GNAT_descriptive_type: <0x98a>
[...]
<4><7df>: Abbrev Number: 8 (DW_TAG_subrange_type)
<7e0> DW_AT_type : <0xa79>
where DIE 0xa79 is:
<1><a79>: Abbrev Number: 2 (DW_TAG_base_type)
<a7a> DW_AT_byte_size : 8
<a7b> DW_AT_encoding : 7 (unsigned)
<a7c> DW_AT_name : (indirect string, offset: 0xfc): sizetype
The actual array subrange type can be found in the array's
parallel XA type (the DW_AT_GNAT_descriptive_type).
The recent commit correctly found that that bounds taken from
the descriptive type are the same as bounds of our array's index
type. But it failed to notice that ignoring this descriptive
type would make us lose the actual array index type, making us
think that we're printing an array indexed by integers.
I hadn't seen that problem, because the compiler I used produced
debugging info where the array's index type is correctly described:
<3><79f>: Abbrev Number: 10 (DW_TAG_array_type)
<7a0> DW_AT_name : (indirect string, offset: 0xb3d): p__rtable
[...]
<4><7b0>: Abbrev Number: 8 (DW_TAG_subrange_type)
<7b1> DW_AT_type : <0x9b2>
<7b5> DW_AT_upper_bound : 2
... where DIE 0x9b2 leads us to ...
<3><9b2>: Abbrev Number: 9 (DW_TAG_subrange_type)
[...]
<9b8> DW_AT_type : <0x962>
<2><962>: Abbrev Number: 22 (DW_TAG_enumeration_type)
<963> DW_AT_name : (indirect string, offset: 0xb34): p__index
[...]
This patch fixes the issue by also making sure that the subtype
of the original range type does match the subtype found in the
descriptive type.
gdb/ChangeLog:
* ada-lang.c (ada_is_redundant_range_encoding): Return 0
if the TYPE_CODE of range_type's base type does not match
the TYPE_CODE of encoding_type's base type.
Using the example in gdb.ada/complete.exp, the following command
on x86_64-windows returns one unwanted completion choice :
(gdb) complete p pck
p <pck_E>>
[all following completions entries snipped, all expected]
I tracked down this suprising entry to a minimal symbol whose name
is ".refptr.pck_E". The problem occurs while trying to see if
this symbol matches "pck" when doing wild-matching as we are doing
here:
/* Second: Try wild matching... */
if (!match && wild_match_p)
{
/* Since we are doing wild matching, this means that TEXT
may represent an unqualified symbol name. We therefore must
also compare TEXT against the unqualified name of the symbol. */
sym_name = ada_unqualified_name (ada_decode (sym_name));
if (strncmp (sym_name, text, text_len) == 0)
match = 1;
}
What happens is that ada_decode correctly identifies the fact that
SYM_NAME (".refptr.pck_E") is not following any GNAT encoding, and
therefore returns that same name, but bracketed: "<.refptr.pck_E>".
This is the convention we use for telling GDB that the decoded name
is not a real Ada name - and therefore should not be encoded for
operations such as name matching, symbol lookups, etc. So far, so good.
Next is the call to ada_unqualified_name, which unfortunately does
not notice that the decoded name it is being given isn't a natural
symbol, and just blindly strips everything up to the last do, returning
"pck_E>". And of course, "pck_E>" matches "pck" now, and so we end
up accepting this symbol as a match.
This patch fixes the problem by making ada_unqualified_name a little
smarter by making sure that the given decoded symbol name does not
start with '<'.
gdb/ChangeLog:
* ada-lang.c (ada_unqualified_name): Return DECODED_NAME if
it starts with '<'.
Tested on x86_64-windows using AdaCore's testsuite as well as
on x86_64-linux.
Consider the following code which declares a variable A2 which
is an array of arrays of integers.
type Array2_First is array (24 .. 26) of Integer;
type Array2_Second is array (1 .. 2) of Array2_First;
A1 : Array1_Second := ((10, 11, 12), (13, 14, 15));
Trying to print the type of that variable currently yields:
(gdb) ptype A2
type = array (1 .. 2, 24 .. 26) of integer
This is not correct, as this is the description of a two-dimension
array, which is different from an array of arrays. The expected
output is:
(gdb) ptype a2
type = array (1 .. 2) of foo_n926_029.array2_first
GDB's struct type currently handles multi-dimension arrays the same
way arrays of arrays, where each dimension is stored as a sub-array.
The ada-valprint module considers that consecutive array layers
are in fact multi-dimension arrays. For array of arrays, a typedef
layer is introduced between the two arrays, creating a break between
each array type.
In our situation, A2 is a described as a typedef of an array type...
.uleb128 0x8 # (DIE (0x125) DW_TAG_variable)
.ascii "a2\0" # DW_AT_name
.long 0xfc # DW_AT_type
.uleb128 0x4 # (DIE (0xfc) DW_TAG_typedef)
.long .LASF5 # DW_AT_name: "foo__array2_second"
.long 0x107 # DW_AT_type
.uleb128 0x5 # (DIE (0x107) DW_TAG_array_type)
.long .LASF5 # DW_AT_name: "foo__array2_second"
.long 0xb4 # DW_AT_type
.uleb128 0x6 # (DIE (0x114) DW_TAG_subrange_type)
.long 0x11b # DW_AT_type
.byte 0x2 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x107
... whose element type is, as expected, a typedef to the sub-array
type:
.uleb128 0x4 # (DIE (0xb4) DW_TAG_typedef)
.long .LASF4 # DW_AT_name: "foo__array2_first"
.long 0xbf # DW_AT_type
.uleb128 0x9 # (DIE (0xbf) DW_TAG_array_type)
.long .LASF4 # DW_AT_name: "foo__array2_first"
.long 0xd8 # DW_AT_GNAT_descriptive_type
.long 0x1c5 # DW_AT_type
.uleb128 0xa # (DIE (0xd0) DW_TAG_subrange_type)
.long 0xf0 # DW_AT_type
.byte 0x18 # DW_AT_lower_bound
.byte 0x1a # DW_AT_upper_bound
.byte 0 # end of children of DIE 0xbf
The reason why things fails is that, during expression evaluation,
GDB tries to "fix" A1's type. Because the sub-array has a parallel
(descriptive) type (DIE 0xd8), GDB thinks that our array's index
type must be dynamic and therefore needs to be fixed. This in turn
causes the sub-array to be "fixed", which itself results in the
typedef layer to be stripped.
However, looking closer at the parallel type, we see...
.uleb128 0xb # (DIE (0xd8) DW_TAG_structure_type)
.long .LASF8 # DW_AT_name: "foo__array2_first___XA"
[...]
.uleb128 0xc # (DIE (0xe4) DW_TAG_member)
.long .LASF10 # DW_AT_name: "foo__Tarray2_firstD1___XDLU_24__26"
... that all it tells us is that the array bounds are 24 and 26,
which is already correctly provided by the array's DW_TAG_subrange_type
bounds, meaning that this parallel type is just redundant.
Parallel types in general are slowly being removed in favor of
standard DWARF constructs. But in the meantime, this patch kills
two birds with one stone:
1. It recognizes this situation where the XA type is useless,
and saves an unnecessary range-type fixing;
2. It fixes the issue at hand because ignoring the XA type results
in no type fixing being required, which allows the typedef layer
to be preserved.
gdb/ChangeLog:
* ada-lang.c (ada_is_redundant_range_encoding): New function.
(ada_is_redundant_index_type_desc): New function.
(to_fixed_array_type): Ignore parallel XA type if redundant.
gdb/testsuite/ChangeLog:
* gdb.ada/arr_arr: New testcase.
Tested on x86_64-linux.
... when that packed array is part of a discriminated record and
one of the bounds is a discriminant.
Consider the following code:
type FUNNY_CHAR_T is (NUL, ' ', '"', '#', [etc]);
type FUNNY_STR_T is array (POSITIVE range <>) of FUNNY_CHAR_T;
pragma PACK (FUNNY_STR_T);
type FUNNY_STRING_T (SIZE : NATURAL := 1) is
record
STR : FUNNY_STR_T (1 .. SIZE) := (others => '0');
LENGTH : NATURAL := 4;
end record;
TEST: FUNNY_STRING_T(100);
GDB is able to print the value of variable "test" and "test.str".
But not "test.str(1)":
(gdb) p test
$1 = (size => 100, str => (33 'A', nul <repeats 99 times>), length => 1)
(gdb) p test.str
$2 = (33 'A', nul <repeats 99 times>)
(gdb) p test.str(1)
object size is larger than varsize-limit
The problem occurs during the phase where we are trying to resolve
the expression subscript operation. On the one hand of the subscript
operator, we have the result of the evaluation of "test.str", which
is our packed array. We have the following code to handle packed
arrays in particular:
if (ada_is_constrained_packed_array_type
(desc_base_type (value_type (argvec[0]))))
argvec[0] = ada_coerce_to_simple_array (argvec[0]);
This eventually leads to a call to constrained_packed_array_type
to return the "simple array". This function relies on a parallel
___XA type, when available, to determine the bounds. In our case,
we find type...
failure__funny_string_t__T4b___XA"
... which has one field describing the bounds of our array as:
failure__funny_string_t__T3b___XDLU_1__size
The part that interests us is after the ___XD suffix or,
in other words: "LU_1__size". What this means in GNAT encoding
parlance is that the lower bound is 1, and that the upper bound
is the value of "size". "size" is our discriminant in this case.
Normally, we would access the record's discriminant in order to
get the upper bound's value, but we do not have that information,
here. We are in a mode where we are just trying to "fix" the type
without an actual value. This is what the call to to_fixed_range_type
is doing, and because the fix'ing fails, it ends up returning
the ___XDLU type unmodified as our index type.
This shouldn't be a problem, except that the later part of
constrained_packed_array_type then uses that index_type to
determine the array size, via a call to get_discrete_bounds.
The problem is that the upper bound of the ___XDLU type is
dynamic (in the DWARF sense) while get_discrete_bounds implicitly
assumes that the bounds are static, and therefore accesses
them using macros that assume the bounds values are constants:
case TYPE_CODE_RANGE:
*lowp = TYPE_LOW_BOUND (type);
*highp = TYPE_HIGH_BOUND (type);
This therefore returns a bogus value for the upper bound,
leading to an unexpectedly large size for our array, which
later triggers the varsize-limit guard we've seen above.
This patch avoids the problem by adding special handling
of dynamic range types. It also extends the documentation
of the constrained_packed_array_type function to document
what happens in this situation.
gdb/ChangeLog:
* ada-lang.c (constrained_packed_array_type): Set the length
of the return array as if both bounds where zero if that
returned array's index type is dynamic.
gdb/testsuite/ChangeLog:
* gdb.ada/pkd_arr_elem: New Testcase.
Tested on x86_64-linux.
I cross-compile gdb for msdosdjgpp (both target and host is
i586-pc-msdosdjgpp), so the CC should be i586-pc-msdosdjgpp-gcc.
However, CC is set incorrectly to gcc after config/i386/go32.mh is inlined
into the Makefile.
This patch is to remove the CC setting in config/i386/go32.mh.
gdb:
2014-11-19 Yao Qi <yao@codesourcery.com>
* config/i386/go32.mh (CC): Remove.
This patch is conceptually quite simple.
If you look at end_symtab_from_static_block you'll see
that the static_block == NULL case is completely different
than the non-NULL case.
There's a lot of complexity to handle the NULL case but it seems
entirely unnecessary. For example, whether blockvector is NULL
is decided at the start, before this for loop:
for (subfile = subfiles; subfile; subfile = nextsub)
Secondly, after the for loop, we test symtab for non-NULL here:
/* Set this for the main source file. */
if (symtab)
but symtab will only ever be non-NULL if blockvector was non-NULL.
And if blockvector was non_NULL so will symtab.
The other case to consider is these lines of code executed before
the for loop:
/* Read the line table if it has to be read separately.
This is only used by xcoffread.c. */
if (objfile->sf->sym_read_linetable != NULL)
objfile->sf->sym_read_linetable (objfile);
/* Handle the case where the debug info specifies a different path
for the main source file. It can cause us to lose track of its
line number information. */
watch_main_source_file_lossage ();
From my reading of the code, neither of these is useful
in the static_block == NULL case.
Thus we can make the code more readable by splitting these two cases up,
which is what this patch does.
gdb/ChangeLog:
* buildsym.c (main_subfile): New static global.
(free_subfiles_list): New function.
(start_symtab): Set main_subfile.
(restart_symtab): Replace init of subfiles, current_subfile with
call to free_subfiles_list.
(watch_main_source_file_lossage): Use main_subfile.
(reset_symtab_globals): Replace init of current_subfile with call
to free_subfiles_list.
(end_symtab_without_blockvector, end_symtab_with_blockvector): New
functions, split out from ...
(end_symtab_from_static_block): ... here. Rewrite to call them.
gdb/ChangeLog:
* dwarf2read.c (dw2_instantiate_symtab): Add assert.
(dw2_lookup_symbol): Remove unnecessary test for primary symbol table.
* psymtab.c (lookup_symbol_aux_psymtabs): Ditto.
(psymtab_to_symtab): Add comment and assert.
(map_matching_symbols_psymtab): Remove unnecessary test for
non-primary symtab.
Basically the problem is that "symtab" is ambiguous.
Is it the primary symtab (where we canonically think of
blockvectors as being stored) or is it for a specific file
(where each file's line table is stored) ?
gdb_disassembly wants the symtab that contains the line table
but is instead getting the primary symtab.
gdb/ChangeLog:
PR symtab/17559
* symtab.c (find_pc_line_symtab): New function.
* symtab.h (find_pc_line_symtab): Declare.
* disasm.c (gdb_disassembly): Call find_pc_line_symtab instead of
find_pc_symtab.
* tui/tui-disasm.c (tui_set_disassem_content): Ditto.
* tui/tui-hooks.c (tui_selected_frame_level_changed_hook): Ditto.
* tui/tui-source.c (tui_vertical_source_scroll): Ditto.
* tui/tui-win.c (make_visible_with_new_height): Ditto.
* tui/tui-winsource.c (tui_horizontal_source_scroll): Ditto.
(tui_display_main): Call find_pc_line_symtab instead of find_pc_line.
gdb/testsuite/ChangeLog:
PR symtab/17559
* gdb.base/line-symtabs.exp: New file.
* gdb.base/line-symtabs.c: New file.
* gdb.base/line-symtabs.h: New file.
This patch just renames one function.
Its only caller is in stack.c where we're printing a backtrace
with non-zero info_verbose and we want to make sure all the needed
symtabs are expanded before printing the backtrace
so that debug symbol reading messages don't pollute the backtrace.
I think the new name of the function makes clearer to the reader
what is going on.
gdb/ChangeLog:
* symtab.c (expand_symtab_containing_pc): Renamed from
find_pc_sect_symtab_via_partial. All callers updated.
One parenthesis is missing, and it causes a compilation error. This
patch is to fix it.
gdb:
2014-11-15 Yao Qi <yao@codesourcery.com>
* go32-nat.c (go32_create_inferior): Add missing parenthesis.
When trying to build gdbserver on ppc-lynx178, the compiler reports
while trying to compile gdbserver/ax.c that vsprintf is not declared.
Looking at my C99 reference manual (a draft), I see the following
synopsis:
#include <stdarg.h>
#include <stdio.h>
int vsprintf(char * restrict s, [etc]);
Looking at stdio.h on LynxOS-178, if found where vsprintf gets
declared:
#if defined(__varargs_h) || defined(__stdarg_h) \
|| defined(_VARARGS_H) || defined(_STDARG_H)
extern int vsprintf _AP((char *, const char *, va_list));
#endif
Digging further, I noticed that common-defs.h, which is included
via server.h, includes stdarg.h after including stdio, explaining
why vsprintf does not get declared in this case.
This patch fixes the problem by including stdarg.h before stdio.h.
gdb/ChangeLog:
* common/common-defs.h: Move <stdarg.h> #include ahead of
<stdio.h> #include.
Tested on x86_64-linux.
We're currently pulling gnulib's errno module as a dependency of some
other module. That provides an errno.h that defines EILSEQ to a
distinct value if the system's errno.h doesn't define it already.
However, GNU iconv does this:
/* Get errno declaration and values. */
#include <errno.h>
/* Some systems, like SunOS 4, don't have EILSEQ. Some systems, like BSD/OS,
have EILSEQ in a different header. On these systems, define EILSEQ
ourselves. */
#ifndef EILSEQ
#define EILSEQ @EILSEQ@
#endif
That's in:
http://git.savannah.gnu.org/cgit/libiconv.git/tree/include/iconv.h.in
The "different header" mentioned is wchar.h. This is handled in:
http://git.savannah.gnu.org/cgit/libiconv.git/tree/m4/eilseq.m4
which defines @EILSEQ@ to ENOENT if EILSEQ isn't found in either
errno.h or wchar.h.
So if iconv sets errno to EILSEQ on such system's, it's really setting
it to ENOENT. And when we check for EILSEQ, we're checking for
gnulib's value. The result is we won't detect the error correctly.
As we dropped support for both SunOS 4 or old BSD/OS, maybe we don't
need to care about the wchar.h issue anymore. Still, AFAICS, gnulib's
m4/errno_h.m4 doesn't know that EILSEQ may be defined in wchar.h, and
so on such systems, ISTM gnulib ends up defining an incompatible
EILSEQ itself, but I think that should be fixed on the gnulib side, by
making it extract the EILSEQ value out of the system's wchar.h, like
GNU iconv does.
So that leaves handling the case of gnulib making up a EILSEQ value,
which we take as meaning the system really doesn't really define it,
which will be the same systems GNU iconv sets errno to ENOENT instead
of EILSEQ.
Looking at glibc's iconv it seems that ENOENT is never used there.
It seems it's safe to always treat ENOENT the same as EILSEQ.
The current EILSEQ definition under PHONY_ICONV is obviously stale as
gnulib garantees there's always a EILSEQ defined.
Tested on x86_64 Fedora 20.
gdb/
2014-11-14 Pedro Alves <palves@redhat.com>
* charset.c [PHONY_ICONV && !EILSEQ] (EILSEQ): Don't define.
[!PHONY_ICONV] (gdb_iconv): New function.
[!PHONY_ICONV] (iconv): Redefine to gdb_iconv.
No longer used since the non-continuable watchpoints handling rework.
gdb/
2014-11-12 Pedro Alves <palves@redhat.com>
* infrun.c (enum infwait_states, infwait_state): Delete.
The gdb.arch/i386-bp_permanent.exp test is currently failing an
assertion recently added:
(gdb) stepi
../../src/gdb/infrun.c:2237: internal-error: resume: Assertion `sig != GDB_SIGNAL_0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
FAIL: gdb.arch/i386-bp_permanent.exp: Single stepping past permanent breakpoint. (GDB internal error)
The assertion expects that the only reason we currently need to step a
breakpoint instruction is when we have a signal to deliver. But when
stepping a permanent breakpoint (with or without a signal) we also
reach this code.
The assertion is correct and the permanent breakpoints skipping code
is wrong.
Consider the case of the user doing "step/stepi" when stopped at a
permanent breakpoint. GDB's `resume' calls the
gdbarch_skip_permanent_breakpoint hook and then happily continues
stepping:
/* Normally, by the time we reach `resume', the breakpoints are either
removed or inserted, as appropriate. The exception is if we're sitting
at a permanent breakpoint; we need to step over it, but permanent
breakpoints can't be removed. So we have to test for it here. */
if (breakpoint_here_p (aspace, pc) == permanent_breakpoint_here)
{
gdbarch_skip_permanent_breakpoint (gdbarch, regcache);
}
But since gdbarch_skip_permanent_breakpoint already advanced the PC
manually, this ends up executing the instruction that is _after_ the
breakpoint instruction. The user-visible result is that a single-step
steps two instructions.
The gdb.arch/i386-bp_permanent.exp test is actually ensuring that
that's indeed how things work. It runs to an int3 instruction, does
"stepi", and checks that "leave" was executed with that "stepi". Like
this:
(gdb) b *0x0804848c
Breakpoint 2 at 0x804848c
(gdb) c
Continuing.
Breakpoint 2, 0x0804848c in standard ()
(gdb) disassemble
Dump of assembler code for function standard:
0x08048488 <+0>: push %ebp
0x08048489 <+1>: mov %esp,%ebp
0x0804848b <+3>: push %edi
=> 0x0804848c <+4>: int3
0x0804848d <+5>: leave
0x0804848e <+6>: ret
0x0804848f <+7>: nop
(gdb) si
0x0804848e in standard ()
(gdb) disassemble
Dump of assembler code for function standard:
0x08048488 <+0>: push %ebp
0x08048489 <+1>: mov %esp,%ebp
0x0804848b <+3>: push %edi
0x0804848c <+4>: int3
0x0804848d <+5>: leave
=> 0x0804848e <+6>: ret
0x0804848f <+7>: nop
End of assembler dump.
(gdb)
One would instead expect that a stepi at 0x0804848c stops at
0x0804848d, _before_ the "leave" is executed. This commit changes GDB
this way. Care is taken to make stepping into a signal handler when
the step starts at a permanent breakpoint instruction work correctly.
The patch adjusts gdb.arch/i386-bp_permanent.exp in this direction,
and also makes it work on x86_64 (currently it only works on i*86).
The patch also adds a new gdb.base/bp-permanent.exp test that
exercises many different code paths related to stepping permanent
breakpoints, including the stepping with signals cases. The test uses
"hack/trick" to make it work on all (or most) platforms -- it doesn't
really hard code a breakpoint instruction.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-11-12 Pedro Alves <palves@redhat.com>
* infrun.c (resume): Clear the thread's 'stepped_breakpoint' flag.
Rewrite stepping over a permanent breakpoint.
(thread_still_needs_step_over, proceed): Don't set
stepping_over_breakpoint for permanent breakpoints.
(handle_signal_stop): Don't clear stepped_breakpoint. Also pull
single-step breakpoints out of the target on hardware step
targets.
(process_event_stop_test): If stepping a permanent breakpoint
doesn't hit the step-resume breakpoint, delete the step-resume
breakpoint.
(switch_back_to_stepped_thread): Also check if the stepped thread
has advanced already on hardware step targets.
(currently_stepping): Return true if the thread stepped a
breakpoint.
gdb/testsuite/
2014-11-12 Pedro Alves <palves@redhat.com>
* gdb.arch/i386-bp_permanent.c: New file.
* gdb.arch/i386-bp_permanent.exp: Don't skip on x86_64.
(srcfile): Set to i386-bp_permanent.c.
(top level): Adjust to work in both 32-bit and 64-bit modes. Test
that stepi does not execute the 'leave' instruction, instead of
testing it does execute.
* gdb.base/bp-permanent.c: New file.
* gdb.base/bp-permanent.exp: New file.
"permanent"-ness is currently a property of the breakpoint. But, it
should actually be an implementation detail of a _location_. Consider
this bit in infrun.c:
/* Normally, by the time we reach `resume', the breakpoints are either
removed or inserted, as appropriate. The exception is if we're sitting
at a permanent breakpoint; we need to step over it, but permanent
breakpoints can't be removed. So we have to test for it here. */
if (breakpoint_here_p (aspace, pc) == permanent_breakpoint_here)
{
if (gdbarch_skip_permanent_breakpoint_p (gdbarch))
gdbarch_skip_permanent_breakpoint (gdbarch, regcache);
else
error (_("\
The program is stopped at a permanent breakpoint, but GDB does not know\n\
how to step past a permanent breakpoint on this architecture. Try using\n\
a command like `return' or `jump' to continue execution."));
}
This will wrongly skip a non-breakpoint instruction if we have a
multiple location breakpoint where the whole breakpoint was set to
"permanent" because one of the locations happened to be permanent,
even if the one GDB is resuming from is not.
Related, because the permanent breakpoints are only marked as such in
init_breakpoint_sal, we currently miss marking momentary breakpoints
as permanent. A test added by a following patch trips on that.
Making permanent-ness be per-location, and marking locations as such
in add_location_to_breakpoint, the natural place to do this, fixes
this issue...
... and then exposes a latent issue with mark_breakpoints_out. It's
clearing the inserted flag of permanent breakpoints. This results in
assertions failing like this:
Breakpoint 1, main () at testsuite/gdb.base/callexit.c:32
32 return 0;
(gdb) call callexit()
[Inferior 1 (process 15849) exited normally]
gdb/breakpoint.c:12854: internal-error: allegedly permanent breakpoint is not actually inserted
A problem internal to GDB has been detected,
further debugging may prove unreliable.
The call dummy breakpoint, which is a momentary breakpoint, is set on
top of a manually inserted breakpoint instruction, and so is now
rightfully marked as a permanent breakpoint. See "Write a legitimate
instruction at the point where the infcall breakpoint is going to be
inserted." comment in infcall.c.
Re. make_breakpoint_permanent. That's only called by solib-pa64.c.
Permanent breakpoints were actually originally invented for HP-UX [1].
I believe that that call (the only one in the tree) is unnecessary
nowadays, given that nowadays the core breakpoints code analyzes the
instruction under the breakpoint to automatically detect whether it's
setting a breakpoint on top of a breakpoint instruction in the
program. I know close to nothing about HP-PA/HP-UX, though.
[1] https://sourceware.org/ml/gdb-patches/1999-q3/msg00245.html, and
https://sourceware.org/ml/gdb-patches/1999-q3/msg00242.html
In addition to the per-location issue, "permanent breakpoints" are
currently always displayed as enabled=='n':
(gdb) b main
Breakpoint 3 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29.
(gdb) info breakpoints
Num Type Disp Enb Address What
3 breakpoint keep n 0x000000000040053c ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29
But OTOH they're always enabled; there's no way to disable them...
In turn, this means that if one adds commands to such a breakpoint,
they're _always_ run:
(gdb) start
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.arch/i386-permbkpt
...
Temporary breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29
29 int3
(gdb) b main
Breakpoint 2 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29.
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep n 0x000000000040053c ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29
(gdb) commands
Type commands for breakpoint(s) 2, one per line.
End with a line saying just "end".
>echo "hello!"
>end
(gdb) disable 2
(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Temporary breakpoint 3 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29.
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.arch/i386-permbkpt
Breakpoint 2, main () at ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29
29 int3
"hello!"(gdb)
IMO, one should be able to disable such a breakpoint, and GDB should
then behave just like if the user hadn't created the breakpoint in the
first place (that is, report a SIGTRAP).
By making permanent-ness a property of the location, and eliminating
the bp_permanent enum enable_state state ends up fixing that as well.
No tests are added for these changes yet; they'll be added in a follow
up patch, as skipping permanent breakpoints is currently broken and
trips on an assertion in infrun.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/ChangeLog:
2014-11-12 Pedro Alves <palves@redhat.com>
Mark locations as permanent, not the whole breakpoint.
* breakpoint.c (remove_breakpoint_1, remove_breakpoint): Adjust.
(mark_breakpoints_out): Don't mark permanent breakpoints as
uninserted.
(breakpoint_init_inferior): Use mark_breakpoints_out.
(breakpoint_here_p): Adjust.
(bpstat_stop_status, describe_other_breakpoints): Remove handling
of permanent breakpoints.
(make_breakpoint_permanent): Mark each location as permanent,
instead of marking the breakpoint.
(add_location_to_breakpoint): If the location is permanent, mark
it as such, and as inserted.
(init_breakpoint_sal): Don't make the breakpoint permanent here.
(bp_location_compare, update_global_location_list): Adjust.
(update_breakpoint_locations): Don't make the breakpoint permanent
here.
(disable_breakpoint, enable_breakpoint_disp): Don't skip permanent
breakpoints.
* breakpoint.h (enum enable_state) <bp_permanent>: Delete field.
(struct bp_location) <permanent>: New field.
* guile/scm-breakpoint.c (bpscm_enable_state_to_string): Remove
reference to bp_permanent.
breakpoint.c uses gdbarch_breakpoint_from_pc to determine whether a
breakpoint location points at a permanent breakpoint:
static int
bp_loc_is_permanent (struct bp_location *loc)
{
...
addr = loc->address;
bpoint = gdbarch_breakpoint_from_pc (loc->gdbarch, &addr, &len);
...
if (target_read_memory (loc->address, target_mem, len) == 0
&& memcmp (target_mem, bpoint, len) == 0)
retval = 1;
...
So I think we should default the gdbarch_skip_permanent_breakpoint
hook to advancing the PC by the length of the breakpoint instruction,
as determined by gdbarch_breakpoint_from_pc. I believe that simple
implementation does the right thing for most architectures. If
there's an oddball architecture where that doesn't work, then it
should override the hook, just like it should be overriding the hook
if there was no default anyway.
The only two implementation of skip_permanent_breakpoint are
i386_skip_permanent_breakpoint, for x86, and
hppa_skip_permanent_breakpoint, for PA-RISC/HP-UX
The x86 implementation is trivial, and can clearly be replaced by the
new default.
I don't know about the HP-UX one though, I know almost nothing about
PA. It may well be advancing the PC ends up being equivalent.
Otherwise, it must be that "jump $pc_after_bp" doesn't work either...
Tested on x86_64 Fedora 20 native and gdbserver.
gdb/
2014-11-12 Pedro Alves <palves@redhat.com>
* arch-utils.c (default_skip_permanent_breakpoint): New function.
* arch-utils.h (default_skip_permanent_breakpoint): New
declaration.
* gdbarch.sh (skip_permanent_breakpoint): Now an 'f' function.
Install default_skip_permanent_breakpoint as default method.
* i386-tdep.c (i386_skip_permanent_breakpoint): Delete function.
(i386_gdbarch_init): Don't install it.
* infrun.c (resume): Assume there's always a
gdbarch_skip_permanent_breakpoint implementation.
* gdbarch.h, gdbarch.c: Regenerate.
Linux supports multiple "PID namespaces". Processes in different PID
namespaces have different views of the system process list. Sometimes,
a single process can appear in more than one PID namespace, but with a
different PID in each. When GDB and its target are in different PID
namespaces, various features can break due to the mismatch between
what the target believes its PID to be and what GDB believes its PID
to be. The most visible broken functionality is thread enumeration
silently failing.
This patch explicitly warns users against trying to debug across PID
namespaces.
The patch introduced no new failures in my test suite run on an x86_64
installation of Ubuntu 14.10. It doesn't include a test: writing an
automated test that exercises this code would be very involved because
CLONE_NEWNS requires CAP_SYS_ADMIN; the easier way to reproduce the
problem is to start a new lxc container.
gdb/
2014-11-11 Daniel Colascione <dancol@dancol.org>
Warn about cross-PID-namespace debugging.
* nat/linux-procfs.h (linux_proc_pid_get_ns): New prototype.
* nat/linux-procfs.c (linux_proc_pid_get_ns): New function.
* linux-thread-db.c (check_pid_namespace_match): New function.
(thread_db_inferior_created): Call it.
When searching static symbols, gdb would search over all
expanded symtabs of all objfiles, and if that fails only then
would it search all partial/gdb_index tables of all objfiles.
This means that the user could get a random instance of the
symbol depending on what symtabs have been previously expanded.
Now the search is consistent, searching each objfile completely
before proceeding to the next one.
gdb/ChangeLog:
PR symtab/17564
* symtab.c (lookup_symbol_in_all_objfiles): Delete.
(lookup_static_symbol): Move definition to new location and rewrite.
(lookup_symbol_in_objfile): New function.
(lookup_symbol_global_iterator_cb): Call it.
gdb/testsuite/ChangeLog:
PR symtab/17564
* gdb.base/symtab-search-order.exp: New file.
* gdb.base/symtab-search-order.c: New file.
* gdb.base/symtab-search-order-1.c: New file.
* gdb.base/symtab-search-order-shlib-1.c: New file.
A recent change to eval.c triggered a GCC bug that causes a false positive
"may be used uninitialized" warning in evaluate_subexp_standard. This seems
to be triggered by a specific CFG constructed via setjmp and gotos.
While the GCC bug is in the process of being fixed, there are released
compiler versions (in particular GCC 4.9) in the field that show this
problem. In order to allow compiling GDB with one of those compilers,
this commit slightly reworks the CFG (in an equivalent way) of the
affected function, so that the GCC bug is no longer triggered.
gdb/ChangeLog:
* eval.c (evaluate_subexp_standard): Work around GCC bug 63748.
The in_prologue check in the nexti code is obsolete; this commit
removes that, and then removes the in_prologue function as nothing
else uses it.
Looking at the code in GDB that makes use in_prologue, all we find is
this one caller:
if ((ecs->event_thread->control.step_over_calls == STEP_OVER_NONE)
|| ((ecs->event_thread->control.step_range_end == 1)
&& in_prologue (gdbarch, ecs->event_thread->prev_pc,
ecs->stop_func_start)))
{
/* I presume that step_over_calls is only 0 when we're
supposed to be stepping at the assembly language level
("stepi"). Just stop. */
/* Also, maybe we just did a "nexti" inside a prolog, so we
thought it was a subroutine call but it was not. Stop as
well. FENN */
/* And this works the same backward as frontward. MVS */
end_stepping_range (ecs);
return;
}
This was added by:
commit 100a02e1de
...
From Fernando Nasser:
* infrun.c (handle_inferior_event): Handle "nexti" inside function
prologues.
The mailing list thread is here:
https://sourceware.org/ml/gdb-patches/2001-01/msg00047.html
Not much discussion there, and no test, but looking at the code around
what was patched in that revision, we see that the checks that detect
whether the program has just stepped into a subroutine didn't rely on
the unwinders at all back then.
From 'git show 100a02e1:gdb/infrun.c':
if (stop_pc == ecs->stop_func_start /* Quick test */
|| (in_prologue (stop_pc, ecs->stop_func_start) &&
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!IN_SOLIB_RETURN_TRAMPOLINE (stop_pc, ecs->stop_func_name))
|| IN_SOLIB_CALL_TRAMPOLINE (stop_pc, ecs->stop_func_name)
|| ecs->stop_func_name == 0)
{
/* It's a subroutine call. */
if ((step_over_calls == STEP_OVER_NONE)
|| ((step_range_end == 1)
&& in_prologue (prev_pc, ecs->stop_func_start)))
{
/* I presume that step_over_calls is only 0 when we're
supposed to be stepping at the assembly language level
("stepi"). Just stop. */
/* Also, maybe we just did a "nexti" inside a prolog,
so we thought it was a subroutine call but it was not.
Stop as well. FENN */
stop_step = 1;
print_stop_reason (END_STEPPING_RANGE, 0);
stop_stepping (ecs);
return;
}
Stripping the IN_SOLIB_RETURN_TRAMPOLINE checks for simplicity, we had:
if (stop_pc == ecs->stop_func_start /* Quick test */
|| in_prologue (stop_pc, ecs->stop_func_start)
|| ecs->stop_func_name == 0)
{
/* It's a subroutine call. */
That is, detecting a subroutine call was based on prologue detection
back then. So the in_prologue check in the current tree only made
sense back then as it was undoing a bad decision the in_prologue check
that used to exist above did.
Today, the check for a subroutine call relies on frame ids instead,
which are stable throughout the function. So we can just remove the
in_prologue check for nexti, and the whole in_prologue function along
with it.
Tested on x86_64 Fedora 20, and also by nexti-ing manually a prologue.
gdb/
2014-11-07 Pedro Alves <palves@redhat.com>
* infrun.c (process_event_stop_test) <subroutine check>: Don't
check if we did a "nexti" inside a prologue.
* symtab.c (in_prologue): Delete function.
* symtab.h (in_prologue): Delete declaration.
"aux" doesn't contribute anything to the name, and it makes the
reader wonder what it's supposed to mean.
gdb/ChangeLog:
* symtab.c (lookup_local_symbol): Renamed from lookup_symbol_aux_local.
All callers updated.
(lookup_symbol_in_all_objfiles): Renamed from
lookup_symbol_aux_symtabs. All callers updated.
(lookup_symbol_via_quick_fns): Renamed from lookup_symbol_aux_quick.
All callers updated.
(lookup_symbol_in_objfile_symtabs): Renamed from
lookup_symbol_aux_objfile. All callers updated.
and lookup_static_symbol_aux to lookup_static_symbol.
gdb/ChangeLog:
* symtab.c (lookup_static_symbol): Renamed from
lookup_static_symbol_aux. All callers updated.
(lookup_symbol_in_static_block): Renamed from lookup_symbol_static.
All callers updated.
gdb/ChangeLog:
* block.h (ALL_BLOCK_SYMBOLS_WITH_NAME): New macro.
* block.c (block_lookup_symbol): Use it.
* cp-support.c (make_symbol_overload_list_block): Use it.
* symtab.c (iterate_over_symbols): Use it.
There is another function, lookup_symbol_aux_block, and
the names lookup_block_symbol and lookup_symbol_aux_block don't
convey any real difference between them.
The difference is that lookup_block_symbol lives in the lower level
block API, and lookup_symbol_aux_block lives in the higher level symtab API.
This patch makes this distinction clear.
gdb/ChangeLog:
* symtab.c (lookup_block_symbol): Moved to ...
* block.c (block_lookup_symbol): ... here and renamed.
All callers updated.
* block.h (block_lookup_symbol): Declare.
* symtab.h (lookup_block_symbol): Delete.
Non-primary symtabs share the block vector with their primary symtabs.
In these cases there's no need to use ALL_SYMTABS.
gdb/ChangeLog:
* ada-lang.c (ada_make_symbol_completion_list): Use
ALL_PRIMARY_SYMTABS instead of ALL_SYMTABS.
* symtab.c (lookup_objfile_from_block): Ditto.
obstack_next_free is supposed to return a void*, rather than a char*
as it does currently. Avoid warning on void* arithmetic when
obstack_next_free gets it proper return type.
* cp-valprint.c (cp_print_value_fields): Cast obstack_next_free
to char* before doing pointer arithmetic.
obstack_blank isn't the correct macro to call for shrinking obstacks
since it does size checking.
* charset.c (convert_between_encodings): Shrink obstack using
obstack_blank_fast.
* minsyms.c (install_minimal_symbols): Likewise.
Older versions of ncurses' newterm can't take NULL for their ofp and ifp
parameters. Newer versions can, and they fall back on stdout/stdin if
that is the case.
This patch explicitly passes stdout/stdin to the call to newterm to
avoid segfaulting with older ncurses.
gdb/Changelog:
2014-11-04 Simon Marchi <simon.marchi@ericsson.com>
* tui/tui.c (tui_enable): Pass stdout and stdin to newterm.
Used to be necessary for the thread-hop code, but that's gone now.
Nothing uses this anymore.
gdb/
2014-11-04 Pedro Alves <palves@redhat.com>
* breakpoint.c (breakpoint_thread_match): Delete function.
* breakpoint.h (breakpoint_thread_match): Delete declaration.
When evaluating method calls under EVAL_SKIP, the "object" and the
arguments to the method should also be evaluated under EVAL_SKIP,
instead of skipping to evaluate them as was being done previously.
gdb/ChangeLog:
PR c++/17494
* eval.c (evaluate_subexp_standard): Evaluate the "object" and
the method args also under EVAL_SKIP when evaluating method
calls under EVAL_SKIP.
gdb/testsuite/ChangeLog:
PR c++/17494
* gdb.cp/pr17494.cc: New file.
* gdb.cp/pr17494.exp: New file.
gdb/ChangeLog:
* NEWS: Mention ability add attributes to gdb.Objfile and
gdb.Progspace objects.
* python/py-objfile.c (objfile_object): New member dict.
(objfpy_dealloc): Py_XDECREF dict.
(objfpy_initialize): Initialize dict.
(objfile_getset): Add __dict__.
(objfile_object_type): Set tp_dictoffset member.
* python/py-progspace.c (progspace_object): New member dict.
(pspy_dealloc): Py_XDECREF dict.
(pspy_initialize): Initialize dict.
(pspace_getset): Add __dict__.
(pspace_object_type): Set tp_dictoffset member.
gdb/doc/ChangeLog:
* python.texi (Progspaces In Python): Document ability to add
random attributes to gdb.Progspace objects.
(Objfiles In Python): Document ability to add random attributes to
gdb.objfile objects.
gdb/testsuite/ChangeLog:
* gdb.python/py-objfile.exp: Add tests for setting random attributes
in objfiles.
* gdb.python/py-progspace.exp: Add tests for setting random attributes
in progspaces.
In gdb/command/prompt.py:before_prompt_hook, the '\' in the new prompt
is replaced with '\\', shown as below,
> def before_prompt_hook(self, current):
> if self.value is not '':
> newprompt = gdb.prompt.substitute_prompt(self.value)
> return newprompt.replace('\\', '\\\\')
> else:
> return None
I don't see any explanations on this in comments nor email. As doc
said, "set extended-prompt \w" substitute the current working
directory, but it prints something different from what pwd or
os.getcwdu() prints on mingw32 host.
(gdb) python print os.getcwdu()^M
\\build2-lucid-cs\yqi\yqi\arm-none-eabi
(gdb) pwd^M
Working directory \\build2-lucid-cs\yqi\yqi\arm-none-eabi
(gdb) set extended-prompt \w
\\\\build2-lucid-cs\\yqi\\yqi\\arm-none-eabi
This makes me think whether the substitution in before_prompt_hook is
necessary or not. This patch is to remove this substitution.
Run gdb.python on x86_64-linux and arm-none-eabi on mingw32 host. No
regressions.
gdb:
2014-10-30 Yao Qi <yao@codesourcery.com>
* python/lib/gdb/command/prompt.py (before_prompt_hook): Don't
replace '\\' with '\\\\'.
infrun.c:
5392 /* Did we find the stepping thread? */
5393 if (tp->control.step_range_end)
5394 {
5395 /* Yep. There should only one though. */
5396 gdb_assert (stepping_thread == NULL);
5397
5398 /* The event thread is handled at the top, before we
5399 enter this loop. */
5400 gdb_assert (tp != ecs->event_thread);
5401
5402 /* If some thread other than the event thread is
5403 stepping, then scheduler locking can't be in effect,
5404 otherwise we wouldn't have resumed the current event
5405 thread in the first place. */
5406 gdb_assert (!schedlock_applies (currently_stepping (tp)));
5407
5408 stepping_thread = tp;
5409 }
Like:
gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed.
The way the assertion is written is assuming that with schedlock=step
we'll always leave threads other than the one with the stepping range
locked, while that's not true with the "next" command. With schedlock
"step", other threads still run unlocked when "next" detects a
function call and steps over it. Whether that makes sense or not,
still, it's documented that way in the manual. If another thread hits
an event that doesn't cause a stop while the nexting thread steps over
a function call, we'll get here and fail the assertion.
The fix is just to adjust the assertion. Even though we found the
stepping thread, we'll still step-over the breakpoint that just
triggered correctly.
Surprisingly, gdb.threads/schedlock.exp doesn't have any test that
steps over a function call. This commits fixes that. This ensures
that "next" doesn't switch focus to another thread, and checks whether
other threads run locked or not, depending on scheduler locking mode
and command. There's a lot of duplication in that file that this ends
cleaning up. There's more that could be cleaned up, but that would
end up an unrelated change, best done separately.
This new coverage in schedlock.exp happens to trigger the internal
error in question, like so:
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount)
That's because we have more than one thread running the same loop, and
while one thread is stepping over a function call, the other thread
hits the step-resume breakpoint of the first, which needs to be
stepped over, and we end up in switch_back_to_stepped_thread exactly
in the problem case.
I think a simpler and more directed test is also useful, to not rely
on internal breakpoint magics. So this commit also adds a test that
has a thread trip on a conditional breakpoint that doesn't cause a
user-visible stop while another thread is stepping over a call. That
currently fails like this:
FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error)
Tested on x86_64 Fedora 20.
gdb/
2014-10-29 Pedro Alves <palves@redhat.com>
PR gdb/17408
* infrun.c (switch_back_to_stepped_thread): Use currently_stepping
instead of assuming a thread with a stepping range is always
stepping.
gdb/testsuite/
2014-10-29 Pedro Alves <palves@redhat.com>
PR gdb/17408
* gdb.threads/schedlock.c (some_function): New function.
(call_function): New global.
(MAYBE_CALL_SOME_FUNCTION): New macro.
(thread_function): Call it.
* gdb.threads/schedlock.exp (get_args): Add description parameter,
and use it instead of a global counter. Adjust all callers.
(get_current_thread): Use "find current thread" for test message
here rather than having all callers pass down the same string.
(goto_loop): New procedure, factored out from ...
(my_continue): ... this.
(step_ten_loops): Change parameter from test message to command to
use. Adjust.
(list_count): Delete global.
(check_result): New procedure, factored out from duplicate top
level code.
(continue tests): Wrap in with_test_prefix.
(test_step): New procedure, factored out from duplicate top level
code.
(top level): Test "step" in combination with all scheduler-locking
modes. Test "next" in combination with all scheduler-locking
modes, and in combination with stepping over a function call or
not.
* gdb.threads/next-bp-other-thread.c: New file.
* gdb.threads/next-bp-other-thread.exp: New file.
This is more of a readline/terminal issue than a Python one.
PR17372 is a regression in 7.8 caused by the fix for PR17072:
commit 0017922d02
Author: Pedro Alves <palves@redhat.com>
Date: Mon Jul 14 19:55:32 2014 +0100
Background execution + pagination aborts readline/gdb
gdb_readline_wrapper_line removes the handler after a line is
processed. Usually, we'll end up re-displaying the prompt, and that
reinstalls the handler. But if the output is coming out of handling
a stop event, we don't re-display the prompt, and nothing restores the
handler. So the next input wakes up the event loop and calls into
readline, which aborts.
...
gdb/
2014-07-14 Pedro Alves <palves@redhat.com>
PR gdb/17072
* top.c (gdb_readline_wrapper_line): Tweak comment.
(gdb_readline_wrapper_cleanup): If readline is enabled, reinstall
the input handler callback.
The problem is that installing the input handler callback also preps
the terminal, putting it in raw mode and with echo disabled, which is
bad if we're going to call a command that assumes cooked/canonical
mode, and echo enabled, like in the case of the PR, Python's
interactive shell. Another example I came up with that doesn't depend
on Python is starting a subshell with "(gdb) shell /bin/sh" from a
multi-line command. Tests covering both these examples are added.
The fix is to revert the original fix for PR gdb/17072, and instead
restore the callback handler after processing an asynchronous target
event.
Furthermore, calling rl_callback_handler_install when we already have
some input in readline's line buffer discards that input, which is
obviously a bad thing to do while the user is typing. No specific
test is added for that, because I first tried calling it even if the
callback handler was still installed and that resulted in hundreds of
failures in the testsuite.
gdb/
2014-10-29 Pedro Alves <palves@redhat.com>
PR python/17372
* event-top.c (change_line_handler): Call
gdb_rl_callback_handler_remove instead of
rl_callback_handler_remove.
(callback_handler_installed): New global.
(gdb_rl_callback_handler_remove, gdb_rl_callback_handler_install)
(gdb_rl_callback_handler_reinstall): New functions.
(display_gdb_prompt): Call gdb_rl_callback_handler_remove and
gdb_rl_callback_handler_install instead of
rl_callback_handler_remove and rl_callback_handler_install.
(gdb_disable_readline): Call gdb_rl_callback_handler_remove
instead of rl_callback_handler_remove.
* event-top.h (gdb_rl_callback_handler_remove)
(gdb_rl_callback_handler_install)
(gdb_rl_callback_handler_reinstall): New declarations.
* infrun.c (reinstall_readline_callback_handler_cleanup): New
cleanup function.
(fetch_inferior_event): Install it.
* top.c (gdb_readline_wrapper_line) Call
gdb_rl_callback_handler_remove instead of
rl_callback_handler_remove.
(gdb_readline_wrapper_cleanup): Don't call
rl_callback_handler_install.
gdb/testsuite/
2014-10-29 Pedro Alves <palves@redhat.com>
PR python/17372
* gdb.python/python.exp: Test a multi-line command that spawns
interactive Python.
* gdb.base/multi-line-starts-subshell.exp: New file.
While running GDB under Valgrind, I noticed that if the very first
command entered is just <RET>, GDB accesses an uninitialized value:
$ valgrind ./gdb -q -nx
==26790== Memcheck, a memory error detector
==26790== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==26790== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==26790== Command: ./gdb -q -nx
==26790==
(gdb)
==26790== Conditional jump or move depends on uninitialised value(s)
==26790== at 0x619DFC: command_line_handler (event-top.c:588)
==26790== by 0x7813D5: rl_callback_read_char (callback.c:220)
==26790== by 0x6194B4: rl_callback_read_char_wrapper (event-top.c:166)
==26790== by 0x61988A: stdin_event_handler (event-top.c:372)
==26790== by 0x61847D: handle_file_event (event-loop.c:762)
==26790== by 0x617964: process_event (event-loop.c:339)
==26790== by 0x617A2B: gdb_do_one_event (event-loop.c:403)
==26790== by 0x617A7B: start_event_loop (event-loop.c:428)
==26790== by 0x6194E6: cli_command_loop (event-top.c:181)
==26790== by 0x60F86B: current_interp_command_loop (interps.c:317)
==26790== by 0x610A34: captured_command_loop (main.c:321)
==26790== by 0x60C728: catch_errors (exceptions.c:237)
==26790==
(gdb)
It's this check here:
/* If we just got an empty line, and that is supposed to repeat the
previous command, return the value in the global buffer. */
if (repeat && p == linebuffer && *p != '\\')
{
The problem is that linebuffer's contents were never initialized at
this point.
gdb/
2014-10-29 Pedro Alves <palves@redhat.com>
* event-top.c (command_line_handler): Clear the first byte of
linebuffer, when it is first allocated.
exiting instead of throwing an error. E.g.:
$ TERM=foo gdb
(gdb) layout asm
Error opening terminal: foo.
$
The problem is that we're calling initscr to initialize the screen.
As mentioned in
http://pubs.opengroup.org/onlinepubs/7908799/xcurses/initscr.html:
If errors occur, initscr() writes an appropriate error message to
standard error and exits.
^^^^^
Instead, we should use newterm:
"A program that needs an indication of error conditions, so it can
continue to run in a line-oriented mode if the terminal cannot support
a screen-oriented program, would also use this function."
After the patch:
$ TERM=foo gdb -q -nx
(gdb) layout asm
Cannot enable the TUI: error opening terminal [TERM=foo]
(gdb)
And then PR tui/17519 is about GDB not validating whether the terminal
has the necessary capabilities when enabling the TUI. If one tries to
enable the TUI with TERM=dumb (and e.g., from a shell within emacs),
GDB ends up with a clear screen, the cursor is placed at the
bottom/right corner of the screen, there's no prompt, typing shows no
echo, and there's no indication of what's going on. c-x,a gets you
out of the TUI, but it's completely non-obvious.
After the patch, we get:
$ TERM=dumb gdb -q -nx
(gdb) layout asm
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
(gdb)
While at it, I've moved all the tui_allowed_p validation to
tui_enable, and expanded the error messages. Previously we'd get:
$ gdb -q -nx -i=mi
(gdb)
layout asm
&"layout asm\n"
&"TUI mode not allowed\n"
^error,msg="TUI mode not allowed"
and:
$ gdb -q -nx -ex "layout asm" > foo
TUI mode not allowed
While now we get:
$ gdb -q -nx -i=mi
(gdb)
layout asm
&"layout asm\n"
&"Cannot enable the TUI when the interpreter is 'mi'\n"
^error,msg="Cannot enable the TUI when the interpreter is 'mi'"
(gdb)
and:
$ gdb -q -nx -ex "layout asm" > foo
Cannot enable the TUI when output is not a terminal
Tested on x86_64 Fedora 20.
gdb/
2014-10-29 Pedro Alves <palves@redhat.com>
PR tui/16138
PR tui/17519
* tui/tui-interp.c (tui_is_toplevel): Delete global.
(tui_allowed_p): Delete function.
* tui/tui.c: Include "interps.h".
(tui_enable): Don't use tui_allowed_p. Error out here with
detailed error messages if the TUI is the top level interpreter,
or if output is not a terminal. Use newterm instead of initscr,
and error out if initializing the terminal fails. Also error out if
the terminal doesn't support cursor addressing.
* tui/tui.h (tui_allowed_p): Delete declaration.
I noticed that with:
$ TERM=dumb ./gdb -q -nx
<c-x,a>
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
(gdb)
The next key the user types is silently eaten.
The problem is that we're throwing an exception while in a readline
callback that isn't prepared for that:
(top-gdb) bt
#0 tui_enable () at /home/pedro/gdb/mygit/build/../src/gdb/tui/tui.c:388
#1 0x000000000051f47b in tui_rl_switch_mode (notused1=1, notused2=1) at /home/pedro/gdb/mygit/build/../src/gdb/tui/tui.c:101
#2 0x0000000000768d6f in _rl_dispatch_subseq (key=1, map=0xd069c0 <emacs_ctlx_keymap>, got_subseq=0) at /home/pedro/gdb/mygit/build/../src/readline/readline.c:774
#3 0x0000000000768acb in _rl_dispatch_callback (cxt=0x1ce6190) at /home/pedro/gdb/mygit/build/../src/readline/readline.c:686
#4 0x000000000078120b in rl_callback_read_char () at /home/pedro/gdb/mygit/build/../src/readline/callback.c:170
#5 0x0000000000619445 in rl_callback_read_char_wrapper (client_data=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/event-top.c:166
#6 0x000000000061981b in stdin_event_handler (error=0, client_data=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/event-top.c:372
#7 0x000000000061840e in handle_file_event (data=...) at /home/pedro/gdb/mygit/build/../src/gdb/event-loop.c:762
#8 0x00000000006178f5 in process_event () at /home/pedro/gdb/mygit/build/../src/gdb/event-loop.c:339
#9 0x00000000006179bc in gdb_do_one_event () at /home/pedro/gdb/mygit/build/../src/gdb/event-loop.c:403
#10 0x0000000000617a0c in start_event_loop () at /home/pedro/gdb/mygit/build/../src/gdb/event-loop.c:428
Here, in _rl_dispatch_subseq:
769
770 rl_executing_keymap = map;
771
772 rl_dispatching = 1;
773 RL_SETSTATE(RL_STATE_DISPATCHING);
774 (*map[key].function)(rl_numeric_arg * rl_arg_sign, key);
775 RL_UNSETSTATE(RL_STATE_DISPATCHING);
776 rl_dispatching = 0;
777
778 /* If we have input pending, then the last command was a prefix
779 command. Don't change the state of rl_last_func. Otherwise,
GDB is called from line 774, but longjmp'ing at that point leaves
rl_dispatching and RL_STATE_DISPATCHING set.
Fix this by wrapping tui_rl_switch_mode in a TRY_CATCH.
gdb/
2014-10-29 Pedro Alves <palves@redhat.com>
* tui/tui.c (tui_rl_switch_mode): Wrap tui_enable/tui_disable in
TRY_CATCH.
We are trying to insert a breakpoint on line 4 for the following
Ada code.
3 procedure STR is
4 XX : String (1 .. Blocks.Sz) := (others => 'X'); -- STOP
5 K : Integer;
6 begin
7 K := 13;
The code generated on ARM (-march=armv7-m) starts like this:
(gdb) disass str'address
Dump of assembler code for function _ada_str:
--# Line str.adb:3
0x08000014 <+0>: push {r4, r7, lr}
0x08000016 <+2>: sub sp, #28
0x08000018 <+4>: add r7, sp, #0
0x0800001a <+6>: mov r3, sp
0x0800001c <+8>: mov r4, r3
--# Line str.adb:4
0x0800001e <+10>: ldr r3, [pc, #84] ; (0x8000074 <_ada_str+96>)
0x08000020 <+12>: ldr r3, [r3, #0]
0x08000022 <+14>: str r3, [r7, #20]
0x08000024 <+16>: ldr r3, [r7, #20]
[...]
When computing the address related to str.adb:4, GDB correctly
resolves it to 0x0800001e first, but then considers the next
3 instructions as being part of the prologue because it thinks
they are part of stack-protector code. As a result, instead
of inserting the breakpoint at line 4, it skips those instruction
and consequently the rest of the instructions until the start
of the next line, which his line 7.
The stack-protector code is expected to start like this...
ldr Rn, .Label
....
.Lable:
.word __stack_chk_guard
... but the implementation actually accepts a sequence where
the ldr location points to an address for which there is no symbol.
It only aborts if the address points to a symbol which is not
__stack_chk_guard.
Since the __stack_chk_guard symbol is always expected to exist
when used (it lives in .dynsym), this patch fixes the issue by
requiring that the ldr gets the address of the __stack_chk_guard
symbol. If the address could not be resolved, then it rejects
the sequence as being stack-protector code.
gdb/ChangeLog:
* arm-tdep.c (arm_skip_stack_protector): Return early if
address loaded by first "ldr" instruction does not have
a corresponding minimal symbol. Update comment.
Tested on arm-eabi using AdaCore's testsuite.
Tested on arm-linux-gnueabi by Yao as well.
This patch fixes the bug in my patch skipping stack protector
https://www.sourceware.org/ml/gdb-patches/2010-12/msg00110.html
In my skipping stack protector patch, I misunderstood the constant vs.
immediate on instruction encodings, and treated immediate as constant
by mistake. The instruction 'ldr Rd, [PC, #immed]' loads the
address of __stack_chk_guard to Rd, and #immed is an offset from PC.
We should get the __stack_chk_guard from *(pc + #immed).
As a result of this mistake, arm_analyze_load_stack_chk_guard returns
the wrong address of __stack_chk_guard, and the symbol
__stack_chk_guard can't be found. However, we continue to match the
following instructions when symbol isn't found, so the code still
works. In other words, the code just matches the instruction pattern
without checking __stack_chk_guard symbol correctly.
Joel's patch <https://sourceware.org/ml/gdb-patches/2014-10/msg00605.html>
makes the heuristics stricter that we stop matching instructions if
symbol __stack_chk_guard isn't found. Then the bug is exposed. This
patch is to correct the load address computation for ldr instruction,
and it fixes some fails in gdb.mi/gdb792.exp on armv4t both arm and
thumb mode.
Regression tested on arm-linux-gnueabi target with
{armv4t, armv7-a} x {marm, mthumb} x {-fstack-protector,-fno-stack-protector}
gdb:
2014-10-29 Yao Qi <yao@codesourcery.com>
* arm-tdep.c (arm_analyze_load_stack_chk_guard): Compute the
loaded address correctly of ldr instruction.
TL;DR - if we step an instruction that is as long as
decr_pc_after_break (1-byte on x86) right after removing the
breakpoint at PC, in non-stop mode, adjust_pc_after_break adjusts the
PC, but it shouldn't.
In non-stop mode, when a breakpoint is removed, it is moved to the
"moribund locations" list. This is because other threads that are
running may have tripped on that breakpoint as well, and we haven't
heard about it. When a trap is reported, we check if perhaps it was
such a deleted breakpoint that caused the trap. If so, we also need
to adjust the PC (decr_pc_after_break).
Now, say that, on x86:
- a breakpoint was placed at an address where we have an instruction
of the same length as decr_pc_after_break on this arch (1 on x86).
- the breakpoint is removed, and thus put on the moribund locations
list.
- the thread is single-stepped.
As there's no breakpoint inserted at PC anymore, the single-step
actually executes the 1-byte instruction normally. GDB should _not_
adjust the PC for the resulting SIGTRAP. But, adjust_pc_after_break
confuses the step SIGTRAP reported for this single-step as being a
SIGTRAP for the moribund location of the breakpoint that used to be at
the previous PC, and so infrun applies the decr_pc_after_break
adjustment incorrectly.
The confusion comes from the special case mentioned in the comment:
static void
adjust_pc_after_break (struct execution_control_state *ecs)
{
...
As a special case, we could have hardware single-stepped a
software breakpoint. In this case (prev_pc == breakpoint_pc),
we also need to back up to the breakpoint address. */
if (thread_has_single_step_breakpoints_set (ecs->event_thread)
|| !ptid_equal (ecs->ptid, inferior_ptid)
|| !currently_stepping (ecs->event_thread)
|| (ecs->event_thread->stepped_breakpoint
&& ecs->event_thread->prev_pc == breakpoint_pc))
regcache_write_pc (regcache, breakpoint_pc);
The condition that incorrectly triggers is the
"ecs->event_thread->prev_pc == breakpoint_pc" one.
Afterwards, the next resume resume re-executes an instruction that had
already executed, which if you're lucky, results in the inferior
crashing. If you're unlucky, you'll get silent bad behavior...
The fix is to remember that we stepped a breakpoint. Turns out the
only case we step a breakpoint instruction today isn't covered by the
testsuite. It's the case of a 'handle nostop" signal arriving while a
step is in progress _and_ we have a software watchpoint, which forces
always single-stepping. This commit extends sigstep.exp to cover
that, and adds a new test for the adjust_pc_after_break issue.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-28 Pedro Alves <palves@redhat.com>
PR gdb/12623
* gdbthread.h (struct thread_info) <stepped_breakpoint>: New
field.
* infrun.c (resume) <stepping breakpoint instruction>: Set the
thread's stepped_breakpoint field. Skip if reverse debugging.
Add comment.
(init_thread_stepping_state, handle_signal_stop): Clear the
thread's stepped_breakpoint field.
gdb/testsuite/
2014-10-28 Pedro Alves <palves@redhat.com>
PR gdb/12623
* gdb.base/sigstep.c (no_handler): New global.
(main): If 'no_handler is true, set the signal handlers to
SIG_IGN.
* gdb.base/sigstep.exp (breakpoint_over_handler): Add
with_sw_watch and no_handler parameters. Handle them.
(top level) <stepping over handler when stopped at a breakpoint
test>: Add a test axis for testing with a software watchpoint, and
another for testing with the signal handler set to SIG_IGN.
* gdb.base/step-sw-breakpoint-adjust-pc.c: New file.
* gdb.base/step-sw-breakpoint-adjust-pc.exp: New file.
In https://sourceware.org/ml/gdb-patches/2014-10/msg00652.html, Sandra
shows a target that was broken by the recent update_thread_list
optimization:
(gdb) target remote qa8-centos32-cs:10514
...
(gdb) continue
Continuing.
Cannot execute this command without a live selected thread.
(gdb)
The error means that the current thread is in "exited" state when the
continue command is processed. The root of the problem was found
here:
> Sending packet: $Hg0#df...Packet received:
...
> Sending packet: $?#3f...Packet received: S00
> Sending packet: $qfThreadInfo#bb...Packet received: l
> Sending packet: $Hc-1#09...Packet received:
> Sending packet: $qC#b4...Packet received: unset
This target doesn't really support threads (no thread indication in
stop reply packets; no support for qC), but then supports
qfThreadInfo, and returns an empty thread list to GDB.
See https://sourceware.org/ml/gdb-patches/2014-10/msg00665.html for
why the target does that.
As remote_update_thread_list deletes threads from GDB's list that are
not found in the thread list that the target reports, the result is
that GDB deletes the "fake" main thread that GDB added itself. (As
that thread is currently selected, it is marked "exited" instead of
being deleted straight away.)
This commit avoids deleting the main thread in this scenario.
gdb/
2014-10-27 Pedro Alves <palves@redhat.com>
* remote.c (remote_thread_alive): New, factored out from ...
(remote_thread_alive): ... this.
(remote_update_thread_list): Bail out before deleting threads if
the target returned an empty list, and, the current thread has a
magic/fake ptid.
I noticed that "si" behaves differently when a "handle nostop" signal
arrives while the step is in progress, depending on whether the
program was stopped at a breakpoint when "si" was entered.
Specifically, in case GDB needs to step off a breakpoint, the handler
is skipped and the program stops in the next "mainline" instruction.
Otherwise, the "si" stops in the first instruction of the signal
handler.
I was surprised the testsuite doesn't catch this difference. Turns
out gdb.base/sigstep.exp covers a bunch of cases related to stepping
and signal handlers, but does not test stepi nor nexti, only
step/next/continue.
My first reaction was that stopping in the signal handler was the
correct thing to do, as it's where the next user-visible instruction
that is executed is. I considered then "nexti" -- a signal handler
could be reasonably considered a subroutine call to step over, it'd
seem intuitive to me that "nexti" would skip it.
But then, I realized that signals that arrive while a plain/line
"step" is in progress _also_ have their handler skipped. A user might
well be excused for being confused by this, given:
(gdb) help step
Step program until it reaches a different source line.
And the signal handler's sources will be in different source lines,
after all.
I think that having to explain that "stepi" steps into handlers, (and
that "nexti" wouldn't according to my reasoning above), while "step"
does not, is a sign of an awkward interface.
E.g., if a user truly is interested in stepping into signal handlers,
then it's odd that she has to either force the signal to "handle
stop", or recall to do "stepi" whenever such a signal might be
delivered. For that use case, it'd seem nicer to me if "step" also
stepped into handlers.
This suggests to me that we either need a global "step-into-handlers"
setting, or perhaps better, make "handle pass/nopass stop/nostop
print/noprint" have have an additional axis - "handle
stepinto/nostepinto", so that the user could configure whether
handlers for specific signals should be stepped into.
In any case, I think it's simpler (and thus better) for all step
commands to behave the same. This commit thus makes "si/ni" skip
handlers for "handle nostop" signals that arrive while the command was
already in progress, like step/next do.
To be clear, nothing changes if the program was stopped for a signal,
and the user enters a stepping command _then_ -- GDB still steps into
the handler. The change concerns signals that don't cause a stop and
that arrive while the step is in progress.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-27 Pedro Alves <palves@redhat.com>
* infrun.c (handle_signal_stop): Also skip handlers when a random
signal arrives while handling a "stepi" or a "nexti". Set the
thread's 'step_after_step_resume_breakpoint' flag.
gdb/doc/
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Continuing and Stepping): Add cross reference to
info on stepping and signal handlers.
(Signals): Explain stepping and signal handlers. Add context
index entry, and cross references.
gdb/testsuite/
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.base/sigstep.c (dummy): New global.
(main): Issue a couple writes to the new global.
* gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New
procedures.
(skip_over_handler): Use test_skip_handler.
(top level): Call skip_over_handler for stepi and nexti too.
(breakpoint_over_handler): Use test_skip_handler.
(top level): Call breakpoint_over_handler for stepi and nexti too.
When running GDB's reverse debugging testsuite against a few ARM
multilibs, i noticed failures in the machinestate* testcases.
Further investigation showed that push and pop instruction encodings
A1 and A2 were not being handled properly, thus we missed saving
important contents from registers and memory. When going backwards,
such contents were not restored and thus we ended up with a corrupted
state that did not correspond to the real values we had at a
particular point in time.
Attached is a patch that fixes around 36 failures for both
gdb.reverse/machinestate.exp and
gdb.reverse/machinestate-precsave.exp testcases, making them fully
pass. This is for both armv7 and armv4. I still see failures for
armv4 thumb though, so it needs a bit more investigation.
I see no regressions due to this patch for armv7, armv7 thumb, armv4
and armv4 thumb.
gdb/ChangeLog:
* arm-tdep.c (INSN_S_L_BIT_NUM): Document.
(arm_record_ld_st_imm_offset): Reimplement to cover all
load/store cases for ARM opcode 010.
(arm_record_ld_st_multiple): Reimplement to cover all
load/store cases for ARM opcode 100.
This commit modifies the code that prints attach and detach messages
related to following fork and vfork. The changes include using
target_terminal_ours_for_output instead of target_terminal_ours,
printing "vfork" instead of "fork" for all vfork-related messages,
and using _() for the format strings of all of the messages.
We also add a "detach" message for when a fork parent is detached.
Previously in this case the only message was notification of attaching
to the child. We still do not print any messages when following the
parent and detaching the child (the default). The rationale for this
is that from the user's perspective the new child was never attached.
Note that all of these messages are only printed when 'verbose' is set
or when debugging is turned on.
The tests gdb.base/foll-fork.exp and gdb.base/foll-vfork.exp were
modified to check for the new message.
Tested on x64 Ubuntu Lucid, native only.
gdb/ChangeLog:
* infrun.c (follow_fork_inferior): Update fork message printing
to use target_terminal_ours_for_output instead of
target_terminal_ours, to use _() for all format strings, to print
"vfork" instead of "fork" for vforks, and to add a detach message.
(handle_vfork_child_exec_or_exit): Update message printing to use
target_terminal_ours_for_output instead of target_terminal_ours, to
use _() for all format strings, and to fix some formatting.
gdb/testsuite/ChangeLog:
* gdb.base/foll-fork.exp (test_follow_fork,
catch_fork_child_follow): Check for updated fork messages emitted
from infrun.c.
* gdb.base/foll-vfork.exp (vfork_parent_follow_through_step,
vfork_parent_follow_to_bp, vfork_and_exec_child_follow_to_main_bp,
vfork_and_exec_child_follow_through_step): Check for updated vfork
messages emitted from infrun.c.
gdb/ChangeLog:
* gnu-v3-abi.c (gnuv3_pass_by_reference): Call TYPE_TARGET_TYPE
on the arg type of a constructor only if it is of reference type.
gdb/testsuite/ChangeLog:
* gdb.cp/non-trivial-retval.cc: Add a test case.
* gdb.cp/non-trivial-retval.exp: Add a test.
If one is watching new_objfile events in python, it helps to know
when the list of objfiles is cleared. This patch adds a new
clear_objfiles event to support this.
This patch is all just cut-n-paste-n-tweak derived from
the new_objfiles event.
gdb/ChangeLog:
* NEWS: Mention new event gdb.clear_objfiles.
* python/py-event.h (emit_clear_objfiles_event): Clear
* python/py-events.h (events_object): New member clear_objfiles.
* python/py-evts.c (gdbpy_initialize_py_events): Add clear_objfiles
event.
* python/py-inferior.c (python_new_objfile): If objfile is NULL,
emit clear_objfiles event.
* python/py-newobjfileevent.c (create_clear_objfiles_event_object): New
function.
(emit_clear_objfiles_event): New function.
(clear_objfiles): New event.
* python/python-internal.h (gdbpy_initialize_clear_objfiles_event):
Declare.
* python/python.c (_initialize_python): Call
gdbpy_initialize_clear_objfiles_event.
gdb/doc/ChangeLog:
* python.texi (Events In Python): Document clear_objfiles event.
gdb/testsuite/ChangeLog:
* gdb.python/py-events.exp: Update expected output for clear_objfiles
event.
* gdb.python/py-events.py: Add clear_objfiles event.
gdb/ChangeLog:
* NEWS: Mention new gdb.Objfile.progspace attribute.
* python/py-objfile.c (objfpy_get_progspace): New function.
(objfile_getset): New entry for "progspace".
gdb/doc/ChangeLog:
* python.texi (Objfiles In Python): Document new progspace attribute.
gdb/testsuite/ChangeLog:
* gdb.python/py-objfile.exp: Test progspace attribute.
When we repeat a command, by just pressing <ret>, the input from the
previous command is reused for the new command invocation.
When an execution command strips the "&" out of its incoming argument
string, to detect background execution, we poke a '\0' directly to the
incoming argument string.
Combine both, and a repeat of a background command loses the "&".
This is actually only visible if args other than "&" are specified
(e.g., "c 1&" or "next 2&" or "c -a&"), as in the special case of "&"
alone (e.g. "c&") doesn't actually clobber the incoming string.
Fix this by making strip_bg_char return a new string instead of poking
a hole in the input string.
New test included.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17471
* infcmd.c (strip_bg_char): Change prototype and rewrite. Now
returns a copy of the input.
(run_command_1, continue_command, step_1, jump_command)
(signal_command, until_command, advance_command, finish_command)
(attach_command): Adjust and install a cleanup to free the
stripped args.
gdb/testsuite/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17471
* gdb.base/bg-execution-repeat.c: New file.
* gdb.base/bg-execution-repeat.exp: New file.
If all threads in the target were already running when the user does
"c -a", nothing puts the inferior's terminal settings in effect and
removes stdin from the event loop, which we must when running a
foreground command. The result is that user input afterwards crashes
readline/gdb:
(gdb) start
Temporary breakpoint 1 at 0x4005d4: file continue-all-already-running.c, line 23.
Starting program: continue-all-already-running
Temporary breakpoint 1, main () at continue-all-already-running.c:23
23 sleep (10);
(gdb) c -a&
Continuing.
(gdb) c -a
Continuing.
p 1
readline: readline_callback_read_char() called with no handler!
Aborted (core dumped)
$
Backtrace:
Program received signal SIGABRT, Aborted.
0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(top-gdb) p 1
$1 = 1
(top-gdb) bt
#0 0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x0000003b36a36f68 in __GI_abort () at abort.c:89
#2 0x0000000000784aa9 in rl_callback_read_char () at readline/callback.c:116
#3 0x0000000000619181 in rl_callback_read_char_wrapper (client_data=0x0) at gdb/event-top.c:167
#4 0x0000000000619557 in stdin_event_handler (error=0, client_data=0x0) at gdb/event-top.c:373
#5 0x000000000061814a in handle_file_event (data=...) at gdb/event-loop.c:763
#6 0x0000000000617631 in process_event () at gdb/event-loop.c:340
#7 0x00000000006176f8 in gdb_do_one_event () at gdb/event-loop.c:404
#8 0x0000000000617748 in start_event_loop () at gdb/event-loop.c:429
#9 0x00000000006191b3 in cli_command_loop (data=0x0) at gdb/event-top.c:182
#10 0x000000000060f538 in current_interp_command_loop () at gdb/interps.c:318
#11 0x0000000000610701 in captured_command_loop (data=0x0) at gdb/main.c:323
#12 0x000000000060c3f5 in catch_errors (func=0x6106e6 <captured_command_loop>, func_args=0x0, errstring=0x9002c1 "", mask=RETURN_MASK_ALL)
at gdb/exceptions.c:237
#13 0x0000000000611bff in captured_main (data=0x7fffffffd780) at gdb/main.c:1151
#14 0x000000000060c3f5 in catch_errors (func=0x610afe <captured_main>, func_args=0x7fffffffd780, errstring=0x9002c1 "", mask=RETURN_MASK_ALL)
at gdb/exceptions.c:237
#15 0x0000000000611c28 in gdb_main (args=0x7fffffffd780) at gdb/main.c:1159
#16 0x000000000045ef97 in main (argc=5, argv=0x7fffffffd888) at gdb/gdb.c:32
(top-gdb)
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17300
* infcmd.c (continue_1): If continuing all threads in the
foreground, make sure the inferior's terminal settings are put in
effect.
gdb/testsuite/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17300
* gdb.base/continue-all-already-running.c: New file.
* gdb.base/continue-all-already-running.exp: New file.
Jan caught an intermittent GDB crash with the annota1.exp test:
Starting program: .../gdb/testsuite/gdb.base/annota1 ^M
[...]
FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
[...]
readline: readline_callback_read_char() called with no handler!^M
ERROR: Process no longer exists
All we need to is to continue the inferior in the foreground, and type
a command while the inferior is running. E.g.:
(gdb) set annotate 2
▒▒pre-prompt
(gdb)
▒▒prompt
c
▒▒post-prompt
Continuing.
▒▒starting
▒▒frames-invalid
*inferior is running now*
p 1<ret>
readline: readline_callback_read_char() called with no handler!
Aborted (core dumped)
$
When we run a foreground execution command we call
target_terminal_inferior to stop GDB from processing input, and to put
the inferior's terminal settings in effect. Then we tell readline to
hide the prompt with display_gdb_prompt, which clears readline's input
callback too. When the target stops, we call target_terminal_ours,
which re-installs stdin in the event loop, and then we redisplay the
prompt, reinstalling the readline callbacks.
However, when annotations are in effect, the "frames-invalid"
annotation code calls target_terminal_ours after 'resume' had already
called target_terminal_inferior:
(top-gdb) bt
#0 0x000000000056b82f in annotate_frames_invalid () at gdb/annotate.c:219
#1 0x000000000072e6cc in reinit_frame_cache () at gdb/frame.c:1705
#2 0x0000000000594bb9 in registers_changed_ptid (ptid=...) at gdb/regcache.c:612
#3 0x000000000064cca1 in target_resume (ptid=..., step=1, signal=GDB_SIGNAL_0) at gdb/target.c:2136
#4 0x00000000005f57af in resume (step=1, sig=GDB_SIGNAL_0) at gdb/infrun.c:2263
#5 0x00000000005f6051 in proceed (addr=18446744073709551615, siggnal=GDB_SIGNAL_DEFAULT, step=1) at gdb/infrun.c:2613
And then once we hide the prompt and remove readline's input handler
callback, we're in a bad state. We end up with the target running
supposedly in the foreground, but with stdin still installed on the
event loop. Any input then calls into readline, which aborts because
no rl_linefunc callback handler is installed:
Program received signal SIGABRT, Aborted.
0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(top-gdb) bt
#0 0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x0000003b36a36f68 in __GI_abort () at abort.c:89
During symbol reading, debug info gives source 9 included from file at zero line 0.
During symbol reading, debug info gives command-line macro definition with non-zero line 19: _STDC_PREDEF_H 1.
#2 0x0000000000784a25 in rl_callback_read_char () at src/readline/callback.c:116
#3 0x0000000000619111 in rl_callback_read_char_wrapper (client_data=0x0) at src/gdb/event-top.c:167
#4 0x00000000006194e7 in stdin_event_handler (error=0, client_data=0x0) at src/gdb/event-top.c:373
#5 0x00000000006180da in handle_file_event (data=...) at src/gdb/event-loop.c:763
#6 0x00000000006175c1 in process_event () at src/gdb/event-loop.c:340
#7 0x0000000000617688 in gdb_do_one_event () at src/gdb/event-loop.c:404
#8 0x00000000006176d8 in start_event_loop () at src/gdb/event-loop.c:429
#9 0x0000000000619143 in cli_command_loop (data=0x0) at src/gdb/event-top.c:182
#10 0x000000000060f4c8 in current_interp_command_loop () at src/gdb/interps.c:318
#11 0x0000000000610691 in captured_command_loop (data=0x0) at src/gdb/main.c:323
#12 0x000000000060c385 in catch_errors (func=0x610676 <captured_command_loop>, func_args=0x0, errstring=0x900241 "", mask=RETURN_MASK_ALL)
at src/gdb/exceptions.c:237
#13 0x0000000000611b8f in captured_main (data=0x7fffffffd7b0) at src/gdb/main.c:1151
#14 0x000000000060c385 in catch_errors (func=0x610a8e <captured_main>, func_args=0x7fffffffd7b0, errstring=0x900241 "", mask=RETURN_MASK_ALL)
at src/gdb/exceptions.c:237
#15 0x0000000000611bb8 in gdb_main (args=0x7fffffffd7b0) at src/gdb/main.c:1159
#16 0x000000000045ef57 in main (argc=3, argv=0x7fffffffd8b8) at src/gdb/gdb.c:32
The fix is to make the annotation code call target_terminal_inferior
again after printing, if the inferior's settings were in effect.
While at it, when we're doing output only, instead of
target_terminal_ours, we should call target_terminal_ours_for_output.
The latter doesn't actually remove stdin from the event loop, and also
leaves SIGINT forwarded to the target.
New test included.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17472
* annotate.c (annotate_breakpoints_invalid): Use
target_terminal_our_for_output instead of target_terminal_ours.
Give back the terminal to the target.
(annotate_frames_invalid): Likewise.
gdb/testsuite/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17472
* gdb.base/annota-input-while-running.c: New file.
* gdb.base/annota-input-while-running.exp: New file.
I found a place that should be giving back the terminal to the target,
but only if the target was already owning it. So I need to add a
getter for who owns the terminal.
The trouble is that several places/target have their own globals to
track this state:
- inflow.c:terminal_is_ours
- remote.c:remote_async_terminal_ours_p
- linux-nat.c:async_terminal_is_ours
- go32-nat.c:terminal_is_ours
While one might think of adding a new target_ops method to query this,
conceptually, this state isn't really part of a particular target_ops.
Considering multi-target, the core shouldn't have to ask all targets
to know whether it's GDB that owns the terminal. There's only one GDB
(or rather, only one top level interpreter).
So what this comment does is add a new global that is tracked by the
core instead. A subsequent pass may later remove the other globals.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-17 Pedro Alves <palves@redhat.com>
* target.c (enum terminal_state): New enum.
(terminal_state): New global.
(target_terminal_init): New function.
(target_terminal_inferior): Skip if inferior already owns the
terminal.
(target_terminal_ours, target_terminal_ours_for_output): New
functions.
* target.h (target_terminal_init): Convert to function prototype.
(target_terminal_ours_for_output): Convert to function prototype
and tweak comment.
(target_terminal_ours): Convert to function prototype and tweak
comment.
* windows-nat.c (do_initial_windows_stuff): Call
target_terminal_init instead of child_terminal_init_with_pgrp.
This commit does most of the mechanical removal. IOW, the easy part.
procfs.c isn't touched beyond removing a couple obvious bits that are
guarded by a couple macros defined in config/alpha/nm-osf3.h. Going
beyond that for procfs.c & co would be a harder excision that
potentially affects Solaris.
Some comments in the generic alpha code ABIs that may still be
relevant and I wouldn't know what to do with them. That can always be
done on a separate pass, preferably by someone who can test on alpha.
A couple other spots have references to OSF/Tru64 and related files
being removed, but it felt like removing them would make things worse,
not better. We can revisit those when we next need to touch that
code.
I didn't remove a reference to osf in testsuite/lib/future.exp, as I
believe that code is imported from DejaGNU.
Built and tested on x86_64 Fedora 20, with --enable-targets=all.
Tested that building for --target=alpha-osf3 on x86_64 Fedora 20
fails with:
checking for default auto-load directory... $debugdir:$datadir/auto-load
checking for default auto-load safe-path... $debugdir:$datadir/auto-load
*** Configuration alpha-unknown-osf3 is obsolete.
*** Support has been REMOVED.
make[1]: *** [configure-gdb] Error 1
make[1]: Leaving directory `build-osf'
make: *** [all] Error 2
gdb/
2014-10-17 Pedro Alves <palves@redhat.com>
* Makefile.in (ALL_64_TARGET_OBS): Remove alpha-osf1-tdep.o.
(HFILES_NO_SRCDIR): Remove config/alpha/nm-osf3.h.
(ALLDEPFILES): Remove alpha-nat.c, alpha-osf1-tdep.c and
solib-osf.c.
* NEWS: Mention that support for alpha*-*-osf* has been removed.
* ada-lang.h [__alpha__ && __osf__]
(ADA_KNOWN_RUNTIME_FILE_NAME_PATTERNS): Delete.
* alpha-nat.c, alpha-osf1-tdep.c: Delete files.
* alpha-tdep.c (alpha_gdbarch_init): Remove reference to
GDB_OSABI_OSF1.
* config/alpha/alpha-osf3.mh, config/alpha/nm-osf3.h: Delete
files.
* config/djgpp/fnchange.lst (config/alpha/alpha-osf1.mh)
(config/alpha/alpha-osf2.mh, config/alpha/alpha-osf3.mh): Delete.
* configure: Regenerate.
* configure.ac: Remove references to osf.
* configure.host: Handle alpha*-*-osf* in the obsolete hosts
section. Remove all other references to osf.
* configure.tgt: Add alpha*-*-osf* to the obsolete targets section.
Remove all other references to osf.
* dec-thread.c: Delete file.
* defs.h (GDB_OSABI_OSF1): Delete.
* inferior.h (START_INFERIOR_TRAPS_EXPECTED): New unconditionally
defined.
* osabi.c (gdb_osabi_names): Delete "OSF/1".
* procfs.c (procfs_debug_inferior) [PROCFS_DONT_TRACE_FAULTS]:
Delete code.
(unconditionally_kill_inferior)
[PROCFS_NEED_CLEAR_CURSIG_FOR_KILL]: Delete code.
* solib-osf.c: Delete file.
gdb/testsuite/
2014-10-17 Pedro Alves <palves@redhat.com>
* gdb.base/callfuncs.exp: emove references to osf.
* gdb.base/sigall.exp: Likewise.
* gdb.gdb/selftest.exp: Likewise.
* gdb.hp/gdb.base-hp/callfwmall.exp: Likewise.
* gdb.mi/non-stop.c: Likewise.
* gdb.mi/pthreads.c: Likewise.
* gdb.reverse/sigall-precsave.exp: Likewise.
* gdb.reverse/sigall-reverse.exp: Likewise.
* gdb.threads/pthreads.c: Likewise.
* gdb.threads/pthreads.exp: Likewise.
gdb/doc/
2014-10-17 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Ada Tasks and Core Files): Delete mention of Tru64.
(SVR4 Process Information): Delete mention of OSF/1.
clear_threads_listing_context is used for thread listing methods other
than the xml based, but it's only defined when HAVE_LIBEXPAT is defined.
gdb/
2014-10-17 Pedro Alves <palves@redhat.com>
* remote.c (clear_threads_listing_context): Move higher up, out of
the HAVE_LIBEXPAT guard.
Some Darwin kernels return values out of bounds for gs and fs segments.
With this commit, they are masked to avoid garbage.
gdb/ChangeLog:
* i386-darwin-nat.c (i386_darwin_fetch_inferior_registers)
(i386_darwin_store_inferior_registers): Sanitize gs and fs values
on amd64.
Seems to me that we can simplify DEC thread's
target_update_thread_list implementation, avoiding the need to build
the array of GDB threads.
I have no way to test this, but then again support for Tru64 is about
to be removed.
Pushing anyway to have the last version in git be the cleanest one
should start from, if this file turns out to be resurrected in the
future.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* dec-thread.c (dec_thread_count_gdb_threads)
(dec_thread_add_gdb_thread): Delete.
(dec_thread_update_thread_list): Delete.
(dec_thread_find_new_threads): Rename to ...
(dec_thread_update_thread_list): ... this. Delete GDB-size
threads that are no longer found in dec_thread_list.
(resync_thread_list): Delete.
(dec_thread_wait): Call dec_thread_update_thread_list instead of
resync_thread_list.
This commit avoids the prune_threads call in the remote target's
target_update_thread_list's implementation, eliminating all the "thread
alive" RSP traffic (one packet per thread) whenever we fetch the
thread list.
IOW, this:
Sending packet: $Tp2141.2150#82...Packet received: OK
Sending packet: $Tp2141.214f#b7...Packet received: OK
Sending packet: $Tp2141.2141#82...Packet received: OK
... more T packets; it's one per previously known live thread ...
Sending packet: $qXfer:threads:read::0,fff#03...Packet received: l<threads>\n<thread id="p2141.2141" core="2"/>\n<thread id="p2141.214f" core="1"/>\n<thread id="p2141.2150" core="2"/>\n</threads>\n
Becomes:
Sending packet: $qXfer:threads:read::0,fff#03...Packet received: l<threads>\n<thread id="p2141.2141" core="2"/>\n<thread id="p2141.214f" core="1"/>\n<thread id="p2141.2150" core="2"/>\n</threads>\n
Tested on x86_64 Fedora 20, native gdbserver:
- tests the qXfer:threads:read method.
Tested on x86_64 Fedora 20, native gdbserver with qXfer:threads:read
force-disabled in gdbserver:
- So that GDB falls back to the qfThreadInfo/qsThreadInfo method.
And also manually smoked tested force disabling both
qXfer:threads:read and qfThreadInfo/qsThreadInfo in gdbserver.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* gdbthread.h (ALL_NON_EXITED_THREADS_SAFE): New macro.
* remote.c (remote_update_thread_list): Skip calling prune_threads
if any thread listing method is supported, and instead walk over
the set of remote threads listed, deleting those that are not
found in GDB's thread list.
When GDB wants to sync the thread list with the target's (e.g., due to
"info threads"), it calls update_thread_list:
update_thread_list (void)
{
prune_threads ();
target_find_new_threads ();
update_threads_executing ();
}
And then prune_threads does:
prune_threads (void)
{
struct thread_info *tp, *next;
for (tp = thread_list; tp; tp = next)
{
next = tp->next;
if (!thread_alive (tp))
delete_thread (tp->ptid);
}
}
Calling thread_live on each thread one by one is expensive.
E.g., on Linux, it ends up doing kill(SIG0) once for each thread. Not
a big deal, but still a bunch of syscalls...
With the remote target, it's cumbersome. That thread_alive call ends
up generating one T packet per thread:
Sending packet: $Tp2141.2150#82...Packet received: OK
Sending packet: $Tp2141.214f#b7...Packet received: OK
Sending packet: $Tp2141.2141#82...Packet received: OK
Sending packet: $qXfer:threads:read::0,fff#03...Packet received: l<threads>\n<thread id="p2141.2141" core="2"/>\n<thread id="p2141.214f" core="1"/>\n<thread id="p2141.2150" core="2"/>\n</threads>\n
That seems a bit silly when target_find_new_threads method
implementations will always fetch the whole current set of target
threads, and then add those that are not in GDB's thread list, to
GDB's thread list.
This patch thus pushes down the responsibility of pruning dead threads
to the target_find_new_threads method instead, so a target may
implement pruning dead threads however it wants.
Once we do that, target_find_new_threads becomes a misnomer, so the
patch renames it to target_update_thread_list.
The patch doesn't attempt to do any optimization to any target yet.
It simply exports prune_threads, and makes all implementations of
target_update_thread_list call that. It's meant to be a no-op.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* ada-tasks.c (print_ada_task_info, task_command_1): Adjust.
* bsd-uthread.c (bsd_uthread_find_new_threads): Rename to ...
(bsd_uthread_update_thread_list): ... this. Call prune_threads.
(bsd_uthread_target): Adjust.
* corelow.c (core_open): Adjust.
* dec-thread.c (dec_thread_find_new_threads): Update comment.
(dec_thread_update_thread_list): New function.
(init_dec_thread_ops): Adjust.
* gdbthread.h (prune_threads): New declaration.
* linux-thread-db.c (thread_db_find_new_threads): Rename to ...
(thread_db_update_thread_list): ... this. Call prune_threads.
(init_thread_db_ops): Adjust.
* nto-procfs.c (procfs_find_new_threads): Rename to ...
(procfs_update_thread_list): ... this. Call prune_threads.
(procfs_attach, procfs_create_inferior, init_procfs_targets):
Adjust.
* obsd-nat.c (obsd_find_new_threads): Rename to ...
(obsd_update_thread_list): ... this. Call prune_threads.
(obsd_add_target): Adjust.
* procfs.c (procfs_target): Adjust.
(procfs_notice_thread): Update comment.
(procfs_find_new_threads): Rename to ...
(procfs_update_thread_list): ... this. Call prune_threads.
* ravenscar-thread.c (ravenscar_update_inferior_ptid): Update
comment.
(ravenscar_wait): Adjust.
(ravenscar_find_new_threads): Rename to ...
(ravenscar_update_thread_list): ... this. Call prune_threads.
(init_ravenscar_thread_ops): Adjust.
* record-btrace.c (record_btrace_find_new_threads): Rename to ...
(record_btrace_update_thread_list): ... this. Adjust comment.
(init_record_btrace_ops): Adjust.
* remote.c (remote_threads_info): Rename to ...
(remote_update_thread_list): ... this. Call prune_threads.
(remote_start_remote, extended_remote_attach_1, init_remote_ops):
Adjust.
* sol-thread.c (check_for_thread_db): Adjust.
(sol_find_new_threads_callback): Rename to ...
(sol_update_thread_list_callback): ... this.
(sol_find_new_threads): Rename to ...
(sol_update_thread_list): ... this. Call prune_threads. Adjust.
(sol_get_ada_task_ptid, init_sol_thread_ops): Adjust.
* target-delegates.c: Regenerate.
* target.c (target_find_new_threads): Rename to ...
(target_update_thread_list): ... this.
* target.h (struct target_ops): Rename to_find_new_threads field
to to_update_thread_list.
(target_find_new_threads): Rename to ...
(target_update_thread_list): ... this.
* thread.c (prune_threads): Make extern.
(update_thread_list): Adjust.
We have three methods to list the current remote thread list:
1. The qXfer:threads:read method (the preferred one nowadays), builds a
remote thread list while parsing the XML, and then after the XML
parsing is done, goes over the built list and adds threads GDB doesn't
know about yet to GDB's list.
2. If the qXfer method isn't available, we fallback to using the
qfThreadInfo/qsThreadInfo packets. When we do this, we adds threads
to GDB's list immediately as we parse the qfThreadInfo/qsThreadInfo
packet replies.
3. And then if the previous method isn't available either, we try the
old deprecated qL packet. This path is already looking somewhat
broken for not using remote_notice_new_inferior to add threads to
GDB's list.
This patch makes all variants work in two passes, like the qXfer
method, and then makes all variants share the code path that adds
threads to GDB's list.
Tested on x86_64 Fedora 20 with native gdbserver.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* remote.c (remote_get_threadlist, remote_threadlist_iterator):
Add describing comment. Return -1 if the qL packet is not
supported.
(struct thread_item, thread_item_t): Move higher up in
the file. Add comments.
(struct threads_parsing_context): Move higher up in
the file, add comments, and remote to ...
(struct threads_listing_context): ... this.
(remote_newthread_step): Don't add the thread to GDB's thread
database here. Instead push it to the thread_listing_context
list.
(remote_find_new_threads): Rename to ...
(remote_get_threads_with_ql): ... this. Add target_ops and
targets_listing_context parameters. Pass down context.
(start_thread): Adjust.
(clear_threads_parsing_context): Rename to ...
(clear_threads_listing_context): ... this.
(remote_get_threads_with_qxfer): New, with parts salvaged from old
remote_threads_info.
(remote_get_threads_with_qthreadinfo): Ditto.
(remote_threads_info): Reimplement.
This finally reverts this bit of commit 929dfd4f:
2009-07-31 Pedro Alves <pedro@codesourcery.com>
Julian Brown <julian@codesourcery.com>
...
(resume): If this is a software single-stepping arch, and
displaced-stepping is enabled, use it for all single-step
requests.
...
That means that in non-stop (or really displaced-stepping) mode, on
software single-step archs - even those that only use sss breakpoints
to deal with atomic sequences, like PPC - if we have more than one
thread single-stepping, we'll always serialize the threads'
single-steps, as only one thread may be displaced stepping at a given
time, because there's only one scratch pad.
We originally did that because GDB didn't support having multiple
threads software-single-stepping simultaneously. The previous patches
fixed that limitation, so we can now finally revert this too.
Tested on:
- x86_64 Fedora 20, on top of the 'software single-step on x86'
series.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* infrun.c (resume): Don't force displaced-stepping for all
single-steps on software single-stepping archs.
This patch finally makes each thread have its own set of single-step
breakpoints. This paves the way to have multiple threads software
single-stepping, though this patch doesn't flip that switch on yet.
That'll be done on a subsequent patch.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* breakpoint.c (single_step_breakpoints): Delete global.
(insert_single_step_breakpoint): Adjust to store the breakpoint
pointer in the current thread.
(single_step_breakpoints_inserted, remove_single_step_breakpoints)
(cancel_single_step_breakpoints): Delete functions.
(breakpoint_has_location_inserted_here): Make extern.
(single_step_breakpoint_inserted_here_p): Adjust to walk the
breakpoint list.
* breakpoint.h (breakpoint_has_location_inserted_here): New
declaration.
(single_step_breakpoints_inserted, remove_single_step_breakpoints)
(cancel_single_step_breakpoints): Remove declarations.
* gdbthread.h (struct thread_control_state)
<single_step_breakpoints>: New field.
(delete_single_step_breakpoints)
(thread_has_single_step_breakpoints_set)
(thread_has_single_step_breakpoint_here): New declarations.
* infrun.c (follow_exec): Also clear the single-step breakpoints.
(singlestep_breakpoints_inserted_p, singlestep_ptid)
(singlestep_pc): Delete globals.
(infrun_thread_ptid_changed): Remove references to removed
globals.
(resume_cleanups): Delete the current thread's single-step
breakpoints.
(maybe_software_singlestep): Remove references to removed globals.
(resume): Adjust to use thread_has_single_step_breakpoints_set and
delete_single_step_breakpoints.
(init_wait_for_inferior): Remove references to removed globals.
(delete_thread_infrun_breakpoints): Delete the thread's
single-step breakpoints too.
(delete_just_stopped_threads_infrun_breakpoints): Don't delete
single-step breakpoints here.
(delete_stopped_threads_single_step_breakpoints): New function.
(adjust_pc_after_break): Adjust to use
thread_has_single_step_breakpoints_set.
(handle_inferior_event): Remove references to removed globals.
Use delete_stopped_threads_single_step_breakpoints.
(handle_signal_stop): Adjust to per-thread single-step
breakpoints. Swap test order to do cheaper tests first.
(switch_back_to_stepped_thread): Extend debug output. Remove
references to removed globals.
* record-full.c (record_full_wait_1): Adjust to per-thread
single-step breakpoints.
* thread.c (delete_single_step_breakpoints)
(thread_has_single_step_breakpoints_set)
(thread_has_single_step_breakpoint_here): New functions.
(clear_thread_inferior_resources): Also delete the thread's
single-step breakpoints.
A little refactoring to reduce duplicate code.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* thread.c (delete_thread_breakpoint): New function.
(delete_step_resume_breakpoint)
(delete_exception_resume_breakpoint): Use it.
(delete_at_next_stop): New function.
(clear_thread_inferior_resources): Use delete_at_next_stop.
There are no users of deprecated_{insert,remove}_raw_breakpoint left.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* breakpoint.c (regular_breakpoint_inserted_here_p): Inline ...
(breakpoint_inserted_here_p): ... here. Remove special case for
software single-step breakpoints.
(find_non_raw_software_breakpoint_inserted_here): Inline ...
(software_breakpoint_inserted_here_p): ... here. Remove special
case for software single-step breakpoints.
(bp_target_info_copy_insertion_state)
(deprecated_insert_raw_breakpoint)
(deprecated_remove_raw_breakpoint): Delete functions.
* breakpoint.h (deprecated_insert_raw_breakpoint)
(deprecated_remove_raw_breakpoint): Remove declarations.
This patch makes single-step breakpoints "real" breakpoints on the
global location list.
There are several benefits to this:
- It removes the currently limitation that only 2 single-step
breakpoints can be inserted. See an example here of a discussion
around a case that wants more than 2, possibly unbounded:
https://sourceware.org/ml/gdb-patches/2014-03/msg00663.html
- makes software single-step work on read-only code regions.
The logic to convert a software breakpoint to a hardware breakpoint
if the memory map says the breakpoint address is in read only memory
is in insert_bp_location. Because software single-step breakpoints
bypass all that go and straight to target_insert_breakpoint, we
can't software single-step over read only memory. This patch
removes that limitation, and adds a test that makes sure that works,
by forcing a code region to read-only with "mem LOW HIGH ro" and
then stepping through that.
- Fixes PR breakpoints/9649
This is an assertion failure in insert_single_step_breakpoint in
breakpoint.c, because we may leave stale single-step breakpoints
behind on error.
The tests for stepping through read-only regions exercise the root
cause of the bug, which is that we leave single-step breakpoints
behind if we fail to insert any single-step breakpoint. Deleting
the single-step breakpoints in resume_cleanups,
delete_just_stopped_threads_infrun_breakpoints, and
fetch_inferior_event fixes this. Without that, we'd no longer hit
the assertion, as that code is deleted, but we'd instead run into
errors/warnings trying to insert/remove the stale breakpoints on
next resume.
- Paves the way to have multiple threads software single-stepping at
the same time, leaving update_global_location_list to worry about
duplicate locations.
- Makes the moribund location machinery aware of software single-step
breakpoints, paving the way to enable software single-step on
non-stop, instead of forcing serialized displaced stepping for all
single steps.
- It's generaly cleaner.
We no longer have to play games with single-step breakpoints
inserted at the same address as regular breakpoints, like we
recently had to do for 7.8. See this discussion:
https://sourceware.org/ml/gdb-patches/2014-06/msg00052.html.
Tested on x86_64 Fedora 20, on top of my 'single-step breakpoints on
x86' series.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
PR breakpoints/9649
* breakpoint.c (single_step_breakpoints, single_step_gdbarch):
Delete array globals.
(single_step_breakpoints): New global.
(breakpoint_xfer_memory): Remove special handling for single-step
breakpoints.
(update_breakpoints_after_exec): Delete bp_single_step
breakpoints.
(detach_breakpoints): Remove special handling for single-step
breakpoints.
(breakpoint_init_inferior): Delete bp_single_step breakpoints.
(bpstat_stop_status): Add comment.
(bpstat_what, bptype_string, print_one_breakpoint_location)
(adjust_breakpoint_address, init_bp_location): Handle
bp_single_step.
(new_single_step_breakpoint): New function.
(set_momentary_breakpoint, bkpt_remove_location): Remove special
handling for single-step breakpoints.
(insert_single_step_breakpoint, single_step_breakpoints_inserted)
(remove_single_step_breakpoints, cancel_single_step_breakpoints):
Rewrite.
(detach_single_step_breakpoints, find_single_step_breakpoint):
Delete functions.
(breakpoint_has_location_inserted_here): New function.
(single_step_breakpoint_inserted_here_p): Rewrite.
* breakpoint.h: Remove FIXME.
(enum bptype) <bp_single_step>: New enum value.
(insert_single_step_breakpoint): Update comment.
* infrun.c (resume_cleanups)
(delete_step_thread_step_resume_breakpoint): Remove single-step
breakpoints.
(fetch_inferior_event): Install a cleanup that removes infrun
breakpoints.
(switch_back_to_stepped_thread) <expect thread advanced also>:
Clear step-over info.
gdb/testsuite/
2014-10-15 Pedro Alves <palves@redhat.com>
PR breakpoints/9649
* gdb.base/breakpoint-in-ro-region.c (main): Add more instructions.
* gdb.base/breakpoint-in-ro-region.exp
(probe_target_hardware_step): New procedure.
(top level): Probe hardware stepping and hardware breakpoint
support. Test stepping through a read-only region, with both
"breakpoint auto-hw" on and off and both "always-inserted" on and
off.
This is a preparatory/cleanup patch that does two things:
- Renames 'delete_step_thread_step_resume_breakpoint'. The
"step_resume" part is misnomer these days, as the function deletes
other kinds of breakpoints, not just the step-resume breakpoint. A
following patch will want to make it delete yet another kind of
breakpoint, even.
- Splits out the logic of which threads get those breakpoints deleted
to a separate "for_each"-style function, so that the same following
patch may use it with a different callback.
Tested on x86_64 Fedora 20.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* infrun.c (delete_step_resume_breakpoint_callback): Delete.
(delete_thread_infrun_breakpoints): New function, with parts
salvaged from delete_step_resume_breakpoint_callback.
(delete_step_thread_step_resume_breakpoint): Delete.
(for_each_just_stopped_thread_callback_func): New typedef.
(for_each_just_stopped_thread): New function.
(delete_just_stopped_threads_infrun_breakpoints): New function.
(delete_step_thread_step_resume_breakpoint_cleanup): Rename to ...
(delete_just_stopped_threads_infrun_breakpoints_cleanup):
... this. Adjust.
(wait_for_inferior, fetch_inferior_event): Adjust to renames.
When GDB finds out the target triggered a watchpoint, and the target
has non-continuable watchpoints, GDB sets things up to step past the
instruction that triggered the watchpoint. This is just like stepping
past a breakpoint, but goes through a different mechanism - it resumes
only the thread that needs to step past the watchpoint, but also
switches a "infwait state" global, that has the effect that the next
target_wait only wait for events only from that thread.
This forcing of a ptid to pass to target_wait obviously becomes a
bottleneck if we ever support stepping past different watchpoints
simultaneously (in separate processes).
It's also unnecessary -- the target should only return events for
threads that have been resumed; if no other thread than the one we're
stepping past the watchpoint has been resumed, then those other
threads should not report events. If we couldn't assume that, then
stepping past regular breakpoints would be broken for not likewise
forcing a similar infwait_state.
So this patch eliminates infwait_state, and instead teaches keep_going
to mark step_over_info in a way that has the breakpoints module skip
inserting watchpoints (because we're stepping past one), like it skips
breakpoints when we're stepping past one.
Tested on:
- x86_64 Fedora 20 (continuable watchpoints)
- PPC64 Fedora 18 (non-steppable watchpoints)
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* breakpoint.c (should_be_inserted): Don't insert watchpoints if
trying to step past a non-steppable watchpoint.
* gdbthread.h (struct thread_info) <stepping_over_watchpoint>: New
field.
* infrun.c (struct step_over_info): Add new field
'nonsteppable_watchpoint_p' and adjust comments.
(set_step_over_info): New 'nonsteppable_watchpoint_p' parameter.
Adjust.
(clear_step_over_info): Clear nonsteppable_watchpoint_p as well.
(stepping_past_nonsteppable_watchpoint): New function.
(step_over_info_valid_p): Also return true if stepping past a
nonsteppable watchpoint.
(proceed): Adjust call to set_step_over_info. Remove reference to
init_infwait_state.
(init_wait_for_inferior): Remove reference to init_infwait_state.
(waiton_ptid): Delete global.
(struct execution_control_state)
<stepped_after_stopped_by_watchpoint>: Delete field.
(wait_for_inferior, fetch_inferior_event): Always pass
minus_one_ptid to target_wait.
(init_thread_stepping_state): Clear 'stepping_over_watchpoint'
field.
(init_infwait_state): Delete function.
(handle_inferior_event): Remove infwait_state handling.
(handle_signal_stop) <watchpoints handling>: Adjust after
stepped_after_stopped_by_watchpoint removal. Don't remove
breakpoints here nor set infwait_state. Set the thread's
stepping_over_watchpoint flag, and call keep_going instead.
(keep_going): Handle stepping_over_watchpoint. Adjust
set_step_over_info calls.
* infrun.h (stepping_past_nonsteppable_watchpoint): Declare
function.
... instead of trap_expected.
Gets rid of one singlestep_breakpoints_inserted_p reference, and is
generally more to the point.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* infrun.c (step_over_info_valid_p): New function.
(resume): Use step_over_info_valid_p instead of checking the
threads's trap_expected flag.
gdb/ChangeLog:
* python/lib/gdb/__init__.py (packages): Add "printer".
* python/lib/gdb/command/bound_registers.py: Moved to ...
* python/lib/gdb/printer/bound_registers.py: ... here.
Add printer to global set of builtin printers. Rename printer from
"bound" to "mpx_bound128".
* python/lib/gdb/printing.py (_builtin_pretty_printers): New global,
registered as global "builtin" printer.
(add_builtin_pretty_printer): New function.
* data-directory/Makefile.in (PYTHON_FILE_LIST): Update, and add
gdb/printer/__init__.py.
On 32-bit S390 targets the longjmp target address "naturally" has the
most significant bit set. That bit indicates the addressing mode and
is not part of the address itself. Thus, in analogy with similar
cases (like when computing the caller PC in
insert_step_resume_breakpoint_at_caller), this change removes
non-address bits from the longjmp target address before using it as a
breakpoint address.
Note that there are two ways for determining the longjmp target
address: via a probe or via a gdbarch method. This change only
affects the probe method, because it is assumed that the address
returned by the gdbarch method is usable as-is.
This change was tested together with a patch that enables longjmp
probes in glibc for S/390:
https://sourceware.org/ml/libc-alpha/2014-10/msg00277.html
gdb/ChangeLog:
* gdb/infrun.c (process_event_stop_test): Apply
gdbarch_addr_bits_remove to longjmp resume address.
This file:
- Isn't used by GDBserver currently.
- Isn't included in the WHICH list in features/Makefile, so hasn't
been regenerated to pick the latest microblaze or generic fixes.
Just delete it.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* regformats/microblaze.dat: Delete file.
The Microblaze PC register is called "rpc", not "pc", as can be seen
in microblaze-core.xml. Fix this, so GDBserver can find the register in
the regcache.
gdb/
2014-10-15 Ajit Agarwal <ajitkum@xilinx.com>
* features/Makefile (microblaze-expedite): Replace pc with rpc.
* regformats/microblaze-with-stack-protect.dat: Regenerate.
Before this, a copy constructor declared as in the following snippet was
not being treated as a copy constructor.
class A
{
public:
A (A &); // OK.
A (const A &); // Not being treated as a copy constructor because of the
// 'const' qualifier.
};
gdb/ChangeLog:
PR c++/13403
PR c++/15154
* gnu-v3-abi.c (gnuv3_pass_by_reference): Lookup copy constructors
with qualified args.
When trying to evaluate an expression which adds a pointer and
an integral, the evaluation succeeds if the pointer is on
the left handside of the operator, but not when it is on the right
handside:
(gdb) p something'address + 0
$1 = (system.address) 0x613418 <pck.something>
(gdb) p 0 + something'address
Argument to arithmetic operation not a number or boolean.
Same issue when doing subtractions:
(gdb) p something'address - 0
$2 = (system.address) 0x613418 <pck.something>
(gdb) p 0 - something'address
Argument to arithmetic operation not a number or boolean.
This patch enhances the Ada expression evaluator to handle
these two situations.
gdb/ChangeLog:
* ada-lang.c (ada_evaluate_subexp) <BINOP_ADD>: Add handling
of the case where the second operand is a pointer.
<BINOP_SUB>: Likewise.
gdb/testsuite/ChangeLog:
* gdb.ada/addr_arith: New testcase.
Tested on x86_64-linux.
This patch is a response to what I commented on:
<https://sourceware.org/ml/gdb-patches/2014-10/msg00046.html>
When reviewing Jose's USDT probe support patches. Basically, in his
patch he had to create dummy functions for the set_semaphore and the
clear_semaphore methods of probe_ops (gdb/probe.h), because those
functions were called inconditionally from inside gdb/breakpoint.c and
gdb/tracepoint.c. However, the semaphore concept may not apply to all
types of probes, and this is the case here: USDT probes do not have
semaphores (although SDT probes do).
Anyway, this is a simple (almost obvious) patch to guard the call to
{set,clear}_semaphore. It does not introduce any regression on a
Fedora 20 x86_64.
I will apply it in a few days in case there is no comment.
gdb/ChangeLog:
2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com>
* breakpoint.c (bkpt_probe_insert_location): Call set_semaphore
only if it is not NULL.
(bkpt_probe_remove_location): Likewise, for clear_semaphore.
* probe.h (struct probe_ops) <set_semaphore>: Update comment.
(struct probe_ops) <clear_semaphore>: Likewise.
* tracepoint.c (start_tracing): Call set_semaphore only if it is
not NULL.
(stop_tracing): Likewise, for clear_semaphore.
Joel contacted me offlist with a question about a warning that one of
his customers was seeing. The message came from the new
linker-debugger interface, which uses SDT probes internally. The
warning said:
(gdb) run
[...]
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
Argument to arithmetic operation not a number or boolean.
This should not have happened in the environment the customer was
using (RHEL-6.x), so I found it strange. Another thing caught my
attention: the last message, saying "Argument to arithmetic operation
not a number or boolean.".
Joel kindly investigated the issue further, and found the answer for
this. To quote him:
(gdb) set lang c
(gdb) p 48+$ebp
$4 = (void *) 0xffffd0f8
So far so good. But...
(gdb) set lang ada
(gdb) p 48+$ebp
Argument to arithmetic operation not a number or boolean.
Ooops! Interestingly, if you revert the order of the operands...
(gdb) p $ebp+48
$5 = (access void) 0xffffd0f8
So the problem is doing pointer arithmetics when the language is set
to Ada.
I remembered that, during the parsing and the evaluation of SDT probe
arguments, the code sets the language as current_language, because, at
that time, I thought it was not necessary to worry about the language
given that the code implements its own parser. I was wrong. So here
is a patch to fix that, by setting the language as C, which should
guarantee that the maths are done in the right way (TM).
It was somewhat hard to find a reproducer for this issue. In the end,
what I had to do was to create a testcase that used the %ebp register
on some displacement (e.g., "-4(%ebp)"), which finally triggered the
bug. I am not sure why I could not trigger it when using other
registers, but I did not want to spend too much time investigating
this issue, which seemed like an Ada issue. Also, because of this
peculiar way to trigger the problem, the testcase only covers x86-like
targets (i.e., i*86 and x86_64 with -m32).
Joel kindly tested this for me, and it worked. I also ran a full
regression test here on my Fedora 20 x86_64, and everything is fine.
I will push this patch in a few days if there are no comments.
gdb/ChangeLog:
2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com>
* stap-probe.c (stap_parse_argument): Initialize expout explicitly
using language_c, instead of current_language.
gdb/testsuite/ChangeLog:
2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.arch/stap-eval-lang-ada.S: Likewise.
* gdb.arch/stap-eval-lang-ada.c: Likewise.
* gdb.arch/stap-eval-lang-ada.exp: New file.
gdb/ChangeLog:
* py-objfile.c (objfpy_initialize): New function.
(objfpy_new, objfile_to_objfile_object): Call it.
* py-progspace.c (pspy_initialize): New function.
(pspy_new, pspace_to_pspace_object): Call it.
gdb/ChangeLog
2014-10-13 Miroslav Franc <mfranc@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Fix "save breakpoints" for "catch" command.
* break-catch-sig.c (signal_catchpoint_print_recreate): Add trailing
newline.
gdb/testsuite/ChangeLog
2014-10-13 Jan Kratochvil <jan.kratochvil@redhat.com>
Yao Qi <yao@codesourcery.com>
Fix "save breakpoints" for "catch" command.
* gdb.base/catch-signal.exp: Add gdb_breakpoint "main".
Remove -nonewline. Match also the added "main" line.
This does most of the mechanical removal. IOW, the easy part.
This doesn't touch procfs.c as that'd be a harder excision,
potentially affecting Solaris.
mips-tdep.c is left alone. E.g., I didn't delete the GDB_OSABI_IRIX
enum value, nor references to it in mips-tdep.c. Some comments
mentioning IRIX ABIs may still be relevant and I wouldn't know what to
do with them. in That can always be done on a separate pass,
preferably by someone who can test on MIPS.
I didn't remove a reference to IRIX in testsuite/lib/future.exp, as I
believe that code is imported from DejaGNU.
Built and tested on x86_64 Fedora 20, with --enable-targets=all.
Tested that building for --target=mips-sgi-irix6 on x86_64 Fedora 20
fails with:
checking for default auto-load directory... $debugdir:$datadir/auto-load
checking for default auto-load safe-path... $debugdir:$datadir/auto-load
*** Configuration mips-sgi-irix6 is obsolete.
*** Support has been REMOVED.
make[1]: *** [configure-gdb] Error 1
make[1]: Leaving directory `/home/pedro/gdb/mygit/build-irix'
make: *** [all] Error 2
gdb/
2014-10-10 Pedro Alves <palves@redhat.com>
* Makefile.in (ALL_TARGET_OBS): Remove mips-irix-tdep.o and solib-irix.o.
(ALLDEPFILES): Remove mips-irix-tdep.c and solib-irix.c.
(HFILES_NO_SRCDIR): Remove solib-irix.h.
* NEWS: Mention that support for mips-sgi-irix5* mips-sgi-irix6*
and been removed.
* config/mips/irix5.mh, config/mips/irix6.mh: Delete files.
* configure.ac: Remove references to IRIX.
* configure.host: Add *-*-irix* to the obsolete hosts section.
Remove all other references to irix.
* irix5-nat.c, mips-irix-tdep.c, solib-irix.c, solib-irix.h:
Delete files.
gdb/testsuite/
2014-10-10 Pedro Alves <palves@redhat.com>
* gdb.base/bigcore.exp: Remove references to IRIX.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/interrupt.exp: Likewise.
* gdb.base/mips_pro.exp: Likewise.
* gdb.base/nodebug.exp: Likewise.
* gdb.base/setvar.exp: Likewise.
* lib/gdb.exp (gdb_compile_shlib): Remove mips-sgi-irix* case.
We currently validate the target description, but then forget to
reject it if found invalid.
Tested that incorrect descriptions are rejected and GDB warns about
them.
Tested the Microblaze Design with and without stack-protect registers.
The gdb command "info registers" displayed the register correctly. If
a stack protect design is not selected, only core registers are
displayed. When the stack-protect registers are selected in the
design, the core registers along with stack-protect registers are
displayed.
gdb/
2014-10-10 Ajit Agarwal <ajitkum@xilinx.com>
* microblaze-tdep.c (microblaze_gdbarch_init): If the description
isn't valid, release the tdesc arch data and return NULL.
We're now doing a vsyscall/vDSO address range lookup whenever we fetch
shared libraries, either through an explicit "info shared", or when
the target reports new libraries have been loaded, in order to filter
out the vDSO from glibc's DSO list. Before we started doing that, GDB
would only ever lookup the vsyscall's address range once in the
process's lifetime.
Looking up the vDSO address range requires an auxv lookup (which is
already cached, so no problem), but also reading the process's
mappings from /proc to find out the vDSO's mapping's size. That
generates extra RSP traffic when remote debugging. Particularly
annoying when the process's mappings grow linearly as more libraries
are mapped in, and we went through the trouble of making incremental
DSO list updates work against gdbserver (when the probes-based dynamic
linker interface is available).
The vsyscall/vDSO is mapped by the kernel when the process is
initially mapped in, and doesn't change throughout the process's
lifetime, so we can cache its address range.
Caching at this level brings GDB back to one and only one vsyscall
address range lookup per process.
Tested on x86_64 Fedora 20.
gdb/
2014-10-10 Pedro Alves <palves@redhat.com>
* linux-tdep.c: Include observer.h.
(linux_inferior_data): New global.
(struct linux_info): New structure.
(invalidate_linux_cache_inf, linux_inferior_data_cleanup)
(get_linux_inferior_data): New functions.
(linux_vsyscall_range): Rename to ...
(linux_vsyscall_range_raw): ... this.
(linux_vsyscall_range): New function; handles caching.
(_initialize_linux_tdep): Register linux_inferior_data. Install
inferior_exit and inferior_appeared observers.
With upstream glibc, GDB prints:
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
A bug's been filed for glibc a few years back:
http://sourceware.org/bugzilla/show_bug.cgi?id=13097
but it's still not resolved. It's not clear whether there's even
consensus that this is indeed a glibc bug. It would actually be nice
if GDB also listed the vDSO in the shared library list, but there are
some design considerations with that:
- the vDSO is mapped by the kernel, not userspace, therefore we
should load its symbols right from the process's start of life,
even before glibc / the userspace loader sets up the initial DSO
list. The program might even be using a custom loader or no
loader.
- that kind of hints at that solib.c should handle retrieving shared
library lists from more than one source, and that symfile-mem.c's
loading of the vDSO would be converted to load and relocate the
vDSO's bfd behind the target_so_ops interface.
- and then, once glibc links in the vDSO to its DSO list, we'd need
to either:
a) somehow hand over the vDSO from one target_so_ops to the other
b) simply keep hiding glibc's entry.
And then b) seems the simplest.
With that in mind, this patch simply discards the vDSO from glibc's
reported shared library list.
We can match the vDSO address range with the addresses found iterating
the dynamic linker list, to tell which dynamic linker entry is the
vDSO.
Tested on x86_64 Fedora 20.
gdb/
2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
PR symtab/14466
* solib-svr4.c (svr4_read_so_list): Rename to ...
(svr4_current_sos_1): ... this and change the function comment.
(svr4_current_sos): New function.
gdb/testsuite/
2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
PR symtab/14466
* gdb.base/vdso-warning.c: New file.
* gdb.base/vdso-warning.exp: New file.
We have a case in solib-svr4.c where we could reuse symfile-mem.c's
vDSO range lookup. Since symfile-mem.c is not present in all
configurations solib-svr4.c is, move that lookup to a gdbarch hook.
This has the minor (good) side effect that we stop even trying the
target_auxv_search lookup against targets that don't have a concept of
a vDSO, in case symfile-mem.c happens to be linked in the build
(--enable-targets=all).
Tested on x86_64 Fedora 20.
gdb/
2014-10-10 Pedro Alves <palves@redhat.com>
* arch-utils.c (default_vsyscall_range): New function.
* arch-utils.h (default_vsyscall_range): New declaration.
* gdbarch.sh (vsyscall_range): New hook.
* gdbarch.h, gdbarch.c: Regenerate.
* linux-tdep.c (linux_vsyscall_range): New function.
(linux_init_abi): Install linux_vsyscall_range as
vsyscall_range gdbarch hook.
* memrange.c (address_in_mem_range): New function.
* memrange.h (address_in_mem_range): New declaration.
* symfile-mem.c (find_vdso_size): Delete function.
(add_vsyscall_page): Use gdbarch_vsyscall_range.
This patch fixes the bug described in PR tdep/9390, which is about a
wrong check in the following code:
...
/* optional copying of args in r2-r7 to r10-r13. */
/* Probably only in optimized case but legal action for prologue. */
else if ((inst & 0xff00) == 0x4600 /* 46SD mov rD, rS */
&& (inst & 0x00f0) >= 0x0020 && (inst & 0x00f0) <= 0x0070
&& (inst & 0x000f) >= 0x00a0 && (inst & 0x000f) <= 0x000d)
^^^^^^^^^^^^^^^^^^^^^^^^^
...
This condition will never trigger, and the fix proposed in the bug
(which made sense to me) was to test against 0x000a. I tried finding
documentation about this target, but couldn't find anything. I don't
even know if it is still used, but decided to submit the fix anyway.
Tested on my x86_64 Fedora 20 GNU/Linux.
gdb/ChangeLog:
2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
PR tdep/9390
* xstorxstormy16-tdep.c (xstormy16_analyze_prologue): Fix possible
typo when using logical AND to determine instruction type.
As a result of commit b57bacec, local variable 'printed' is no longer
used. This patch is to remove it.
gdb:
2014-10-09 Yao Qi <yao@codesourcery.com>
* infrun.c (handle_signal_stop): Remove local variable 'printed'.
This commit makes fbsd-tdep.c not include string.h or gdb_assert.h
as both are already included by defs.h.
gdb/ChangeLog:
* fbsd-tdep.c: Do not include string.h or gdb_assert.h.
This commit includes common-exceptions.h in common-defs.h and removes
all other inclusions.
gdb/ChangeLog:
* common/common-defs.h: Include common-exceptions.h.
* exceptions.h: Do not include common-exceptions.h.
gdb/gdbserver/ChangeLog:
* server.h: Do not include common-exceptions.h.
This commit includes cleanups.h in common-defs.h and removes all other
inclusions.
gdb/ChangeLog:
* common/common-defs.h: Include cleanups.h.
* common/common-exceptions.c: Do not include cleanups.h.
* utils.h: Likewise.
gdb/gdbserver/ChangeLog:
* server.h: Do not include cleanups.h.
A helper function called `add_offset_16' is used by
`extended_mips16_next_pc' to calculate branch destinations. Weirdly
enough the helper does not do what the name suggests and rather than
doing its work for a 16-bit immediate branch offset it makes its
calculations on a 26-bit immediate target used by JAL and JALX
instructions. Furthermore the JAL/JALX calculation is only needed once
by `extended_mips16_next_pc' while a 16-bit branch offset calculation
is made inline several times across `extended_mips16_next_pc'.
This change therefore replaces the contents of `add_offset_16' with the
16-bit branch offset calculation and updates `extended_mips16_next_pc'
accordingly.
* mips-tdep.c (add_offset_16): Rewrite to implement what the
name implies.
(extended_mips16_next_pc): Update accordingly.
This change addresses a regression in gdb.dwarf2/dw2-skip-prologue.exp
across MIPS16 multilibs:
(gdb) file .../gdb.dwarf2/dw2-skip-prologue
Reading symbols from .../gdb.d/gdb.dwarf2/dw2-skip-prologue...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
warning: Breakpoint address adjusted from 0x00400725 to 0x00400721.
Breakpoint 1 at 0x400721
(gdb) set remotetimeout 5
(gdb) kill
The program is not being run.
(gdb)
[...]
target remote ...:2345
Reading symbols from .../mips16/lib/ld.so.1...done.
warning: Breakpoint address adjusted from 0x00400725 to 0x00400721.
warning: Breakpoint address adjusted from 0x00400725 to 0x00400721.
0x2aaa8e81 in __start () from .../mips16/lib/ld.so.1
(gdb) continue
Continuing.
warning: Breakpoint address adjusted from 0x00400725 to 0x00400721.
warning: Breakpoint 1 address previously adjusted from 0x00400725 to
0x00400721.
Breakpoint 1, 0x00400721 in main ()
(gdb) break func
Breakpoint 2 at 0x4006a1: func. (2 locations)
(gdb) continue
Continuing.
warning: GDB can't find the start of the function at 0x4006dd.
GDB is unable to find the start of the function at 0x4006dd
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x4006dd for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
Program received signal SIGBUS, Bus error.
0x0040072b in main ()
(gdb) FAIL: gdb.dwarf2/dw2-skip-prologue.exp: continue to breakpoint: func
-- notice the breakpoint adjustment messages that are already a bad
sign. These happen when a breakpoint is requested in a branch delay
slot and are not supposed to happen unless explicitly requested with an
address pointing to a branch delay slot instruction. No symbol or line
debug information is supposed to direct GDB to place a breakpoint in a
delay slot.
Here's how `main' looks like:
00400718 <main>:
400718: 64f5 save 40,ra,s0-s1
40071a: 1a00 01a8 jal 4006a0 <func>
40071e: 0104 addiu s1,sp,16
400720: 1a00 01b7 jal 4006dc <func+0x3c>
400724: 6702 move s0,v0
400726: e049 addu v0,s0,v0
400728: 65b9 move sp,s1
40072a: 6473 restore 24,ra,s0-s1
40072c: e8a0 jrc ra
40072e: 6500 nop
-- so 0x400725 is the MIPS16 instruction address of the first MOVE
instruction seen above, in a delay slot of the preceding JAL instruction
indeed. This test case arranges for `main' to have no debug information
so it is one of the heuristic prologue scanners, `mips16_scan_prologue'
specifically in this case, that is responsible for finding the right
location for the breakpoint to place.
In this case the prologue really ends with the ADDIU instruction,
reordered into the delay slot of the first JAL instruction. Of course
we can't place the breakpoint for `main' after it as by doing so we'll
let `func' to be called before hitting this breakpoint. So the
breakpoint has to go at the JAL instruction instead, or 0x40071b.
To make a general case out of it we must never consider any jump or
branch instruction to be a part of a function's prologue. In the
presence of a jump or branch at the beginning of a function the furthest
instruction examined for the purpose of constructing frame information
can be one in the delay slot of that jump or branch if present, and
otherwise -- that is when the jump or branch is compact and has no delay
slot -- the instruction immediately preceding the jump or branch.
This change implements that approach across prologue scanners for the
three instruction ISAs. In implementing it I have factored out code
from the existing `*_instruction_has_delay_slot' handlers to be shared
and a side effect for the microMIPS implementation is it now always
fetches the second 16-bit halfword of 32-bit instructions even if it
eventually is not going to be needed. I think it's an acceptable
tradeoff for the purpose of code sharing.
To make things more consistent I also carried logic from
`micromips_scan_prologue' over to the other two scanners to accept (and
ignore) a single non-prologue non-control transfer instruction reordered
by the compiler into the prologue. While doing this I simplified the
exit path from the scan loop such that `end_prologue_addr' is set only
once. This made some concerns expressed in comments no longer
applicable, although even before they were not valid.
I have not fixed the logic around `load_immediate_bytes' in
`mips32_scan_prologue' though, it remains broken, although I took care
not to break it more. An approach similar to one taken for handling
larger stack adjustments in `micromips_scan_prologue' will have to be
eventually implemented here.
For regression testing I used my usual choice of the mips-linux-gnu
target and the following multilibs:
-EB
-EB -msoft-float
-EB -mips16
-EB -mips16 -msoft-float
-EB -mmicromips
-EB -mmicromips -msoft-float
-EB -mabi=n32
-EB -mabi=n32 -msoft-float
-EB -mabi=64
-EB -mabi=64 -msoft-float
and the -EL variants of same.
That removed gdb.dwarf2/dw2-skip-prologue.exp failures across MIPS16
multilibs, the test log now shows:
(gdb) file .../gdb.dwarf2/dw2-skip-prologue
Reading symbols from .../gdb.d/gdb.dwarf2/dw2-skip-prologue...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x40071b
(gdb) set remotetimeout 5
(gdb) kill
The program is not being run.
(gdb)
[...]
target remote ...:2345
Reading symbols from .../mips16/lib/ld.so.1...done.
0x2aaa8e81 in __start () from .../mips16/lib/ld.so.1
(gdb) continue
Continuing.
Breakpoint 1, 0x0040071b in main ()
(gdb) break func
Breakpoint 2 at 0x4006a1: func. (2 locations)
(gdb) continue
Continuing.
Breakpoint 2, func (param=0) at main.c:5
5 This program is free software; you can redistribute it and/or modify
(gdb) PASS: gdb.dwarf2/dw2-skip-prologue.exp: continue to breakpoint: func
-- so things look like intended.
That also did regress, again across MIPS16 multilibs, another test case,
gdb.base/step-symless.exp:
(gdb) file .../gdb.d/gdb.base/step-symless
Reading symbols from .../gdb.base/step-symless...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x4006d3
(gdb) set remotetimeout 5
(gdb) kill
The program is not being run.
(gdb)
[...]
target remote ...:2345
Reading symbols from .../mips16/lib/ld.so.1...done.
0x2aaa8e81 in __start () from .../mips16/lib/ld.so.1
(gdb) continue
Continuing.
Breakpoint 1, 0x004006d3 in main ()
(gdb) break symful
Breakpoint 2 at 0x4006a5
(gdb) step
Single stepping until exit from function main,
which has no line number information.
warning: GDB can't find the start of the function at 0x4006b9.
GDB is unable to find the start of the function at 0x4006b9
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x4006b9 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
0x004006b9 in ?? ()
(gdb) FAIL: gdb.base/step-symless.exp: step
-- but that is actually a good sign. Here `main', again, has no debug
information and code involved looks like:
004006a0 <symful>:
4006a0: 6491 save 8,s1
4006a2: 673d move s1,sp
4006a4: b204 lw v0,4006b4 <symful+0x14>
4006a6: 9a40 lw v0,0(v0)
4006a8: 4261 addiu v1,v0,1
4006aa: b203 lw v0,4006b4 <symful+0x14>
4006ac: da60 sw v1,0(v0)
4006ae: 65b9 move sp,s1
4006b0: 6411 restore 8,s1
4006b2: e8a0 jrc ra
4006b4: 0041 addiu s0,sp,260
4006b6: 0860 la s0,400834 <__libc_start_main@mips16plt+0x54>
4006b8: 6491 save 8,s1
4006ba: 673d move s1,sp
4006bc: b204 lw v0,4006cc <symful+0x2c>
4006be: 9a40 lw v0,0(v0)
4006c0: 4261 addiu v1,v0,1
4006c2: b203 lw v0,4006cc <symful+0x2c>
4006c4: da60 sw v1,0(v0)
4006c6: 65b9 move sp,s1
4006c8: 6411 restore 8,s1
4006ca: e8a0 jrc ra
4006cc: 0041 addiu s0,sp,260
4006ce: 0860 la s0,40084c <__libc_start_main@mips16plt+0x6c>
004006d0 <main>:
4006d0: 64d4 save 32,ra,s1
4006d2: 1a00 01ae jal 4006b8 <symful+0x18>
4006d6: 0104 addiu s1,sp,16
4006d8: 1a00 01a8 jal 4006a0 <symful>
4006dc: 6500 nop
4006de: 6740 move v0,zero
4006e0: 65b9 move sp,s1
4006e2: 6452 restore 16,ra,s1
4006e4: e8a0 jrc ra
4006e6: 6500 nop
4006e8: 6500 nop
4006ea: 6500 nop
4006ec: 6500 nop
4006ee: 6500 nop
-- and the original log:
(gdb) file .../gdb.base/step-symless
Reading symbols from .../gdb.base/step-symless...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
warning: Breakpoint address adjusted from 0x004006dd to 0x004006d9.
Breakpoint 1 at 0x4006d9
(gdb) set remotetimeout 5
(gdb) kill
The program is not being run.
(gdb)
[...]
target remote ...:2345
Reading symbols from .../mips16/lib/ld.so.1...done.
warning: Breakpoint address adjusted from 0x004006dd to 0x004006d9.
warning: Breakpoint address adjusted from 0x004006dd to 0x004006d9.
0x2aaa8e81 in __start () from .../mips16/lib/ld.so.1
(gdb) continue
Continuing.
warning: Breakpoint address adjusted from 0x004006dd to 0x004006d9.
warning: Breakpoint 1 address previously adjusted from 0x004006dd to
0x004006d9.
Breakpoint 1, 0x004006d9 in main ()
(gdb) break symful
Breakpoint 2 at 0x4006a5
(gdb) step
Single stepping until exit from function main,
which has no line number information.
Breakpoint 2, 0x004006a5 in symful ()
(gdb) PASS: gdb.base/step-symless.exp: step
So the breakpoint at `main' was actually set at an instruction after the
call to `symful+0x18' aka `symless' and the test only passed because
single-stepping through `symless' wasn't actually done at all. With
this change in place this test fails for MIPS16 multilibs consistently
with all the other multilibs where it already failed in this manner
previously.
* mips-tdep.c (mips16_instruction_is_compact_branch): New
function.
(micromips_instruction_is_compact_branch): Likewise.
(mips16_scan_prologue): Terminate scanning upon seeing a branch
or a compact jump, reaching a jump delay slot, or seeing a
second non-prologue instruction.
(micromips_scan_prologue): Also terminate scanning upon seeing a
compact branch or jump, or reaching a branch or jump delay slot.
(mips32_scan_prologue): Terminate scanning upon reaching a branch
or jump delay slot, or seeing a second non-prologue instruction.
(mips32_instruction_has_delay_slot): Retain instruction
examination code only, update arguments accordingly and move
instruction fetch pieces to...
(mips32_insn_at_pc_has_delay_slot): ... this new function.
(micromips_instruction_has_delay_slot): Likewise and to...
(micromips_insn_at_pc_has_delay_slot): ... this new function.
(mips16_instruction_has_delay_slot): Likewise and to...
(mips16_insn_at_pc_has_delay_slot): ... this new function.
(mips_single_step_through_delay): Update accordingly.
(mips_adjust_breakpoint_address): Likewise.
This change addresses `micromips_instruction_has_delay_slot' and
`mips16_instruction_has_delay_slot' that both incorrectly interpret
their MUSTBE32 argument. Their callers assume that when the flag is
clear these functions will return 1 when any non-compact jump or branch
instruction is present at ADDR, while in fact they will only return 1
for 16-bit such instructions only. This change makes the implementation
match the expectations.
* mips-tdep.c (micromips_instruction_has_delay_slot): When
!mustbe32 also return 1 for 32-bit instructions.
(mips16_instruction_has_delay_slot): Likewise. Add an
explanatory comment.
In installing minimal symbols for ELF shared library trampolines
we "forget" to make individual symbols special where required. This
leads to problems on the MIPS target using microMIPS SVR4 lazy stubs.
Lacking the special annotation these stubs are treated as standard
MIPS code and this makes GDB insert the wrong software breakpoint
instruction, breaking e.g. single-stepping through these stubs. This
is not a very frequent scenario as microMIPS SVR4 lazy stubs are
typically only used in shared libraries with the main executable
using PLT, handled elsewhere. Still it triggers e.g. when a software
watchpoint has been installed. The symptom is SIGILL or the program
going astray, depending on the endianness. Disassembly of these stubs
is also wrong.
* elfread.c (elf_symtab_read): Also mark solib trampoline minimal
symbols special.
This change:
commit b775012e84
Author: Luis Machado <luisgpm@br.ibm.com>
Date: Fri Feb 24 15:10:59 2012 +0000
2012-02-24 Luis Machado <lgustavo@codesourcery.com>
* remote.c (remote_supports_cond_breakpoints): New forward
declaration.
[...]
changed the way breakpoints are inserted and removed such that
`insert_bp_location' can now be called with the breakpoint being handled
already in place, while previously the call was only ever made for
breakpoints that have not been put in place. This in turn caused an
issue for software breakpoints and targets for which a breakpoint's
`placed_address' may not be the same as the original requested address.
The issue is `insert_bp_location' overwrites the previously adjusted
value in `placed_address' with the original address, that is only
replaced back with the correct adjusted address later on when
`gdbarch_breakpoint_from_pc' is called. Meanwhile there's a window
where the value in `placed_address' does not correspond to data stored
in `shadow_contents', leading to incorrect instruction bytes being
supplied when `one_breakpoint_xfer_memory' is called to supply the
instruction overlaid by the breakpoint.
And this is exactly what happens on the MIPS target with software
breakpoints placed in microMIPS code. In this case not only
`placed_address' is not the original address because of the ISA bit, but
`mips_breakpoint_from_pc' has to read the original instruction to
determine which one of the two software breakpoint instruction encodings
to choose as well. The 16-bit encoding is used to replace 16-bit
instructions and similarly the 32-bit one is used with 32-bit
instructions, to satisfy branch delay slot size requirements.
The mismatch between `placed_address' and the address data in
`shadow_contents' has been obtained from leads to the wrong encoding
being used in some cases, which in the case of a 32-bit software
breakpoint instruction replacing a 16-bit instruction causes corruption
to the adjacent following instruction and leads the debug session astray
if execution reaches there e.g. with a jump.
To address this problem I made the change below, that adds a
`reqstd_address' field to `struct bp_target_info' and leaves
`placed_address' unchanged once it has been set. This ensures data in
`shadow_contents' is always consistent with `placed_address'.
This approach also has this good side effect that all the places that
examine the breakpoint's address see a consistent value, either
`reqstd_address' or `placed_address', as required. Currently some
places see either the original or the adjusted address in
`placed_address', depending on whether they have been called before
`gdbarch_remote_breakpoint_from_pc' or afterwards. This is in
particular true for subsequent calls to
`gdbarch_remote_breakpoint_from_pc' itself, e.g. from
`one_breakpoint_xfer_memory'. This is also important for places like
`find_single_step_breakpoint' where a breakpoint's address is compared
to the raw value of $pc.
* breakpoint.h (bp_target_info): Add `reqstd_address' member,
update comments.
* breakpoint.c (one_breakpoint_xfer_memory): Use `reqstd_address'
for the breakpoint's address. Don't preinitialize `placed_size'.
(insert_bp_location): Set `reqstd_address' rather than
`placed_address'.
(bp_target_info_copy_insertion_state): Also copy `placed_address'.
(bkpt_insert_location): Use `reqstd_address' for the breakpoint's
address.
(bkpt_remove_location): Likewise.
(deprecated_insert_raw_breakpoint): Likewise.
(deprecated_remove_raw_breakpoint): Likewise.
(find_single_step_breakpoint): Likewise.
* mem-break.c (default_memory_insert_breakpoint): Use
`reqstd_address' for the breakpoint's address. Don't set
`placed_address' or `placed_size' if breakpoint contents couldn't
have been determined.
* remote.c (remote_insert_breakpoint): Use `reqstd_address' for
the breakpoint's address.
(remote_insert_hw_breakpoint): Likewise. Don't set
`placed_address' or `placed_size' if breakpoint couldn't have been
set.
* aarch64-linux-nat.c (aarch64_linux_insert_hw_breakpoint): Use
`reqstd_address' for the breakpoint's address.
* arm-linux-nat.c (arm_linux_hw_breakpoint_initialize): Likewise.
* ia64-tdep.c (ia64_memory_insert_breakpoint): Likewise.
* m32r-tdep.c (m32r_memory_insert_breakpoint): Likewise.
* microblaze-linux-tdep.c
(microblaze_linux_memory_remove_breakpoint): Likewise.
* monitor.c (monitor_insert_breakpoint): Likewise.
* nto-procfs.c (procfs_insert_breakpoint): Likewise.
(procfs_insert_hw_breakpoint): Likewise.
* ppc-linux-nat.c (ppc_linux_insert_hw_breakpoint): Likewise.
* ppc-linux-tdep.c (ppc_linux_memory_remove_breakpoint): Likewise.
* remote-m32r-sdi.c (m32r_insert_breakpoint): Likewise.
* remote-mips.c (mips_insert_breakpoint): Likewise.
* x86-nat.c (x86_insert_hw_breakpoint): Likewise.
On MIPS64 little endian, attempting an assignment to a bit field
that lives in a register yields the wrong result. It just corrupts
the data in the register depending on the specific position of the
bit field inside the structure.
FAIL: gdb.base/store.exp: f_1.j
FAIL: gdb.base/store.exp: f_1.k
FAIL: gdb.base/store.exp: F_1.i
FAIL: gdb.base/store.exp: F_1.j
FAIL: gdb.base/store.exp: F_1.k
FAIL: gdb.base/store.exp: f_2.j
FAIL: gdb.base/store.exp: f_2.k
FAIL: gdb.base/store.exp: F_2.i
FAIL: gdb.base/store.exp: F_2.j
FAIL: gdb.base/store.exp: F_2.k
FAIL: gdb.base/store.exp: f_3.j
FAIL: gdb.base/store.exp: f_3.k
FAIL: gdb.base/store.exp: F_3.i
FAIL: gdb.base/store.exp: F_3.j
FAIL: gdb.base/store.exp: F_3.k
FAIL: gdb.base/store.exp: f_4.j
FAIL: gdb.base/store.exp: f_4.k
FAIL: gdb.base/store.exp: F_4.i
FAIL: gdb.base/store.exp: F_4.j
FAIL: gdb.base/store.exp: F_4.k
=== gdb Summary ===
Now, GDB knows how to do bit field assignment properly, but MIPS is
one of those architectures that uses a hook for the register-to-value
conversion. Although we can properly tell when the type being passed
is a structure or union, we cannot tell when it is a bit field,
because the bit field data lives in a value structure. Such data
only lives in a "type" structure when the parent structure is being
referenced, thus you can collect them from the flds_bnds members.
A bit field type structure looks pretty much the same as any other
primitive type like int or char, so we can't distinguish them.
Forcing more fields into the type structure wouldn't help much,
because the type structs are shared.
2014-10-03 Luis Machado <lgustavo@codesourcery.com>
* valops.c (value_assign): Check for bit field assignments
before calling architecture-specific register value
conversion functions.
Trying to debug gdb with itself,
I stumbled on the following complaints
Unknown symbol type 0x2e
or
Unknown symbol type 0x4e
It appears that those corrspond to N_BNSYM and N_ENSYM,
which are MacOS extensions of stabs debugging format.
But these extensions have been used inside gcc probalby
for a while already, see:
https://gcc.gnu.org/ml/gcc/2004-08/msg00157.html
As the only purpose of these entries is to allow for removal
of stabs information if the function is removed,
it can be safely ignored by GDB.
This patch simply adds those two entry types to the list
of ignored entry type in read_dbx_symtab function.
Is this OK?
Pierre Muller
2014-10-03 Pierre Muller <muller@sourceware.org>
* dbxread.c (read_dbx_symtab): Also ignore N_BNSYM/N_ENSYM.
Commit a25a5a45 (Fix "breakpoint always-inserted off"; remove
"breakpoint always-inserted auto") regressed non-stop remote
debugging.
This was exposed by mi-nsintrall.exp intermittently failing with a
spurious SIGTRAP.
The problem is that when debugging with "target remote", new threads
the target has spawned but have never reported a stop aren't visible
to GDB until it explicitly resyncs its thread list with the target's.
For example, in a program like this:
int
main (void)
{
pthread_t child_thread;
pthread_create (&child_thread, NULL, child_function, NULL);
return 0; <<<< set breakpoint here
}
If the user sets a breakpoint at the "return" statement, and runs the
program, when that breakpoint hit is reported, GDB is only aware of
the main thread. So if we base the decision to remove or insert
breakpoints from the target based on whether all the threads we know
about are stopped, we'll miss that child_thread is running, and thus
we'll remove breakpoints from the target, even through they should
still remain inserted, otherwise child_thread will miss them.
The break-while-running.exp test actually should also be exposing this
thread-list-out-of-synch problem. That test sets a breakpoint while
the main thread is stopped, but other threads are running. Because
other threads are running, the breakpoint is supposed to be inserted
immediately. But, unless something forces a refetch of the thread
list, like, e.g., "info threads", GDB won't be aware of the other
threads that had been spawned by the main thread, and so won't insert
new or old breakpoints in the target. And it turns out that the test
is exactly doing an explicit "info threads", masking out the
problem... This commit adjust the test to exercise the case of not
issuing "info threads". The test then fails without the GDB fix.
In the ni-nsintrall.exp case, what happens is that several threads hit
the same breakpoint, and when the first thread reports the stop,
because GDB wasn't aware other threads exist, all threads known to GDB
are found stopped, so GDB removes the breakpoints from the target.
The other threads follow up with SIGTRAPs too for that same
breakpoint, which has already been removed. For the first few
threads, the moribund breakpoints machinery suppresses the SIGTRAPs,
but after a few events (precisely '3 * thread_count () + 1' at the
time the breakpoint was removed, see update_global_location_list), the
moribund breakpoint machinery is no longer aware of the removed
breakpoint, and the SIGTRAP is reported as a spurious stop.
The fix is naturally then to stop assuming that if no thread in the
list is executing, then the target is fully stopped. We can't know
that until we fully sync the thread list. Because updating the thread
list on every stop would be too much RSP traffic, I chose instead to
update it whenever we're about to present a stop to the user.
Actually updating the thread list at that point happens to be an item
I had added to the local/remote parity wiki page a while ago:
Native GNU/Linux debugging adds new threads to the thread list as
the program creates them "The [New Thread foo] messages". Remote
debugging can't do that, and it's arguable whether we shouldn't even
stop native debugging from doing that, as it hinders inferior
performance. However, a related issue is that with remote targets
(and gdbserver), even after the program stops, the user still needs
to do "info threads" to pull an updated thread list. This, should
most likely be addressed, so that GDB pulls the list itself, perhaps
just before presenting a stop to the user.
With that in place, the need to delay "Program received signal FOO"
was actually caught by the manythreads.exp test. Without that bit, I
was getting:
[Thread 0x7ffff7f13700 (LWP 4499) exited]
[New Thread 0x7ffff7f0b700 (LWP 4500)]
^C
Program received signal SIGINT, Interrupt.
[New Thread 0x7ffff7f03700 (LWP 4501)] <<< new output
[Switching to Thread 0x7ffff7f0b700 (LWP 4500)]
__GI___nptl_death_event () at events.c:31
31 {
(gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1
That is, I was now getting "New Thread" lines after the "Program
received signal" line, and the test doesn't expect them. As the
number of new threads discovered before and after the "Program
received signal" output is unbounded, it's much nicer to defer
"Program received signal" until after synching the thread list, thus
close to the "switching to thread" output and "current frame/source"
info:
[Thread 0x7ffff7863700 (LWP 7647) exited]
^C[New Thread 0x7ffff786b700 (LWP 7648)]
Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7ffff7fc4740 (LWP 6243)]
__GI___nptl_create_event () at events.c:25
25 {
(gdb) PASS: gdb.threads/manythreads.exp: stop threads 1
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-02 Pedro Alves <palves@redhat.com>
* breakpoint.c (breakpoints_should_be_inserted_now): Use
threads_are_executing.
* breakpoint.h (breakpoints_should_be_inserted_now): Add
describing comment.
* gdbthread.h (threads_are_executing): Declare.
(handle_signal_stop) <random signals>: Don't print about the
signal here if stopping.
(end_stepping_range): Don't notify observers here.
(normal_stop): Update the thread list. If stopped by a random
signal or a stepping range ended, notify observers.
* thread.c (threads_executing): New global.
(init_thread_list): Clear 'threads_executing'.
(set_executing): Set or clear 'threads_executing'.
(threads_are_executing): New function.
(update_threads_executing): New function.
(update_thread_list): Use it.
gdb/testsuite/
2014-10-02 Pedro Alves <palves@redhat.com>
* gdb.threads/break-while-running.exp (test): Add new
'update_thread_list' argument. Skip "info threads" if false.
(top level): Add new 'update_thread_list' axis.
Following an exec with "breakpoint always-inserted on" tries to insert
breakpoints in the new image at the addresses the symbols had in the
old image.
With "always-inserted off", we see:
gdb gdb.multi/multi-arch-exec -ex "set breakpoint always-inserted off"
GNU gdb (GDB) 7.8.50.20140924-cvs
...
(gdb) b main
Breakpoint 1 at 0x400664: file gdb.multi/multi-arch-exec.c, line 24.
^^^^^^^^
(gdb) c
The program is not being run.
(gdb) r
Starting program: testsuite/gdb.multi/multi-arch-exec
Breakpoint 1, main () at gdb/testsuite/gdb.multi/multi-arch-exec.c:24
24 execl (BASEDIR "/multi-arch-exec-hello",
(gdb) c
Continuing.
process 9212 is executing new program: gdb/testsuite/gdb.multi/multi-arch-exec-hello
Breakpoint 1, main () at gdb/testsuite/gdb.multi/hello.c:40
40 bar();
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x080484e4 in main at gdb/testsuite/gdb.multi/hello.c:40
^^^^^^^^^^
breakpoint already hit 2 times
(gdb)
Note how main was 0x400664 in multi-arch-exec, and 0x080484e4 in
gdb.multi/hello.
With "always-inserted on", we get:
Breakpoint 1, main () at gdb/testsuite/gdb.multi/multi-arch-exec.c:24
24 execl (BASEDIR "/multi-arch-exec-hello",
(gdb) c
Continuing.
infrun: target_wait (-1, status) =
infrun: 9444 [process 9444],
infrun: status->kind = execd
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_EXECD
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x400664
(gdb)
That is, GDB is trying to insert a breakpoint at 0x400664, after the
exec, and then that address happens to not be mapped at all in the new
image.
The problem is that update_breakpoints_after_exec is creating
breakpoints, which ends up in update_global_location_list immediately
inserting breakpoints if "breakpoints always-inserted" is "on".
update_breakpoints_after_exec is called very early when we see an exec
event. At that point, we haven't loaded the symbols of the new
post-exec image yet, and thus haven't reset breakpoint's addresses to
whatever they may be in the new image. All we should be doing in
update_breakpoints_after_exec is deleting breakpoints that no longer
make sense after an exec. So the fix removes those breakpoint
creations.
The question is then, if not here, where are those breakpoints
re-created? Turns out we don't need to do anything else, because at
the end of follow_exec, we call breakpoint_re_set, whose tail is also
creating exactly the same breakpoints update_breakpoints_after_exec is
currently creating:
breakpoint_re_set (void)
{
...
create_overlay_event_breakpoint ();
create_longjmp_master_breakpoint ();
create_std_terminate_master_breakpoint ();
create_exception_master_breakpoint ();
}
A new test is added to exercise this.
Tested on x86_64 Fedora 20.
gdb/
2014-10-02 Pedro Alves <palves@redhat.com>
PR breakpoints/17431
* breakpoint.c (update_breakpoints_after_exec): Don't create
overlay, longjmp, std terminate nor exception breakpoints here.
gdb/testsuite/
2014-10-02 Pedro Alves <palves@redhat.com>
PR breakpoints/17431
* gdb.base/execl-update-breakpoints.c: New file.
* gdb.base/execl-update-breakpoints.exp: New file.
A patch I wrote made GDB pull the thread list sooner when debugging
with target remote, and I noticed an intended consequence. GDB
started bouncing around the currently selected remote/general thread
more frequently. E.g.:
Sending packet: $qTMinFTPILen#3b...Packet received: 5
+Sending packet: $Hgp726d.726d#53...Packet received: OK
Sending packet: $m400680,40#2f...Packet received: 85c0741455bff00d60004889e5ffd05de97bffffff0f1f00e973ffffff0f1f00554889e5c745fc00000000c745fc01000000e900000000c745fc02000000b800
+Sending packet: $Hgp726d.7278#28...Packet received: OK
Sending packet: $m4006b2,1#28...Packet received: e9
Fast tracepoint 2 at 0x4006b2: file gdb/testsuite/gdb.trace/range-stepping.c, line 53.
Sending packet: $qTStatus#49...Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes::
This ended up breaking "tstart" when one has fast tracepoints set,
because gdbserver isn't expecting an Hg packet in response to
qRelocInsn:
(gdb) ftrace *set_point
Fast tracepoint 3 at 0x4006b2: file gdb/testsuite/gdb.trace/range-stepping.c, line 53.
(gdb) PASS: gdb.trace/range-stepping.exp: ftrace: ftrace *set_point
tstart
gdbserver: Malformed response to qRelocInsn, ignoring: Hgp2783.2783
Target does not support this command.
(gdb) FAIL: gdb.trace/range-stepping.exp: ftrace: tstart
remote_trace_start should probably start by making sure the remote
current thread matches inferior_ptid (calling set_general_thread), but
still, reducing unnecessary bouncing is a good idea. It happens
because the memory/symbol/breakpoint routines use
switch_to_program_space_and_thread to do something in the right
context and then revert back to the previously current thread.
The fix is to simply make any_thread_of_process,
find_inferior_for_program_space, etc. give preference to the current
thread/inferior it if matches.
gdb/
2014-10-02 Pedro Alves <palves@redhat.com>
* gdbthread.h (any_thread_of_process, any_live_thread_of_process):
Adjust comments.
* inferior.c (find_inferior_for_program_space): Give preference to
the current inferior.
* inferior.h (find_inferior_for_program_space): Update comment.
* progspace.c (switch_to_program_space_and_thread): Prefer the
current inferior if it's bound to the program space requested. If
the inferior found doesn't have a PID yet, don't bother looking up
a thread.
* progspace.h (switch_to_program_space_and_thread): Adjust
comment.
* thread.c (any_thread_of_process, any_live_thread_of_process):
Give preference to the current thread.
Currently, with "set breakpoint auto-hw off", we'll still try to
insert a software breakpoint at addresses covered by supposedly
read-only or inacessible regions:
(top-gdb) mem 0x443000 0x450000 ro
(top-gdb) set mem inaccessible-by-default off
(top-gdb) disassemble
Dump of assembler code for function main:
0x0000000000443956 <+34>: movq $0x0,0x10(%rax)
=> 0x000000000044395e <+42>: movq $0x0,0x18(%rax)
0x0000000000443966 <+50>: mov -0x24(%rbp),%eax
0x0000000000443969 <+53>: mov %eax,-0x20(%rbp)
End of assembler dump.
(top-gdb) b *0x0000000000443969
Breakpoint 5 at 0x443969: file ../../src/gdb/gdb.c, line 29.
(top-gdb) c
Continuing.
warning: cannot set software breakpoint at readonly address 0x443969
Breakpoint 5, 0x0000000000443969 in main (argc=1, argv=0x7fffffffd918) at ../../src/gdb/gdb.c:29
29 args.argc = argc;
(top-gdb)
We warn, saying that the insertion can't be done, but then proceed
attempting the insertion anyway, and in case of manually added
regions, the insert actually succeeds.
This is a regression; GDB used to fail inserting the breakpoint. More
below.
I stumbled on this as I wrote a test that manually sets up a read-only
memory region with the "mem" command, in order to test GDB's behavior
with breakpoints set on read-only regions, even when the real memory
the breakpoints are set at isn't really read-only. I wanted that in
order to add a test that exercises software single-stepping through
read-only regions.
Note that the memory regions that target_memory_map returns aren't
like e.g., what would expect to see in /proc/PID/maps on Linux.
Instead, they're the physical memory map from the _debuggers_
perspective. E.g., a read-only region would be real ROM or flash
memory, while a read-only+execute mapping in /proc/PID/maps is still
read-write to the debugger (otherwise the debugger wouldn't be able to
set software breakpoints in the code segment).
If one tries to manually write to memory that falls within a memory
region that is known to be read-only, with e.g., "p foo = 1", then we
hit a check in memory_xfer_partial_1 before the write mananges to make
it to the target side.
But writing a software/memory breakpoint nowadays goes through
target_write_raw_memory, and unlike when writing memory with
TARGET_OBJECT_MEMORY, nothing on the TARGET_OBJECT_RAW_MEMORY path
checks whether we're trying to write to a read-only region.
At the time "breakpoint auto-hw" was added, we didn't have the
TARGET_OBJECT_MEMORY vs TARGET_OBJECT_RAW_MEMORY target object
distinction yet, and the code path in memory_xfer_partial that blocks
writes to read-only memory was hit for memory breakpoints too. With
GDB 6.8 we had:
warning: cannot set software breakpoint at readonly address 0000000000443943
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x443943: Input/output error.
So I started out by fixing this by adding the memory region validation
to TARGET_OBJECT_RAW_MEMORY too.
But later, when testing against GDBserver, I realized that that would
only block software/memory breakpoints GDB itself inserts with
gdb/mem-break.c. If a target has a to_insert_breakpoint method, the
insertion request will still pass through to the target. So I ended
up converting the "cannot set breakpoint" warning in breakpoint.c to a
real error return, thus blocking the insertion sooner.
With that, we'll end up no longer needing the TARGET_OBJECT_RAW_MEMORY
changes once software single-step breakpoints are converted to real
breakpoints. We need them today as software single-step breakpoints
bypass insert_bp_location. But, it'll be best to leave that in as
safeguard anyway, for other direct uses of TARGET_OBJECT_RAW_MEMORY.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* breakpoint.c (insert_bp_location): Error out if inserting a
software breakpoint at a read-only address.
* target.c (memory_xfer_check_region): New function, factored out
from ...
(memory_xfer_partial_1): ... this. Make the 'reg_len' local a
ULONGEST.
(target_xfer_partial) <TARGET_OBJECT_RAW_MEMORY>: Check the access
against the memory region attributes.
gdb/testsuite/
2014-10-01 Pedro Alves <palves@redhat.com>
* gdb.base/breakpoint-in-ro-region.c: New file.
* gdb.base/breakpoint-in-ro-region.exp: New file.
Don't reset the exit code at inferior exit and print it in
-list-thread-groups.
gdb/ChangeLog:
* NEWS: Announce new exit-code field in -list-thread-groups
output.
* inferior.c (exit_inferior_1): Don't clear exit code.
(inferior_appeared): Clear exit code.
* mi/mi-main.c (print_one_inferior): Add printing of the exit
code.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-exit-code.exp: New file.
* gdb.mi/mi-exit-code.c: New file.
gdb/doc/ChangeLog:
* gdb.texinfo (Miscellaneous gdb/mi Commands): Document new
exit-code field in -list-thread-groups output.
This makes it easier to rebuild all GDB's generated target description
C files.
It also clarifies the comments a bit. One might think we need a GDB
configured for the particular arquitecture (--target=foo). But a
build that includes support for the target description is sufficient.
(GDB rejects target descriptions that explicitly specify the
architecture, with an <architecture> element, if the architecture is
unknown.)
Tested that "make clean-cfiles" deletes all .c files under
src/gdb/features/, and that "make cfiles" generates them all without
error, and that diffing the newly generated C files against master
comes out an empty diff.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/Makefile: Update comments.
(XMLTOC): List all xml files we build C files from.
(clean-cfiles): New rule.
I regenerated all the .c files under src/gdb/features/ and this is
what I got.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/i386/amd64-avx512-linux.c: Regenerate.
* features/i386/amd64-avx512.c: Regenerate.
* features/i386/x32-avx512-linux.c: Regenerate.
* features/i386/x32-avx512.c: Regenerate.
The only reason .dat files exist is for GBBserver to use them in its
build system.
A few .dat files are listed as targets for generation that shouldn't.
The target descriptions these files are built from aren't used by
GDBserver. They're fallback descriptions GDB itself has baked in.
Remove them from the list of .dat files to be generated, otherwise a
plain "make" under src/gdb/features/ generates new .dat files that
aren't even in the tree today.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/Makefile (WHICH): Remove arm-with-m,
arm-with-m-fpa-layout and arm-with-m-vfp-d16.
So that we can do "make clean all" to regenerate all the renerated
.dat files.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/Makefile (clean): New rule.
This file's format is invalid, as it's missing some end quotes.
I noticed this because I tried to regenerate all the .dat files in
gdb/regformats/. I got:
sh ../../move-if-change ../regformats/i386/x32-avx.tmp ../regformats/i386/x32-avx.dat
echo "# DO NOT EDIT: generated from i386/x32-avx512.xml" > ../regformats/i386/x32-avx512.tmp
echo "name:`echo x32-avx512 | sed 's/-/_/g'`" >> ../regformats/i386/x32-avx512.tmp
echo "xmltarget:x32-avx512.xml" >> ../regformats/i386/x32-avx512.tmp
echo "expedite:rbp,rsp,rip" \
>> ../regformats/i386/x32-avx512.tmp
xsltproc --path "/home/pedro/gdb/mygit/src/gdb/features" --xinclude number-regs.xsl i386/x32-avx512.xml | \
xsltproc sort-regs.xsl - | \
xsltproc gdbserver-regs.xsl - >> ../regformats/i386/x32-avx512.tmp
i386/64bit-avx512.xml:81: parser error : Unescaped '<' not allowed in attributes values
<reg name="zmm11h" bitsize="256" type="v2ui128/>
^
i386/64bit-avx512.xml:81: parser error : attributes construct error
<reg name="zmm11h" bitsize="256" type="v2ui128/>
^
i386/64bit-avx512.xml:81: parser error : Couldn't find end of Start Tag reg line 80
<reg name="zmm11h" bitsize="256" type="v2ui128/>
^
i386/64bit-avx512.xml:82: parser error : Unescaped '<' not allowed in attributes values
<reg name="zmm12h" bitsize="256" type="v2ui128/>
^
i386/64bit-avx512.xml:82: parser error : attributes construct error
<reg name="zmm12h" bitsize="256" type="v2ui128/>
^
...
i386/x32-avx512.xml:17: element include: XInclude error : could not load i386/64bit-avx512.xml, and no fallback was found
-:1: parser error : Document is empty
^
-:1: parser error : Start tag expected, '<' not found
^
unable to parse -
-:1: parser error : Document is empty
^
-:1: parser error : Start tag expected, '<' not found
^
unable to parse -
make: *** [../regformats/i386/x32-avx512.dat] Error 6
Interestingly, gdb/expat manages to grok the broken file.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/i386/64bit-avx512.xml (zmm10h, zmm11h, zmm12h, zmm13h)
(zmm14h): Add missing end quotes.
This reverts commit a4d9ba85 - 'AARCH64: Change cpsr type to be
64bit.'.
Even though Linux's ptrace exposes CPSR as 64-bit, CPSR is really
32-bit, and basing GDB's fundamentals on a particular OS's ptrace(2)
implementation is a bad idea.
In addition, while that commit intended to fix big endian Aarch64, it
ended up breaking floating point debugging against GDBserver, for both
big and little endian, because it changed the CPSR to be 64-bit in the
features/aarch64-core.xml file, but missed regenerating the
regformats/aarch64.dat file. If we generate it now, we see this:
diff --git c/gdb/regformats/aarch64.dat w/gdb/regformats/aarch64.dat
index afe1028..0d32183 100644
--- c/gdb/regformats/aarch64.dat
+++ w/gdb/regformats/aarch64.dat
@@ -35,7 +35,7 @@ expedite:x29,sp,pc
64:x30
64:sp
64:pc
-32:cpsr
+64:cpsr
128:v0
128:v1
128:v2
IOW, that commit left regformats/aarch64.dat still considering CPSR as
32-bits. regformats/aarch64.dat is used by GDBserver for its internal
regcache layout, and for the g/G packet register block. See the
generated aarch64.c file in GDBserver's build dir.
So the target description xml file that GDBserver reports to GDB is
now claiming that CPSR is 64-bit, but what GDBserver actually puts in
the g/G register packets is 32-bits. Because GDB thinks CPSR is
64-bit (because that's what the XML description says), GDB will be
reading the remaining 32-bit bits of CPSR out of v0 (the register
immediately afterwards), and then all the registers that follow CPSR
in the register packet end up wrong in GDB, because they're being read
from the wrong offsets...
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/aarch64-core.xml (cpsr): Change back to 32-bit.
* features/aarch64.c: Regenerate.
This patch reorganizes the code that implements follow-fork and
detach-on-fork in preparation for implementation of those features for the
extended-remote target. The function linux-nat.c:linux_child_follow_fork
contained target-independent code mixed in with target-dependent code. The
target-independent pieces need to be accessible for the host-side
implementation of follow-fork for extended-remote Linux targets.
The changes are fairly mechanical. A new routine, follow_fork_inferior,
is implemented in infrun.c, containing those parts of
linux_child_follow_fork that manage inferiors and the inferior list. The
parts of linux_child_follow_fork that deal with LWPs and target-specifics
were left in-place. Although the order of some operations was changed, the
resulting functionality was not.
Modifications were made to the other native target follow-fork functions,
inf_ttrace_follow_fork and inf_ptrace_follow_fork, that should allow them
to work with follow_fork_inferior. Some other adjustments were necessary
in inf-ttrace.c. The changes to inf-ttrace.c and inf-ptrace.c were not
tested.
gdb/ChangeLog:
* inf-ptrace.c (inf_ptrace_follow_fork): Remove target-independent
code so as to work with follow_fork_inferior.
* inf-ttrace.c (inf_ttrace_follow_fork): Ditto.
(inf_ttrace_create_inferior): Remove reference to
inf_ttrace_vfork_ppid.
(inf_ttrace_attach): Ditto.
(inf_ttrace_detach): Ditto.
(inf_ttrace_kill): Use current_inferior instead of
inf_ttrace_vfork_ppid.
(inf_ttrace_wait): Eliminate use of inf_ttrace_vfork_ppid, report
TARGET_WAITKIND_VFORK_DONE event, delete HACK that switched the
inferior away from the parent.
* infrun.c (follow_fork): Call follow_fork_inferior instead of
target_follow_fork.
(follow_fork_inferior): New function.
(follow_inferior_reset_breakpoints): Make function static.
* infrun.h (follow_inferior_reset_breakpoints): Remove declaration.
* linux-nat.c (linux_child_follow_fork): Move target-independent
code to infrun.c:follow_fork_inferior.
Now that all instances of the regset_from_core_section gdbarch method
have been replaced by the new iterator method, delete the obsolete
method from the gdbarch interface. Adjust all invocations and
references to it.
gdb/ChangeLog:
* gdbarch.sh (regset_from_core_section): Remove gdbarch method.
* gdbarch.c: Regenerate.
* gdbarch.h: Likewise.
* corelow.c (sniff_core_bfd): Drop presence check for deleted
gdbarch method 'regset_from_core_section'.
(get_core_register_section): Remove handling for the case that
regset == NULL and regset_from_core_section is defined.
(get_core_registers): Drop check for deleted method.
* procfs.c (procfs_do_thread_registers): Adjust comment.
Now that all Linux targets use the regset iterator, the fall back to
the deprecated target method is dropped.
gdb/ChangeLog:
* linux-nat.c (linux_nat_collect_thread_registers): Remove.
(linux_nat_make_corefile_notes): Remove.
(linux_target_install_ops): Do not set target method
'make_corefile_notes'.
* linux-tdep.c (struct linux_corefile_thread_data)<collect>:
Remove field.
(linux_corefile_thread_callback): Instead of args->collect, call
linux_collect_thread_registers.
(linux_make_corefile_notes): Remove 'collect' parameter. Return
NULL unless there is a regset iterator.
(linux_make_corefile_notes_1): Remove.
(linux_init_abi): Replace reference to linux_make_corefile_notes_1
by linux_make_corefile_notes.
* linux-tdep.h (linux_make_corefile_notes): Remove prototype.
Now that all users of the target method 'fbsd_make_corefile_notes'
have been converted to the version in fbsd-tdep.c, the old method is
removed.
gdb/ChangeLog:
* fbsd-nat.c (find_signalled_thread, find_stop_signal)
(fbsd_collect_regset_section_cb, fbsd_make_corefile_notes):
Remove.
* fbsd-nat.h (fbsd_make_corefile_notes): Remove prototype.
For TILE-Gx GNU/Linux targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.
gdb/ChangeLog:
* tilegx-linux-tdep.c (TILEGX_LINUX_SIZEOF_GREGSET): New macro.
(tilegx_regset_from_core_section): Remove.
(tilegx_iterate_over_regset_sections): New.
(tilegx_linux_init_abi): Adjust gdbarch initialization.
For Super-H targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.
gdb/ChangeLog:
* sh-linux-tdep.c (sh_linux_init_abi): Set tdep fields
'sizeof_gregset' and 'sizeof_fpregset'.
* sh-tdep.c (sh_regset_from_core_section): Remove.
(sh_iterate_over_regset_sections): New.
(sh_gdbarch_init): Adjust gdbarch initialization.
* sh-tdep.h (struct gdbarch_tdep): New fields sizeof_gregset and
sizeof_fpregset.
* shnbsd-tdep.c (shnbsd_init_abi): Set tdep field
'sizeof_gregset'.
For Nios II GNU/Linux targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.
gdb/ChangeLog:
* nios2-linux-tdep.c (NIOS2_GREGS_SIZE): New macro.
(nios2_regset_from_core_section): Remove.
(nios2_iterate_over_regset_sections): New.
(nios2_linux_init_abi): Adjust gdbarch initialization.
Don't define the 'regset_from_core_section' method, but the iterator
method instead. Do this for GNU/Linux- as well as
Net/OpenBSD-targets. In the case of GNU/Linux this should enable
non-native use of the 'generate-core-file' command.
gdb/ChangeLog:
* alpha-linux-tdep.c (alpha_linux_regset_from_core_section): Remove.
(alpha_linux_iterate_over_regset_sections): New.
(alpha_linux_init_abi): Adjust gdbarch initialization.
* alphabsd-tdep.h (alphanbsd_regset_from_core_section): Remove
prototype.
(alphanbsd_iterate_over_regset_sections): New prototype.
* alphafbsd-tdep.c (alphafbsd_init_abi): Add comment for missing
fbsd_init_abi invocation.
* alphanbsd-tdep.c (alphanbsd_supply_gregset): Move below
alphanbsd_aout_supply_gregset. Invoke the latter for the
appropriate size.
(alphanbsd_aout_gregset): Remove.
(alphanbsd_regset_from_core_section): Remove.
(alphanbsd_iterate_over_regset_sections): New.
(alphanbsd_init_abi): Adjust gdbarch initialization.
* alphaobsd-tdep.c (alphaobsd_init_abi): Likewise.
Don't define the 'regset_from_core_section' method, but the iterator
method instead. This slightly reduces the code and enables non-native
use of the 'generate-core-file' command.
Also, when all instances of 'regset_from_core_section' are replaced,
it can be dropped from the gdbarch interface.
gdb/ChangeLog:
* aarch64-linux-tdep.c (aarch64_linux_regset_from_core_section):
Remove.
(aarch64_linux_iterate_over_regset_sections): New.
(aarch64_linux_init_abi): Adjust gdbarch initialization.
This creates a new version of the FreeBSD core file note generation
logic in the new target-dependent file "fbsd-tdep.c". The new version
is mostly copied from "fbsd-nat.c", but uses the iterator instead of
regset_from_core_section and defines fbsd_make_corefile_notes as a
gdbarch method instead of a target method.
Consecutive architecture-dependent changes exploit the new version,
migrating away from the target method. When all FreeBSD targets are
changed, the target method can go away.
gdb/ChangeLog:
* fbsd-tdep.c: New file.
* fbsd-tdep.h: New file.
* Makefile.in (ALL_TARGET_OBS): Add fbsd-tdep.o.
(HFILES_NO_SRCDIR): Add fbsd-tdep.h.
(ALLDEPFILES): Add fbsd-tdep.c.
This adds the 'regset' parameter to the iterator callback.
Consequently the 'regset_from_core_section' method is dropped for all
targets that provide the iterator method.
This change prepares for replacing regset_from_core_section
everywhere, thereby eliminating one gdbarch interface. Since the
iterator is usually no more complex than regset_from_core_section
alone, targets that previously didn't define core_regset_sections will
then gain multi-arch capable core file generation support without
increased complexity.
gdb/ChangeLog:
* gdbarch.sh (iterate_over_regset_sections_cb): Add regset
parameter.
* gdbarch.h: Regenerate.
* corelow.c (sniff_core_bfd): Don't sniff if gdbarch has a regset
iterator.
(get_core_register_section): Add parameter 'regset' and use it, if
set. Add parameter 'min_size' and verify the bfd section size
against it.
(get_core_registers_cb): Add parameter 'regset' and pass it to
get_core_register section. For the "standard" register sections
".reg" and ".reg2", set an appropriate default for human_name.
(get_core_registers): Don't abort when the gdbarch has an iterator
but no regset_from_core_section. Add NULL/0 for parameters
'regset'/'min_size' in calls to get_core_register_section.
* linux-tdep.c (linux_collect_regset_section_cb): Add parameter
'regset' and use it instead of calling the
regset_from_core_section gdbarch method.
* i386-tdep.h (struct gdbarch_tdep): Add field 'fpregset'.
* i386-tdep.c (i386_supply_xstateregset)
(i386_collect_xstateregset, i386_xstateregset): Moved to
i386-linux-tdep.c.
(i386_regset_from_core_section): Drop handling for .reg-xfp and
.reg-xstate.
(i386_gdbarch_init): Set tdep field 'fpregset'. Enable generic
core file support only if the regset iterator hasn't been set.
* i386-linux-tdep.c (i386_linux_supply_xstateregset)
(i386_linux_collect_xstateregset, i386_linux_xstateregset): New.
Moved from i386-tdep.c and renamed to *_linux*.
(i386_linux_iterate_over_regset_sections): Add regset parameter to
each callback invocation. Allow any .reg-xstate size when reading
from a core file.
* amd64-tdep.c (amd64_supply_xstateregset)
(amd64_collect_xstateregset, amd64_xstateregset): Moved to
amd64-linux-tdep.c.
(amd64_regset_from_core_section): Remove.
(amd64_init_abi): Set new tdep field 'fpregset'. No longer
install an amd64-specific regset_from_core_section gdbarch method.
* amd64-linux-tdep.c (amd64_linux_supply_xstateregset)
(amd64_linux_collect_xstateregset, amd64_linux_xstateregset): New.
Moved from amd64-tdep.c and renamed to *_linux*.
(amd64_linux_iterate_over_regset_sections): Add regset parameter
to each callback invocation. Allow any .reg-xstate size when
reading from a core file.
* arm-linux-tdep.c (arm_linux_regset_from_core_section): Remove.
(arm_linux_iterate_over_regset_sections): Add regset parameter to
each callback invocation.
(arm_linux_init_abi): No longer set the regset_from_core_section
gdbarch method.
* ppc-linux-tdep.c (ppc_linux_regset_from_core_section): Remove.
(ppc_linux_iterate_over_regset_sections): Add regset parameter to
each callback invocation.
(ppc_linux_init_abi): No longer set the regset_from_core_section
gdbarch method.
* s390-linux-tdep.c (struct gdbarch_tdep): Remove the fields
gregset, sizeof_gregset, fpregset, and sizeof_fpregset.
(s390_regset_from_core_section): Remove.
(s390_iterate_over_regset_sections): Add regset parameter to each
callback invocation.
(s390_gdbarch_init): No longer set the regset_from_core_section
gdbarch method. Drop initialization of deleted tdep fields.
The core_regset_sections list in gdbarch (needed for multi-arch
capable core file generation support) is replaced by an iterator
method. Overall, this reduces the code a bit, and it allows for more
flexibility.
gdb/ChangeLog:
* amd64-linux-tdep.c (amd64_linux_regset_sections): Remove.
(amd64_linux_iterate_over_regset_sections): New.
(amd64_linux_init_abi_common): Don't install the regset section
list, but the new iterator in gdbarch.
* arm-linux-tdep.c (arm_linux_fpa_regset_sections)
(arm_linux_vfp_regset_sections): Remove. Move combined logic...
(arm_linux_iterate_over_regset_sections): ...here. New function.
(arm_linux_init_abi): Set iterator instead of section list.
* corelow.c (get_core_registers_cb): New function, logic moved
from...
(get_core_registers): ...loop body here. Use new iterator method
instead of walking through the regset section list.
* gdbarch.sh: Remove 'core_regset_sections'. New method
'iterate_over_regset_sections'. New typedef
'iterate_over_regset_sections_cb'.
* gdbarch.c: Regenerate.
* gdbarch.h: Likewise.
* i386-linux-tdep.c (i386_linux_regset_sections)
(i386_linux_sse_regset_sections, i386_linux_avx_regset_sections):
Remove.
(i386_linux_iterate_over_regset_sections): New.
(i386_linux_init_abi): Don't choose a regset section list, but
install new iterator in gdbarch.
* linux-tdep.c (struct linux_collect_regset_section_cb_data): New.
(linux_collect_regset_section_cb): New function, logic moved
from...
(linux_collect_thread_registers): ...loop body here. Use iterator
method instead of walking through list.
(linux_make_corefile_notes_1): Check for presence of iterator
method instead of regset section list.
* ppc-linux-tdep.c (ppc_linux_vsx_regset_sections)
(ppc_linux_vmx_regset_sections, ppc_linux_fp_regset_sections)
(ppc64_linux_vsx_regset_sections, ppc64_linux_vmx_regset_sections)
(ppc64_linux_fp_regset_sections): Remove. Move combined logic...
(ppc_linux_iterate_over_regset_sections): ...here. New function.
(ppc_linux_init_abi): Don't choose from above regset section
lists, but install new iterator in gdbarch.
* regset.h (struct core_regset_section): Remove.
* s390-linux-tdep.c (struct gdbarch_tdep): Add new fields
have_linux_v1, have_linux_v2, and have_tdb.
(s390_linux32_regset_sections, s390_linux32v1_regset_sections)
(s390_linux32v2_regset_sections, s390_linux64_regset_sections)
(s390_linux64v1_regset_sections, s390_linux64v2_regset_sections)
(s390x_linux64_regset_sections, s390x_linux64v1_regset_sections)
(s390x_linux64v2_regset_sections): Remove. Move combined logic...
(s390_iterate_over_regset_sections): ...here. New function. Use
new tdep fields.
(s390_gdbarch_init): Set new tdep fields. Don't choose from above
regset section lists, but install new iterator.
commit 2268b414f4
added file "features/library-list-svr4.dtd" but the added code uses
"library-list.dtd" instead.
Curiously after changing for a test s/name/nXme/ in the DTD making the
gdbserver output non-conforming there is no warning or regression seen (tested
gdb.base/shlib-call.exp, using_xfer is still 1). I did not check more why the
DTD conformance verification does not work.
gdb/ChangeLog
2014-09-29 Jan Kratochvil <jan.kratochvil@redhat.com>
* solib-svr4.c (svr4_parse_libraries): Use "library-list-svr4.dtd".
Remove the pruning of program spaces in print_program_space to remove
unwanted side-effects. "info" commands and print routines should
generally not change the state of the debugger.
gdb/Changelog:
* progspace.c (print_program_space): Don't prune program spaces
before printing them.
What matters for this function, is whether the user requested a
"step", for "set scheduler-locking step", not whether GDB is doing an
internal step for some reason.
/* Return a ptid representing the set of threads that we will proceed,
in the perspective of the user/frontend. */
extern ptid_t user_visible_resume_ptid (int step);
Therefore, the check for singlestep_breakpoints_inserted_p is actually
incorrect, and we end up applying schedlock more often on sss targets
than on non-sss targets.
Found by inspection while working on a patch that eliminates the
singlestep_breakpoints_inserted_p global.
Tested on x86_64 Fedora 20 on top of my 'software single-step on x86'
series.
gdb/
2014-09-25 Pedro Alves <palves@redhat.com>
* infrun.c (user_visible_resume_ptid): Don't check
singlestep_breakpoints_inserted_p.
gdb/
2014-09-25 Pedro Alves <palves@redhat.com>
* infrun.c (stepping_past_instruction_at)
(clear_exit_convenience_vars): Point at infrun.h instead of
inferior.h.
(handle_signal_stop): Fix typo.
This patch fixes a typo in the bit mask I've made in my previous code
refactor. If PC is in the register list, the bit 8 is one, so bit
mask 0xff00 should be used. Current condition is a constant false.
gdb:
2014-09-24 Yao Qi <yao@codesourcery.com>
* arm-tdep.c (thumb_in_function_epilogue_p): Fix typo in the
bitmask.
This commit renames target_stop_ptid as target_stop_and_wait and
target_continue_ptid as target_continue_no_signal. Comments are
updated to more fully describe the functions' behaviour.
gdb/ChangeLog:
* target/target.h (target_stop_ptid): Renamed as...
(target_stop_and_wait): New function. Updated comment.
All uses updated.
(target_continue_ptid): Renamed as...
(target_continue_no_signal): New function. Updated comment.
All uses updated.
By default, GDB removes all breakpoints from the target when the
target stops and the prompt is given back to the user. This is useful
in case GDB crashes while the user is interacting, as otherwise,
there's a higher chance breakpoints would be left planted on the
target.
But, as long as any thread is running free, we need to make sure to
keep breakpoints inserted, lest a thread misses a breakpoint. With
that in mind, in preparation for non-stop mode, we added a "breakpoint
always-inserted on" mode. This traded off the extra crash protection
for never having threads miss breakpoints, and in addition is more
efficient if there's a ton of breakpoints to remove/insert at each
user command (e.g., at each "step").
When we added non-stop mode, and for a period, we required users to
manually set "always-inserted on" when they enabled non-stop mode, as
otherwise GDB removes all breakpoints from the target as soon as any
thread stops, which means the other threads still running will miss
breakpoints. The test added by this patch exercises this.
That soon revealed a nuisance, and so later we added an extra
"breakpoint always-inserted auto" mode, that made GDB behave like
"always-inserted on" when non-stop was enabled, and "always-inserted
off" when non-stop was disabled. "auto" was made the default at the
same time.
In hindsight, this "auto" setting was unnecessary, and not the ideal
solution. Non-stop mode does depends on breakpoints always-inserted
mode, but only as long as any thread is running. If no thread is
running, no breakpoint can be missed. The same is true for all-stop
too. E.g., if, in all-stop mode, and the user does:
(gdb) c&
(gdb) b foo
That breakpoint at "foo" should be inserted immediately, but it
currently isn't -- currently it'll end up inserted only if the target
happens to trip on some event, and is re-resumed, e.g., an internal
breakpoint triggers that doesn't cause a user-visible stop, and so we
end up in keep_going calling insert_breakpoints. The test added by
this patch also covers this.
IOW, no matter whether in non-stop or all-stop, if the target fully
stops, we can remove breakpoints. And no matter whether in all-stop
or non-stop, if any thread is running in the target, then we need
breakpoints to be immediately inserted. And then, if the target has
global breakpoints, we need to keep breakpoints even when the target
is stopped.
So with that in mind, and aiming at reducing all-stop vs non-stop
differences for all-stop-on-stop-of-non-stop, this patch fixes
"breakpoint always-inserted off" to not remove breakpoints from the
target until it fully stops, and then removes the "auto" setting as
unnecessary. I propose removing it straight away rather than keeping
it as an alias, unless someone complains they have scripts that need
it and that can't adjust.
Tested on x86_64 Fedora 20.
gdb/
2014-09-22 Pedro Alves <palves@redhat.com>
* NEWS: Mention merge of "breakpoint always-inserted" modes "off"
and "auto" merged.
* breakpoint.c (enum ugll_insert_mode): New enum.
(always_inserted_mode): Now a plain boolean.
(show_always_inserted_mode): No longer handle AUTO_BOOLEAN_AUTO.
(breakpoints_always_inserted_mode): Delete.
(breakpoints_should_be_inserted_now): New function.
(insert_breakpoints): Pass UGLL_INSERT to
update_global_location_list instead of calling
insert_breakpoint_locations manually.
(create_solib_event_breakpoint_1): New, factored out from ...
(create_solib_event_breakpoint): ... this.
(create_and_insert_solib_event_breakpoint): Use
create_solib_event_breakpoint_1 instead of calling
insert_breakpoint_locations manually.
(update_global_location_list): Change parameter type from boolean
to enum ugll_insert_mode. All callers adjusted. Adjust to use
breakpoints_should_be_inserted_now and handle UGLL_INSERT.
(update_global_location_list_nothrow): Change parameter type from
boolean to enum ugll_insert_mode.
(_initialize_breakpoint): "breakpoint always-inserted" option is
now a boolean command. Update help text.
* breakpoint.h (breakpoints_always_inserted_mode): Delete declaration.
(breakpoints_should_be_inserted_now): New declaration.
* infrun.c (handle_inferior_event) <TARGET_WAITKIND_LOADED>:
Remove breakpoints_always_inserted_mode check.
(normal_stop): Adjust to use breakpoints_should_be_inserted_now.
* remote.c (remote_start_remote): Likewise.
gdb/doc/
2014-09-22 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Set Breaks): Document that "set breakpoint
always-inserted off" is the default mode now. Delete
documentation of "set breakpoint always-inserted auto".
gdb/testsuite/
2014-09-22 Pedro Alves <palves@redhat.com>
* gdb.threads/break-while-running.exp: New file.
* gdb.threads/break-while-running.c: New file.
This adds a new mode for update_global_location_list, that allows
callers saying "please insert breakpoints, even if
breakpoints_always_inserted_mode() is false". This allows removing a
couple breakpoints_always_inserted_mode checks.
gdb/
2014-09-22 Pedro Alves <palves@redhat.com>
* breakpoint.c (enum ugll_insert_mode): Add UGLL_INSERT.
(insert_breakpoints): Don't call insert_breakpoint_locations here.
Instead, pass UGLL_INSERT to update_global_location_list.
(update_global_location_list): Change parameter type from boolean
to enum ugll_insert_mode. All callers adjusted. Adjust to use
breakpoints_should_be_inserted_now and handle UGLL_INSERT.
(create_solib_event_breakpoint_1): New, factored out from ...
(create_solib_event_breakpoint): ... this.
(create_and_insert_solib_event_breakpoint): Use
create_solib_event_breakpoint_1 instead of calling
insert_breakpoint_locations manually.
(update_global_location_list): Handle UGLL_INSERT.
Later we'll want a tristate, but for now, convert to an enum that maps 1-1
with the current boolean's true/false.
gdb/
2014-09-22 Pedro Alves <palves@redhat.com>
* breakpoint.c (enum ugll_insert_mode): New enum.
(update_global_location_list)
(update_global_location_list_nothrow): Change parameter type from
boolean to enum ugll_insert_mode. All callers adjusted.
This commit implements functions for identifying and extracting extended
ptrace event information from a Linux wait status. These are just
convenience functions intended to hide the ">> 16" used to extract the
event from the wait status word, replacing the hard-coded shift with a more
descriptive function call. This is preparatory work for implementation of
follow-fork and detach-on-fork for extended-remote linux targets.
gdb/ChangeLog:
* linux-nat.c (linux_handle_extended_wait): Call
linux_ptrace_get_extended_event.
(wait_lwp): Call linux_is_extended_waitstatus.
(linux_nat_filter_event): Call linux_ptrace_get_extended_event
and linux_is_extended_waitstatus.
* nat/linux-ptrace.c (linux_test_for_tracefork): Call
linux_ptrace_get_extended_event.
(linux_ptrace_get_extended_event): New function.
(linux_is_extended_waitstatus): New function.
* nat/linux-ptrace.h (linux_ptrace_get_extended_event)
(linux_is_extended_waitstatus): New declarations.
gdb/gdbserver/ChangeLog:
* linux-low.c (handle_extended_wait): Call
linux_ptrace_get_extended_event.
(get_stop_pc, get_detach_signal, linux_low_filter_event): Call
linux_is_extended_waitstatus.
---
I see the following fail on arm-none-eabi target,
(gdb) b 24^M
Breakpoint 1 at 0x4: file
../../../../git/gdb/testsuite/gdb.base/break-on-linker-gcd-function.cc,
line 24.^M
(gdb) FAIL: gdb.base/break-on-linker-gcd-function.exp: b 24
Currently, we are using flag has_section_at_zero to determine whether
address zero in debug info means the corresponding code has been
GC'ed, like this:
case DW_LNE_set_address:
address = read_address (abfd, line_ptr, cu, &bytes_read);
if (address == 0 && !dwarf2_per_objfile->has_section_at_zero)
{
/* This line table is for a function which has been
GCd by the linker. Ignore it. PR gdb/12528 */
However, this is incorrect on some bare metal targets, as .text
section is located at 0x0, so dwarf2_per_objfile->has_section_at_zero
is true. If a function is GC'ed by linker, the address is zero. GDB
thinks address zero is a function's address rather than this function
is GC'ed.
In this patch, we choose 'lowpc' got in read_file_scope to check
whether 'lowpc' is greater than zero. If it isn't, address zero really
means the function is GC'ed. In this patch, we pass 'lowpc' in
read_file_scope through handle_DW_AT_stmt_list and dwarf_decode_lines,
and to dwarf_decode_lines_1 finally.
This patch fixes the fail above. This patch also covers the path that
partial symbol isn't used, which is tested by starting gdb with
--readnow option.
It is regression tested on x86-linux with
target_board=dwarf4-gdb-index, and arm-none-eabi. OK to apply?
gdb:
2014-09-19 Yao Qi <yao@codesourcery.com>
* dwarf2read.c (dwarf_decode_lines): Update declaration.
(handle_DW_AT_stmt_list): Add argument 'lowpc'. Update
comments. Callers update.
(dwarf_decode_lines): Likewise.
(dwarf_decode_lines_1): Add argument 'lowpc'. Update
comments. Skip the line table if 'lowpc' is greater than
'address'. Don't check
dwarf2_per_objfile->has_section_at_zero.
gdb/testsuite:
2014-09-19 Yao Qi <yao@codesourcery.com>
* gdb.base/break-on-linker-gcd-function.exp: Move test into new
proc set_breakpoint_on_gcd_function. Invoke
set_breakpoint_on_gcd_function. Restart GDB with --readnow and
invoke set_breakpoint_on_gcd_function again.
If accessing memory via safe_read_memory_integer fails, that function
used to print an error message even though callers were perfectly able
to handle (and even expected!) failures.
This patch removes the confusing message by changing the routine to
directly use target_read_memory.
gdb/ChangeLog:
PR gdb/17384
* corefile.c (struct captured_read_memory_integer_arguments): Remove.
(do_captured_read_memory_integer): Remove.
(safe_read_memory_integer): Use target_read_memory directly instead
of catching errors in do_captured_read_memory_integer.
This obvious change removes dead code from objc-lang.c. I was
grepping for "fprintf (stderr..." and found this code between "#if
0".."#endif" blocks.
2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
* objc-lang.c (find_implementation_from_class): Remove dead code.
This is an obvious replacement of "fprintf (stderr..." by
"fprintf_unfiltered (gdb_stdlog...", which is the standard to use in
these cases.
gdb/ChangeLog:
2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
PR cli/7233
* linux-nat.c (linux_nat_wait_1): Replace "fprintf (stderr..." by
"fprintf_unfiltered (gdb_stdlog...)".
PR 12526 reports that -location watchpoints against bitfield arguments
trigger false positives when bits around the bitfield, but not the
bitfield itself, are modified.
This happens because -location watchpoints naturally operate at the
byte level, not at the bit level. When the address of a bitfield
lvalue is taken, information about the bitfield (i.e. its offset and
size) is lost in the process.
This information must first be retained throughout the lifetime of the
-location watchpoint. This patch achieves this by adding two new
fields to the watchpoint struct: val_bitpos and val_bitsize. These
fields are set when a watchpoint is first defined in watch_command_1.
They are both equal to zero if the watchpoint is not a -location
watchpoint or if the argument is not a bitfield.
Then these bitfield parameters are used inside update_watchpoint and
watchpoint_check to extract the actual value of the bitfield from the
watchpoint address, with the help of a local helper function
extract_bitfield_from_watchpoint_value.
Finally when creating a HW breakpoint pointing to a bitfield, we
optimize the address and length of the breakpoint. By skipping over
the bytes that don't cover the bitfield, this step reduces the
frequency at which a read watchpoint for the bitfield is triggered.
It also reduces the number of times a false-positive call to
check_watchpoint is triggered for a write watchpoint.
gdb/
PR breakpoints/12526
* breakpoint.h (struct watchpoint): New fields val_bitpos and
val_bitsize.
* breakpoint.c (watch_command_1): Use these fields to retain
bitfield information.
(extract_bitfield_from_watchpoint_value): New function.
(watchpoint_check): Use it.
(update_watchpoint): Use it. Optimize the address and length of a
HW watchpoint pointing to a bitfield.
* value.h (unpack_value_bitfield): New prototype.
* value.c (unpack_value_bitfield): Make extern.
gdb/testsuite/
PR breakpoints/12526
* gdb.base/watch-bitfields.exp: New file.
* gdb.base/watch-bitfields.c: New file.
gdb:
2014-08-13 Omair Javaid <omair.javaid@linaro.org>
* arm-tdep.c (arm_record_vdata_transfer_insn): Added record handler for
vector data transfer instructions.
(arm_record_coproc_data_proc): Updated.
gdb:
2014-08-13 Omair Javaid <omair.javaid@linaro.org>
* arm-tdep.c (arm_record_coproc_data_proc): Add record handler stubs
for asimd, vfp and coprocessor insns.
(arm_record_asimd_vfp_coproc): Add record handler for asimd, vfp
and coprocessor insns.
(thumb2_record_coproc_insn): New function.
(thumb2_record_decode_insn_handler): Update coprocessor insns record
handlers.
(decode_insn): Install arm_record_asimd_vfp_coproc as handler for
opcode 110 insns.
If I want to change the signalled state of multiple threads
it's a bit cumbersome to do with the "signal" command.
What you really want is a way to set the signal state of the
desired threads and then just do "continue".
This patch adds a new command, queue-signal, to accomplish this.
Basically "signal N" == "queue-signal N" + "continue".
That's not precisely true in that "signal" can be used to inject
any signal, including signals set to "nopass"; whereas "queue-signal"
just queues the signal as if the thread stopped because of it.
"nopass" handling is done when the thread is resumed which
"queue-signal" doesn't do.
One could add extra complexity to allow queue-signal to be used to
deliver "nopass" signals like the "signal" command. I have no current
need for it so in the interests of incremental complexity, I have
left such support out and just have the code flag an error if one
tries to queue a nopass signal.
gdb/ChangeLog:
* NEWS: Mention new "queue-signal" command.
* infcmd.c (queue_signal_command): New function.
(_initialize_infcmd): Add new queue-signal command.
gdb/doc/ChangeLog:
* gdb.texinfo (Signaling): Document new queue-signal command.
gdb/testsuite/ChangeLog:
* gdb.threads/queue-signal.c: New file.
* gdb.threads/queue-signal.exp: New file.
Ulrich Weigand
Jan Kratochvil
Martin Galvan
Siva Chandra
Yao Qi
Pierre Muller
Joel Brobecker
Mark Wielaard
Sandra Loosemore
Samuel Thibault
Doug Evans
Patrick Palka
Doug Evans
Sergio Durigan Junior
Pedro Alves
Daniel Colascione
Alan Modra
Simon Marchi
Luis Machado
Don Breazeal
Tristan Gingold
Iain Buclaw
Andreas Arnez
Ajit Kumar Agarwal
Ajit Kumar Agarwal
Stan Shebs
Gary Benson
Maciej W. Rozycki
Pierre Muller
Omair Javaid