Level of indentation was not proper handled when printing
the elements type's name.
Before:
type = Type t1
integer(kind=4) :: var_1
integer(kind=4) :: var_2
End Type t1
After:
type = Type t1
integer(kind=4) :: var_1
integer(kind=4) :: var_2
End Type t1
2016-05-25 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* f-typeprint.c (f_type_print_base): Take print level into account.
gdb/testsuite/Changelog:
* gdb.fortran/print_type.exp: Fix expected output.
* gdb.fortran/whatis_type.exp: Fix expected output.
This patch fixes PR python/17386.
The bug is that gdb.Value does not implement the Python __index__
method. This method is needed to convert a Python object to an index
and is used by various operations in Python, such as indexing an
array.
The fix is to implement the nb_index method for gdb.Value.
nb_index was added in Python 2.5. I don't have a good way to test
Python 2.4, but I made an attempt to accomodate it.
I chose to use valpy_long in all cases because this simplifies porting
to Python 3, and because there didn't seem to be any harm.
Built and regtested on x86-64 Fedora 23.
2016-05-24 Tom Tromey <tom@tromey.com>
PR python/17386:
* python/py-value.c (value_object_as_number): Add
nb_inplace_floor_divide, nb_inplace_true_divide, nb_index.
2016-05-24 Tom Tromey <tom@tromey.com>
PR python/17386:
* gdb.python/py-value.exp (test_value_numeric_ops): Add tests that
use value as an index.
PR python/17981 notes that gdb.breakpoints() returns None when there
are no breakpoints; whereas an empty list or tuple would be more in
keeping with Python and the documentation.
This patch fixes the bug by changing the no-breakpoint return to make
an empty tuple.
Built and regtested on x86-64 Fedora 23.
2016-05-23 Tom Tromey <tom@tromey.com>
PR python/17981:
* python/py-breakpoint.c (gdbpy_breakpoints): Return a new tuple
when there are no breakpoints.
2016-05-23 Tom Tromey <tom@tromey.com>
* python.texi (Basic Python): Document gdb.breakpoints return.
2016-05-23 Tom Tromey <tom@tromey.com>
PR python/17981:
* gdb.python/py-breakpoint.exp (test_bkpt_basic): Add test for
no-breakpoint case.
When GDB attaches to a process, it looks at the /proc/PID/task/ dir
for all clone threads of that process, and attaches to each of them.
Usually, if there is more than one clone thread, it means the program
is multi threaded and linked with pthreads. Thus when GDB soon after
attaching finds and loads a libthread_db matching the process, it'll
add a thread to the thread list for each of the initially found
lower-level LWPs.
If, however, GDB fails to find/load a matching libthread_db, nothing
is adding the LWPs to the thread list. And because of that, "detach"
hits an internal error:
(gdb) PASS: gdb.threads/clone-attach-detach.exp: fg attach 1: attach
info threads
Id Target Id Frame
* 1 LWP 6891 "clone-attach-de" 0x00007f87e5fd0790 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84
(gdb) FAIL: gdb.threads/clone-attach-detach.exp: fg attach 1: info threads shows two LWPs
detach
.../src/gdb/thread.c:1010: internal-error: is_executing: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
FAIL: gdb.threads/clone-attach-detach.exp: fg attach 1: detach (GDB internal error)
From here:
...
#8 0x00000000007ba7cc in internal_error (file=0x98ea68 ".../src/gdb/thread.c", line=1010, fmt=0x98ea30 "%s: Assertion `%s' failed.")
at .../src/gdb/common/errors.c:55
#9 0x000000000064bb83 in is_executing (ptid=...) at .../src/gdb/thread.c:1010
#10 0x00000000004c23bb in get_pending_status (lp=0x12c5cc0, status=0x7fffffffdc0c) at .../src/gdb/linux-nat.c:1235
#11 0x00000000004c2738 in detach_callback (lp=0x12c5cc0, data=0x0) at .../src/gdb/linux-nat.c:1317
#12 0x00000000004c1a2a in iterate_over_lwps (filter=..., callback=0x4c2599 <detach_callback>, data=0x0) at .../src/gdb/linux-nat.c:899
#13 0x00000000004c295c in linux_nat_detach (ops=0xe7bd30, args=0x0, from_tty=1) at .../src/gdb/linux-nat.c:1358
#14 0x000000000068284d in delegate_detach (self=0xe7bd30, arg1=0x0, arg2=1) at .../src/gdb/target-delegates.c:34
#15 0x0000000000694141 in target_detach (args=0x0, from_tty=1) at .../src/gdb/target.c:2241
#16 0x0000000000630582 in detach_command (args=0x0, from_tty=1) at .../src/gdb/infcmd.c:2975
...
Tested on x86-64 Fedora 23. Also confirmed the test passes against
gdbserver with "maint set target-non-stop".
gdb/ChangeLog:
2016-05-24 Pedro Alves <palves@redhat.com>
PR gdb/19828
* linux-nat.c (attach_proc_task_lwp_callback): Mark the lwp
resumed, and add the thread to GDB's thread list.
testsuite/ChangeLog:
2016-05-24 Pedro Alves <palves@redhat.com>
PR gdb/19828
* gdb.threads/clone-attach-detach.c: New file.
* gdb.threads/clone-attach-detach.exp: New file.
This patch fixes a syntax error which caused a failure in
annota-input-while-running.exp to crash the test suite runner.
2016-05-24 Francis Ricci <francisjricci@gmail.com>
* gdb.base/annota-input-while-running.exp: Fix syntax error.
This fixes PR python/19438 and PR python/18393. Both bugs are about
invoking dir() on some Python object implemented by gdb, and getting a
crash.
The crash happens because the dictionary field of these objects was
not initialized. Apparently what happens is that this field can be
lazily initialized by Python when assigning to an attribute; and it
can also be handled ok when using dir() but without __dict__ defined;
but gdb defines __dict__ because this isn't supplied automatically by
Python.
The docs on this seem rather sparse, but this patch works ok.
An alternative might be to lazily create the dictionary in
gdb_py_generic_dict, but I went with this approach because it seemed
more straightforward.
Built and regtested on x86-64 Fedora 23.
2016-05-23 Tom Tromey <tom@tromey.com>
PR python/19438, PR python/18393:
* python/py-objfile.c (objfpy_initialize): Initialize self->dict.
* python/py-progspace.c (pspy_initialize): Initialize self->dict.
2016-05-23 Tom Tromey <tom@tromey.com>
PR python/19438, PR python/18393:
* gdb.python/py-progspace.exp: Add "dir" test.
* gdb.python/py-objfile.exp: Add "dir" test.
This patch fixes the errors below:
Running /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.arch/thumb-prologue.exp ...
gdb compile failed, arm-linux-gnueabihf/bin/ld: cannot open output file /scratch/yao/gdb/build-git/arm-linux-gnueabihf/gdb/testsuite/gdb.arch/thumb-prologue: No such file or directory
collect2: error: ld returned 1 exit status
Running /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.arch/thumb2-it.exp ...
gdb compile failed, arm-linux-gnueabihf/bin/ld: cannot open output file /scratch/yao/gdb/build-git/arm-linux-gnueabihf/gdb/testsuite/gdb.arch/thumb2-it: No such file or directory
gdb/testsuite:
2016-05-23 Yao Qi <yao.qi@linaro.org>
* gdb.arch/thumb-prologue.exp: Use standard_testfile.
* gdb.arch/thumb2-it.exp: Likewise.
Add a new test for PR 20039. The test spawns new threads, then tries to
interrupt, continue, and interrupt again. This use case was fixed by
commit 5fe966540d in master, but gdb 7.11
is affected (so if you try it on the gdb-7.11-branch right now, the test
will fail).
New in v2, the test now handles mi-async on mode properly. The failure
was specific to mi-async off, but I don't think it's bad to test the
same thing under async on mode. I added a little hack when running in
async mode to work around bug 20045.
I also removed one continue/interrupt pair, as a single one was enough to
trigger the problem.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-threads-interrupt.c: New file.
* gdb.mi/mi-threads-interrupt.exp: New file.
When doing -exec-run on a freshly started GDB, the only target on the
target stack at the time the dummy one. When mi_async_p is called to
know whether the run should be async, it queries whether the current
target (dummy) supports async, and the answer is no. The fix is to make
the code query the target that will be used for the run, which is not
necessarily the current target.
No regressions in the gdb.mi directory using the unix, native-gdbserver
and native-extended-gdbserver boards. The test doesn't pass when
forcing maint set target-async off, obviously, since it makes mi-async
have no effect. It doesn't seem like other tests are checking for that
eventuality, so I didn't in the new test.
gdb/ChangeLog:
* mi/mi-main.c (run_one_inferior): Use run target to determine
whether to run async or not.
(mi_cmd_exec_run): Likewise.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-async-run.exp: New file.
* gdb.mi/mi-async-run.c: New file.
This updates the gdb test suite for Rust.
2016-05-17 Tom Tromey <tom@tromey.com>
Manish Goregaokar <manishsmail@gmail.com>
* lib/rust-support.exp: New file.
* lib/gdb.exp (skip_rust_tests): New proc.
(build_executable_from_specs): Handle rust.
* lib/future.exp (gdb_find_rustc): New proc.
(gdb_default_target_compile): Handle rust.
* gdb.rust/expr.exp: New file.
* gdb.rust/generics.exp: New file.
* gdb.rust/generics.rs: New file.
* gdb.rust/methods.exp: New file.
* gdb.rust/methods.rs: New file.
* gdb.rust/modules.exp: New file.
* gdb.rust/modules.rs: New file.
* gdb.rust/simple.exp: New file.
* gdb.rust/simple.rs: New file.
I wanted to unit test the Rust lexer, so I added a simple unit testing
command to gdb.
The intent is that self tests will only be compiled into gdb in
development mode. In release mode they simply won't exist. So, this
exposes $development to C code as GDB_SELF_TEST.
In development mode, test functions are registered with the self test
module. A test function is just a function that does some checks, and
throws an exception on failure.
Then this adds a new "maint selftest" command which invokes the test
functions, and a new dejagnu test case that invokes it.
2016-05-17 Tom Tromey <tom@tromey.com>
* NEWS: Add "maint selftest" entry.
* selftest.h: New file.
* selftest.c: New file.
* maint.c: Include selftest.h.
(maintenance_selftest): New function.
(_initialize_maint_cmds): Add "maint selftest" command.
* configure.ac (GDB_SELF_TEST): Maybe define.
* config.in, configure: Rebuild.
* Makefile.in (SFILES): Add selftest.c.
(COMMON_OBS): Add selftest.o.
2016-05-17 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Maintenance Commands): Document "maint selftest".
2016-05-17 Tom Tromey <tom@tromey.com>
* gdb.gdb/unittest.exp: New file.
batch-preserve-term-settings.exp fails if the shell prompt isn't $. It
is # in our testing env. In fact, the shell prompt can be anything.
The perfect solution would be "set_board_info shell_prompt" in the
host board file, and use board_info shell_prompt in
batch-preserve-term-settings.exp. This is a little bit overkill to
me, and we still need to figure out the different prompts on different
shells. I also tried to start shell with the prompt preset, but there is
not unique way to set shell prompt in different shells, so I give up.
It is reasonably simple to match either $ or # for the shell prompt, and
we can easily extend it to match other char, like >.
gdb/testsuite:
2016-05-16 Yao Qi <yao.qi@linaro.org>
* gdb.base/batch-preserve-term-settings.exp: Remove variable
shell_prompt. Update shell_prompt_re.
gdb/ChangeLog:
* dwarf2loc.c (dwarf2_find_location_expression): For DWO files still
add base_offset.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (build_executable_from_fission_assembler): Pass
$options when building executable.
* gdb.dwarf2/fission-loclists-pie.c: New file.
* gdb.dwarf2/fission-loclists-pie.exp: New file.
This test currently uses [is_remote target] to check if the test is
supported. This is not quite correct, as the limitation is actually
that it requires support for "running", ruling out stub-like targets.
Therefore, it should check for use_gdb_stub.
This has no visible effect right now, but it will once we make the
native-gdbserver board non-dejagnu-remote.
gdb/testsuite/ChangeLog:
* gdb.base/solib-display.exp: Check for [use_gdb_stub] instead
of [is_remote target],
This patch introduces the use_gdb_stub procedure, which allows getting
the right value of the use_gdb_stub variable/property in any all
situations.
When calling it before the $use_gdb_stub global variable has been set,
it will return the value of the use_gdb_stub property from the board
file. This happens when tests want to bail out early (even before gdb
has been started) when the current test setup is a stub.
Otherwise, it returns the value of the $use_gdb_stub global.
It's possible for these two to differ when a test file overrides the
value of the global.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (use_gdb_stub): New procedure.
PR symtab/19914
* dwarf2read.c (open_and_init_dwp_file): Look at backlink if objfile
is separate debug file.
testsuite/
* gdb.dwarf2/dwp-sepdebug.c: New file.
* gdb.dwarf2/dwp-sepdebug.exp: New file.
This test seems to work with both native-gdbserver and
native-extended-gdbserver, so I removed the remote check.
When running with native-gdbserver (a stub-like target), detach makes
gdbserver stop and gdb disconnect. runto_main just spawns a brand new
gdbserver. So it tests the exact same thing twice. It doesn't hurt
though.
With native-extended-gdbserver, the test is probably a bit more useful
(and similar to native). It tests running/detaching twice using the
same gdb/gdbserver instances, since with extended-remote, you can
detach/attach/run all you want, unlike with remote.
gdb/testsuite/ChangeLog:
* gdb.base/detach.exp: Remove is_remote check.
The comment says that we can't use runto_main here becore it doesn't
know how to handle annotation. Instead, the test puts a breakpoint at
main and calls run by hand. Therefore, it can't work with stub targets,
since they can't "run". The check should be then changed to check the
use_gdb_stub variable instead of [is_remote target].
But as an alternative, we can just use runto_main and enable annotations
after, since the "run to main" part is not really part of what we want
to test.
I also removed the "set test..." line that is unused.
gdb/testsuite/ChangeLog:
* gdb.base/annota-input-while-running.exp: Don't check for
[is_remote target]. Enable annotations after running to main.
Remove unused "set test..." line.
This patch adds a test for tracepoints enabling/disabling, which
didn't work properly for fast tracepoints on big endian systems.
gdb/testsuite/ChangeLog:
* gdb.trace/trace-enable-disable.exp: New file.
* gdb.trace/trace-enable-disable.c: New file.
Some fast tracepoints tests make sure that the in-process agent library
is properly loaded, by searching for the library name in "info
sharedlibrary".
Originally, it would search for the full path. Since patch "Make ftrace
tests work with remote targets" [1], the "runtime" location of the IPA,
in the standard output directory, is not the same as the original
location, in the gdbserver build directory. Therefore, the patch
changed the checks:
gdb_test "info sharedlibrary" ".*${libipa}.*" "IPA loaded"
to
gdb_test "info sharedlibrary" ".*[file tail ${libipa}].*" "IPA loaded"
so that only the "libinproctrace.so" part would be searched for.
Antoine (in CC) pointed out that I missed some, so I have to update
them. In the mean time, I noticed that I missed a few test failures:
adding the SONAME to the IPA makes it possible for the test executable
to erroneously pick up libinproctrace.so from /usr/lib if the test
harness failed to put the libinproctrace.so we want to test in the right
place. To mitigate that kind of error in the future, we can use the
return value of gdb_load_shlib (the path of the "runtime" version of the
library) and use that to search in the output of info sharedlibrary.
When testing locally, gdb_load_shlib returns the full normalized path of
the destination library, which the test executable should use e.g.:
/path/to/gdb/testsuite/outputs/gdb.trace/thetest/libinproctrace.so
My testing showed that it was the same path that gdb displayed in info
sharedlibrary. If the test executable picks up another
libinproctrace.so, the test will fail.
When testing remotely, gdb_load_shlib/gdb_remote_download only returns
us "libinproctrace.so", so the situation doesn't really change. If
there is a rogue libinproctrace.so in /usr/lib on the target and we fail
to download ours, it might cover up a test failure. But that situation
is probably still better than the original one, where it wasn't possible
to test remotely using the IPA at all.
[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=6e774b13c3b81ac2599812adf058796948ce7e95
gdb/testsuite/ChangeLog:
* gdb.arch/ftrace-insn-reloc.exp: Save gdb_load_shlib result,
use it in info sharedlibrary test.
* gdb.trace/ftrace-lock.exp: Likewise.
* gdb.trace/ftrace.exp: Likewise.
* gdb.trace/range-stepping.exp: Likewise.
* gdb.trace/trace-break.exp: Likewise.
* gdb.trace/trace-condition.exp: Likewise.
* gdb.trace/trace-mt.exp: Likewise.
This patch makes gdb_load_shlibs return the destination path of the
copied library. To make the procedure implementation and interface more
straightforward, it also changes it so that it accepts a single shared
library path at the time. Therefore, calls that are passed multiple
libraries:
gdb_load_shlibs $lib1 $lib2
must be changed to separate calls:
gdb_load_shlibs $lib1
gdb_load_shlibs $lib2
A subtle impact is the solib-search-path handling. In the former
version, solib-search-path is set using the directory of the first
passed lib (further calls overwrite the value). In the later version,
the directory of the library passed to the last call to gdb_load_shlibs
remnains. I don't think that's a problem in practice, since if we had
tests that needed multiple different paths in solib-search-path, they
wouldn't work in the first place.
Changed in v2:
* Split behavioural and rename changes in two separate patches.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_load_shlibs): Accept a single argument. Return
result of gdb_remote_download.
* gdb.base/ctxobj.exp: Split gdb_load_shlibs call.
* gdb.base/dso2dso.exp: Likewise.
* gdb.base/global-var-nested-by-dso.exp: Likewise.
* gdb.base/print-file-var.exp: Likewise.
* gdb.base/shlib-call.exp: Likewise.
* gdb.base/shreloc.exp: Likewise.
* gdb.base/solib-overlap.exp: Likewise.
* gdb.base/solib-weak.exp (do_test): Likewise.
* gdb.base/unload.exp: Likewise.
I get a timeout fail in branch-to-self.exp when it is compiled by a
bare-mental target running qemu, which doesn't have signal.
The test should be skipped if gdb,nosignals exists, and that is
what this patch does.
gdb/testsuite:
2016-04-27 Yao Qi <yao.qi@linaro.org>
* gdb.base/branch-to-self.exp: Skip it if gdb,nosignals
exists.
Instead of pre-computing indices into a fortran array re-use
the value_* interfaces to subscript a fortran array.
The benefit of using the new interface is that it takes care of
dynamic types and resolve them when needed.
This fixes issues when printing structures with dynamic arrays from toplevel.
Before:
(gdb) p twov
$1 = ( (( ( 6352320, 0, -66, -1, 267) ( 343476, 1, -15, 1, 0) ( 5, 0, 5, 0, 1) ...
After:
(gdb) p twov
$1 = ( (( ( 1, 1, 1, 1, 1) ( 1, 1, 321, 1, 1) ( 1, 1, 1, 1, 1) ...
2016-04-26 Sanimir Agovic <sanimir.agovic@intel.com>
Keven Boell <keven.boell@intel.com>
Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* f-valprint.c (f77_create_arrayprint_offset_tbl): Remove
function.
(F77_DIM_SIZE, F77_DIM_OFFSET): Remove macro.
(f77_print_array_1): Use value_subscript to subscript a
value array.
(f77_print_array): Remove call to f77_create_arrayprint_offset_tbl.
(f_val_print): Use value_field to construct a field value.
gdb/testsuite/Changelog:
* vla-type.exp: Print structure from toplevel.
Resolve type of an array's element to be printed in case it is dynamic.
Otherwise we don't use the correct boundaries nor the right location.
Before:
ptype fivearr(1)
type = Type five
Type one
integer(kind=4) :: ivla(34196784:34196832,34197072:34197120,34197360:34197408)
End Type one :: tone
End Type five
After:
ptype fivearr(1)
type = Type five
Type one
integer(kind=4) :: ivla(2,4,6)
End Type one :: tone
End Type five
2016-04-26 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* valarith.c (value_address): Resolve dynamic types.
gdb/testsuite/Changelog:
* gdb.fortran/vla-type.f90: Add test for static and dynamic arrays
of dynamic types.
* gdb.fortran/vla-type.exp: Add test for static and dynamic arrays
of dynamic types.
Fortran supports dynamic types for which bounds, size and location
can vary during their lifetime. As a result of the dynamic
behaviour, they have to be resolved at every query.
This patch will resolve the type of a structure field when it
is dynamic.
2016-04-26 Bernhard Heckel <bernhard.heckel@intel.com>
2016-04-26 Keven Boell <keven.boell@intel.com>
Before:
(gdb) print threev%ivla(1)
Cannot access memory at address 0x3
(gdb) print threev%ivla(5)
no such vector element
After:
(gdb) print threev%ivla(1)
$9 = 1
(gdb) print threev%ivla(5)
$10 = 42
gdb/Changelog:
* NEWS: Add new supported features for fortran.
* gdbtypes.c (remove_dyn_prop): New.
(resolve_dynamic_struct): Keep type length for fortran structs.
* gdbtypes.h: Forward declaration of new function.
* value.c (value_address): Return dynamic resolved location of a value.
(set_value_component_location): Adjust the value address
for single value prints.
(value_primitive_field): Support value types with a dynamic location.
(set_internalvar): Remove dynamic location property of
internal variables.
gdb/testsuite/Changelog:
* gdb.fortran/vla-type.f90: New file.
* gdb.fortran/vla-type.exp: New file.
I am seeing some test fails in gdb.trace/unavailable.exp on aarch64-linux,
like this,
print derived_whole^M
$43 = (Derived) {<Middle> = {<Base> = {x = 2}, _vptr.Middle = 0x401860 <VTT for Derived>, y = 3}, _vptr.Derived = 0x401848 <vtable for Derived+32>, z = 4}^M
(gdb) FAIL: gdb.trace/unavailable.exp: collect globals: print object on: print derived_whole
print derived_whole^M
$47 = {<Middle> = {<Base> = {x = 2}, _vptr.Middle = 0x401860 <VTT for Derived>, y = 3}, _vptr.Derived = 0x401848 <vtable for Derived+32>, z = 4}^M
(gdb) FAIL: gdb.trace/unavailable.exp: collect globals: print object off: print derived_whole
these fails are also found by recent x86_64-linux buildbot,
https://sourceware.org/ml/gdb-testers/2016-q2/msg00622.html
The fix is exactly the same as this one
http://www.sourceware.org/ml/gdb-patches/2015-10/msg00252.html (the
extra "VTT" after hex), in which we match extra things after $hex.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.trace/unavailable.exp (gdb_collect_globals_test_1): Match
more after $hex.
Hi,
I am seeing the fail below on aarch64-linux with gcc 4.9.2,
break main
Breakpoint 1 at 0x4006e8: file binutils-gdb/gdb/testsuite/gdb.base/annota1.c, line 14.^M
(gdb) FAIL: gdb.base/annota1.exp: breakpoint main
the test expects the breakpoint is set on line 15. Let us look at
the main function,
12 int
13 main (void)
14 {
15 int my_array[3] = { 1, 2, 3 }; /* break main */
16
17 value = 7;
18
19 #ifdef SIGUSR1
20 signal (SIGUSR1, handle_USR1);
21 #endif
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004006e0 <+0>: stp x29, x30, [sp,#-48]!
0x00000000004006e4 <+4>: mov x29, sp
0x00000000004006e8 <+8>: adrp x0, 0x411000 <signal@got.plt>
0x00000000004006ec <+12>: add x0, x0, #0x40
the breakpoint is set on the right address after skipping prologue, but
0x00000000004006e8 is mapped to the line 14, as shown below,
(gdb) maintenance info line-table
objfile: /home/yao.qi/source/build-aarch64/gdb/testsuite/outputs/gdb.base/annota1/annota1 ((struct objfile *) 0x2b0e1850)
compunit_symtab: ((struct compunit_symtab *) 0x2b0ded50)
symtab: /home/yao.qi/source/binutils-gdb/gdb/testsuite/gdb.base/annota1.c ((struct symtab *) 0x2b0dedd0)
linetable: ((struct linetable *) 0x2b12c8b0):
INDEX LINE ADDRESS
0 7 0x00000000004006d0
1 8 0x00000000004006d8
2 14 0x00000000004006e0
3 14 0x00000000004006e8
4 15 0x00000000004006fc
so GDB does nothing wrong. Program hits breakpoint on either line 14
or line 15 is right to me. With anther gcc (4.9.3), the line-table looks
correct, and no test fail. Instead of setting breakpoint on main and
assuming the line is what we get from the source, we can set breakpoint
on that line. On the other hand, the test prints the values of the
array and check, so we need to set breakpoint on the line setting the
values of array and "next", rather than setting the breakpoint on main.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.base/annota1.exp: Set breakpoint on line $main_line.
* gdb.base/annota3.exp: Likewise.
I see the following test fail in arm-linux with -marm and -fomit-frame-pointer,
step
callee () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c:27
27 } /* RETURN FROM CALLEE */
(gdb) step
main () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c:58
58 callee(); /* STEP INTO THIS CALL */
(gdb) FAIL: gdb.reverse/step-precsave.exp: reverse step into fn call
As we can see, the "step" has already stepped into the function callee,
but in the last line. The second "step" attempts to step to function
body, but it goes out of callee, which isn't expected.
The program is compiled with -marm and -fomit-frame-pointer, the
function callee is prologue-less, because nothing needs to be saved
on stack,
(gdb) disassemble callee
Dump of assembler code for function callee:
0x00010680 <+0>: movw r3, #2364 ; 0x93c
0x00010684 <+4>: movt r3, #2
0x00010688 <+8>: ldr r3, [r3]
0x0001068c <+12>: add r2, r3, #1
0x00010690 <+16>: movw r3, #2364 ; 0x93c
0x00010694 <+20>: movt r3, #2
0x00010698 <+24>: str r2, [r3]
0x0001069c <+28>: mov r3, #0
0x000106a0 <+32>: mov r0, r3
0x000106a4 <+36>: bx lr
program stops at the 0x106a0 (passed the epilogue) after the first
"step". When second "step" is executed, the stepping range is
[0x10680-0x106a0], which starts from the first instruction of function
callee (because it doesn't have prologue).
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [LWP 2461] at 0x1069c^M
infrun: prepare_to_wait^M
infrun: target_wait (-1.0.0, status) =^M
infrun: 2461.2461.0 [LWP 2461],^M
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP^M
infrun: TARGET_WAITKIND_STOPPED^M
infrun: stop_pc = 0x10698^M
infrun: stepping inside range [0x10680-0x106a0]
When program goes out of the range, it stops at the caller of callee,
and test fails. IOW, if function callee has prologue, the stepping
range won't start from the first instruction of the function, and
program stops at the prologue and test passes.
IMO, GDB does nothing wrong, but test shouldn't expect the program
stops in callee after the second "step". I decide to fix test rather
than GDB. In this patch, I change to test to do one "step", and check
the program is still in callee, then, do multiple "step" until program
goes out of the callee.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.reverse/step-precsave.exp: Do one step and test program
stops in "callee" and do multiple steps until program goes out
of "callee".
* gdb.reverse/step-reverse.exp: Likewise.
GDBserver doesn't deliver signal when stepping over a breakpoint even
hardware single step is used. When GDBserver started to step over
(thread creation) breakpoint for mutlit-threaded debugging in 2002 [1],
GDBserver behaves this way.
This behavior gets trouble on conditional breakpoints on branch to
self instruction like this,
0x00000000004005b6 <+29>: jmp 0x4005b6 <main+29>
and I set breakpoint
$(gdb) break branch-to-self.c:43 if counter > 3
and the variable counter will be set to 5 in SIGALRM signal handler.
Since GDBserver keeps stepping over breakpoint, the SIGALRM can never
be dequeued and delivered to the inferior, so the program can't stop.
The test can be found in gdb.base/branch-to-self.exp.
GDBserver didn't deliver signal when stepping over a breakpoint because
a tracepoint is collected twice if GDBserver does so in the following
scenario, which can be reproduced by gdb.trace/signal.exp.
- program stops at tracepoint, and tracepoint is collected,
- gdbserver starts a step-over,
- a signal arrives, step-over is canceled, and signal should be passed,
- gdbserver starts a new step-over again, pass the signal as well,
- program stops at the entry of signal handler, step-over finished,
- gdbserver proceeds,
- program returns from the signal handler, again to the tracepoint,
and thus is collected again.
The spurious collection isn't that harmful, IMO, so it should be OK
to let GDBserver deliver signal when stepping over a breakpoint.
gdb/gdbserver:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* linux-low.c (lwp_signal_can_be_delivered): Don't deliver
signal when stepping over breakpoint with software single
step.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.trace/signal.exp: Also pass if
$tracepoint_hits($i) > $iterations.
This is to test whether GDBserver deliver signal to the inferior while
doing the step over. Nowadays, GDBserver doesn't deliver signal, so
there won't be spurious collection, however, if GDBserver does deliver
signal, there might be spurious collection.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.trace/signal.c: New file.
* gdb.trace/signal.exp: New file.
After compiling a program which uses C++ references some optimizations may
convert the references into synthetic "pointers". Trying to print the address
of one of such synthetic references causes gdb to crash with the following
error:
(gdb) print &ref
/build/buildd/gdb-7.7.1/gdb/dwarf2loc.c:1624: internal-error: Should not be able to create a lazy value with an enclosing type
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Apparently, what was causing it was that value_addr returns a copy of the value
that represents the reference with its type set to T* instead of T&. However,
its enclosing_type is left untouched, which fails a check made in
read_pieced_value. We only see the crash happen for references that are
synthetic because they're treated as pieced values, thus the call to
read_pieced_value.
On a related note, it seems that in general there are all sorts of breakage
when working with synthetic references. This is reported here:
https://sourceware.org/bugzilla/show_bug.cgi?id=19893
gdb/ChangeLog:
2016-04-18 Martin Galvan <martin.galvan@tallertechnologies.com>
* valops.c (value_addr): For C++ references, set the copied value's
enclosing_type as well.
gdb/testsuite/ChangeLog:
2016-04-18 Martin Galvan <martin.galvan@tallertechnologies.com>
* gdb.dwarf2/implref.exp: New file.
Gfortran and ifort have different names for data types. Encapsulate
type names in a library to increase number of supported compilers.
gfortran -4.2 : int4
gfortran>=4.3 : integer(kind=4)
ifort : INTEGER(4)
2016-04-18 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/testsuite/Changelog:
* gdb.fortran/common-block.exp: Use type naming defined in lib fortran.
* gdb.fortran/derived-type.exp: Use type naming defined in lib fortran.
* gdb.fortran/multi-dim.exp: Use type naming defined in lib fortran.
* gdb.fortran/vla-datatypes.exp: Use type naming defined in lib fortran.
* gdb.fortran/vla-ptype-sub.exp: Use type naming defined in lib fortran.
* gdb.fortran/vla-ptype.exp: Use type naming defined in lib fortran.
* gdb.fortran/whatis_type.exp: Use type naming defined in lib fortran.
* lib/fortran.exp (fortran_int4): New procedure.
(fortran_real4, fortran_real8, fortran_complex4): Likewise.
(fortran_logical4): Likewise.
We are missing "-fpic" flag when compiling shared libraries with ICC.
2016-04-18 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Testsuite/Changelog:
* lib/gdb.exp (gdb_compile_shlib): Add flag for ICC compiler.
Add Intel specific preprocessor macros to query the version of the compiler.
2016-04-18 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Testsuite/Changelog:
* lib/compiler.c: Add Intel specific preprocessor macros.
* lib/compiler.cc: Likewise.
This test exercises the scenarios where we attempt to connect GDB to GDBserver
in standard remote mode, query the symbol file path, attempt to open said
symbol file on GDB's end and fail, causing the connection to drop abruptly.
Regression-tested on x86-64/Ubuntu.
With an unpatched GDB we should see this:
FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: action=permission: connection to GDBserver succeeded (the program is no longer running)
FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: action=delete: connection to GDBserver succeeded (the program is no longer running)
FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: connection to GDBserver succeeded (the program is no longer running)
FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=delete: connection to GDBserver succeeded (the program is no longer running)
A patched GDB should have full passes.
gdb/testsuite/ChangeLog:
2016-04-13 Luis Machado <lgustavo@codesourcery.com>
* gdb.server/connect-with-no-symbol-file.c: New file.
* gdb.server/connect-with-no-symbol-file.exp: New file.
This patch fixes the current comment in gdb_remote_download, which is
false (the "except if that's already where it is" part). It also
improves it, by explaining why pass TOFILE through standard_output_file,
even it is an absolute path.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_remote_download): Fix and extend comment.
gdbserver-base.exp is used as the base for both native-gdbserver.exp and
native-extended-gdbserver.exp. (Despite its name, it should really be
considered as a "local-gdbserver-base", as it's not really appropriate to
implement a remote gdbserver board.)
Currently, the _download procedure is implemented as a no-op (it returns
the source file path). Because of the SONAME change, The fast
tracepoint tests now require the executable and the IPA
(libinproctrace.so) to be located in the same directory (see [1]). When
using the native-gdbserver board, because _download returns the original
file path, the executable does not end up in the same directory as the
library, and it fails to execute.
In more general terms, with the recent changes, the testsuite now
assumes that when it does
${board}_download <source path 1> <destination path 1>
${board}_download <source path 2> <destination path 2>
where the destination paths are relative (generally just the file name),
both files will end up in the same base directory. That assumption does
not hold for the current implementation in gdbserver-base.exp.
The proper fix would be to make native-gdbserver non-remote, so that
gdb_remote_download would not call DejaGnu's remote_download (see [2]).
We could then get rid of ${board}_download in gdbserver-base.exp.
However, that will likely take some time to complete. In the mean time,
in order to make the fast tracepoint tests pass, we can simply copy the
file to the standard output directory. Basically, it just mimics what
gdb_remote_download would do if the board wasn't flagged as remote.
Note that I missed these failures originally because I had a
libinproctrace.so in /usr/local/lib. So, even though libinproctrace.so
wasn't copied to the test output directory, it did find the one in
/usr/local/lib. It would be nice to find a way to protect against this,
as it could easily happen again...
Regtested with unix, native-gdbserver and native-extended-gdbserver, and
didn't see anything notable, except the ftrace tests now passing for
native-gdbserver.
[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=6e774b13c3b81ac2599812adf058796948ce7e95
[2] https://sourceware.org/ml/gdb-patches/2016-04/msg00112.html
gdb/testsuite/ChangeLog:
* boards/gdbserver-base.exp (${board}_download): Copy source file to
standard output directory.
This patch fixes the following failure:
FAIL: gdb.trace/trace-condition.exp: ftrace: -(21 << 1) == -42: check 10
frames were collected.
This was due to aarch64_emit_sub using the wrong order in its operands, so the
operation would end up being 42 - 0 rather than 0 - 42.
This patch also fixes the order of aarch64_emit_add for clarity.
The test case for emit_sub is fixed so that the proper order of
the operands is needed for the test to pass.
Tested on aarch64-native-extended-gdbserver.
Note: trace-condition.exp was broken a bit so I had to modify it to run
the test. A fix is coming for that in another patch.
gdb/gdbserver/ChangeLog:
* linux-aarch64-low.c (aarch64_emit_add): Switch x1 and x0.
(aarch64_emit_sub): Likewise.
gdb/testsuite/ChangeLog:
* gdb.trace/trace-condition.exp (foreach): Fix emit_sub testcase.
On systems with a newer version of GCC the gdb.btrace/instruction_history.exp
test fails to build like this:
Running .../gdb.btrace/instruction_history.exp ...
gdb compile failed, .../gdb.btrace/instruction_history.c:
In function 'main': .../gdb.btrace/instruction_history.c:24:3: warning:
implicit declaration of function 'loop' [-Wimplicit-function-declaration]
loop ();
^
Declare loop to fix it.
testsuite/
* gdb.btrace/instruction_history.c (loop): Add declaration.
This obvious patch replaces "ond" wiht "cond" as the test prefix for
conditional tests.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace.exp (proc): Change test prefix from "ond" to "cond".
There are a few small changes needed to make it work with a real remote
target.
- Remove the [is_remote target] check.
- Remove soname setting when building the lib, it's done by default now
anyway.
- In the compilation of the executable, pass the shared lib using the
shlib option, so that RPATH is set.
- Download the program to the target using gdb_remote_download, and
record the remote path. Remove loading of the program using
gdb_load_shlibs, which was not really appropriate anyway.
- Run the remote path through readlink (see comment in the code).
- Start gdbserver with the remote path.
Also, don't set executable and objfile variables, as they are unused.
Tested with native, native-gdbserver, native-extended-gdbserver, and a
remote gdbserver.
gdb/testsuite/ChangeLog:
* gdb.server/solib-list.exp: Remove is_remote check.
Pass shlib= to gdb_compile. Don't link shared library with
-soname. Call gdb_remote_download instead of gdb_load_shlibs.
Run binary filename through "readlink -f" on the target.
Commit 7817ea4614 (Improve gdb_remote_download, remove gdb_download)
caused:
FAIL: gdb.server/solib-list.exp: non-stop 0: target extended-remote (timeout)
FAIL: gdb.server/solib-list.exp: non-stop 0: continue (the program is no longer running)
FAIL: gdb.server/solib-list.exp: non-stop 0: p libvar
FAIL: gdb.server/solib-list.exp: non-stop 1: target extended-remote (timeout)
FAIL: gdb.server/solib-list.exp: non-stop 1: continue (the program is no longer running)
FAIL: gdb.server/solib-list.exp: non-stop 1: p libvar
gdb.log shows:
system interpreter is: /lib64/ld-linux-x86-64.so.2
...
spawn ../gdbserver/gdbserver --once :2347 /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.server/solib-list/ld-linux-x86-64.so.2 /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.server/solib-list/solib-list
Process /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.server/solib-list/ld-linux-x86-64.so.2 created; pid = 18637
Cannot exec /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.server/solib-list/ld-linux-x86-64.so.2: No such file or directory.
...
The test copied the interpreter to the outputs directory, however
ld-linux-x86-64.so.2 is a relative symlink that when copied points
nowhere:
$ ls -l testsuite/outputs/gdb.server/solib-list/
total 52
-rwxrwxr-x. 1 pedro pedro 13450 Apr 7 10:52 gdb.log
-rw-rw-r--. 1 pedro pedro 1512 Apr 7 10:52 gdb.sum
lrwxrwxrwx. 1 pedro pedro 10 Apr 7 11:39 ld-linux-x86-64.so.2 -> ld-2.22.so
-rwxrwxr-x. 1 pedro pedro 9464 Apr 7 11:39 solib-list
-rw-rw-r--. 1 pedro pedro 3472 Apr 7 11:39 solib-list-lib.c.o
-rw-rw-r--. 1 pedro pedro 2760 Apr 7 11:39 solib-list.o
-rwxrwxr-x. 1 pedro pedro 9232 Apr 7 11:39 solib-list.so
The copying comes from gdbserver_spawn ->
gdbserver_download_current_prog -> gdb_remote_download.
There's actually no need to download the interpreter to the target -
it's part of the target system/environment. So fix this by making the
test just not use gdb_load (and gdb_file_cmd as consequence) at all,
and instead pass the interpreter filename to gdbserver as an argument.
gdb/testsuite/ChangeLog:
2016-04-08 Pedro Alves <palves@redhat.com>
* gdb.server/solib-list.exp: Don't use gdb_load. Instead pass the
interpreter filename as argument to gdbserver_spawn.
* lib/gdbserver-support.exp (gdbserver_download_current_prog):
Return empty if $last_loaded_file does not exist.
on CentOS-7.2 I get
Running /home/jkratoch/redhat/gdb-test-reg/gdb/testsuite/gdb.base/jit.exp ...
FAIL: gdb.base/jit.exp: one_jit_test-1: continue to breakpoint: break here 2 (the program exited)
FAIL: gdb.base/jit.exp: one_jit_test-2: continue to breakpoint: break here 2 (the program exited)
FAIL: gdb.base/jit.exp: attach: one_jit_test-2: continue to breakpoint: break here 2 (the program exited)
FAIL: gdb.base/jit.exp: attach: one_jit_test-2: break here 2: set var wait_for_gdb = 1
FAIL: gdb.base/jit.exp: attach: one_jit_test-2: break here 2: detach (the program is no longer running)
FAIL: gdb.base/jit.exp: attach: one_jit_test-2: break here 2: attach
FAIL: gdb.base/jit.exp: attach: one_jit_test-2: break here 2: set var wait_for_gdb = 0
FAIL: gdb.base/jit.exp: PIE: one_jit_test-1: continue to breakpoint: break here 2 (the program exited)
Running /home/jkratoch/redhat/gdb-test-reg/gdb/testsuite/gdb.base/jit-so.exp ...
FAIL: gdb.base/jit-so.exp: one_jit_test-1: continue to breakpoint: break here 2 (the program exited)
FAIL: gdb.base/jit-so.exp: one_jit_test-2: continue to breakpoint: break here 2 (the program exited)
since:
85af34ee0211eedf8d30a5c44dfc59dddf8b512a is the first bad commit
commit 85af34ee0211eedf8d30a5c44dfc59dddf8b512a
Author: Pedro Alves <palves@redhat.com>
Date: Thu Mar 31 19:28:47 2016 +0100
Add regression test for PR gdb/19858 (JIT code registration on attach)
The compiled code's .debug_line is wrong (for the simplistic approach of GDB
to put a breakpoint on the first address belonging to that source line) and so
GDB misses the breakpoint at the last line:
WAIT_FOR_GDB; return 0; /* gdb break here 2 */
Most of the patch is just about reindentation, no changes there.
gdb/testsuite/ChangeLog
2016-04-08 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix compatibility with gcc-4.8.5-4.el7.x86_64.
* gdb.base/jit-main.c: Use exit after usage.
Bernhard Heckel
Tom Tromey
Pedro Alves
Francis Ricci
Yao Qi
Simon Marchi
Doug Evans
Keven Boell
Doug Evans
Martin Galvan
Luis Machado
Antoine Tremblay
Markus Metzger
Simon Marchi
Jan Kratochvil