gdb_interact is a small utility that we have found quite useful to debug
test cases.
Putting gdb_interact in a test suspends it and allows to interact with
gdb to inspect whatever you want. You can then type ">>>" to resume the
test execution. Of course, this is only for gdb devs. It wouldn't make
sense to leave a gdb_interact permanently in a test case.
When starting the interaction with the user, the script prints this
banner:
+------------------------------------------+
| Script interrupted, you can now interact |
| with by gdb. Type >>> to continue. |
+------------------------------------------+
Notes:
* When gdb is launched, the gdb_spawn_id variable (lib/gdb.exp) is
assigned -1. Given the name, I would expect it to contain the gdb
expect spawn id, which is needed for interact. I changed all places
that set gdb_spawn_id to -1 to set it to the actual gdb spawn id
instead.
* When entering the "interact" mode, the last (gdb) prompt is already
eaten by expect, so it doesn't show up on the terminal. Subsequent
prompts do appear though. We tried to print "(gdb)" just before the
interact to replace it. However, it could be misleading if you are
debugging an MI test case, it makes you think that you are typing in a
CLI prompt, when in reality it's MI. In the end I decided that since
the feature is for developers who know what they're doing and that one
is normally consciously using gdb_interact, the script doesn't need
to babysit the user.
* There are probably some quirks depending on where in the script
gdb_interact appears (e.g. it could interfere with following
commands and make them fail), but it works for most cases. Quirks can
always be fixed later.
The idea and original implementation was contributed by Anders
Granlund, a colleague of mine. Thanks to him.
gdb/testsuite/ChangeLog:
* gdb.base/statistics.exp: Assign spawn id to gdb_spawn_id.
* gdb.base/valgrind-db-attach.exp: Same.
* gdb.base/valgrind-infcall.exp: Same.
* lib/mi-support.exp (default_mi_gdb_start): Same.
* lib/prompt.exp (default_prompt_gdb_start): Same.
* lib/gdb.exp (default_gdb_spawn): Same.
(gdb_interact): New.
downstream Fedora request:
Please make it easier to find the backtrace of the crashing thread
https://bugzilla.redhat.com/show_bug.cgi?id=1024504
Currently after loading a core file GDB prints:
Core was generated by `./threadcrash1'.
Program terminated with signal SIGSEGV, Segmentation fault.
8 *(volatile int *)0=0;
(gdb) _
there is nowhere seen which of the threads had crashed. In reality GDB always
numbers that thread as #1 and it is the current thread that time. But after
dumping all the info into a file for later analysis it is no longer obvious.
'thread apply all bt' even puts the thread #1 to the _end_ of the output!!!
I find maybe as good enough and with no risk of UI change flamewar to just
sort the threads by their number. Currently they are printed as they happen
in the internal GDB list which has no advantage. Printing thread #1 as the
first one with assumed 'thread apply all bt' (after the core file is loaded)
should make the complaint resolved I guess.
On Thu, 15 Jan 2015 20:29:07 +0100, Doug Evans wrote:
No objection to sorting the list, but if thread #1 is the important one,
then a concern could be it'll have scrolled off the screen (such a
concern has been voiced in another thread in another context),
and if not lost (say it's in an emacs buffer) one would still have
to scroll back to see it.
So one *could* still want #1 to be last.
Do we want an option to choose the sort direction?
gdb/ChangeLog
2015-01-22 Jan Kratochvil <jan.kratochvil@redhat.com>
* NEWS (Changes since GDB 7.9): Add 'thread apply all' option
'-ascending'.
* thread.c (tp_array_compar_ascending, tp_array_compar): New.
(thread_apply_all_command): Parse CMD for tp_array_compar_ascending.
Sort tp_array using tp_array_compar.
(_initialize_thread): Extend thread_apply_all_command help.
gdb/doc/ChangeLog
2015-01-22 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.texinfo (Threads): Describe -ascending for thread apply all.
downstream Fedora request:
Please make it easier to find the backtrace of the crashing thread
https://bugzilla.redhat.com/show_bug.cgi?id=1024504
Currently after loading a core file GDB prints:
Core was generated by `./threadcrash1'.
Program terminated with signal SIGSEGV, Segmentation fault.
8 *(volatile int *)0=0;
(gdb) _
there is nowhere seen which of the threads had crashed. In reality GDB always
numbers that thread as #1 and it is the current thread that time. But after
dumping all the info into a file for later analysis it is no longer obvious.
'thread apply all bt' even puts the thread #1 to the _end_ of the output!!!
Should GDB always print after loading a core file what "thread" command would
print?
[Current thread is 1 (Thread 0x7fcbe28fe700 (LWP 15453))]
BTW I think it will print the thread even when loading single/non-threaded
core file when other inferior(s) exist. But that currently crashes
[Bug threads/12074] multi-inferior internal error
https://sourceware.org/bugzilla/show_bug.cgi?id=12074
plus I think that would be a correct behavior anyway.
gdb/ChangeLog
2015-01-22 Jan Kratochvil <jan.kratochvil@redhat.com>
* corelow.c (core_open): Call also thread_command.
* gdbthread.h (thread_command): New prototype moved from ...
* thread.c (thread_command): ... here.
(thread_command): Make it global.
When GDB is configured with "--without-tui --with-curses" or "--with-tui",
$prefer_curses is set to yes. But, that still doesn't mean that curses
will be used. configure will still search for the curses library, and
continue building without it. That's done here:
curses_found=no
if test x"$prefer_curses" = xyes; then
...
AC_SEARCH_LIBS(waddstr, [ncurses cursesX curses])
if test "$ac_cv_search_waddstr" != no; then
curses_found=yes
fi
fi
So if waddstr is not found, meaning curses is not really
available, even though it'd be preferred, $prefer_curses is
'yes', but $curses_found is 'no'.
So the right fix to tell whether we're linking with curses is
$curses_found=yes.
gdb/ChangeLog:
2015-01-22 Pedro Alves <palves@redhat.com>
* configure.ac [*mingw32*]: Check $curses_found instead of
$prefer_curses.
* configure: Regenerate.
* windows-termcap.c: Remove HAVE_CURSES_H, HAVE_NCURSES_H and
HAVE_NCURSES_NCURSES_H checks.
gdb/
2015-01-22 Eli Zaretskii <eliz@gnu.org>
* gdb/tui/tui.c (tui_enable) [__MINGW32__]: If the call to 'newterm'
fails with the 1st arg NULL, try again with "unknown". Don't test
the "cup" capability: it isn't supported by the Windows port of
ncurses, but the Windows console driver is still capable of
supporting TUI.
TBH while I always comment reasons for each of the compilation options in
reality I tried them all and chose that combination that needs the most simple
compile/compile-object-load.c (ld.so emulation) implementation.
gdb/ChangeLog
2015-01-22 Jan Kratochvil <jan.kratochvil@redhat.com>
* compile/compile.c (_initialize_compile): Use -fPIE for compile_args.
gdb/testsuite/ChangeLog
2015-01-22 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile.exp (pointer to jit function): New test.
gdb/
2015-01-22 Eli Zaretskii <eliz@gnu.org>
* Makefile.in (HFILES_NO_SRCDIR): Remove ada-varobj.h.
(ALLDEPFILES): Remove irix5-nat.c. These two are part of the
reason that "make TAGS" is broken.
Original working flow has several issues:
- typo issue: "(inst >> 26) == 0x1f && ..." for checking 'stw(m)'.
- "(inst >> 6) == 0xa" needs to be "((inst >> 6) & 0xf) == 0xa".
And also need check additional store instructions:
- For absolute memory: 'stby', 'stdby'.
- For unaligned: 'stwa', 'stda'.
The original code also can be improved:
- Remove redundant double check "(inst >> 26) == 0x1b" for 'stwm'.
- Use 2 'switch' statements instead of all 'if' statements.
* hppa-tdep.c (inst_saves_gr): Fix logical working flow issues
and check additional store instructions.
gdb/
2015-01-17 Eli Zaretskii <eliz@gnu.org>
* configure.ac [*mingw32*]: Only add windows-termcap.o to
CONFIG_OBS if not building with a curses library.
* configure: Regenerate.
* windows-termcap.c: Include defs.h. Make the whole body empty if
either one of HAVE_CURSES_H or HAVE_NCURSES_H or
HAVE_NCURSES_NCURSES_H is defined.
This commit fixes the regression on RHEL-5 systems introduced by
nat/linux-personality.c's check of HAVE_DECL_ADDR_NO_RANDOMIZE.
RHEL-5 systems define HAVE_DECL_ADDR_NO_RANDOMIZE as zero, so we
cannot use #ifndef; instead this patch uses the "#if !" construction.
The regression was reported by Ulrich Weigand here:
<https://sourceware.org/ml/gdb-patches/2015-01/msg00458.html>
gdb/ChangeLog
2015-01-16 Sergio Durigan Junior <sergiodj@redhat.com>
* nat/linux-personality.c: Replace "#ifndef
HAVE_DECL_ADDR_NO_RANDOMIZE" by "#if
!HAVE_DECL_ADDR_NO_RANDOMIZE", fixing a regression in RHEL-5
systems.
gdb/
2015-01-16 Eli Zaretskii <eliz@gnu.org>
* tui/tui-win.c (tui_rehighlight_all, tui_set_var_cmd): New
functions.
(_initialize_tui_win) <border-kind, border-mode>:
<active-border-mode>: Use tui_set_var_cmd as the "set" function.
* tui/tui-win.h: Add prototype for tui_rehighlight_all.
gdb/ChangeLog:
2015-01-16 Eli Zaretskii <eliz@gnu.org>
* tui/tui-win.c (tui_set_tab_width_command): Delete and
recreate the source and the disassembly windows, to show the
effect of the changed tab size immediately.
tui/tui-win.c (tui_scroll_left_command, tui_scroll_right_command):
Doc fix.
doc/gdb.texinfo (TUI Commands): Document the possible
values of NAME argument to 'winheight' command. Explain the
effect of 'tabset' setting better.
gdb/tui/tui-data.h (LINE_PREFIX): Make shorter
(MAX_PID_WIDTH): Enlarge from 14 to 19, to leave enough space for
"Thread NNNNN.XXXX" thread ID notation on Windows.
With gcc-5.0 pre-release one gets:
hppa-tdep.c: In function ‘inst_saves_gr’:
hppa-tdep.c:1406:30: error: comparison of constant ‘9’ with boolean expression is always false [-Werror=bool-compare]
I find the misplaced parentheses obvious.
gdb/ChangeLog
2015-01-16 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix gcc-5 compilation.
* hppa-tdep.c (inst_saves_gr): Fix parentheses typo.
This patch moves the shared code present on
gdb/linux-nat.c:linux_nat_create_inferior and
gdb/gdbserver/linux-low.c:linux_create_inferior to
nat/linux-personality.c. This code is responsible for disabling
address space randomization based on user setting, and using
<sys/personality.h> to do that. I decided to put the prototype of the
maybe_disable_address_space_randomization on nat/linux-osdata.h
because it seemed the best place to put it.
I regression-tested this patch on Fedora 20 x86_64, and found no
regressions.
gdb/ChangeLog
2015-01-15 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (HFILES_NO_SRCDIR): Add nat/linux-personality.h.
(linux-personality.o): New rule.
* common/common-defs.h: Include <stdint.h>.
* config/aarch64/linux.mh (NATDEPFILES): Include
linux-personality.o.
* config/alpha/alpha-linux.mh (NATDEPFILES): Likewise.
* config/arm/linux.mh (NATDEPFILES): Likewise.
* config/i386/linux64.mh (NATDEPFILES): Likewise.
* config/i386/linux.mh (NATDEPFILES): Likewise.
* config/ia64/linux.mh (NATDEPFILES): Likewise.
* config/m32r/linux.mh (NATDEPFILES): Likewise.
* config/m68k/linux.mh (NATDEPFILES): Likewise.
* config/mips/linux.mh (NATDEPFILES): Likewise.
* config/pa/linux.mh (NATDEPFILES): Likewise.
* config/powerpc/linux.mh (NATDEPFILES): Likewise.
* config/powerpc/ppc64-linux.mh (NATDEPFILES): Likewise.
* config/powerpc/spu-linux.mh (NATDEPFILES): Likewise.
* config/s390/linux.mh (NATDEPFILES): Likewise.
* config/sparc/linux64.mh (NATDEPFILES): Likewise.
* config/sparc/linux.mh (NATDEPFILES): Likewise.
* config/tilegx/linux.mh (NATDEPFILES): Likewise.
* config/xtensa/linux.mh (NATDEPFILES): Likewise.
* defs.h: Remove #include <stdint.h> (moved to
common/common-defs.h).
* linux-nat.c: Include nat/linux-personality.h. Remove #include
<sys/personality.h>; do not define ADDR_NO_RANDOMIZE (moved to
nat/linux-personality.c).
(linux_nat_create_inferior): Remove code to disable address space
randomization (moved to nat/linux-personality.c). Create cleanup
to disable address space randomization.
* nat/linux-personality.c: New file.
* nat/linux-personality.h: Likewise.
gdb/gdbserver/ChangeLog
2015-01-15 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (SFILES): Add linux-personality.c.
(linux-personality.o): New rule.
* configure.srv (srv_linux_obj): Add linux-personality.o to the
list of objects to be built.
* linux-low.c: Include nat/linux-personality.h.
(linux_create_inferior): Remove code to disable address space
randomization (moved to ../nat/linux-personality.c). Create
cleanup to disable address space randomization.
This patch moves safe_strerror from the gdb/{posix,mingw}-hdep.c files
to the respective common/{posix,mingw}-strerror.c files. This is a
preparation for the next patch, which shares a common code (to disable
address space randomization when creating a new inferior).
The patch has been regtested on Fedora 20 x86_64, and no regressions
were found.
gdb/ChangeLog
2015-01-15 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (ALLDEPFILES): Including common/mingw-strerror.c and
common/posix-strerror.c.
(posix-strerror.o): New rule.
(mingw-strerror.o): Likewise.
* common/common-utils.h (safe_strerror): Move prototype to here,
from utils.h.
* common/common.host: New file.
* common/mingw-strerror.c: Likewise.
* common/posix-strerror.c: Likewise.
* configure: Regenerated.
* configure.ac: Source common/common.host. Add variable
common_host_obs to gdb_host_obs.
* contrib/ari/gdb_ari.sh: Mention gdb/common/mingw-strerror.c and
gdb/common/posix-strerror.c when warning about the use of
strerror.
* mingw-hdep.c (safe_strerror): Remove definition; move it to
common/mingw-strerror.c.
* posix-hdep.c (safe_strerror): Remove definition; move it to
common/posix-hdep.c.
* utils.h (safe_strerror): Remove prototype; move to
common/common-utils.h.
gdb/gdbserver/ChangeLog
2015-01-15 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (posix-strerror.o): New rule.
(mingw-strerror.o): Likewise.
* configure: Regenerated.
* configure.ac: Source file ../common/common.host. Initialize new
variable srv_host_obs. Add srv_host_obs to GDBSERVER_DEPFILES.
This patch updates two attach tests to use utility procs for checking if
the attach test should run and for launching the program to be attached, as
follows:
1) Use can_spawn_for_attach instead of is_remote target
2) Use spawn_wait_for_attach instead of exec/sleep
Tested (1) with i686-mingw32 host and i686-pc-linux-gnu build/target and
both with x86_64 Ubuntu.
gdb/testsuite/ChangeLog:
* gdb.base/attach-pie-noexec.exp: Use can_spawn_for_attach
instead of checking whether the target board is remote and
use spawn_wait_for_attach instead of exec/sleep.
* gdb.base/attach-twice.exp: Likewise.
Consider the following code:
type Table is array (Positive range <>) of Integer;
type Object (N : Integer) is record
Data : Table (1 .. N);
end record;
My_Object : Object := (N => 3, Data => (3, 5, 8));
Trying to print the range and length of the My_Object.Data array yields:
(gdb) print my_object.data'first
$1 = 1
(gdb) print my_object.data'last
$2 = 0
(gdb) print my_object.data'length
$3 = 0
The first one is correct, and that is thanks to the fact that
the lower bound is statically known. However, for the upper
bound, and consequently the array's length, the values are incorrect.
It should be:
(gdb) print my_object.data'last
$2 = 3
(gdb) print my_object.data'length
$3 = 3
What happens here is that ada_array_bound_from_type sees that
our array has a parallel "___XA" type, and therefore tries to
use it. In particular, it described our array's index type as:
[...]___XDLU_1__n, which means lower bound = 1, and upper bound
is value of "n". Unfortunately, ada_array_bound_from_type does
not have access to the discriminant, and is therefore unable to
compute the bound correctly.
Fortunately, at this stage, the bound has already been computed
a while ago, and therefore doesn't need to be re-computed here.
This patch fixes the issue by ignoring that ___XA type if the array
is marked as already fixed.
This also fixes the same issue with packed arrays.
gdb/ChangeLog:
* ada-lang.c (ada_array_bound_from_type): Ignore array's parallel
___XA type if the array has already been fixed.
gdb/testsuite/ChangeLog:
* gdb.ada/var_arr_attrs: New testcase.
This patch is to teach both GDB and GDBServer to detect 64-bit inferior
correctly. We find a problem that GDBServer is unable to detect on a
e5500 core processor. Current GDBServer assumes that MSR is a 64-bit
register, but MSR is a 32-bit register in Book III-E. This patch is
to fix this problem by checking the right bit in MSR, in order to handle
both Book III-S and Book III-E. In order to detect Book III-S and
Book III-E, we check the PPC_FEATURE_BOOKE from the host's HWCAP (by
getauxval on glibc >= 2.16. If getauxval doesn't exist, we implement
the fallback by parsing /proc/self/auxv), because it should an invariant
on the same machine cross different processes.
In order to share code, I add nat/ppc-linux.c for both GDB and
GDBserver side.
gdb:
2015-01-14 Yao Qi <yao@codesourcery.com>
* Makefile.in (ppc-linux.o): New rule.
* config/powerpc/ppc64-linux.mh (NATDEPFILES): Add ppc-linux.o.
* configure.ac: AC_CHECK_FUNCS(getauxval).
* config.in: Re-generated.
* configure: Re-generated.
* nat/ppc-linux.h [__powerpc64__] (ppc64_64bit_inferior_p):
Declare.
* nat/ppc-linux.c: New file.
* ppc-linux-nat.c (ppc_linux_target_wordsize) [__powerpc64__]:
Call ppc64_64bit_inferior_p.
gdb/gdbserver:
2015-01-14 Yao Qi <yao@codesourcery.com>
* Makefile.in (SFILES): Add nat/ppc-linux.c.
(ppc-linux.o): New rule.
* configure.srv (powerpc*-*-linux*): Add ppc-linux.o.
* configure.ac: AC_CHECK_FUNCS(getauxval).
* config.in: Re-generated.
* configure: Re-generated.
* linux-ppc-low.c (ppc_arch_setup) [__powerpc64__]: Call
ppc64_64bit_inferior_p
When I use PPC_FEATURE_BOOKE in GDBserver, I find it is defined in GDB
but not in GDBserver. After taking a further look, I find some macros
are duplicated between ppc-linux-nat.c and linux-ppc-low.c, so this
patch is to move them into nat/ppc-linux.h.
gdb/gdbserver:
2015-01-14 Yao Qi <yao@codesourcery.com>
* linux-ppc-low.c: Include "nat/ppc-linux.h".
(PPC_FEATURE_HAS_VSX): Move to nat/ppc-linux.h.
(PPC_FEATURE_HAS_ALTIVEC, PPC_FEATURE_HAS_SPE): Likewise.
(PT_ORIG_R3, PT_TRAP): Likewise.
(PTRACE_GETVSXREGS, PTRACE_SETVSXREGS): Likewise.
(PTRACE_GETVRREGS, PTRACE_SETVRREGS): Likewise.
(PTRACE_GETEVRREGS, PTRACE_SETEVRREGS): Likewise.
gdb:
2015-01-14 Yao Qi <yao@codesourcery.com>
* ppc-linux-nat.c (PT_ORIG_R3, PT_TRAP): Move to
nat/ppc-linux.h.
(PPC_FEATURE_CELL, PPC_FEATURE_BOOKE): Likewise.
(PPC_FEATURE_HAS_DFP): Likewise.
(PTRACE_GETVRREGS, PTRACE_SETVRREGS): Likewise.
(PTRACE_GETVSXREGS, PTRACE_SETVSXREGS): Likewise.
(PTRACE_GETEVRREGS, PTRACE_SETEVRREGS): Likewise.
Include "nat/ppc-linux.h".
* nat/ppc-linux.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add nat/ppc-linux.h.
Executing a gdb script that runs the inferior (from the command line
with -x), and has it hit breakpoints with breakpoint commands that
themselves run the target, is currently broken on async targets
(Linux, remote).
While we're executing a command list or a script, we force the
interpreter to be sync, which results in some functions nesting an
event loop and waiting for the target to stop, instead of returning
immediately and having the top level event loop handle the stop.
The issue with this bug is simply that bpstat_do_actions misses
checking whether the interpreter is sync. When we get here, in the
case of executing a script (or, when the interpreter is sync), the
program has already advanced to the next breakpoint, through
maybe_wait_sync_command_done. We need to process its breakpoints
immediately, just like with a sync target.
Tested on x86_64 Fedora 20.
gdb/
2015-01-14 Pedro Alves <palves@redhat.com>
PR gdb/17525
* breakpoint.c: Include "interps.h".
(bpstat_do_actions_1): Also check whether the interpreter is
async.
gdb/testsuite/
2015-01-14 Pedro Alves <palves@redhat.com>
Joel Brobecker <brobecker@adacore.com>
PR gdb/17525
* gdb.base/bp-cmds-execution-x-script.c: New file.
* gdb.base/bp-cmds-execution-x-script.exp: New file.
* gdb.base/bp-cmds-execution-x-script.gdb: New file.
Commit d3d4baed (PR python/17372 - Python hangs when displaying
help()) had the side effect of causing 'gdb -batch' to leave the
terminal in the wrong state if the program was run. E.g,.
$ echo 'main(){*(int*)0=0;}' | gcc -x c -; ./gdb/gdb -batch -ex r ./a.out
Program received signal SIGSEGV, Segmentation fault.
0x00000000004004ff in main ()
$
If you start typing the next command, seemingly nothing happens - GDB
left the terminal with echo disabled.
The issue is that that "r" ends up in fetch_inferior_event, which
calls reinstall_readline_callback_handler_cleanup, which causes
readline to prep the terminal (raw, echo disabled). But "-batch"
causes GDB to exit before the top level event loop is first started,
and then nothing de-preps the terminal.
The reinstall_readline_callback_handler_cleanup function's intro
comment mentions:
"Need to do this as we go back to the event loop, ready to process
further input."
but the implementation forgets the case of when the interpreter is
sync, which indicates we won't return to the event loop yet, or as in
the case of -batch, we have not started it yet.
The fix is to not install the readline callback in that case.
For the test, in this case, checking that command echo still works is
sufficient. Comparing stty output before/after running GDB is even
better. Because stty may not be available, the test tries both ways.
In any case, since expect's spawn (what we use to start gdb) creates a
new pseudo tty, another expect spawn or tcl exec after GDB exits would
not see the wrong terminal settings. So instead, the test spawns a
shell and runs stty and GDB in it.
Tested on x86_64 Fedora 20.
gdb/
2015-01-14 Pedro Alves <palves@redhat.com>
PR cli/17828
* infrun.c (reinstall_readline_callback_handler_cleanup): Don't
reinstall if the interpreter is sync.
gdb/testsuite/
2015-01-14 Pedro Alves <palves@redhat.com>
PR cli/17828
* gdb.base/batch-preserve-term-settings.c: New file.
* gdb.base/batch-preserve-term-settings.exp: New file.
gdb/Changelog:
* objfiles.c (objfile_filename): New function.
* objfiles.h (objfile_filename): Declare it.
(objfile_name): Add function comment.
* python/py-objfile.c (objfpy_lookup_objfile_by_name): Try both the
bfd file name (which may be realpath'd), and the original name.
gdb/testsuite/ChangeLog:
* gdb.python/py-objfile.exp: Test gdb.lookup_objfile on symlinked
binary.
A sanity-check in my release scripts caught something: After having
created the tarballs, I verify that no checked-in file disappeared
in the process, and lo and behod, it found that the following file
got wiped:
- gdb/testsuite/dg-extract-results.py:
And it's not part of the tarball either.
I don't understand while we delete all *.py files in gdb/testsuite,
since I don't see a rule that expected to create one. A run of the
testsuite also doesn't seem to be creating .py files there.
I traced this to the following commit, which unfortunately provided
no explanation. Perhaps we used to run some tests in the gdb/testsuite
directory and caused files to be left behind there. Perhaps we still
do today?
In the meantime, Executive Decision: In order to allow me to create
tarballs without losing files, I removed it. It's easy to put something
back if we find out why it might still be needed.
gdb/testsuite/ChangeLog:
* Makefile.in (clean mostlyclean): Do not delete *.py.
Tested on x86_64-linux by running the src-release.sh script again,
and this time, dg-extract-results.py no longer gets wiped.
Now that the GDB 7.9 branch has been created, we can
bump the version number.
gdb/ChangeLog:
GDB 7.9 branch created (92fc2e6978):
* version.in: Bump version to 7.9.50.DATE-cvs.
The following change...
commit 1994afbf19
Date: Tue Dec 23 07:55:39 2014 -0800
Subject: Look up primitive types as symbols.
... caused the following regression:
% gdb
(gdb) set lang ada
(gdb) python print gdb.lookup_type('character')
Traceback (most recent call last):
File "<string>", line 1, in <module>
gdb.error: No type named character.
Error while executing Python code.
This is because the language_lookup_primitive_type_as_symbol call
was moved to the la_lookup_symbol_nonlocal hook. A couple of
implementations have been upated accordingly, but the Ada version
has not. This patch fixes this omission.
gdb/ChangeLog:
* ada-lang.c (ada_lookup_symbol_nonlocal): If name not found
in static block, then try searching for primitive types.
gdb/testsuite/ChangeLog:
* gdb.python/py-lookup-type.exp: New file.
This patch makes readline append new history lines to the GDB history
file on exit instead of overwriting the entire history file on exit.
This change allows us to run multiple simultaneous GDB sessions without
having each session overwrite the added history of each other session on
exit.
Care must be taken to ensure that the history file doesn't get corrupted
when multiple GDB processes are trying to simultaneously append to and
then truncate it. Safety is achieved in such a situation by using an
intermediate local history file to mutually exclude multiple processes
from simultaneously performing write operations on the global history
file.
gdb/ChangeLog:
* top.h (gdb_add_history): Declare.
* top.c (command_count): New variable.
(gdb_add_history): New function.
(gdb_safe_append_history): New static function.
(quit_force): Call it.
(command_line_input): Use gdb_add_history instead of
add_history.
* event-top.c (command_line_handler): Likewise.
The `machine/setjmp.h' header is no longer present on OS X 10.10, and is
non-standard. Instead, `darwin-nat.c' should be using the standard
`setjmp.h' header.
gdb/ChangeLog:
2015-01-12 James Clarke <jrtc27@jrtc27.com> (tiny patch)
PR gdb/17046
* darwin-nat.c: Replace <machine/setjmp.h> #include by
<setjmp.h> #include.
The previous change to py-prompt.exp made it return without restoring
GDBFLAGS, resulting in breaking the following tests:
$ make check RUNTESTFLAGS="--target_board=native-gdbserver --directory=gdb.python"
...
Running src/gdb/testsuite/gdb.python/py-prompt.exp ...
Running src/gdb/testsuite/gdb.python/py-section-script.exp ...
ERROR: (timeout) GDB never initialized after 10 seconds.
ERROR: no fileid for gdbuild
ERROR: Couldn't send python print ('test') to GDB.
ERROR: no fileid for gdbuild
ERROR: Couldn't send python print (sys.version_info[0]) to GDB.
ERROR: no fileid for gdbuild
ERROR: Couldn't send python print (sys.version_info[1]) to GDB.
ERROR: no fileid for gdbuild
ERROR: no fileid for gdbuild
...
gdb/testsuite/
2015-01-12 Pedro Alves <palves@redhat.com>
* gdb.python/py-prompt.exp: When the board can't spawn for attach,
restore GDBFLAGS before returning.
for x86_64 -m32 run one gets:
+FAIL: gdb.python/py-frame.exp: test Frame.read_register(rip)
I do not have x32 OS here but the %rip test should PASS there I think.
On Sun, 11 Jan 2015 14:58:06 +0100, Yao Qi wrote:
With your patch applied, this test is skipped on 'x86_64 -m32'. I
prefer to increasing the test coverage, so how about extending the test
for 'x86_64 -m32'? I mean test Frame.read_register(eip)...
gdb/testsuite/ChangeLog
2015-01-12 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.python/py-frame.exp (test Frame.read_register(rip)): Use
is_amd64_regs_target and is_x86_like_target.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (Dwarf): Flag an error if a numeric attribute value
is given without an explicit form.
* gdb.dwarf2/arr-subrange.exp: Specify forms for all numeric
attributes.
* gdb.dwarf/corrupt.exp: Ditto.
* gdb.dwarf2/enum-type.exp: Ditto.
* gdb.trace/entry-values.exp: Ditto.
* gdb.trace/unavailable-dwarf-piece.exp: Ditto.
clear_symtab_users calls breakpoint_re_set before
observer_notify_new_objfile(NULL), and thus symbol lookup
done during breakpoint_re_set will see a stale cache.
Presumably we just need to move the call to observer_notify_new_objfile(NULL)
to before breakpoint_re_set, but need to check for other such issues,
and 7.9 is scheduled to branch tomorrow.
Reverts commits:
b2fb95e006400678a494d98b9ccbcc77087adf50
gdb/ChangeLog:
* symtab.c (eq_symbol_entry): Use SYMBOL_SEARCH_NAME and
symbol_matches_domain for symbol comparisons.
* symtab.c (symbol_cache_mark_found): Improve function comment.
Rename parameter objfile to objfile_context.
(symbol_cache_mark_not_found): Improve function comment.
Add symbol lookup cache.
* NEWS: Document new options and commands.
* symtab.c (symbol_cache_key): New static global.
(DEFAULT_SYMBOL_CACHE_SIZE, MAX_SYMBOL_CACHE_SIZE): New macros.
(SYMBOL_LOOKUP_FAILED): New macro.
(symbol_cache_slot_state): New enum.
(block_symbol_cache): New struct.
(symbol_cache): New struct.
(new_symbol_cache_size, symbol_cache_size): New static globals.
(hash_symbol_entry, eq_symbol_entry): New functions.
(symbol_cache_byte_size, resize_symbol_cache): New functions.
(make_symbol_cache, free_symbol_cache): New functions.
(get_symbol_cache, symbol_cache_cleanup): New function.
(set_symbol_cache_size, set_symbol_cache_size_handler): New functions.
(symbol_cache_lookup, symbol_cache_clear_slot): New function.
(symbol_cache_mark_found, symbol_cache_mark_not_found): New functions.
(symbol_cache_flush, symbol_cache_dump): New functions.
(maintenance_print_symbol_cache): New function.
(maintenance_flush_symbol_cache): New function.
(symbol_cache_stats): New function.
(maintenance_print_symbol_cache_statistics): New function.
(symtab_new_objfile_observer): New function.
(symtab_free_objfile_observer): New function.
(lookup_static_symbol, lookup_global_symbol): Use symbol cache.
(_initialize_symtab): Init symbol_cache_key. New parameter
maint symbol-cache-size. New maint commands print symbol-cache,
print symbol-cache-statistics, flush-symbol-cache.
Install new_objfile, free_objfile observers.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Document new commands
"maint print symbol-cache", "maint print symbol-cache-statistics",
"maint flush-symbol-cache". Document new option
"maint set symbol-cache-size".
gdb/ChangeLog:
PR gdb/15830
* NEWS: The "maint demangle" command is renamed as "demangle".
* demangle.c: #include cli/cli-utils.h, language.h.
(demangle_command): New function.
(_initialize_demangle): Add new command "demangle".
* maint.c (maintenance_demangle): Stub out.
(_initialize_maint_cmds): Update help text for "maint demangle",
and mark as deprecated.
gdb/doc/ChangeLog:
* gdb.texinfo (Debugging C Plus Plus): Mention "demangle".
(Symbols): Ditto.
(Maintenance Commands): Delete docs for "maint demangle".
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp: Remove references to "maint demangle".
* gdb.cp/demangle.exp: Update. "maint demangle" -> "demangle".
Add tests for explicitly specifying language to demangle.
* gdb.dlang/demangle.exp: Ditto.
gdb/ChangeLog:
Add symbol lookup cache.
* NEWS: Document new options and commands.
* symtab.c (symbol_cache_key): New static global.
(DEFAULT_SYMBOL_CACHE_SIZE, MAX_SYMBOL_CACHE_SIZE): New macros.
(SYMBOL_LOOKUP_FAILED): New macro.
(symbol_cache_slot_state): New enum.
(block_symbol_cache): New struct.
(symbol_cache): New struct.
(new_symbol_cache_size, symbol_cache_size): New static globals.
(hash_symbol_entry, eq_symbol_entry): New functions.
(symbol_cache_byte_size, resize_symbol_cache): New functions.
(make_symbol_cache, free_symbol_cache): New functions.
(get_symbol_cache, symbol_cache_cleanup): New function.
(set_symbol_cache_size, set_symbol_cache_size_handler): New functions.
(symbol_cache_lookup, symbol_cache_clear_slot): New function.
(symbol_cache_mark_found, symbol_cache_mark_not_found): New functions.
(symbol_cache_flush, symbol_cache_dump): New functions.
(maintenance_print_symbol_cache): New function.
(maintenance_flush_symbol_cache): New function.
(symbol_cache_stats): New function.
(maintenance_print_symbol_cache_statistics): New function.
(symtab_new_objfile_observer): New function.
(symtab_free_objfile_observer): New function.
(lookup_static_symbol, lookup_global_symbol): Use symbol cache.
(_initialize_symtab): Init symbol_cache_key. New parameter
maint symbol-cache-size. New maint commands print symbol-cache,
print symbol-cache-statistics, flush-symbol-cache.
Install new_objfile, free_objfile observers.
doc/ChangeLog:
* gdb.texinfo (Symbols): Document new commands
"maint print symbol-cache", "maint print symbol-cache-statistics",
"maint flush-symbol-cache". Document new option
"maint set symbol-cache-size".
gdb/gdbserver/ChangeLog:
* i387-fp.c (i387_cache_to_xsave): In look over
num_avx512_zmmh_high_registers, replace use of struct i387_xsave
zmmh_low_space field by use of zmmh_high_space.
Tested on x86_64-linux, using boards/native-gdbserver.exp.
The #line directives within GDB's autogenerated yacc files (e.g.
c-exp.c) are being incorrectly munged, causing these directives to refer
to nonexistent source files, e.g.
#line 36 "/home/patrick/binutils-gdb/gdb//home/patrick/binutils-gdb/gdb/c-exp.y"
as opposed to
#line 36 "/home/patrick/binutils-gdb/gdb/c-exp.y"
The munging happens due to a sed expression added by commit 954d8cae
whose intended purpose[1] was to work around the fact that ylwrap emitted #line
directives without any directory information, e.g.
#line 36 "c-exp.y"
So the sed expression was meant to munge such directives to refer to
absolute paths instead. But the behavior of ylwrap was changed some
years ago[2] to emit absolute paths within #line directives. And when
our local copy of ylwrap was synced by commit e30465112, the sed
expression in question became unnecessary, and indeed harmful.
This patch removes the now-obsolete sed expression. The emitted #line
directives are now correct without it.
gdb/ChangeLog:
* Makefile.in (.y.c): Don't munge yacc's #line
directives.
[1]: https://sourceware.org/ml/gdb-patches/2010-11/msg00265.html
[2]: http://git.savannah.gnu.org/cgit/automake.git/commit/lib/ylwrap?id=b6359a5f3
This patch primarily rewrites defaulted_query() to use
gdb_readline_wrapper() to prompt the user for input, like
prompt_for_continue() does. The motivation for this rewrite is to be
able to reuse the default query hook in TUI, obviating the need for a
custom TUI query hook.
However, having TUI use the default query mechanism exposed a couple of
latent bugs in tui_redisplay_readline() related to the handling of
multi-line prompts, in particular GDB's multi-line quit prompt.
The first issue is an off-by-one error in the calculation of the height
of the prompt. The check in question should be col <= prev_col, not c <
prev_col, to properly account for the case when a prompt contains
multiple consecutive newlines. Failing to do so makes TUI have the
wrong idea of the vertical height of the prompt. This patch fixes the
column check.
The second issue is that cur_line does not get updated to reflect the
cursor position if the user's prompt cursor is at the end of the prompt
(i.e. if rl_point == rl_end). cur_line only gets updated if rl_point
lies between 0..rl_end-1 because that is the bounds of the for loop
responsible for updating cur_line. This patch changes the loop's bounds
to 0..rl_end so that cur_line always gets updated.
With these two bug fixes out of the way, the default query mechanism
works well in TUI even with multi-line prompts like GDB's quit prompt.
gdb/ChangeLog:
* utils.c (defaulted_query): Rewrite to use gdb_readline_wrapper
to prompt for input.
* tui/tui-hooks.c (tui_query_hook): Remove.
(tui_install_hooks): Don't set deprecated_query_hook.
* tui/tui-io.c (tui_redisplay_readline): Fix off-by-one error in
height calculation. Always update the command window's cur_line.
This commit adds a non-stop mode test originally inspired by
signal-while-stepping-over-bp-other-thread.exp, that exposes the
thread starvation issues fixed by the previous patches. It sets a set
of threads stepping in parallel, and has one of them get a signal.
Without the previous fixes, this would fail with timeouts.
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.threads/non-stop-fair-events.c: New file.
* gdb.threads/non-stop-fair-events.exp: New file.
This patch applies the same starvation avoidance improvements of the
previous patch to the Linux gdbserver side.
Without this, the test added by the following commit
(gdb.threads/non-stop-fair-events.exp) always fails with time outs.
gdb/gdbserver/
2015-01-09 Pedro Alves <palves@redhat.com>
* linux-low.c (step_over_bkpt): Move higher up in the file.
(handle_extended_wait): Don't store the stop_pc here.
(get_stop_pc): Adjust comments and rename to ...
(check_stopped_by_breakpoint): ... this. Record whether the LWP
stopped for a software breakpoint or hardware breakpoint.
(thread_still_has_status_pending_p): New function.
(status_pending_p_callback): Use
thread_still_has_status_pending_p. If the event is no longer
interesting, resume the LWP.
(handle_tracepoints): Add assert.
(maybe_move_out_of_jump_pad): Remove cancel_breakpoints call.
(wstatus_maybe_breakpoint): New function.
(cancel_breakpoint): Delete function.
(check_stopped_by_watchpoint): New function, factored out from
linux_low_filter_event.
(lp_status_maybe_breakpoint): Delete function.
(linux_low_filter_event): Remove filter_ptid argument.
Leave thread group exits pending here. Store the LWP's stop PC.
Always leave events pending.
(linux_wait_for_event_filtered): Pull all events out of the
kernel, and leave them all pending.
(count_events_callback, select_event_lwp_callback): Consider all
events.
(cancel_breakpoints_callback, linux_cancel_breakpoints): Delete.
(select_event_lwp): Only give preference to the stepping LWP in
all-stop mode. Adjust comments.
(ignore_event): New function.
(linux_wait_1): Delete 'retry' label. Use ignore_event. Remove
references to cancel_breakpoints. Adjust to renames. Also give
equal priority to all LWPs that have had events in non-stop mode.
If reporting a software breakpoint event, unadjust the LWP's PC.
(linux_wait): If linux_wait_1 returned an ignored event, retry.
(stuck_in_jump_pad_callback, move_out_of_jump_pad_callback):
Adjust.
(linux_resume_one_lwp): Store the LWP's PC. Adjust.
(resume_status_pending_p): Use thread_still_has_status_pending_p.
(linux_stopped_by_watchpoint): Adjust.
(linux_target_ops): Remove reference to linux_cancel_breakpoints.
* linux-low.h (enum lwp_stop_reason): New.
(struct lwp_info) <stop_pc>: Adjust comment.
<stopped_by_watchpoint>: Delete field.
<stop_reason>: New field.
* linux-x86-low.c (x86_linux_prepare_to_resume): Adjust.
* mem-break.c (software_breakpoint_inserted_here)
(hardware_breakpoint_inserted_here): New function.
* mem-break.h (software_breakpoint_inserted_here)
(hardware_breakpoint_inserted_here): Declare.
* target.h (struct target_ops) <cancel_breakpoints>: Remove field.
(cancel_breakpoints): Delete.
* tracepoint.c (clear_installed_tracepoints, stop_tracing)
(upload_fast_traceframes): Remove references to
cancel_breakpoints.
Running the testsuite with a series that reimplements user-visible
all-stop behavior on top of a target running in non-stop mode revealed
problems related to event starvation avoidance.
For example, I see
gdb.threads/signal-while-stepping-over-bp-other-thread.exp failing.
What happens is that GDB core never gets to see the signal event. It
ends up processing the events for the same threads over an over,
because Linux's waitpid(-1, ...) returns that first task in the task
list that has an event, starving threads on the tail of the task list.
So I wrote a non-stop mode test originally inspired by
signal-while-stepping-over-bp-other-thread.exp, to stress this
independently of all-stop on top of non-stop. Fixing it required the
changes described below. The test will be added in a following
commit.
1) linux-nat.c has code in place that picks an event LWP at random out
of all that have had events. This is because on the kernel side,
"waitpid(-1, ...)" just walks the task list linearly looking for the
first that had an event. But, this code is currently only used in
all-stop mode. So with a multi-threaded program that has multiple
events triggering debug events in parallel, GDB ends up starving some
threads.
To make the event randomization work in non-stop mode too, the patch
makes us pull out all the already pending events on the kernel side,
with waitpid, before deciding which LWP to report to the core.
There's some code in linux_wait that takes care of leaving events
pending if they were for LWPs the caller is not interested in. The
patch moves that to linux_nat_filter_event, so that we only have one
place that leaves events pending. With that in place, conceptually,
the flow is simpler and more normalized:
#1 - walk the LWP list looking for an LWP with a pending event to report.
#2 - if no pending event, pull events out of the kernel, and store
them in the LWP structures as pending.
#3- goto #1.
2) Then, currently the event randomization code only considers SIGTRAP
(or trap-like) events. That means that if e.g., have have multiple
threads stepping in parallel that hit a breakpoint that needs stepping
over, and one gets a signal, the signal may end up never getting
processed, because GDB will always be giving priority to the SIGTRAPs.
The patch fixes this by making the randomization code consider all
kinds of pending events.
3) If multiple threads hit a breakpoint, we report one of those, and
"cancel" the others. Cancelling means decrementing the PC, and
discarding the event. If the next time the LWP is resumed the
breakpoint is still installed, the LWP should hit it again, and we'll
report the hit then. The problem I found is that this delays threads
from advancing too much, with the kernel potentially ending up
scheduling the same threads over and over, and others not advancing.
So the patch switches away from cancelling the breakpoints, and
instead remembering that the LWP had stopped for a breakpoint. If on
resume the breakpoint is still installed, we report it. If it's no
longer installed, we discard the pending event then. This is actually
how GDBserver used to handle this before d50171e4 (Teach linux
gdbserver to step-over-breakpoints), but with the difference that back
then we'd delay adjusting the PC until resuming, which made it so that
"info threads" could wrongly see threads with unadjusted PCs.
gdb/
2015-01-09 Pedro Alves <palves@redhat.com>
* breakpoint.c (hardware_breakpoint_inserted_here_p): New
function.
* breakpoint.h (hardware_breakpoint_inserted_here_p): New
declaration.
* linux-nat.c (linux_nat_status_is_event): Move higher up in file.
(linux_resume_one_lwp): Store the thread's PC. Adjust to clear
stop_reason.
(check_stopped_by_watchpoint): New function.
(save_sigtrap): Reimplement.
(linux_nat_stopped_by_watchpoint): Adjust.
(linux_nat_lp_status_is_event): Delete.
(stop_wait_callback): Only call save_sigtrap after storing the
pending status.
(status_callback): If the thread had been stopped for a breakpoint
that has since been removed, discard the event and resume the LWP.
(count_events_callback, select_event_lwp_callback): Use
lwp_status_pending_p instead of linux_nat_lp_status_is_event.
(cancel_breakpoint): Rename to ...
(check_stopped_by_breakpoint): ... this. Record whether the LWP
stopped for a software breakpoint or hardware breakpoint.
(select_event_lwp): Only give preference to the stepping LWP in
all-stop mode. Adjust comments.
(stop_and_resume_callback): Remove references to new_pending_p.
(linux_nat_filter_event): Likewise. Leave exit events of the
leader thread pending here. Handle signal short circuiting here.
Only call save_sigtrap after storing the pending waitstatus.
(linux_nat_wait_1): Remove 'retry' label. Remove references to
new_pending. Don't handle leaving events the caller is not
interested in pending here, nor handle signal short-circuiting
here. Also give equal priority to all LWPs that have had events
in non-stop mode. If reporting a software breakpoint event,
unadjust the LWP's PC.
* linux-nat.h (enum lwp_stop_reason): New.
(struct lwp_info) <stop_pc>: New field.
(struct lwp_info) <stopped_by_watchpoint>: Delete field.
(struct lwp_info) <stop_reason>: New field.
* x86-linux-nat.c (x86_linux_prepare_to_resume): Adjust.
A subsequent patch will make the Linux backend's target_wait method
pull all events out of the kernel (with waitpid) and store them as
pending status in the LWP structure if no pending status was already
available. Then, the backend goes over the pending statuses and pick
one to report to the core.
With that, the existing thread-execl.exp test exposes a bug, like:
(gdb) set scheduler-locking on
(gdb) PASS: gdb.threads/thread-execl.exp: schedlock on: set scheduler-locking on
next
FAIL: gdb.threads/thread-execl.exp: schedlock on: get to main in new image (timeout)
Recall that when the non-leader thread execs, all threads in the
process die, the execing thread changes its pid to the tgid, and then
waitpid returns an exec event to the tgid. If GDB didn't resume the
leader LWP, then GDB sees an event for an LWP that was supposedly
stopped, and thus not marked as resumed. Because the code that picks
a pending event to report to the core ignores not-resumed LWPs:
/* Return non-zero if LP has a wait status pending. */
static int
status_callback (struct lwp_info *lp, void *data)
{
/* Only report a pending wait status if we pretend that this has
indeed been resumed. */
if (!lp->resumed)
return 0;
the event ends up pending forever, thus the timeout.
gdb/
2015-01-09 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_handle_extended_wait) <PTRACE_EVENT_EXEC>:
Set the LWP's 'resumed' flag.
Whenever we resume an LWP, we must clear a few flags and flush the
LWP's register cache. We actually currently flush the register cache
of all LWPs, but that's unnecessary. This patch makes us flush the
register cache of only the LWP that is resumed. Instead of open
coding all that in many places, we use a helper function.
Likewise, we have two fields in the LWP structure where a pending
status may be recorded. Add a helper predicate that checks both and
use it throughout instead of open coding the checks.
gdb/
2015-01-09 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_resume_one_lwp): New function.
(resume_lwp): Use lwp_status_pending_p and linux_resume_one_lwp.
(linux_nat_resume): Use lwp_status_pending_p and
linux_resume_one_lwp.
(linux_handle_syscall_trap): Use linux_resume_one_lwp.
(linux_handle_extended_wait): Use linux_resume_one_lwp.
(status_callback, running_callback): Use lwp_status_pending_p.
(lwp_status_pending_p): New function.
(stop_and_resume_callback): Use lwp_status_pending_p.
(linux_nat_filter_event): Use linux_resume_one_lwp.
(linux_nat_wait_1): Always use status_callback to look for an LWP
with a pending status. Use linux_resume_one_lwp.
(resume_stopped_resumed_lwps): Use lwp_status_pending_p and
linux_resume_one_lwp.
Factor out common code, and use the more efficient
ALL_BP_LOCATIONS_AT_ADDR.
gdb/
2015-01-09 Pedro Alves <palves@redhat.com>
* breakpoint.c (bp_location_inserted_here_p): New function,
factored out from ...
(breakpoint_inserted_here_p): ... here. Use
ALL_BP_LOCATIONS_AT_ADDR.
(software_breakpoint_inserted_here_p): Use
bp_location_inserted_here_p and ALL_BP_LOCATIONS_AT_ADDR.
This patch fixes the watch_thread_num.exp test to work when the target
is better at making event handling be fair among threads.
I wrote patches that make GDB native and GDBserver event handling
fairer between threads. That is, if threads A and B both
simultaneously trigger some debug event, GDB will pick either A or B
at random, rather than always handling the event of A first. There's
code for that in the Linux backends (gdb and gdbserver) already, but
it can be improved, and only works in all-stop mode.
With those fixes in place, I found that the watch_thread_num.exp would
often time out. The problem is that the test only works _because_
event handling isn't as fair as intended. With the fairness fixes,
the test falls victim of PR10116 (gdb drops watchpoints on
multi-threaded apps) quite often.
To expand on the PR10116 reference, consider that stop events are
serialized to GDB core, through target_wait. Say a thread-specific
watchpoint as set on thread A. When the "right" thread and some other
"wrong" thread both trigger a watchpoint simultaneously, the target
may report the "wrong" thread's hit to GDB first (thread B). When
handling that event, GDB notices the watchpoint is for another thread,
and so shouldn't cause a user-visible stop. On resume, GDB saves the
now current value of the watched expression. Afterwards, the "right"
thread (thread A) reports its watchpoint trigger. But the watched
value hasn't changed since GDB last saved it, and so GDB doesn't
report the watchpoint hit to the user.
The way the test is written, the watchpoint is associated with the
first thread that happens to report an event. It happens that GDB is
processing events much more often for one of the threads, which
usually will be that same first thread.
Hacking the test with "set debug infrun 1", we see exactly that:
$ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c | sort -nr
70 infrun: 8798 [Thread 8798],
37 infrun: 8798 [Thread 8802],
36 infrun: 8798 [Thread 8804],
36 infrun: 8798 [Thread 8803],
35 infrun: 8798 [Thread 8805],
34 infrun: 8798 [Thread 8806],
The first column shows the number of times the target reported an
event for that thread, from:
infrun: target_wait (-1, status) =
infrun: 8798 [Thread 8798],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
This masks out the PR10116 issue.
However, if the target is better at giving equal priority to all
threads, the PR10116 issue happens often, so it may take quite a while
for the right thread to be the first to report its watchpoint event
just after the memory being watched really changed, resulting in test
time outs.
Here's the number of events handled for each thread on a gdbserver run
with the event fairness patches:
$ grep "infrun.*\[Thread.*," gdb.log | sort | uniq -c
2961 infrun: 13591 [Thread 13591],
2956 infrun: 13591 [Thread 13595],
2941 infrun: 13591 [Thread 13596],
2932 infrun: 13591 [Thread 13597],
2905 infrun: 13591 [Thread 13598],
2891 infrun: 13591 [Thread 13599],
Note how the number of events is much higher. The test routinely
takes over 10 seconds to finish on my machine rather than under a
second as with unpatched gdbserver, when it succeeds, but often it'll
fail with timeouts too.
So to make the test robust, this patch switches the tests to using
"awatch" instead of "watch", as access watchpoints don't care about
the watchpoint's "old value". With this, the test always finishes
quickly, and we can even bump the number of threads concurrently
writting to the shared variable, to have better assurance we're really
testing the case of the "wrong" thread triggering a watchpoint.
Here's the number of events I see for each thread on a run on my
machine, with a gdbserver patched with the event fairness series:
$ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c
5 infrun: 5298 [Thread 5302],
4 infrun: 5298 [Thread 5303],
4 infrun: 5298 [Thread 5304],
4 infrun: 5298 [Thread 5305],
4 infrun: 5298 [Thread 5306],
4 infrun: 5298 [Thread 5307],
4 infrun: 5298 [Thread 5308],
4 infrun: 5298 [Thread 5309],
4 infrun: 5298 [Thread 5310],
4 infrun: 5298 [Thread 5311],
4 infrun: 5298 [Thread 5312],
4 infrun: 5298 [Thread 5313],
4 infrun: 5298 [Thread 5314],
4 infrun: 5298 [Thread 5315],
4 infrun: 5298 [Thread 5316],
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (thread_test): Use srcfile and binfile from
the global scope. Set a breakpoint after all threads are started
rather than stepping over two source lines. Expect the prompt.
* gdb.base/watch_thread_num.c (threads_started_barrier): New
global.
(NUM): Now 15.
(main): Use threads_started_barrier to wait for all threads to
start. Main thread no longer calls thread_function. Exit after
180 seconds.
(loop): New function.
(thread_function): Wait on threads_started_barrier barrier. Call
'loop' at each iteration.
* gdb.base/watch_thread_num.exp: Continue to breakpoint after all
threads have started, instead of hardcoding number of "next"
steps. Use an access watchpoint instead of a write watchpoint.
These three test all spawn a few threads and then send a SIGSTOP to
their parent GDB in order to pause it while the new threads set things
up for the test. With a GDB patch that changes the inferior thread's
scheduling a bit, I sometimes see:
FAIL: gdb.threads/siginfo-threads.exp: catch signal 0 (timeout)
...
FAIL: gdb.threads/watchthreads-reorder.exp: reorder1: continue a (timeout)
...
FAIL: gdb.threads/ia64-sigill.exp: continue (timeout)
...
The issue is that the test program stops GDB before it had a chance of
processing the new thread's clone event:
(gdb) PASS: gdb.threads/siginfo-threads.exp: get pid
continue
Continuing.
Stopping GDB PID 21541.
Waiting till the threads initialize their TIDs.
FAIL: gdb.threads/siginfo-threads.exp: catch signal 0 (timeout)
On Linux (at least), new threads start stopped, and the debugger must
resume them. The fix is to make the test program wait for the new
threads to be running before stopping GDB.
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.threads/ia64-sigill.c (threads_started_barrier): New global.
(thread_func): Wait on barrier.
(main): Wait for all threads to start before stopping GDB.
* gdb.threads/siginfo-threads.c (threads_started_barrier): New
global.
(thread1_func, thread2_func): Wait on barrier.
(main): Wait for all threads to start before stopping GDB.
* gdb.threads/watchthreads-reorder.c (threads_started_barrier):
New global.
(thread1_func, thread2_func): Wait on barrier.
(main): Wait for all threads to start before stopping GDB.
Before the previous fixes, on Linux, this would trigger several
different problems, like:
[New LWP 27106]
[New LWP 27047]
warning: unable to open /proc file '/proc/-1/status'
[New LWP 27813]
[New LWP 27869]
warning: Can't attach LWP 11962: No child processes
Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: debugger service failed
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.threads/attach-many-short-lived-threads.c: New file.
* gdb.threads/attach-many-short-lived-threads.exp: New file.
[A test I wrote stumbled on a libthread_db issue related to thread
event breakpoints. See glibc PR17705:
[nptl_db: stale thread create/death events if debugger detaches]
https://sourceware.org/bugzilla/show_bug.cgi?id=17705
This patch avoids that whole issue by making GDB stop using thread
event breakpoints in the first place, which is good for other reasons
as well, anyway.]
Before PTRACE_EVENT_CLONE (Linux 2.6), the only way to learn about new
threads in the inferior (to attach to them) or to learn about thread
exit was to coordinate with the inferior's glibc/runtime, using
libthread_db. That works by putting a breakpoint at a magic address
which is called when a new thread is spawned, or when a thread is
about to exit. When that breakpoint is hit, all threads are stopped,
and then GDB coordinates with libthread_db to read data structures out
of the inferior to learn about what happened. Then the breakpoint is
single-stepped, and then all threads are re-resumed. This isn't very
efficient (stops all threads) and is more fragile (inferior's thread
list in memory may be corrupt; libthread_db bugs, etc.) than ideal.
When the kernel supports PTRACE_EVENT_CLONE (which we already make use
of), there's really no need to use libthread_db's event reporting
mechanism to learn about new LWPs. And if the kernel supports that,
then we learn about LWP exits through regular WIFEXITED wait statuses,
so no need for the death event breakpoint either.
GDBserver has been likewise skipping the thread_db events for a long
while:
https://sourceware.org/ml/gdb-patches/2007-10/msg00547.html
There's one user-visible difference: we'll no longer print about
threads being created and exiting while the program is running, like:
[Thread 0x7ffff7dbb700 (LWP 30670) exited]
[New Thread 0x7ffff7db3700 (LWP 30671)]
[Thread 0x7ffff7dd3700 (LWP 30667) exited]
[New Thread 0x7ffff7dab700 (LWP 30672)]
[Thread 0x7ffff7db3700 (LWP 30671) exited]
[Thread 0x7ffff7dcb700 (LWP 30668) exited]
This is exactly the same behavior as when debugging against remote
targets / gdbserver. I actually think that's a good thing (and as
such have listed this in the local/remote parity wiki page a while
ago), as the printing slows down the inferior. It's also a
distraction to keep bothering the user about short-lived threads that
she won't be able to interact with anyway. Instead, the user (and
frontend) will be informed about new threads that currently exist in
the program when the program next stops:
(gdb) c
...
* ctrl-c *
[New Thread 0x7ffff7963700 (LWP 7797)]
[New Thread 0x7ffff796b700 (LWP 7796)]
Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7ffff796b700 (LWP 7796)]
clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:81
81 testq %rax,%rax
(gdb) info threads
A couple of tests had assumptions on GDB thread numbers that no longer
hold.
Tested on x86_64 Fedora 20.
gdb/
2014-01-09 Pedro Alves <palves@redhat.com>
Skip enabling event reporting if the kernel supports
PTRACE_EVENT_CLONE.
* linux-thread-db.c: Include "nat/linux-ptrace.h".
(thread_db_use_events): New function.
(try_thread_db_load_1): Check thread_db_use_events before enabling
event reporting.
(update_thread_state): New function.
(attach_thread): Use it. Check thread_db_use_events before
enabling event reporting.
(thread_db_detach): Check thread_db_use_events before disabling
event reporting.
(find_new_threads_callback): Check thread_db_use_events before
enabling event reporting. Update the thread's state if not using
libthread_db events.
gdb/testsuite/
2014-01-09 Pedro Alves <palves@redhat.com>
* gdb.threads/fork-thread-pending.exp: Switch to the main thread
instead of to thread 2.
* gdb.threads/signal-command-multiple-signals-pending.c (main):
Add barrier around each pthread_create call instead of around all
calls.
* gdb.threads/signal-command-multiple-signals-pending.exp (test):
Set a break on thread_function and have the child threads hit it
one at at a time.
I wrote a test that attaches to a program that constantly spawns
short-lived threads, which exposed several issues. This is one of
them.
On GNU/Linux, attaching to a multi-threaded program sometimes prints
out warnings like:
...
[New LWP 20700]
warning: unable to open /proc file '/proc/-1/status'
[New LWP 20850]
[New LWP 21019]
...
That happens because when a thread exits, and is joined, glibc does:
nptl/pthread_join.c:
pthread_join ()
{
...
if (__glibc_likely (result == 0))
{
/* We mark the thread as terminated and as joined. */
pd->tid = -1;
...
/* Free the TCB. */
__free_tcb (pd);
}
So if we attach or interrupt the program (which does an implicit "info
threads") at just the right (or rather, wrong) time, we can find and
return threads in the libthread_db/pthreads thread list with kernel
thread ID -1. I've filed glibc PR nptl/17707 for this. You'll find
more info there.
This patch handles this as a special case in GDB.
This is actually more than just a cosmetic issue. lin_lwp_attach_lwp
will think that this -1 is an LWP we're not attached to yet, and after
failing to attach will try to check we were already attached to the
process, using a waitpid call, which in this case ends up being
"waitpid (-1, ...", which obviously results in GDB potentially
discarding an event when it shouldn't...
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/gdbserver/
2015-01-09 Pedro Alves <palves@redhat.com>
* thread-db.c (find_new_threads_callback): Ignore thread if the
kernel thread ID is -1.
gdb/
2015-01-09 Pedro Alves <palves@redhat.com>
* linux-nat.c (lin_lwp_attach_lwp): Assert that the lwp id we're
about to wait for is > 0.
* linux-thread-db.c (find_new_threads_callback): Ignore thread if
the kernel thread ID is -1.
... instead of relying on libthread_db.
I wrote a test that attaches to a program that constantly spawns
short-lived threads, which exposed several issues. This is one of
them.
On Linux, we need to attach to all threads of a process (thread group)
individually. We currently rely on libthread_db to list the threads,
but that is problematic, because libthread_db relies on reading data
structures out of the inferior (which may well be corrupted). If
threads are being created or exiting just while we try to attach, we
may trip on inconsistencies in the inferior's thread list. To work
around that, when we see a seemingly corrupt list, we currently retry
a few times:
static void
thread_db_find_new_threads_2 (ptid_t ptid, int until_no_new)
{
...
if (until_no_new)
{
/* Require 4 successive iterations which do not find any new threads.
The 4 is a heuristic: there is an inherent race here, and I have
seen that 2 iterations in a row are not always sufficient to
"capture" all threads. */
...
That heuristic may well fail, and when it does, we end up with threads
in the program that aren't under GDB's control. That's obviously bad
and results in quite mistifying failures, like e.g., the process dying
for seeminly no reason when a thread that wasn't attached trips on a
breakpoint.
There's really no reason to rely on libthread_db for this nowadays
when we have /proc mounted. In that case, which is the usual case, we
can list the LWPs from /proc/PID/task/. In fact, GDBserver is already
doing this. The patch factors out that code that knows to walk the
task/ directory out of GDBserver, and makes GDB use it too.
Like GDBserver, the patch makes GDB attach to LWPs and _not_ wait for
them to stop immediately. Instead, we just tag the LWP as having an
expected stop. Because we can only set the ptrace options when the
thread stops, we need a new flag in the lwp structure to keep track of
whether we've already set the ptrace options, just like in GDBserver.
Note that nothing issues any ptrace command to the threads between the
PTRACE_ATTACH and the stop, so this is safe (unlike one scenario
described in gdbserver's linux-low.c).
When we attach to a program that has threads exiting while we attach,
it's easy to race with a thread just exiting as we try to attach to
it, like:
#1 - get current list of threads
#2 - attach to each listed thread
#3 - ooops, attach failed, thread is already gone
As this is pretty normal, we shouldn't be issuing a scary warning in
step #3.
When #3 happens, PTRACE_ATTACH usually fails with ESRCH, but sometimes
we'll see EPERM as well. That happens when the kernel still has the
thread in its task list, but the thread is marked as dead.
Unfortunately, EPERM is ambiguous and we'll get it also on other
scenarios where the thread isn't dead, and in those cases, it's useful
to get a warning. To distiguish the cases, when we get an EPERM
failure, we open /proc/PID/status, and check the thread's state -- if
the /proc file no longer exists, or the state is "Z (Zombie)" or "X
(Dead)", we ignore the EPERM error silently; otherwise, we'll warn.
Unfortunately, there seems to be a kernel race here. Sometimes I get
EPERM, and then the /proc state still indicates "R (Running)"... If
we wait a bit and retry, we do end up seeing X or Z state, or get an
ESRCH. I thought of making GDB retry the attach a few times, but even
with a 500ms wait and 4 retries, I still see the warning sometimes. I
haven't been able to identify the kernel path that causes this yet,
but in any case, it looks like a kernel bug to me. As this just
results failure to suppress a warning that we've been printing since
about forever anyway, I'm just making the test cope with it, and issue
an XFAIL.
gdb/gdbserver/
2015-01-09 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_attach_fail_reason_string): Move to
nat/linux-ptrace.c, and rename.
(linux_attach_lwp): Update comment.
(attach_proc_task_lwp_callback): New function.
(linux_attach): Adjust to rename and use
linux_proc_attach_tgid_threads.
(linux_attach_fail_reason_string): Delete declaration.
gdb/
2015-01-09 Pedro Alves <palves@redhat.com>
* linux-nat.c (attach_proc_task_lwp_callback): New function.
(linux_nat_attach): Use linux_proc_attach_tgid_threads.
(wait_lwp, linux_nat_filter_event): If not set yet, set the lwp's
ptrace option flags.
* linux-nat.h (struct lwp_info) <must_set_ptrace_flags>: New
field.
* nat/linux-procfs.c: Include <dirent.h>.
(linux_proc_get_int): New parameter "warn". Handle it.
(linux_proc_get_tgid): Adjust.
(linux_proc_get_tracerpid): Rename to ...
(linux_proc_get_tracerpid_nowarn): ... this.
(linux_proc_pid_get_state): New function, factored out from
(linux_proc_pid_has_state): ... this. Add new parameter "warn"
and handle it.
(linux_proc_pid_is_gone): New function.
(linux_proc_pid_is_stopped): Adjust.
(linux_proc_pid_is_zombie_maybe_warn)
(linux_proc_pid_is_zombie_nowarn): New functions.
(linux_proc_pid_is_zombie): Use
linux_proc_pid_is_zombie_maybe_warn.
(linux_proc_attach_tgid_threads): New function.
* nat/linux-procfs.h (linux_proc_get_tgid): Update comment.
(linux_proc_get_tracerpid): Rename to ...
(linux_proc_get_tracerpid_nowarn): ... this, and update comment.
(linux_proc_pid_is_gone): New declaration.
(linux_proc_pid_is_zombie): Update comment.
(linux_proc_pid_is_zombie_nowarn): New declaration.
(linux_proc_attach_lwp_func): New typedef.
(linux_proc_attach_tgid_threads): New declaration.
* nat/linux-ptrace.c (linux_ptrace_attach_fail_reason): Adjust to
use nowarn functions.
(linux_ptrace_attach_fail_reason_string): Move here from
gdbserver/linux-low.c and rename.
(ptrace_supports_feature): If the current ptrace options are not
known yet, check them now, instead of asserting.
* nat/linux-ptrace.h (linux_ptrace_attach_fail_reason_string):
Declare.
Some debug output in linux-thread-db.c was being sent to gdb_stdout,
and some to gdb_stderr, while the right place to send debug output to is
gdb_stdlog.
gdb/
2015-01-09 Pedro Alves <palves@redhat.com>
* linux-thread-db.c (thread_db_find_new_threads_silently)
(try_thread_db_load_1, try_thread_db_load, thread_db_load_search)
(find_new_threads_once): Print debug output on gdb_stdlog.
We already skip "attach" tests if the target board is remote, in
dejagnu's sense, as we use TCL's exec to spawn the program on the
build machine. We should also skip these tests if testing with
"target remote" or other stub-like targets where "attach" doesn't make
sense.
Add a helper procedure that centralizes the checks a test that needs
to spawn a program for testing "attach" and make all test files that
use spawn_wait_for_attach check it.
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (can_spawn_for_attach): New procedure.
(spawn_wait_for_attach): Error out if can_spawn_for_attach returns
false.
* gdb.base/attach.exp: Use can_spawn_for_attach instead of
checking whether the target board is remote.
* gdb.multi/multi-attach.exp: Likewise.
* gdb.python/py-sync-interp.exp: Likewise.
* gdb.server/ext-attach.exp: Likewise.
* gdb.python/py-prompt.exp: Use can_spawn_for_attach before the
tests that need to attach, instead of checking whether the target
board is remote at the top of the file.
I see the error message "access outside bounds of object referenced
via synthetic pointer" in the two fails below of mips gdb testing
print d[-2]^M
access outside bounds of object referenced via synthetic pointer^M
(gdb) FAIL: gdb.dwarf2/implptrconst.exp: print d[-2]
(gdb) print/d p[-1]^M
access outside bounds of object referenced via synthetic pointer^M
(gdb) FAIL: gdb.dwarf2/implptrpiece.exp: print/d p[-1]
in the first test, 'd[-2]' is processed by GDB as '* (&d[-2])'. 'd'
is a synthetic pointer, so its value is zero, the address of 'd[-2]'
is -2. In dwarf2loc.c:indirect_pieced_value,
/* This is an offset requested by GDB, such as value subscripts.
However, due to how synthetic pointers are implemented, this is
always presented to us as a pointer type. This means we have to
sign-extend it manually as appropriate. */
byte_offset = value_as_address (value);
if (TYPE_LENGTH (value_type (value)) < sizeof (LONGEST))
byte_offset = gdb_sign_extend (byte_offset,
8 * TYPE_LENGTH (value_type (value)));
byte_offset += piece->v.ptr.offset;
We know that the value is really an offset instead of address, so the
fix is to extract the value as an (signed) offset.
gdb:
2015-01-08 Pedro Alves <palves@redhat.com>
Yao Qi <yao@codesourcery.com>
* dwarf2loc.c (indirect_pieced_value): Don't call
gdb_sign_extend. Call extract_signed_integer instead.
* utils.c (gdb_sign_extend): Remove.
* utils.h (gdb_sign_extend): Remove declaration.
The special handling of C++ special symbol
generates symbols that have no language.
Those symbols cannot be displayed correctly in the backtrace stack.
See
https://sourceware.org/bugzilla/show_bug.cgi?id=17811
for details and examples in C++ and pascal language.
The patch below fixes this issue, by
setting language of new symbol before
special handling of special C++ symbols.
2015-01-07 Pierre Muller <muller@sourceware.org>
PR symtab/17811
* stabsread.c (define_symbol): Set language for C++ special symbols.
The test entry-values.exp doesn't recognize the call instructions
on MIPS, such as JAL, JALS and etc, so this patch sets call_insn
to match various jump and branch instructions first.
Currently, we assume the next instruction address of call instruction
is the address returned from foo, however it is not correct on MIPS
which has delay slot. We extend variable call_insn to match one
instruction after jump or branch instruction, so that
$returned_from_foo is correct on MIPS.
All tests in entry-values.exp are PASS.
gdb/testsuite:
2015-01-08 Yao Qi <yao@codesourcery.com>
* gdb.trace/entry-values.exp: Set call_insn for MIPS target.
Currently when we start an inferior we have the inferior inherit our
terminal state. Under TUI, our terminal is highly modified by ncurses
and readline. So when starting an inferior under TUI, the inferior will
have a highly modified terminal state which will interfere with standard
I/O. For example,
$ gdb gdb
(gdb) break main
(gdb) run
(gdb) print puts ("a\nb")
a
b
$1 = 4
(gdb) [enter TUI mode]
(gdb) run
(gdb) [exit TUI mode]
(gdb) print puts ("a\nb")
a
b
$2 = 4
(gdb) print puts ("a\r\nb\r")
a
b
$3 = 6
As you can see, when we start the inferior under the regular interface,
puts() prints the text properly. But when we start the inferior under
TUI, puts() does not print the text properly. This is because when we
start the inferior under TUI it inherits our current terminal state
which has been modified by ncurses to, among other things, require an
explicit \r\n to print a new line. As a result the inferior performs
standard I/O in an unexpected way.
Because of this discrepancy, it doesn't seem like a good idea to have
the inferior inherit our _current_ terminal state for it may have been
modified by readline and/or ncurses. Instead, we should have the
inferior inherit a pristine snapshot of our terminal state taken before
readline or ncurses have had a chance to alter it. This enables the
inferior to run in a more accurate way, more closely mimicking the
program's behavior had it run standalone. And it fixes the above
mentioned issue.
Tested on x86_64-unknown-linux-gnu.
gdb/ChangeLog:
* terminal.h (set_initial_gdb_ttystate): Declare.
* inflow.c (initial_gdb_ttystate): New static variable.
(set_initial_gdb_ttystate): New setter.
(child_terminal_init_with_pgrp): Copy initial_gdb_ttystate
instead of our current terminal state.
* top.c (gdb_init): Call set_initial_gdb_ttystate.
This fixes a similar error as in the Python support code where
trying to create an empty array.
In guile/scm-type.c::tyscm_array_1, the funtion raises an exception
if N2 < N1:
if (n2 < n1)
{
gdbscm_out_of_range_error (func_name, SCM_ARG3,
But it should be doing so if N2 == N1 - 1, since that would simply
be an empty array, not an array with a negative length.
gdb/ChangeLog:
* guile/scm-type.c (tyscm_array_1): Do not raise out-of-range
error if N2 is equal to N1 - 1.
The following python command fails:
(gdb) python print gdb.lookup_type('char').array(1, 0)
Traceback (most recent call last):
File "<string>", line 1, in <module>
ValueError: Array length must not be negative
Error while executing Python code.
The above is trying to create an empty array, which is fairly command
in Ada.
gdb/ChangeLog:
* python/py-type.c (typy_array_1): Do not raise negative-length
exception if N2 is equal to N1 - 1.
gdb/testsuite/ChangeLog:
* gdb.python/py-type.exp: Add a couple test about empty
array creation, and negative-length array creation.
Make the extracted stack offset signed in the standard MIPS prologue
scanner, to simplify handling and make sure register offsets are correct
in all cases, especially where $fp equals the virtual frame pointer (old
GCC frames) and therefore offsets to save slots are negative.
* mips-tdep.c (mips32_scan_prologue): Make the extracted stack
offset signed.
This patch renames gdb/'s ChangeLog to ChangeLog-2014 and creates
a new one for 2015. config/djgpp/fnchange.lst is updated accordingly.
gdb/ChangeLog:
* config/djgpp/fnchange.lst: Add entry for gdb/ChangeLog-2014.
This patch removes documentation from some commands whose support has
been recently removed.
gdb/ChangeLog:
* NEWS: Document removal of "dll-symbols", "add-shared-symbol-files"
and "assf" commands.
gdb/doc/ChangeLog:
* gdb.texinfo (Files): Remove documentation of the
"add-shared-symbol-files" and "assf" commands.
(Cygwin Native): Remove documentation of the "dll-symbols"
command.
This patch removes a set of commands that have been deprecated for
a while, and which we agreed to remove after the GDB 7.8 release.
gdb/ChangeLog:
* windows-nat.c (safe_symbol_file_add_stub)
(safe_symbol_file_add_cleanup, safe_symbol_file_add)
(dll_symbol_command): Delete.
(_initialize_windows_nat): Delete local variable "c".
Remove "dll-symbols", "add-shared-symbol-files" and assf"
commands.
Tested by rebuilding GDB on x86-windows.
Hi,
This patch is a follow-up of the following discussions:
<https://sourceware.org/ml/gdb-patches/2014-12/msg00421.html>
<https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01293.html>
input_interrupt is currently emiting non-printable characters, which
is confusing the dg-extract-results.sh script. This is obviously not
a good thing, and, by following Pedro's advices here:
<https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01320.html>
I adapted the function to print "client connection closed" when it
receives a NUL character, or use the "isprint" function to decide how
to print the received char. I tested it by running the testcases that
were printing the non-printable chars before:
gdb.base/gdb-sigterm.exp
gdb.threads/non-ldr-exc-1.exp
gdb.threads/non-ldr-exc-2.exp
gdb.threads/non-ldr-exc-3.exp
gdb.threads/non-ldr-exc-4.exp
gdb.threads/thread-execl.exp
and confirming that they print the right message. I tried a bit to
come up with a testcase for this, but failed, and since I did not want
to spend too much time on it, I'm sending the patch anyway.
Comments are welcome, as usual.
gdb/gdbserver/ChangeLog:
2014-12-29 Sergio Durigan Junior <sergiodj@redhat.com>
* remote-utils.c: Include ctype.h.
(input_interrupt): Explicitly handle the case when the char
received is the NUL byte. Improve the printing of non-ASCII
characters.
2014-12-29 Thomas Preud'homme <thomas.preudhomme@arm.com>
gdb/
* arm-tdep.c (arm_gdbarch_init): Remove casts in Tag_ABI_VFP_args
switch case statements.
This patch is to clean up gdb.trace/entry-values.exp as a preparation
of the next patch. It updates the comments to reflect the code.
One DIE generated in dwarf assembler is
GNU_call_site {
{low_pc "$bar_start + $bar_call_foo" addr}
{abstract_origin :$foo_label}
the DW_AT_low_pc attribute is the return address after the call, so I
rename variable bar_call_foo to returned_from_foo.
gdb/testsuite:
2014-12-29 Yao Qi <yao@codesourcery.com>
* gdb.trace/entry-values.exp: Update comments. Rename variable
bar_call_foo to returned_from_foo.
*** bfd/ChangeLog ***
2014-12-25 Thomas Preud'homme <thomas.preudhomme@arm.com>
* elf32-arm.c (elf32_arm_merge_eabi_attributes): Handle new
Tag_ABI_VFP_args value and replace hardcoded values by enum
values.
(elf32_arm_post_process_headers): Set e_flags in ELF header
as hard float only when Tag_ABI_VFP_args is 1, using new enum
value AEABI_VFP_args_vfp to check that.
*** binutils/ChangeLog ***
2014-12-25 Thomas Preud'homme <thomas.preudhomme@arm.com>
* readelf.c (arm_attr_tag_ABI_VFP_args): Add "compatible".
*** gdb/ChangeLog ***
2014-12-25 Thomas Preud'homme <thomas.preudhomme@arm.com>
* arm-tdep.c (arm_gdbarch_init): Explicitely handle value 3 of
Tag_ABI_VFP_args. Also replace hardcoded values by enum values
in the switch handling the different values of Tag_ABI_VFP_args.
*** gold/ChangeLog ***
2014-12-25 Thomas Preud'homme <thomas.preudhomme@arm.com>
* arm.cc (Target_arm::do_adjust_elf_header): Set e_flags in ELF
header as hard float only when Tag_ABI_VFP_args is 1, using new
enum value AEABI_VFP_args_vfp to check that.
(Target_arm::merge_object_attributes): Handle new Tag_ABI_VFP_args
value and replace hardcoded values by enum values.
*** include/elf/ChangeLog ***
2014-12-25 Thomas Preud'homme <thomas.preudhomme@arm.com>
* arm.h: New AEABI_FP_number_model_* and AEABI_VFP_args_* enum
values.
*** ld/testsuite/ChangeLog ***
2014-12-25 Thomas Preud'homme <thomas.preudhomme@arm.com>
* ld-arm/attr-merge-2a.s: Add Tag_ABI_VFP_args.
* ld-arm/attr-merge-2b.s: Likewise.
* ld-arm/attr-merge-2.attr: Likewise.
* ld-arm/attr-merge-4a.s: Add Tag_ABI_FP_number_model and
Tag_ABI_VFP_args.
* ld-arm/attr-merge-4b.s: Likewise.
* ld-arm/attr-merge-4.attr: Likewise.
* ld-arm/attr-merge-6a.s: Likewise.
* ld-arm/attr-merge-6b.s: Likewise.
* ld-arm/attr-merge-6.attr: Add Tag_ABI_FP_number_model.
gdb/ChangeLog:
* ada-lang.c (user_select_syms): Only fetch symtab if symbol is
objfile-owned.
(cache_symbol): Ignore symbols that are not objfile-owned.
* block.c (block_objfile): New function.
(block_gdbarch): New function.
* block.h (block_objfile): Declare.
(block_gdbarch): Declare.
* c-exp.y (classify_name): Remove call to
language_lookup_primitive_type. No longer necessary.
* gdbtypes.c (lookup_typename): Call lookup_symbol_in_language.
Remove call to language_lookup_primitive_type. No longer necessary.
* guile/scm-symbol.c (syscm_gdbarch_data_key): New static global.
(syscm_gdbarch_data): New struct.
(syscm_init_arch_symbols): New function.
(syscm_get_symbol_map): Renamed from syscm_objfile_symbol_map.
All callers updated. Handle symbols owned by arches.
(gdbscm_symbol_symtab): Handle symbols owned by arches.
(gdbscm_initialize_symbols): Initialize syscm_gdbarch_data_key.
* language.c (language_lookup_primitive_type_1): New function.
(language_lookup_primitive_type): Call it.
(language_alloc_type_symbol): New function.
(language_init_primitive_type_symbols): New function.
(language_lookup_primitive_type_as_symbol): New function.
* language.h (struct language_arch_info) <primitive_type_symbols>:
New member.
(language_lookup_primitive_type): Add function comment.
(language_lookup_primitive_type_as_symbol): Declare.
* printcmd.c (address_info): Handle arch-owned symbols.
* python/py-symbol.c (sympy_get_symtab): Ditto.
(set_symbol): Ditto.
(sympy_dealloc): Ditto.
* symmisc.c (print_symbol): Ditto.
* symtab.c (fixup_symbol_section): Ditto.
(lookup_symbol_aux): Initialize block_found.
(basic_lookup_symbol_nonlocal): Try looking up the symbol as a
primitive type.
(initialize_objfile_symbol_1): New function.
(initialize_objfile_symbol): Call it.
(allocate_symbol): Call it.
(allocate_template_symbol): Call it.
(symbol_objfile): Assert symbol is objfile-owned.
(symbol_arch, symbol_symtab, symbol_set_symtab): Ditto.
* symtab.h (struct symbol) <owner>: Replaces member "symtab".
(struct symbol) <is_objfile_owned>: New member.
(SYMBOL_OBJFILE_OWNED): New macro.
* cp-namespace.c (cp_lookup_bare_symbol): New arg langdef.
All callers updated. Try to find the symbol as a primitive type.
(lookup_namespace_scope): New arg langdef. All callers updated.
Call cp_lookup_bare_symbol directly for simple bare symbols.
This patch fixes a problem when trying to insert a breakpoint on
a specific symbol defined in a specific file, eg:
break foo.c:func
This currently works for files in C/C++/Ada, etc, but doesn't always
work for Asm files. Analysis of the problem showed that this related
to a limitation in gas, which does not generate debug info for functions/
symbols. Thus, we have a symtab for the file ("info sources" shows
the file), but it contains no symbols.
When find_linespec_symbols is called in linespec_parse_basic, it calls
find_function_symbols, which uses add_matching_symbols_to_info to
collect all matching symbols.
That function does [pardon any mangled formatting]:
for (ix = 0; VEC_iterate (symtab_ptr, info->file_symtabs, ix, elt); ++ix)
{
if (elt == NULL)
{
iterate_over_all_matching_symtabs (info->state, name, VAR_DOMAIN,
collect_symbols, info,
pspace, 1);
search_minsyms_for_name (info, name, pspace);
}
else if (pspace == NULL || pspace == SYMTAB_PSPACE (elt))
{
/* Program spaces that are executing startup should have
been filtered out earlier. */
gdb_assert (!SYMTAB_PSPACE (elt)->executing_startup);
set_current_program_space (SYMTAB_PSPACE (elt));
iterate_over_file_blocks (elt, name, VAR_DOMAIN,
collect_symbols, info);
}
}
This iterates over the symtabs. In the failing use case, ELT is
non-NULL (points to the symtab for the .s file), so it calls
iterate_over_file_blocks. Herein is where the problem exists: it is
assumed that if NAME exists, it must exist in the given symtab -- a
reasonable assumption for "normal" (non-asm) cases. It never searches
minimal symbols (or in the global default symtab).
This patch fixes the problem by doing so. It is important to note that
iterating over minsyms is fairly expensive, so this patch only adds
that extra search if the language is language_asm and
iterate_over_file_blocks returns no symbols.
gdb/ChangeLog:
2014-12-20 Keith Seitz <keiths@redhat.com>
Mihail-Marian Nistor <mihail.nistor@freescale.com>
PR gdb/17394
* linespec.c (struct collect_minsyms): Add new member `symtab'.
(add_minsym): Handle cases where info.symtab is non-NULL.
(search_minsyms_for_name): Add new parameter `symtab'.
Handle limiting searches to a specific symtab.
(add_matching_symtabs_to_info): Search through minimal symbols
for language_asm files for which no new symbols are found.
gdb/testsuite/ChangeLog:
2014-12-20 Mihail-Marian Nistor <mihail.nistor@freescale.com>
PR gdb/17394
* gdb.linespec/break-asm-file.c: New file.
* gdb.linespec/break-asm-file.exp: New file.
* gdb.linespec/break-asm-file0.s: New file.
* gdb.linespec/break-asm-file1.s: New file.
This patch is to add SDE OS ABI support in GDB, which has been used in
codesourcery gdb tree for some years.
gdb:
2014-12-19 Maciej W. Rozycki <macro@codesourcery.com>
Nigel Stephens <nigel@mips.com>
Chris Dearman <chris@mips.com>
Luis Machado <lgustavo@codesourcery.com>
* Makefile.in (ALL_TARGET_OBS): Add mips-sde-tdep.o.
(ALLDEPFILES): Add mips-sde-tdep.c.
* mips-sde-tdep.c: New file containg SDE specific code.
* configure.tgt (mips*-sde*-elf*): Add mips-sde-dep.o to
gdb_target_obs.
* defs.h (gdb_osabi): Add GDB_OSABI_SDE.
* osabi.c (gdb_osabi_names): Add SDE.
* NEWS: Mention the change.
I stumbled upon a few comments that I think are outdated.
Comment for elfread.c (elf_symfile_init): As far as history goes in git,
I don't see anything related to that.
Comment for elfread.c (elf_symfile_read): References a parameter that was
removed in 1999.
Comment for struct sym_fns/sym_offsets: References a parameter that was
changed in 1999.
gdb/ChangeLog:
* elfread.c (elf_symfile_init): Remove stale comment.
(elf_symfile_read): Same.
* symfile.h (struct sym_fns): Same.
This patch is the V2. V1 can be found in
https://sourceware.org/ml/gdb-patches/2012-05/msg00938.html
V2 is to address Joel's comment
<https://sourceware.org/ml/gdb-patches/2012-06/msg00289.html> about
keeping dumping floating point registers. Additionally, command
'info float' prints bits on nan2008 and abs2008.
------------------------------------------------------------------
The change below provides a MIPS-specific handler for the:
(gdb) info float
command. It provides information about the FPU type available (if any),
the FPU register width, and decodes the CP1 Floating Point Control and
Status Register (FCSR):
(gdb) print /x $fsr
$1 = 0xff83ffff
(gdb) info float
fpu type: double-precision
reg size: 32 bits
cond : 0 1 2 3 4 5 6 7
cause : inexact uflow oflow div0 inval unimp
mask : inexact uflow oflow div0 inval
flags : inexact uflow oflow div0 inval
rounding: -inf
flush : zero
One point to note about CP1.FCSR are the non-standard Flush-to-Nearest
and Flush-Override bits. They are not a part of the MIPS architecture and
take two positions reserved for an implementation-dependent use in the
architecture. They are present in all the FPU implementations made by
MIPS Technologies since the spin-off from SGI.
I haven't been able to track down a single other MIPS FPU implementation
that would make any use of these bits and they are required to be
hardwired to zero by the architecture specification if unimplemented.
Therefore I think it makes sense to report them in the current way.
GDB has no guaranteed access to the CP0 Processor Identification (PRId)
register to validate this feature properly and the ID information stored
in the CP1 Floating Point Implementation Register (FIR) is from my
experience not reliable enough (there's no Company ID available there for
once unlike in CP0.PRId and Processor ID is not guaranteed to be unique).
As a side note we should probably dump CP1.FIR information as well, as
there's useful stuff indicating some FPU features there. That's material
for another change however.
gdb/
2014-12-18 Nigel Stephens <nigel@mips.com>
Maciej W. Rozycki <macro@codesourcery.com>
* mips-tdep.c (print_fpu_flags): New function.
(mips_print_float_info): Likewise.
(mips_gdbarch_init): Install mips_print_float_info as gdbarch
print_float_info routine.
gdb/testsuite/
2014-12-18 Nigel Stephens <nigel@mips.com>
Maciej W. Rozycki <macro@codesourcery.com>
* gdb.base/float.exp: Handle the new output from "info float" on
MIPS targets.
This patch is to change print_float_info gdbarch method for the
following two reasons,
1. we want to add a default implementation of print_float_info to
dump the float pointer registers. It can be reused by backend to
print something more than float point registers.
2. we want to simplify the caller of print_float_info,
infcmd.c:print_float_info.
gdb:
2014-12-18 Yao Qi <yao@codesourcery.com>
* gdbarch.sh (print_float_info): Change its type from 'M' to 'm'.
* gdbarch.c: Re-generated.
* gdbarch.h: Likewise.
* infcmd.c (default_print_float_info): New function.
(print_float_info): Removed. Move code to
default_print_float_info.
(float_info): Adjust to call gdbarch_print_float_info.
* inferior.h (default_print_float_info): Declare it.
In infcmd.c:print_float_info, if the architecture doesn't have gdbarch
method print_float_info implemented and doesn't float reggroup, GDB
will prints "No floating-point info available for this processor."
The h8300 port doesn't have float registers, and don't need to
implement print_float_info. This patch is to remove it.
gdb:
2014-12-18 Yao Qi <yao@codesourcery.com>
* h8300-tdep.c (h8300_print_float_info): Remove.
(h8300_gdbarch_init): Remove the call to
set_gdbarch_print_float_info.
On Sun, 14 Dec 2014 07:00:28 +0100, Yao Qi wrote:
The build on mingw host is broken because mingw has no mkdtemp.
../../../git/gdb/compile/compile.c: In function 'get_compile_file_tempdir':
../../../git/gdb/compile/compile.c:194:3: error: implicit declaration of function 'mkdtemp' [-Werror=implicit-function-declaration]
tempdir_name = mkdtemp (tname);
^
../../../git/gdb/compile/compile.c:194:16: error: assignment makes pointer from integer without a cast [-Werror]
tempdir_name = mkdtemp (tname);
^
cc1: all warnings being treated as errors
In the end I have managed to test it by Wine myself:
$ wine build_win32/gdb/gdb.exe -q build_win32/gdb/gdb.exe -ex start -ex 'compile code 1' -ex 'set confirm no' -ex quit
[...]
Temporary breakpoint 1, main (argc=1, argv=0x241418) at ../../gdb/gdb.c:29
29 args.argc = argc;
Could not load libcc1.so: Module not found.
Even if it managed to load libcc1.so (it needs host-dependent name libcc1.dll)
then it would soon end up at least on:
default_infcall_mmap:
error (_("This target does not support inferior memory allocation by mmap."));
As currently there is only:
linux-tdep.c:
set_gdbarch_infcall_mmap (gdbarch, linux_infcall_mmap);
While one could debug Linux targets from MS-Windows host I find it somehow
overcomplicated now when we are trying to get it running at least on native
Linux x86*.
The 'compile' project needs a larger port effort to run on MS-Windows.
gdb/ChangeLog
2014-12-17 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix MinGW compilation.
* compile/compile.c (get_compile_file_tempdir): Call error if
!HAVE_MKDTEMP.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac (AC_CHECK_FUNCS): Add mkdtemp.
gdb/testsuite/ChangeLog
2014-12-17 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix MinGW compilation.
* gdb.compile/compile-ops.exp: Update untested message if
!skip_compile_feature_tests.
* gdb.compile/compile-setjmp.exp: Likewise.
* gdb.compile/compile-tls.exp: Likewise.
* gdb.compile/compile.exp: Likewise.
* lib/gdb.exp (skip_compile_feature_tests): Check also "Command not
supported on this host".
Anytime you can remove a symbol lookup that loops over all objfiles
is A Good Thing.
The call to lookup_static_symbol in valops.c:value_maybe_namespace_elt
is redundant with this call in cp_lookup_nested_symbol:
/* Now search all static file-level symbols. We have to do this
for things like typedefs in the class. We do not try to
guess any imported namespace as even the fully specified
namespace search is already not C++ compliant and more
assumptions could make it too magic. */
size = strlen (parent_name) + 2 + strlen (nested_name) + 1;
concatenated_name = alloca (size);
xsnprintf (concatenated_name, size, "%s::%s",
parent_name, nested_name);
sym = lookup_static_symbol (concatenated_name, VAR_DOMAIN);
if (sym != NULL)
return sym;
Earlier in value_maybe_namespace_elt we do this:
sym = cp_lookup_symbol_namespace (namespace_name, name,
get_selected_block (0), VAR_DOMAIN);
That sequence goes like:
value_maybe_namespace_elt
-> cp_lookup_symbol_namespace
-> cp_lookup_symbol_in_namespace
-> lookup_symbol_file
-> cp_lookup_nested_symbol
-> lookup_static_symbol
The call was added in commit 41f62f3939.
https://sourceware.org/ml/gdb-patches/2010-06/msg00663.html
With a part 2 here:
https://sourceware.org/ml/gdb-patches/2010-06/msg00664.html
At the time the call to lookup_static_symbol (spelled
lookup_static_symbol_aux at the time) was needed.
However, this patch, 8dea366bbe,
https://sourceware.org/ml/gdb-patches/2012-11/msg00387.html
augmented lookup_symbol_file to call cp_lookup_nested_symbol
and introduced the redundancy.
It's kinda buried, so it's totally not unexpected that this happened.
gdb/ChangeLog:
* valops.c (value_maybe_namespace_elt): Remove redundant call to
lookup_static_symbol.
gdb/ChangeLog:
* buildsym.c: Add comments describing how the buildsym machinery
is used by the various file formats.
(really_free_pendings): Enhance function comment.
See pending_macros to NULL. Simplify resetting pending_addrmap.
Call free_buildsym_compunit.
(free_buildsym_compunit): Set current_subfile to NULL.
(prepare_for_building): New function.
(start_symtab): Call it. Remove call to set_last_source_file.
(restart_symtab): New arg "cust". All callers updated.
Simplify, call prepare_for_building. Re-initialize buildsym_compunit.
(reset_symtab_globals): Enhance function comment.
Set local_symbols, file_symbols, global_symbols to NULL.
Set pending_macros to NULL. Simplify resetting pending_addrmap.
Call free_buildysym_compunit.
(end_symtab_without_blockvector): Delete. All callers updated.
(end_symtab_with_blockvector): Remove redundant call to
free_buildsym_compunit.
(augment_type_symtab): Remove arg "cust". All callers updated.
(buildsym_init): Remove resetting of free_pendings, file_symbols,
global_symbols, pending_blocks, pending_macros. Instead make
handling consistent with pending_addrmap: Assert value was reset
at end of previous symtab building. Initialize context_stack here.
This fixes a failure of the test case "complete 'info registers '" in
completion.exp on architectures where the user registers have numbers
above 99. In that case the output of "maint print user-registers" was
no longer indented, and the regexp in the test case failed to add them
to the list of expected completion results. The fix also swaps the
columns "Name" and "Nr", such that the indentation is always the same,
and to be consistent with the output of "maint print registers".
gdb/ChangeLog:
* user-regs.c (maintenance_print_user_registers): Swap "Nr" and
"Name" columns. Assure that the output is always indented.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Adjust to format changes of "maint
print user-registers".
This patch enhances GDB on GNU/Linux systems in the situation where
we are debugging an inferior that was created from GDB (as opposed
to attached to), by asking the kernel to kill the inferior if GDB
terminates without doing it itself.
This would typically happen when GDB encounters a problem and
crashes, or when it gets killed by an external process. This can
be observed by starting a program under GDB, and then killing
GDB with signal 9. After GDB is killed, the inferior still remains.
This patch also fixes GDBserver similarly.
This fix is conditional on the kernel supporting the PTRACE_O_EXITKILL
feature. On older kernels, the behavior remains unchanged.
gdb/ChangeLog:
* nat/linux-ptrace.h (PTRACE_O_EXITKILL): Define if not
already defined.
(linux_enable_event_reporting): Add parameter "attached".
* nat/linux-ptrace.c (linux_test_for_exitkill): New forward
declaration. New function.
(linux_check_ptrace_features): Add linux_test_for_exitkill call.
(linux_enable_event_reporting): Add new parameter "attached".
Do not call ptrace with the PTRACE_O_EXITKILL if ATTACHED is
nonzero.
* linux-nat.c (linux_init_ptrace): Add parameter "attached".
Use it. Update function description.
(linux_child_post_attach, linux_child_post_startup_inferior):
Update call to linux_enable_event_reporting.
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_low_filter_event): Update call to
linux_enable_event_reporting following the addition of
a new parameter to that function.
Tested on x86_64-linux, native and native-gdbserver.
I also verified by hand that the inferior gets killed when killing
GDB in the "run" case, while the inferior remains in the "attach"
case. Same for GDBserver.
When using aarch64 gdb with gdbserver, floating point registers are
not correctly displayed, as below:
(gdb) info registers fpsr fpcr
fpsr <unavailable>
fpcr <unavailable>
To fix these problems, the missing fpsr and fpcr registers are added
when floating point registers are read/write
Add test for aarch64 floating point
PR server/17457
gdb/gdbserver/
PR server/17457
* linux-aarch64-low.c (AARCH64_FPSR_REGNO): New define.
(AARCH64_FPCR_REGNO): Likewise.
(AARCH64_NUM_REGS): Update to include fpsr/fpcr registers.
(aarch64_fill_fpregset): Add missing fpsr/fpcr registers.
(aarch64_store_fpregset): Likewise.
gdb/testsuite/
PR server/17457
* gdb.arch/aarch64-fp.c: New file.
* gdb.arch/aarch64-fp.exp: New file.
Signed-off-by: Catalin Udma <catalin.udma@freescale.com>
We define an enum ARG_MAX in linux_infcall_mmap, but it is conflict
with macro ARG_MAX which is defined in /usr/include/linux/limits.h.
This causes a build failure below,
gdb/linux-tdep.c: In function 'linux_infcall_mmap':
gdb/linux-tdep.c:1945:70: error: expected identifier before numeric constant
the enum in the pre-processed source becomes:
enum
{
ARG_ADDR, ARG_LENGTH, ARG_PROT, ARG_FLAGS, ARG_FD, ARG_OFFSET, 131072
};
This patch is to replace ARG_MAX with ARG_LAST.
gdb:
2014-12-16 Yao Qi <yao@codesourcery.com>
* linux-tdep.c (linux_infcall_mmap): Replace ARG_MAX with
ARG_LAST.
It has been a while since we don't sync this file with GCC upstream,
and in the meantime some interesting things have happened. The most
interesting is the inclusion of a new dg-extract-results.py which is
apparently faster than its shell equivalent.
This merge will probably fix the bug described in
<https://sourceware.org/ml/gdb-patches/2014-12/msg00421.html>
Though I am still proposing the patch for upstream GCC. Once it gets
accepted, I will merge it too.
OK to apply?
gdb/testsuite/ChangeLog:
2014-12-15 Sergio Durigan Junior <sergiodj@redhat.com>
Merge dg-extract-results.{sh,py} from GCC upstream (r210243,
r210637, r210913, r211666, r215400, r215817).
2014-05-08 Richard Sandiford <rdsandiford@googlemail.com>
* dg-extract-results.py: New file.
* dg-extract-results.sh: Use it if the environment seems
suitable.
2014-05-20 Richard Sandiford <rdsandiford@googlemail.com>
* dg-extract-results.py (parse_run): Handle warnings that
are printed before a test harness is run.
2014-05-25 Richard Sandiford <rdsandiford@googlemail.com>
* dg-extract-results.py (Named): Remove __cmp__ method.
(output_variation): Use a key to sort variation.harnesses.
2014-06-14 Richard Sandiford <rdsandiford@googlemail.com>
* dg-extract-results.py: For Python 3, force sys.stdout to
handle surrogate escape sequences.
(safe_open): New function.
(output_segment, main): Use it.
2014-09-19 Segher Boessenkool <segher@kernel.crashing.org>
* dg-extract-results.py (Prog.result_re): Include options
in test name.
2014-10-02 Segher Boessenkool <segher@kernel.crashing.org>
* dg-extract-results.py (output_variation): Always sort if
do_sum.
This patch introduces find_inferior_ptid to replace the common idiom
find_inferior_pid (ptid_get_pid (...));
It replaces all the instances of that idiom that I found with the new
function.
No significant changes before/after the patch in the regression suite
on amd64 linux.
gdb/ChangeLog:
* inferior.c (find_inferior_ptid): New function.
* inferior.h (find_inferior_ptid): New declaration.
* ada-tasks.c (ada_get_task_number): Use find_inferior_ptid.
* corelow.c (core_pid_to_str): Same.
* darwin-nat.c (darwin_resume): Same.
* infrun.c (fetch_inferior_event): Same.
(get_inferior_stop_soon): Same.
(handle_inferior_event): Same.
(handle_signal_stop): Same.
* linux-nat.c (resume_lwp): Same.
(stop_wait_callback): Same.
* mi/mi-interp.c (mi_new_thread): Same.
(mi_thread_exit): Same.
* proc-service.c (ps_pglobal_lookup): Same.
* record-btrace.c (record_btrace_step_thread): Same.
* remote-sim.c (gdbsim_close_inferior): Same.
(gdbsim_resume): Same.
(gdbsim_stop): Same.
* sol2-tdep.c (sol2_core_pid_to_str): Same.
* target.c (memory_xfer_partial_1): Same.
(default_thread_address_space): Same.
* thread.c (thread_change_ptid): Same.
(switch_to_thread): Same.
(do_restore_current_thread_cleanup): Same.
When gdb starts, the lines that appear before the first prompt may get
paginated if the terminal in which the tests are ran is too small (in
terms of rows). These lines include the welcome/license message and
possibly more, such as "Reading symbols from...". Pagination is disabled
right after gdb is started (with "set height 0"), but this output happens
before we are able to set height.
If these lines get paginated, gdb waits for the user to press enter and
the test harness waits for gdb to print its prompt, resulting in a
deadlock.
My first idea was to launch gdb with --quiet. However, some lines are
still printed ("Reading symbols from...", some more stuff when attaching
with --pid, etc).
The proposed solution simply expects that pagination can occur after
starting gdb. If this is the case, it sends a "\n" and loops.
gdb/testsuite/Changelog:
* lib/gdb.exp (default_gdb_start): After starting gdb, loop
as long as we get pagination notifications.
The type of the function pointer PyOS_ReadlineFunctionPointer (part of the
Python C API), which we use, slightly changed starting with Python 3.4. The
signature went from
PyAPI_DATA(char) *(*PyOS_ReadlineFunctionPointer)(FILE *, FILE *, char *);
to
PyAPI_DATA(char) *(*PyOS_ReadlineFunctionPointer)(FILE *, FILE *, const char *);
The parameter that changed is the prompt text.
This commits adjust gdb accordingly by making the prompt_arg parameter
const, as well as the fallouts of that. I needed to rework how
annotations are added to the prompt, since the it is now const. If
annotations are enabled, it will make a copy of the prompt overwrite the
prompt variable that is used throughout the function. Otherwise, no copy
is done and the original prompt_arg value is passed.
I changed the signature of deprecated_readline_hook. I would've changed any
user of it, but it seems like nothing is using it,
Built-tested with python 2.7.x, 3.3.y and 3.4.z.
gdb/ChangeLog:
* defs.h (gdb_readline): Constify argument.
(gdb_readline_wrapper): Same.
(command_line_input): Same.
(deprecated_readline_hook): Same.
* top.c (deprecated_readline_hook): Same.
(gdb_readline): Same.
(gdb_readline_wrapper): Same.
(command_line_input): Constify argument. Pass prompt to
called functions instead of local_prompt, overwriting prompt
if using annotations.
* event-top.h (display_gdb_prompt): Constify argument.
* event-top.c (display_gdb_prompt): Same.
* python/py-gdb-readline.c (gdbpy_readline_wrapper): Constify
argument if building with Python 3.4 and up.
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
It seems like using os.getcwdu() here is wrong both for Python 2 and Python 3.
For Python 2, this returns a 'unicode' object, which tries to get concatenated
to a 'str' object in substitute_prompt. The implicit conversion works when the
unicode string contains no accent. When it does contain an accent though,
displaying the prompt results in the following error:
(gdb) set extended-prompt \w
...
File "/home/simark/build/binutils-gdb-python2/gdb/data-directory/python/gdb/prompt.py", line 138, in substitute_prompt
result += str(cmd(arg))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 49: ordinal not in range(128)
When using os.getcwd() instead, it works correctly. I suppose that Python does
the necessary decoding internally.
For Python 3, this method simply does not exist. It works fine with os.getcwd().
gdb/ChangeLog:
* python/lib/gdb/prompt.py (_prompt_pwd): Use os.getcwd() instead of
os.getcwdu().
Currently, when we receive a request to single-step one single thread
(Eg, when single-stepping out of a breakpoint), we use the
PTRACE_SINGLESTEP pthread request, which does single-step
the corresponding thread, but also resumes execution of all
other threads in the inferior.
This causes problems when debugging programs where another thread
receives multiple debug events while trying to single-step a specific
thread out of a breakpoint (with infrun traces turned on):
(gdb) continue
Continuing.
infrun: clear_proceed_status_thread (Thread 126)
[...]
infrun: clear_proceed_status_thread (Thread 142)
[...]
infrun: clear_proceed_status_thread (Thread 146)
infrun: clear_proceed_status_thread (Thread 125)
infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT, step=0)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 142] at 0x10684838
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 42000 [Thread 146],
infrun: status->kind = stopped, signal = GDB_SIGNAL_REALTIME_34
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x10a187f4
infrun: context switch
infrun: Switching context from Thread 142 to Thread 146
infrun: random signal (GDB_SIGNAL_REALTIME_34)
infrun: switching back to stepped thread
infrun: Switching context from Thread 146 to Thread 142
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 142] at 0x10684838
infrun: prepare_to_wait
[...handling of similar events for threads 145, 144 and 143 snipped...]
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 42000 [Thread 146],
infrun: status->kind = stopped, signal = GDB_SIGNAL_REALTIME_34
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x10a187f4
infrun: context switch
infrun: Switching context from Thread 142 to Thread 146
../../src/gdb/inline-frame.c:339: internal-error: skip_inline_frames: Assertion `find_inline_frame_state (ptid) == NULL' failed.
What happens is that GDB keeps sending requests to resume one specific
thread, and keeps receiving debugging events for other threads.
Things break down when the one of the other threads receives a debug
event for the second time (thread 146 in the example above).
This patch fixes the problem by making sure that only one thread
gets resumed, thus preventing the other threads from generating
an unexpected event.
gdb/gdbserver/ChangeLog:
* lynx-low.c (lynx_resume): Use PTRACE_SINGLESTEP_ONE if N == 1.
Remove FIXME comment about assumption about N.
When running gdb on 32 bits host for 64 bits target, info mem command
truncates the target address to 32 bits, like in the example below
(gdb) set architecture powerpc:common64
(gdb) mem 0x100000000 0x200000000 rw
(gdb) info mem
1 y 0x0000000000000000 0x0000000000000000 rw nocache
gdb/ChangeLog:
PR gdb/15684
* memattr.c (mem_info_command): Remove "unsigned long" casts.
Signed-off-by: Catalin Udma <catalin.udma@freescale.com>
Trying to print the value of a string whose size is not known at
compile-time before it gets assigned a value can lead to the following
internal error:
(gdb) p my_str
$1 =
/[...]/utils.c:1089: internal-error: virtual memory exhausted.
What happens is that my_str is described as a reference to an array
type whose bounds are dynamic. During the read of that variable's
value (in default_read_var_value), we end up resolving dynamic types
which, for reference types, makes us also resolve the target of that
reference type. This means we resolve our variable to a reference
to an array whose bounds are undefined, and unfortunately very far
appart.
So, when we pass that value to ada-valprint, and in particular to
da_val_print_ref, we eventually try to allocate too large of a buffer
corresponding to the (bogus) size of our array, hence the internal
error.
This patch fixes the problem by adding a size_check before trying
to print the dereferenced value. To perform this check, a function
that was previously specific to ada-lang.c (check_size) gets
exported, and renamed to something less prone to name collisions
(ada_ensure_varsize_limit).
gdb/ChangeLog:
* ada-lang.h (ada_ensure_varsize_limit): Declare.
* ada-lang.c (check_size): Remove advance declaration.
(ada_ensure_varsize_limit): Renames check_size.
Replace calls to check_size by calls to ada_ensure_varsize_limit
throughout.
* ada-valprint.c (ada_val_print_ref): Add call to
ada_ensure_varsize_limit. Add comment explaining why.
gdb/testsuite/ChangeLog:
* gdb.ada/str_uninit: New testcase.
The use of sprintf is discouraged in GDB. Use xsnprintf instead.
gdb/ChangeLog:
* utils.c (make_hex_string): Replace use of sprintf by use of
xsnprintf.
Tested on x86_64-linux.
gdb/ChangeLog:
* compile/compile-object-load.c (link_callbacks_multiple_definition)
(link_callbacks_warning, link_callbacks_einfo): Remove trailing
newline at end of warning message.
Tested on x86_64-linux.
