The HISTSIZE environment variable is generally expected to be read by
shells, not by applications. Some distros for example globally export
HISTSIZE in /etc/profile -- with the intention that it only affects
shells -- and by doing so it renders useless GDB's own mechanism for
setting the history size via .gdbinit. Also, annoyances may arise when
HISTSIZE is not interpreted the same way by the shell and by GDB, e.g.
PR gdb/16999. That can always be fixed on a shell-by-shell basis but it
may be impossible to be consistent with the behavior of all shells at
once. Finally it just makes sense to not confound shell environment
variables with application environment variables.
gdb/ChangeLog:
* NEWS: Mention that GDBHISTSIZE is read instead of HISTSIZE.
* top.c (init_history): Read from GDBHISTSIZE instead of
HISTSIZE.
(init_main): Refer to GDBHISTSIZE instead of HISTSIZE.
gdb/doc/ChangeLog:
* gdb.texinfo (Command History): Replace occurrences of HISTSIZE
with GDBHISTSIZE.
gdb/testsuite/ChangeLog:
* gdb.base/gdbinit-history.exp: Replace occurrences of HISTSIZE
with GDBHISTSIZE.
* gdb.base/readline.exp: Likewise.
This patch fixes the following tcl error
Running ../../../binutils-gdb/gdb/testsuite/gdb.base/break-interp.exp ...
ERROR: (DejaGnu) proc "else" does not exist.
The error code is NONE
The info on the error is:
invalid command name "else"
while executing
"::tcl_unknown else"
("uplevel" body line 1)
invoked from within
"uplevel 1 ::tcl_unknown $args"
gdb/testsuite:
2015-06-17 Yao Qi <yao.qi@linaro.org>
* lib/gdb.exp (get_build_id): Move braces and "else" to the same
line.
We still do not handle "set history size unlimited" correctly. In
particular, after writing to the history file, we truncate the history
even if it is unlimited.
This patch makes sure that we do not call history_truncate_file() if the
history is not stifled (i.e. if it's unlimited). This bug causes the
history file to be truncated to zero on exit when one has "set history
size unlimited" in their gdbinit file. Although this code exists in GDB
7.8, the bug is masked by a pre-existing bug that's been only fixed in
GDB 7.9 (PR gdb/17820).
gdb/ChangeLog:
* top.c (gdb_safe_append_history): Do not call
history_truncate_file if the history is not stifled.
gdb/testsuite/ChangeLog:
* gdb.base/gdbinit-history.exp: Add test case to check that
an unlimited history file does not get truncated on exit.
So far the gnu_vector test was limited to "static" aspects of GDB's
vector support, like evaluating vector-valued expressions. This patch
enriches the test and adds checks for GDB's vector ABI support as well.
The new checks particularly verify inferior function calls with vector
arguments and GDB's handling of vector return values.
The test now attempts to compile for the target's "native" architecture,
such that a hardware vector ABI is used if available.
Since GDB has no vector ABI support for x86 and x86_64 targets, most of
the new checks are KFAILed there.
gdb/testsuite/ChangeLog:
* gdb.base/gnu_vector.c: Include stdarg.h and stdio.h.
(VECTOR): New macro. Use it...
(int4, uint4, char4, float4, int2, longlong2, float2, double2):
...for these typedefs.
(int8, char1, int1, double1): New typedefs.
(struct just_int2, struct two_int2): New structures.
(add_some_intvecs, add_many_charvecs, add_various_floatvecs)
(add_structvecs, add_singlevecs): New functions.
(main): Call add_some_intvecs twice.
* gdb.base/gnu_vector.exp: Drop GCC version check; just attempt
the compile and exit upon failure. Try compiling for the "native"
architecture. Test inferior function calls with vector arguments
and vector return value handling with "finish" and "return".
This promotes BFD's struct elf_build_id to the generic struct bfd_build_id,
populated when an ELF or PE BFD is read.
gdb is updated to use that, and to use the build-id to find symbols for PE files
also.
There is currently no generic way to extract the build-id from an object file,
perhaps an option to objdump to do this might make sense?
On x86_64-pc-cygwin, gdb's sepdebug.exp changes:
-# of unsupported tests 1
+# of expected passes 90
I don't seem to get consistent testsuite runs on i686-linux-gnu, but there
don't appear to be any regressions.
bfd/ChangeLog:
2015-06-10 Jon Turney <jon.turney@dronecode.org.uk>
* elf-bfd.h : Remove struct elf_build_id.
* bfd.c : Add struct bfd_build_id.
* bfd-in2.h: Regenerate.
* elf.c (elfobj_grok_gnu_build_id): Update to use bfd_build_id.
* libpei.h: Add protoype and macros for
bfd_XXi_slurp_codeview_record.
* peXXigen.c (_bfd_XXi_slurp_codeview_record): Make public
* peicode.h (pe_bfd_read_buildid): Add.
(pe_bfd_object_p): Use pe_bfd_read_buildid().
gdb/ChangeLog:
2015-06-10 Jon Turney <jon.turney@dronecode.org.uk>
* build-id.c: Don't include elf-bfd.h.
(build_id_bfd_get): Use bfd_build_id.
(build_id_verify): Ditto.
* build-id.h: Ditto.
(find_separate_debug_file_by_buildid): Ditto.
* python/py-objfile.c: Don't include elf-bfd.h.
(objfpy_get_build_id) Use bfd_build_id.
(objfpy_build_id_matches, objfpy_lookup_objfile_by_build_id): Ditto.
* coffread.c: Include build-id.h.
(coff_symfile_read): Try find_separate_debug_file_by_buildid.
gdb/doc/ChangeLog:
2015-06-10 Jon Turney <jon.turney@dronecode.org.uk>
* gdb.texinfo (Separate Debug Files): Document that PE is also
supported.
gdb/testsuite/ChangeLog:
2015-06-10 Jon Turney <jon.turney@dronecode.org.uk>
* gdb.base/sepdebug.exp: Add EXEEXT where needed.
* lib/gdb.exp (get_build_id): Teach how to extract build-id from a
PE file.
* lib/future.exp (gdb_find_objdump): Add gdb_find_objdump.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
This patch fixes the "Format string required" error when trying to print
a dprintf on a now resolved, pending location when set via the MI interface
even if the format string is entered correctly.
This patch also adds a test case to check that issue called
mi-dprintf-pending.exp.
gdb/ChangeLog:
PR breakpoints/16465
* breakpoint.c (create_breakpoint): Save extra_string for
pending breakpoints.
gdb/testsuite/ChangeLog:
PR breakpoints/16465
* gdb.mi/mi-dprintf-pending.c: New file.
* gdb.mi/mi-dprintf-pending.exp: New test.
* gdb.mi/mi-dprintf-pendshr.c: New file.
Intel(R) Memory protection bound information are located in register
to be tested using the MPX new instructions. Since the number of
bound registers are limited a table is used to provide storage for
bounds during run-time.
In order to investigate the contents of the MPX bound table two new
commands are added to GDB. "show mpx bound" and "set mpx bound" are
used to display and set values on the MPX bound table.
2015-04-20 Walfred Tedeschi <walfred.tedeschi@intel.com>
Mircea Gherzan <mircea.gherzan@intel.com>
* i386-tdep.c (MPX_BASE_MASK, MPX_BD_MASK, MPX_BT_MASK, MPX_BD_MASK_32,
MPX_BT_MASK_32): New macros.
(i386_mpx_set_bounds): New function that implements
the command "set-mpx-bound".
(i386_mpx_enabled) Helper function to test MPX availability.
(i386_mpx_bd_base) Helper function to calculate the base directory
address. (i386_mpx_get_bt_entry) Helper function to access a bound
table entry. (i386_mpx_print_bounds) Effectively display bound
information. (_initialize_i386_tdep): Qdd new commands
to commands "set mpx" and "show mpx". (_initialize_i386_tdep):
Add "bound" to the commands "show mpx" and "set mpx" commands.
(mpx_set_cmdlist and mpx_show_cmdlist):
list for the new prefixed "set mpx" and "show mpx" commands.
* NEWS: List new commands for MPX support.
testsuite:
* gdb.arch/i386-mpx-map.c: New file.
* gdb.arch/i386-mpx-map.exp: New File.
doc:
* gdb.texinfo (i386): Add documentation about "show mpx bound"
and "set mpx bound".
Skips the MPX register test in case target is not Intel.
Improves the test for MPX feature making MPX and AVX512
tests more similar in terms of initialization.
Indentation was improved on sample file and final return added
to have_mpx. On test file identation was improved and
gdb_send was exchanged by gdb_test_multiple.
2015-06-08 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/testsuite
* gdb.arch/i386-mpx.c: Added final return to the have_mpx
function and improved indentation.
* gdb.arch/i386-mpx.exp: Exchanging gdb_send and gdb_expect for
gdb_test_multiple. Added additional tests to skip the test.
Changes on the path for i386-cpuid.h file lead to failure in compiling
tests for AVX512 and MPX.
2015-06-08 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/testsuite
* gdb.arch/i386-avx512.c: Change path in include file.
* gdb.arch/i386-avx512.exp: Change include dir path
compilation flag.
* gdb.arch/i386-mpx.c: Change path in include file.
* gdb.arch/i386-mpx.exp: Change include dir path compilation
flag.
Patch implementing '@' GDB array operator in GCC has been rejected:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00414.html
and so there is now a GDB tracker to implement it just in GDB:
https://sourceware.org/bugzilla/show_bug.cgi?id=18489
gdb/testsuite/ChangeLog
2015-06-04 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile-print.exp (compile print *vararray@3)
(compile print *vararrayp@3): Change xfail to kfail compile/18489.
Currently inferior memory is allocated by inferior mmap() but it is never
deallocated; despite the injected objfile incl. its symbols is freed. This was
intentional so that one can do for example:
inferior:
char *str = "foo";
GDB:
(gdb) compile code str = "bar";
I believe later patches will be needed to introduce full control over keeping
vs. discarding the injected module as being discussed in:
compile: objfiles lifetime UI
https://sourceware.org/ml/gdb/2015-04/msg00051.html
Message-ID: <20150429135735.GA16974@host1.jankratochvil.net>
https://sourceware.org/ml/gdb/2015-05/msg00007.html
As decided by Phil it is better not to leak inferior pages as users can
workaround the issue above for example by:
(gdb) compile code str = strdup ("bar");
I have checked that in fact gdb/doc/ (written by Phil) already expects the
injected code will be unmapped so that does not need to be changed:
compile code int ff = 5; p = &ff;
In this example, @code{p} would point to @code{ff} when the
@code{compile} command is executing the source code provided to it.
However, as variables in the (example) program persist with their
assigned values, the variable @code{p} would point to an invalid
location when the command exists.
gdb/ChangeLog
2015-04-28 Jan Kratochvil <jan.kratochvil@redhat.com>
* arch-utils.c (default_infcall_munmap): New.
* arch-utils.h (default_infcall_munmap): New declaration.
* compile/compile-object-load.c (struct munmap_list, munmap_list_add)
(munmap_list_free, munmap_listp_free_cleanup): New.
(struct setup_sections_data): Add field munmap_list_headp.
(setup_sections): Call munmap_list_add.
(compile_object_load): New variable munmap_list_head, initialize
setup_sections_data.munmap_list_headp, return munmap_list_head.
* compile/compile-object-load.h (struct munmap_list): New declaration.
(struct compile_module): Add field munmap_list_head.
(munmap_list_free): New declaration.
* compile/compile-object-run.c (struct do_module_cleanup): Add field
munmap_list_head.
(do_module_cleanup): Call munmap_list_free.
(compile_object_run): Pass munmap_list_head to do_module_cleanup.
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (infcall_munmap): New.
* linux-tdep.c (linux_infcall_munmap): New.
(linux_init_abi): Install it.
gdb/testsuite/ChangeLog
2015-04-28 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile.exp (keep jit in memory): Rename to ...
(do not keep jit in memory): ... this.
(expect 5): Change it to ...
(expect no 5): ... this.
I sent a patch in 2013 for this (incorrectly named =thread-created):
https://cygwin.com/ml/gdb-patches/2013-06/msg00129.html
Tom Tromey was ok with the change, but suggested to add a test as well.
Then I forgot about this patch until today. So here it is again, with the
corresponding test.
The problem is that the =thread-exited event does not appear when detaching
from a local process. It does appear with remote though. It's not a really
big deal, but I'd like it to be consistent.
Tested with local and remote Linux on my Ubuntu 14.04.
gdb/ChangeLog:
PR gdb/15564
* inferior.c (detach_inferior): Call exit_inferior_1 with silent = 0.
gdb/testsuite/ChangeLog:
PR gdb/15564
* gdb.mi/mi-detach.exp: New file.
Initially there is some chain (let's say the longest one
but that doe snot matter). Consequently its elements from the middle are
being removed and there remains only some few unambiguous top and bottom ones.
The original idea why the comparison should be sharp ("<") was that if there
are multiple chains like (0xaddr show jmp instruction address):
main(0x100) -> a(0x200) -> d(0x400)
main(0x100) -> a(0x200) -> c(0x300) -> d(0x400)
then - such situation cannot exist - if two jmp instructions in "a" have the
same address they must also jump to the same address (*).
(*) jump to a computed address would be never considered for the DWARF
tail-call records.
So there could be:
main(0x100) -> a(0x200) -> d(0x400)
main(0x100) -> a(0x270) -> c(0x300) -> d(0x400)
But then "a" frame itself is ambiguous and it must not be displayed.
I did not realize that there can be self-tail-call:
main(0x100) -> a(0x200) -> d(0x400)
main(0x100) -> a(0x280) -> a(0x200) -> d(0x400)
which intersects to:
main(0x100) -> <???>? -> a(0x200) -> d(0x400)
And so if the first chain was chosen the
main(0x100) -> a(0x200) -> d(0x400)
then the final intersection has callers+callees==length.
> for example, if CALLERS is 3 and
> CALLEES is 2, what does the chain look like?
main(0x100) -> x(0x150) -> y(0x200) -> <???>? -> a(0x200) -> d(0x400)
And if LENGTH is 7 then:
call_site[0] = main(0x100)
call_site[1] = x(0x150)
call_site[2] = y(0x200)
call_site[3] = garbage
call_site[4] = garbage
call_site[5] = a(0x200)
call_site[6] = d(0x400)
gdb/ChangeLog
2015-06-01 Andreas Schwab <schwab@linux-m68k.org>
Jan Kratochvil <jan.kratochvil@redhat.com>
PR symtab/18392
* dwarf2-frame-tailcall.c (pretended_chain_levels): Correct
assertion.
* dwarf2loc.c (chain_candidate): Likewise.
gdb/testsuite/ChangeLog
2015-06-01 Jan Kratochvil <jan.kratochvil@redhat.com>
PR symtab/18392
* gdb.arch/amd64-tailcall-self.S: New file.
* gdb.arch/amd64-tailcall-self.c: New file.
* gdb.arch/amd64-tailcall-self.exp: New file.
The native-extended-gdbserver target now supports fork events and
follow fork, but it does not yet support exec events. Some of the
tests in gdb.base/foll-vfork.exp depend on exec events. This patch
disables those tests for remote targets. We can re-enable these
once the exec event support goes in.
gdb/testsuite/
* gdb.base/foll-vfork.exp (main): Disable exec-dependent
tests for remote targets by checking is_target_gdbserver.
gdb/ChangeLog:
* cp-support.c (cp_lookup_rtti_type): Handle the case of NAME being
a typedef.
gdb/testsuite/ChangeLog:
* gdb.cp/iostream.cc: New file.
* gdb.cp/iostream.exp: New file.
This patch adds a test case to test the process record for some of
aarch64 instructions.
In each function, GDB turns on process record, and single step until
program goes to the end of the function. Then, single step backward.
In each of forward single step and backward single step, the contents
of registers are saved, and test compares them. If there is any
differences, a FAIL is emitted.
The test is flexible, and we can test other instructions easily in the
future.
gdb/testsuite:
2015-05-26 Omair Javaid <omair.javaid@linaro.org>
Yao Qi <yao.qi@linaro.org>
* gdb.reverse/aarch64.c: New.
* gdb.reverse/aarch64.exp: New.
This patch enable gdb.reverse tests for aarch64*-linux targets.
With this patch, there are 7 FAILs in gdb.reverse/ tests.
FAIL: gdb.reverse/finish-reverse-bkpt.exp: reverse-finish from void_func trips breakpoint at entry
FAIL: gdb.reverse/finish-reverse-bkpt.exp: no spurious proceed after breakpoint stop
FAIL: gdb.reverse/next-reverse-bkpt-over-sr.exp: reverse-next over call trips user breakpoint at function entry
FAIL: gdb.reverse/step-precsave.exp: reverse step into fn call
FAIL: gdb.reverse/step-precsave.exp: reverse step out of called fn
FAIL: gdb.reverse/step-reverse.exp: reverse step into fn call
FAIL: gdb.reverse/step-reverse.exp: reverse step out of called fn
gdb/testsuite:
2015-05-26 Omair Javaid <omair.javaid@linaro.org>
* lib/gdb.exp (supports_process_record): Return true for aarch64*-linux*.
(supports_reverse): Likewise.
Use with_test_prefix to avoid duplicating test names when calling
the procedure test_gdbinit_history_setting multiple times.
gdb/testsuite/ChangeLog:
* gdb.base/gdbinit-history.exp (test_gdbinit_history_setting):
Use with_test_prefix.
Add layout name completion for the layout command.
gdb/ChangeLog:
* tui/tui-layout.c (layout_completer): New function.
(_initialize_tui_layout): Set completer on layout command.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Add test for completion of layout
names.
Add a new predicate procedure to the gdb.exp library 'skip_tui_tests',
which returns true if the tui is not compiled into gdb.
Make use of this predicate in the gdb.base/tui-layout.exp test as an
example.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (skip_tui_tests): New proc.
* gdb.base/tui-layout.exp: Check skip_tui_tests.
Some buildslaves are showing that this test is failing. E.g.,:
https://sourceware.org/ml/gdb-testers/2015-q2/msg04164.html
The issue is that HISTSIZE is set to 1000 in the environment that runs
the tests (that's the default in Fedora, set in /etc/profile).
We can trivially reproduce it with:
$ HISTSIZE=1000 make check RUNTESTFLAGS="gdbinit-history.exp"
(...)
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/gdbinit-history.exp ...
FAIL: gdb.base/gdbinit-history.exp: show history size
FAIL: gdb.base/gdbinit-history.exp: show history size
FAIL: gdb.base/gdbinit-history.exp: show commands
gdb.log shows:
...
(gdb) set height 0
(gdb) set width 0
(gdb) show history size
The size of the command history is 1000.
(gdb) FAIL: gdb.base/gdbinit-history.exp: show history size
gdb/testsuite/ChangeLog:
2015-05-19 Pedro Alves <palves@redhat.com>
* gdb.base/gdbinit-history.exp (test_gdbinit_history_setting):
Save the whole env array instead of just HOME. Unset HISTSIZE in
the environment while testing. Restore whole environment
afterwards.
It is planned the existing GDB command 'print' will be able to evaluate its
expressions using the compiler. There will be some option to choose between
the existing GDB evaluation and the compiler evaluation. But as an
intermediate step this patch provides the expression printing feature as a new
command.
I can imagine it could be also called 'maintenance compile print' as in the
future one should be able to use its functionality by the normal 'print'
command.
There was a discussion with Eli about the command name:
https://sourceware.org/ml/gdb-patches/2015-03/msg00880.html
As there were no other comments yet I haven't renamed it yet, before there is
some confirmation about settlement on the final name.
Support for the GDB '@' operator to create arrays has been submitted for GCC:
[gcc patch] libcc1: '@' GDB array operator
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01451.html
gdb/ChangeLog
2015-05-16 Jan Kratochvil <jan.kratochvil@redhat.com>
Phil Muldoon <pmuldoon@redhat.com>
* NEWS (Changes since GDB 7.9): Add compile print.
* compile/compile-c-support.c (add_code_header, add_code_footer)
(c_compute_program): Add COMPILE_I_PRINT_ADDRESS_SCOPE and
COMPILE_I_PRINT_VALUE_SCOPE.
* compile/compile-internal.h (COMPILE_I_PRINT_OUT_ARG_TYPE)
(COMPILE_I_PRINT_OUT_ARG, COMPILE_I_EXPR_VAL, COMPILE_I_EXPR_PTR_TYPE):
New.
* compile/compile-object-load.c: Include block.h.
(get_out_value_type): New function.
(compile_object_load): Handle COMPILE_I_PRINT_ADDRESS_SCOPE and
COMPILE_I_PRINT_VALUE_SCOPE. Set compile_module's OUT_VALUE_ADDR and
OUT_VALUE_TYPE.
* compile/compile-object-load.h (struct compile_module): Add fields
out_value_addr and out_value_type.
* compile/compile-object-run.c: Include valprint.h and compile.h.
(struct do_module_cleanup): Add fields out_value_addr and
out_value_type.
(do_module_cleanup): Handle COMPILE_I_PRINT_ADDRESS_SCOPE and
COMPILE_I_PRINT_VALUE_SCOPE.
(compile_object_run): Propagate out_value_addr and out_value_type.
Pass OUT_VALUE_ADDR.
* compile/compile.c: Include valprint.h.
(compile_print_value, compile_print_command): New functions.
(eval_compile_command): Handle failed COMPILE_I_PRINT_ADDRESS_SCOPE.
(_initialize_compile): Update compile code help text. Install
compile_print_command.
* compile/compile.h (compile_print_value): New prototype.
* defs.h (enum compile_i_scope_types): Add
COMPILE_I_PRINT_ADDRESS_SCOPE and COMPILE_I_PRINT_VALUE_SCOPE.
gdb/doc/ChangeLog
2015-05-16 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.texinfo (Compiling and Injecting Code): Add compile print.
gdb/testsuite/ChangeLog
2015-05-16 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile-print.c: New file.
* gdb.compile/compile-print.exp: New file.
For a reason unknown to me GDB was using -w instead of -Wall for 'compile code'.
The problem is later patch for 'compile printf' really needs some warnings to
be able to catch for example missing format string parameters:
(gdb) compile printf "%d\n"
GCC does not seem to be able to cancel -w (there is nothing like -no-w).
Besides that I think even 'compile code' can benefit from -Wall.
That #ifndef change in print_one_macro() is needed otherwise we get
macro-redefinition warnings for the GCC built-in macros (as -w is no
longer in effect). For example, without the #ifndef/#endif one gets:
compile -r -- void _gdb_expr(){int i = 5;}^M
/tmp/gdbobj-xpU1yB/out4.c:4:0: warning: "__FILE__" redefined [-Wbuiltin-macro-redefined]^M
/tmp/gdbobj-xpU1yB/out4.c:5:0: warning: "__LINE__" redefined^M
...
It makes more sense to pick the inferior's version of the macros, hence
#ifndef instead of #undef.
That new testsuite XFAIL is there as if one changes the struct definition to be
compliant with cv-qualifiers (to prevent the warnings):
struct struct_type {
- struct struct_type *selffield;
+ volatile struct struct_type *selffield;
only then GCC/GDB will hit the crash, described in that GDB PR 18202.
gdb/ChangeLog
2015-05-16 Jan Kratochvil <jan.kratochvil@redhat.com>
* compile/compile-c-support.c (print_one_macro): Use #ifndef.
(generate_register_struct): Use __gdb_uintptr for TYPE_CODE_PTR.
(c_compute_program): Call generate_register_struct after typedefs.
* compile/compile-loc2c.c (push, pushf_register_address)
(pushf_register): Cast to GCC_UINTPTR.
(do_compile_dwarf_expr_to_c): Use unused attribute. Add space after
type. Use GCC_UINTPTR instead of void *. Remove excessive cast.
(compile_dwarf_expr_to_c): Use GCC_UINTPTR instead of void *.
* compile/compile.c (_initialize_compile): Enable warnings for
COMPILE_ARGS.
gdb/testsuite/ChangeLog
2015-05-16 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile-ops.exp: Cast param to void.
* gdb.compile/compile.exp: Complete type for _gdb_expr.
(compile code struct_object.selffield = &struct_object): Add xfail.
In Ada, index types of arrays can be enumeration types, and enumeration
types can be non-contiguous. In which case the address of elements is
not given by the value of the index, but by its position in the enumeration
type.
In other words, in this example:
type Color is (Blue, Red);
for Color use (Blue => 8, Red => 12, Green => 16);
type A is array (Color) of Integer;
type B is array (1 .. 3) of Integer;
Arrays of type A and B will have the same layout in memory, even if
the enumeration Color has a hole in its set of integer value.
Since recently support for such a feature was in ada-lang.c, where the
array was casted to a regular continuous index range. We were losing
the information of index type. And this was not quite working for
subranges in variable-length fields; their bounds are expressed using
the integer value of the bounds, not its position in the enumeration,
and there was some confusion all over ada-lang.c as to whether we had
the position or the integer value was used for indexes.
The idea behind this patch is to clean this up by keeping the real
representation of these array index types and bounds when representing
the value, and only use the position when accessing the elements or
computing the length. This first patch fixes the printing of such
an array.
To the best of my knowledge, this feature only exists in Ada so it
should only affect this language.
gdb/ChangeLog:
Jerome Guitton <guitton@adacore.com>:
* ada-lang.c (ada_value_ptr_subscript): Use enum position of
index to get element instead of enum value.
(ada_value_slice_from_ptr, ada_value_slice): Use enum position
of index to compute length, but enum values to compute bounds.
(ada_array_length): Use enum position of index instead of enum value.
(pos_atr): Move position computation to...
(ada_evaluate_subexp): Use enum values to compute bounds.
* gdbtypes.c (discrete_position): ...this new function.
* gdbtypes.h (discrete_position): New function declaration.
* valprint.c (val_print_array_elements): Call discrete_position
to handle array indexed by non-contiguous enumeration types.
gdb/testsuite/ChangeLog:
* gdb.ada/arr_enum_with_gap: New testcase.
In the case of non bit-packed arrays, GNAT does not generate its
traditional XP encoding; it is not needed. However, it still generates
the so-called "implementation type" with a P suffix. This
implementation type shall be skipped when looking for other
descriptive types such as XA encodings for variable-length
fields.
Note also that there may be an intermediate typedef between the
implementation type and its XA description. It shall be skipped
as well.
gdb/ChangeLog:
Jerome Guitton <guitton@adacore.com>
* ada-lang.c (find_parallel_type_by_descriptive_type):
Go through typedefs during lookup.
(to_fixed_array_type): Add support for non-bit packed arrays
as variable-length fields.
gdb/testsuite/ChangeLog:
* gdb.ada/byte_packed_arr: New testcase.
Consider the following declarations:
type Signed_Small is new Integer range - (2 ** 5) .. (2 ** 5 - 1);
type Signed_Simple_Array is array (1 .. 4) of Signed_Small;
pragma Pack (Signed_Simple_Array);
SSA : Signed_Simple_Array := (-1, 2, -3, 4);
GDB currently print its value incorrectly for the elements that
are negative:
(gdb) print ssa
$1 = (65535, 2, 1048573, 4)
(gdb) print ssa(1)
$2 = 65535
(gdb) print ssa(2)
$3 = 2
(gdb) print ssa(3)
$4 = 1048573
(gdb) print ssa(4)
$5 = 4
What happens is that the sign-extension is not working because
we're trying to do left shift with a negative count. In
ada_value_primitive_packed_val, we have a loop which populates
the extra bits of the target (unpacked) value, after extraction
of the data from the original (packed) value:
while (ntarg > 0)
{
accum |= sign << accumSize;
unpacked[targ] = accum & ~(~0L << HOST_CHAR_BIT);
!!! -> accumSize -= HOST_CHAR_BIT;
accum >>= HOST_CHAR_BIT;
ntarg -= 1;
targ += delta;
}
At each iteration, accumSize gets decremented by HOST_CHAR_BIT,
which can easily cause it to become negative, particularly on
little endian targets, where accumSize is at most HOST_CHAR_BIT - 1.
This causes us to perform a left-shift operation with a negative
accumSize at the next loop iteration, which is undefined, and
acutally does not produce the effect we wanted (value left untouched)
when the code is compiled with GCC.
This patch fixes the issue by simply setting accumSize to zero
if negative.
gdb/ChangeLog:
* ada-lang.c (ada_value_primitive_packed_val): Make sure
accumSize is never negative.
gdb/testsuite/ChangeLog:
* gdb.ada/pckd_neg: New testcase.
This patch is a comprehensive fix for PR 17820 which reports that
using "set history size unlimited" inside one's gdbinit file doesn't
really work.
There are three small changes in this patch. The most important change
this patch makes is to decode the argument of the "size" subcommand
using add_setshow_zuinteger_unlimited_cmd() instead of using
add_setshow_uinteger_cmd(). The new decoder takes an int * and maps
unlimited to -1 whereas the old decoder takes an unsigned int * and maps
unlimited to UINT_MAX. Using the new decoder simplifies our handling of
unlimited and makes it easier to interface with readline which itself
expects a signed-int history size.
The second change is the factoring of the [stifle|unstifle]_history logic
into a common function which is now used by both init_history() and
set_history_size_command(). This is technically the change that fixes
the PR itself.
Thirdly, this patch initializes history_size_setshow_var to -2 to mean
that the variable has not been set yet. Now init_history() tests for -2
instead of 0 to determine whether to give the variable a default value.
This means that having "set history size 0" in one's gdbinit file will
actually keep the history size at 0 and not reset it to 256.
gdb/ChangeLog:
PR gdb/17820
* top.c (history_size_setshow_var): Change type to signed.
Initialize to -2. Update documentation.
(set_readline_history_size): Define.
(set_history_size_command): Use it. Remove logic for handling
out-of-range sizes.
(init_history): Use set_readline_history_size(). Test for a
value of -2 instead of 0 when determining whether to set a
default history size.
(init_main): Decode the argument of the "size" command as a
zuinteger_unlimited.
gdb/testsuite/ChangeLog:
PR gdb/17820
* gdb.base/gdbinit-history.exp: New test.
* gdb.base/gdbinit-history/unlimited/.gdbinit: New file.
* gdb.base/gdbinit-history/zero/.gdbinit: New file.
In my last commit to make gdb.base/coredump-filter.exp be more robust
regarding using arrays in the global namespace, I cleared the
"coredump_var_addr" array like this:
set coredump_var_addr ""
# use coredump_var_addr as an array...
This causes DejaGNU to complain because the variable is first set as
non-array, and the used as an array. The correct way to do this is to
unset the variable using:
unset -nocomplain coredump_var_addr
# use coredump_var_addr as an array...
The "-nocomplain" part is necessary because if the variable doesn't
exist "unset" will not error.
Tested on Fedora 20 x86_64.
gdb/testsuite/ChangeLog:
2015-05-08 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/coredump-filter.exp: Correctly unset
"coredump_var_addr" array.
Sequential test runs are stopping prematurely like this:
$ make check RUNTESTFLAGS="non-existing-program.exp server-exec-info.exp"
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.server/non-existing-program.exp ...
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.server/server-exec-info.exp ...
can not find channel named "exp6"
while executing
"match_max [match_max -d]"
(procedure "default_gdb_init" line 26)
invoked from within
"default_gdb_init $test_file_name"
(procedure "gdb_init" line 83)
invoked from within
"${tool}_init $test_file_name"
(procedure "runtest" line 18)
invoked from within
"runtest $test_name"
("foreach" body line 42)
invoked from within
...
make[2]: *** [check-single] Error 1
make[2]: Leaving directory `/home/pedro/gdb/mygit/build/gdb/testsuite'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/home/pedro/gdb/mygit/build/gdb/testsuite'
make: *** [check] Error 2
default_gdb_init has this:
# Unlike most tests, we have a small number of tests that generate
# a very large amount of output. We therefore increase the expect
# buffer size to be able to contain the entire test output. This
# is especially needed by gdb.base/info-macros.exp.
match_max -d 65536
# Also set this value for the currently running GDB.
match_max [match_max -d]
It's the second match_max that is erroring. As that call does not
specify an explicit channel name with -i, expect defaults to
$spawn_id, which is pointing at a channel that is already gone. (If
the spawn_id variable is not set, match_max defaults to
$user_spawn_id / stdin/out).
gdb/testsuite/ChangeLog:
2015-05-08 Pedro Alves <palves@redhat.com>
* gdb.server/non-existing-program.exp: Unset spawn_id.
Hi,
We see some fails in gdb.base/coredump-filter.exp when we do remote
gdbserver testing, like what I did for arm/aarch64 linux testing or
run it with board file remote-gdbserver-on-localhost
$ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost coredump-filter.exp'
we find that this line in the test doesn't work as expected,
remote_exec target "sh -c \"echo $filter_flag > /proc/$ipid/coredump_filter\""
although such pattern has been used in gdb testsuite somewhere else,
but the special thing here is that we redirect the output to
/proc/$ipid/coredump_filter on the remote target. DejaGNU will
redirect the output from the remote target to local, and looks tcl
gets confused by these two redirection.
After trying pass different parameters to remote_exec and hacking
remote_exec/rsh_exec/local_exec, I got no success, I decide
to give up, and try to update /proc/$ipid/coredump_filter by the c
code directly.
This patch adds a c function set_coredump_filter to update
coredump_filter, and GDB calls it.
gdb/testsuite:
2015-05-08 Yao Qi <yao.qi@linaro.org>
PR gdb/18208
* gdb.base/coredump-filter.c (set_coredump_filter): New function.
* gdb.base/coredump-filter.exp (do_save_core): Call inferior
function set_coredump_filter, and remove remote_exec call.
Remove argument ipid. Callers update.
(top level): Don't get inferior's PID.
Since watch_thread_num.exp was changed to use access watchpoints, the
test case fails on s390 and s390x, since those targets do not support
access watchpoints. This patch skips the test case on such targets.
gdb/testsuite/ChangeLog:
* gdb.base/watch_thread_num.exp: Skip test on targets without
access watchpoints.
$ ./gdbserver :1234 blah
Process blah created; pid = 16471
Cannot exec blah: No such file or directory.
Child exited with status 127
Killing process(es): 16471
../../../../src/binutils-gdb/gdb/gdbserver/linux-low.c:920: A problem internal to GDBserver has been detected.
kill_wait_lwp: Assertion `res > 0' failed.
GDBserver shouldn't even be trying to kill that process. GDBserver
kills or detaches from all processes on exit, and due to a missing
mourn_inferior call, GDBserver tries to kill the process that it had
already seen exit.
Tested on x86_64 Fedora 20. New test included. I emulated what
Windows outputs by hacking an error call in linux_create_inferior.
gdb/gdbserver/ChangeLog:
2015-05-06 Pedro Alves <palves@redhat.com>
PR server/18081
* server.c (start_inferior): If the process exits, mourn it.
gdb/testsuite/ChangeLog:
2015-05-06 Pedro Alves <palves@redhat.com>
PR server/18081
* gdb.server/non-existing-program.exp: New file.
This patch improves the handling of out-of-line functions nested
inside functions that have been inlined.
Consider for instance a situation where function Foo_O224_021
has a function Child1 declared in it, which itself has a function
Child2 nested inside Child1. After compiling the program with
optimization on, Child1 gets inlined, but not Child2.
After inserting a breakpoint on Child2, and running the program
until reaching that breakpoint, we get the following backtrace:
% gdb foo_o224_021
(gdb) break foo_o224_021.child1.child2
(gdb) run
[...]
Breakpoint 1, foo_o224_021 () at foo_o224_021.adb:28
28 Child1;
(gdb) bt
#0 0x0000000000402400 in foo_o224_021 () at foo_o224_021.adb:28
#1 0x00000000004027a4 in foo_o224_021.child1 () at foo_o224_021.adb:23
#2 0x00000000004027a4 in foo_o224_021 () at foo_o224_021.adb:28
GDB reports the wrong function name for frame #0. We also get the same
kind of error in the "Breakpoint 1, foo_o224_021 () [...]" message.
In both cases, the function name should be foo_o224_021.child1.child2,
and the parameters should be "s=...".
What happens is that the inlined frame handling does not handle well
the case where an inlined function is calling an out-of-line function
which was declared inside the inlined function's scope.
In particular, looking first at the inlined-frame sniffer when applying
to frame #0:
/* Calculate DEPTH, the number of inlined functions at this
location. */
depth = 0;
cur_block = frame_block;
while (BLOCK_SUPERBLOCK (cur_block))
{
if (block_inlined_p (cur_block))
depth++;
cur_block = BLOCK_SUPERBLOCK (cur_block);
}
What happens is that cur_block starts as the block associated
to child2, which is not inlined. We shoud be stopping here, but
instead, we keep walking the superblock chain, which takes us
all the way to Foo_O224_021's block, via Child2's block. And
since Child1 was inlined, we end up with a depth count of 1,
wrongly making GDB think that frame #0 is an inlined frame.
Same kind of issue inside skip_inline_frames.
The fix is to stop checking for inlined frames as soon as we see
a block corresponding to a function which is not inlined. This is
the behavior we now obtain:
(gdb) run
[...]
Breakpoint 1, foo_o224_021.child1.child2 (s=...) at foo_o224_021.adb:9
9 function Child2 (S : String) return Boolean is
(gdb) bt
#0 0x0000000000402400 in foo_o224_021.child1.child2 (s=...)
at foo_o224_021.adb:9
#1 0x00000000004027a4 in foo_o224_021.child1 () at foo_o224_021.adb:23
#2 0x00000000004027a4 in foo_o224_021 () at foo_o224_021.adb:28
gdb/ChangeLog:
* inline-frame.c (inline_frame_sniffer, skip_inline_frames):
Stop counting inlined frames as soon as an out-of-line function
is found.
gdb/testsuite/ChangeLog:
* gdb.ada/out_of_line_in_inlined.exp: Add run and "bt" tests.
Consider the following code, which defines a function, Child2,
which is itself nested inside Child1:
procedure Foo_O224_021 is
O1 : constant Object_Type := Get_Str ("Foo");
procedure Child1 is
O2 : constant Object_Type := Get_Str ("Foo");
function Child2 (S : String) return Boolean is -- STOP
begin
for C of S loop
Do_Nothing (C);
if C = 'o' then
return True;
end if;
end loop;
return False;
end Child2;
R : Boolean;
begin
R := Child2 ("Foo");
R := Child2 ("Bar");
R := Child2 ("Foobar");
end Child1;
begin
Child1;
end Foo_O224_021;
On x86_64-linux, when compiled at -O2, GDB is unable to insert
a breakpoint on Child2:
% gnatmake -g -O2 foo_o224_021
% gdb foo_o224_021
(gdb) b child2
Function "child2" not defined.
(gdb) b foo_o224_021.child1.child2
Function "foo_o224_021.child1.child2" not defined.
The problem is caused by the fact that GDB did not create a symbol
for Child2, and this, in turn, is caused by the fact that the compiler
decided to inline Child1, but not Child2. The DWARF debugging info
first provides an abstract instance tree for Child1...
<3><1b7b>: Abbrev Number: 29 (DW_TAG_subprogram)
<1b7c> DW_AT_name : (indirect string, offset: 0x23f8): foo_o224_021__child1
<1b82> DW_AT_inline : 1 (inlined)
<1b83> DW_AT_sibling : <0x1c01>
... where that subprogram is given the DW_AT_inline attribute.
Inside that function there is a lexical block which has no PC
range (corresponding to the fact that this is the abstract tree):
<4><1b87>: Abbrev Number: 30 (DW_TAG_lexical_block)
... inside which our subprogram Child2 is described:
<5><1b92>: Abbrev Number: 32 (DW_TAG_subprogram)
<1b93> DW_AT_name : (indirect string, offset: 0x2452): foo_o224_021__child1__child2
<1b99> DW_AT_type : <0x1ab1>
<1b9d> DW_AT_low_pc : 0x402300
<1ba5> DW_AT_high_pc : 0x57
[...]
Then, later on, we get the concrete instance tree, starting at:
<3><1c5e>: Abbrev Number: 41 (DW_TAG_inlined_subroutine)
<1c5f> DW_AT_abstract_origin: <0x1b7b>
<1c63> DW_AT_entry_pc : 0x4025fd
<1c6b> DW_AT_ranges : 0x150
... which refers to Child1. One of that inlined subroutine children
is the concrete instance of the empty lexical block we saw above
(in the abstract instance tree), which gives the actual address
range for this inlined instance:
<5><1c7a>: Abbrev Number: 43 (DW_TAG_lexical_block)
<1c7b> DW_AT_abstract_origin: <0x1b87>
<1c7f> DW_AT_ranges : 0x180
This is the DIE which provides the context inside which we can
record Child2. But unfortunately, GDB does not take the abstract
origin into account when handling lexical blocks, causing it
to miss the fact that this block contains some symbols described
in the abstract instance tree. This is the first half of this patch:
modifying GDB to follow DW_AT_abstract_origin attributes for
lexical blocks.
But this not enough to fix the issue, as we're still unable to
break on Child2 with just that change. The second issue can be
traced to the way inherit_abstract_dies determines the list of
DIEs to inherit from. For that, it iterates over all the DIEs in
the concrete instance tree, and finds the list of DIEs from the
abstract instance tree that are not referenced from the concrete
instance tree. As it happens, there is one type of DIE in the
concrete instance tree which does reference Child2's DIE, but
in fact does otherwise define a concrete instance of the reference
DIE; that's (where <0x1b92> is Child2's DIE):
<6><1d3c>: Abbrev Number: 35 (DW_TAG_GNU_call_site)
<1d3d> DW_AT_low_pc : 0x4026a4
<1d45> DW_AT_abstract_origin: <0x1b92>
So, the second part of the patch is to modify inherit_abstract_dies
to ignore DW_TAG_GNU_call_site DIEs when iterating over the concrete
instance tree.
This patch also includes a testcase which can be used to reproduce
the issue. Unfortunately, for it to actually pass, a smal patch in
GCC is also necessary to make sure that GCC provides lexical blocks'
DW_AT_abstract_origin attributes from the concrete tree back to
the abstract tree. We hope to be able to submit and integrate that
patch in the GCC tree soon. Meanwhile, a setup_xfail has been added.
gdb/ChangeLog:
2014-05-05 Pierre-Marie de Rodat <derodat@adacore.com>
* dwarf2read.c (inherit_abstract_dies): Skip
DW_TAG_GNU_call_site dies while inheriting children of an
abstract DIE into a scope.
(read_lexical_block_scope): Inherit abstract DIE's for
lexical scopes.
gdb/testsuite/ChangeLog:
* gdb.ada/out_of_line_in_inlined: New testcase.
Hi,
I see this fails below on arm linux native testing and remote testing
with "set remote hardware-watchpoint-limit 1",
rwatch global^M
There are not enough available hardware resources for this watchpoint.^M
(gdb) FAIL: gdb.base/break-idempotent.exp: always-inserted off: rwatch: twice: rwatch global
gdb.base/break-idempotent.exp sets two breakpoints/watchpoints on the
same address. GDB isn't smart enough calculate these two HW
watchpoints can fit in one HW debug register, so the error message
above isn't necessary (there is one HW watchpoint register on arm).
Because target_ops interface can_use_hardware_watchpoint doesn't
pass enough information to the target backend.
Note that if I don't "set remote hardware-watchpoint-limit 1" in
remote testing, this test passes without fails. However without
"set remote hardware-watchpoint-limit 1", many other watchpoint
tests fail.
This patch is to add a check to skip_hw_watchpoint_multi_tests
for rwatch and awatch. We can add such check for watch as well,
but GDB is able to switch to software watchpoint if HW resource
isn't available, it doesn't cause any fail, I decide not to skip.
gdb/testsuite:
2015-04-30 Yao Qi <yao.qi@linaro.org>
* gdb.base/break-idempotent.exp: If
skip_hw_watchpoint_multi_tests returns true, skip the tests
on "rwatch" and "awatch".
Hi,
I see the fail in gdb.base/relativedebug.exp on aarch64 box on which
glibc doesn't have debug info,
bt^M
#0 0x0000002000061a88 in raise () from /lib/aarch64-linux-gnu/libc.so.6^M
#1 0x0000002000064efc in abort () from /lib/aarch64-linux-gnu/libc.so.6^M
#2 0x0000000000400640 in handler (signo=14) at ../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:25^M
#3 <signal handler called>^M
#4 0x00000020000cc478 in ?? () from /lib/aarch64-linux-gnu/libc.so.6^M
#5 0x0000000000400664 in main () at ../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:32^M
(gdb) FAIL: gdb.base/relativedebug.exp: pause found in backtrace
if glibc has debug info, this test doesn't fail.
In sysdeps/unix/sysv/linux/generic/pause.c, __libc_pause calls
__syscall_pause,
static int
__syscall_pause (void)
{
sigset_t set;
int rc =
INLINE_SYSCALL (rt_sigprocmask, 4, SIG_BLOCK, NULL, &set, _NSIG / 8);
if (rc == 0)
rc = INLINE_SYSCALL (rt_sigsuspend, 2, &set, _NSIG / 8);
return rc;
}
int
__libc_pause (void)
{
if (SINGLE_THREAD_P)
return __syscall_pause (); <--- tail call
int oldtype = LIBC_CANCEL_ASYNC ();
int result = __syscall_pause ();
LIBC_CANCEL_RESET (oldtype);
return result;
}
and GDB unwinder is confused by the GCC optimized code,
(gdb) disassemble pause
Dump of assembler code for function pause:
0x0000007fb7f274c4 <+0>: stp x29, x30, [sp,#-32]!
0x0000007fb7f274c8 <+4>: mov x29, sp
0x0000007fb7f274cc <+8>: adrp x0, 0x7fb7fd2000
0x0000007fb7f274d0 <+12>: ldr w0, [x0,#364]
0x0000007fb7f274d4 <+16>: stp x19, x20, [sp,#16]
0x0000007fb7f274d8 <+20>: cbnz w0, 0x7fb7f274e8 <pause+36>
0x0000007fb7f274dc <+24>: ldp x19, x20, [sp,#16]
0x0000007fb7f274e0 <+28>: ldp x29, x30, [sp],#32
0x0000007fb7f274e4 <+32>: b 0x7fb7f27434 <---- __syscall_pause
0x0000007fb7f274e8 <+36>: bl 0x7fb7f5e080
Note that the program stops in __syscall_pause, but its symbol is
stripped in glibc, so GDB doesn't know where the program stops.
__syscall_pause is a tail call in __libc_pause, so it returns to main
instead of __libc_pause. As a result, the backtrace is like,
#0 0x0000007fb7ebca88 in raise () from /lib/aarch64-linux-gnu/libc.so.6
#1 0x0000007fb7ebfefc in abort () from /lib/aarch64-linux-gnu/libc.so.6
#2 0x0000000000400640 in handler (signo=14) at ../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:25
#3 <signal handler called>
#4 0x0000007fb7f27478 in ?? () from /lib/aarch64-linux-gnu/libc.so.6 <-- [in __syscall_pause]
#5 0x0000000000400664 in main () at ../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:32
looks GDB does nothing wrong here. I looked back at the test case
gdb.base/relativedebug.exp, which was added
https://sourceware.org/ml/gdb-patches/2006-10/msg00305.html
This test was indented to test the problem that "backtraces no longer
display some libc functions" after separate debug info is installed.
IOW, it makes few sense to test against libc which doesn't have debug
info at all, such as my case.
This patch is to tweak the test case to catch the output of
"info shared", if "(*)" is found for libc.so, which means libc doesn't
have debug info, then skip the test.
gdb/testsuite:
2015-04-30 Yao Qi <yao.qi@linaro.org>
* gdb.base/relativedebug.exp: Invoke gdb command
"info sharedlibrary", and if libc.so doesn't have debug info,
skip the test.
There are targets GDB thinks support hardware watchpoints, but in reality they
don't. Though it may seem that hardware watchpoint creation was successful,
the actual insertion of such watchpoint will fail when GDB moves the inferior.
(gdb) watch -location q.a^M
Hardware watchpoint 2: -location q.a^M
(gdb) PASS: gdb.base/watch-bitfields.exp: -location watch against bitfields: watch -location q.a
watch -location q.e^M
Hardware watchpoint 3: -location q.e^M
(gdb) PASS: gdb.base/watch-bitfields.exp: -location watch against bitfields: watch -location q.e
print q.a^M
$1 = 0^M
(gdb) PASS: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 0->1: print expression before
continue^M
Continuing.^M
Warning:^M
Could not insert hardware watchpoint 2.^M
Could not insert hardware watchpoint 3.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 0->1: continue
This leads to a number of FAILs:
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 0->1: continue
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 0->1: print expression after
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 0->5: continue
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 0->5: print expression after
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 1->0: print expression before
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 1->0: continue
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 5->4: print expression before
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 5->4: continue
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 5->4: print expression after
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: continue until exit
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 0->4: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 0->4: print expression after
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 4->10: print expression before
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 4->10: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 4->10: print expression after
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 10->3: print expression before
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 10->3: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 10->3: print expression after
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 3->2: print expression before
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 3->2: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 3->2: print expression after
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 2->1: print expression before
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 2->1: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 2->1: print expression after
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 1->0: print expression before
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 1->0: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: continue until exit
We can avoid these errors/FAILs by checking the board data and switching to
software watchpoints if the board does not support hardware watchpoints.
gdb/testsuite/ChangeLog:
2015-04-29 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/watch-bitfields.exp: Switch to software watchpoints if
the target does not support hardware watchpoints.
This is another case of the testcase not handling memory write errors that
happen on some targets (QEMU) when GDB attempts to modify an address that
should contain a breakpoint, for example.
The following patch handles this and prevents spurious failures from
happening. It also adds a foreach loop to avoid duplication of code
and hardcoded patterns.
gdb/testsuite/ChangeLog:
2015-04-29 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/break-always.exp: Abort testing if writing to memory
causes an error.
gdb/ChangeLog:
PR python/18299
* python/lib/gdb/printing.py (register_pretty_printer): Handle
name or __name__ attributes. Handle gdb module as first argument.
gdb/testsuite/ChangeLog:
* gdb.python/py-pp-maint.py: Move "replace" testing to ...
* gdb.python/py-pp-registration.exp: ... here. New file.
* gdb.python/py-pp-registration.c: New file.
* gdb.python/py-pp-registration.py: New file.
gdb/ChangeLog:
PR python/18089
* python/py-prettyprint.c (print_children): Verify result of children
iterator. Provide better error message.
* python/python-internal..h (gdbpy_print_python_errors_p): Declare.
* python/python.c (gdbpy_print_python_errors_p): New function.
gdb/testsuite/ChangeLog:
* gdb.python/py-bad-printers.c: New file.
* gdb.python/py-bad-printers.py: New file.
* gdb.python/py-bad-printers.exp: New file.
