The gdb_load_shlib function will, on remote targets, try to run some
GDB commands. This obviously isn't going to work unless GDB is
running.
The gdb.trace/tspeed.exp test calls gdb_load_shlib before starting
GDB. Don't do that.
The failure that's triggered is actually DeJaGNU complaining that the
variable $use_gdb_stub doesn't exist, this is only created when GDB is
started. Something like this should trigger a failure:
make check-gdb \
RUNTESTFLAGS="--target_board=remote-gdbserver-on-localhost \
gdb.trace/tspeed.exp"
This commit also adds a check to gdb_load_shlib that GDB is running.
The check is always performed, so this should catch cases where a GDB
developer adds a use of gdb_load_shlib but doesn't test their code
with a remote target.
gdb/testsuite/ChangeLog:
* gdb.trace/tspeed.exp: Only call gdb_load_shlib after gdb has
started.
* lib/gdb.exp (gdb_load_shlib): Call perror if GDB is not running.
This changes the help text of a couple of commands in tracepoint.c to
follow the GNU style.
ChangeLog
2018-04-29 Tom Tromey <tom@tromey.com>
* tracepoint.c (_initialize_tracepoint): Update help text.
testsuite/ChangeLog
2018-04-30 Tom Tromey <tom@tromey.com>
* gdb.trace/tfind.exp: Update help tests.
Some of GDB's trace test cases define a function end() and place a
breakpoint there with "break end". However, when libinproctrace is linked
to the binary, there are multiple methods named "end", such as
std::string::end() from the C++ library or format_pieces::end() from
common/format.h. GDB then creates multiple breakpoints instead of just a
single one, and some FAILs result, such as these:
FAIL: gdb.trace/trace-mt.exp: ftrace on: break end
FAIL: gdb.trace/trace-mt.exp: ftrace off: break end
Fix this by adding the "-qualified" option to the break commands. For
consistency, change all occurrences of "break end" (and similar) in all
trace test cases, even if the current behavior does not cause problems.
Also, consequently use the gdb_breakpoint convenience proc.
gdb/testsuite/ChangeLog:
* gdb.trace/actions-changed.exp: Call gdb_breakpoint with the
"qualified" option when setting breakpoints.
* gdb.trace/backtrace.exp: Likewise.
* gdb.trace/circ.exp: Likewise.
* gdb.trace/collection.exp: Likewise.
* gdb.trace/disconnected-tracing.exp: Likewise.
* gdb.trace/ftrace-lock.exp: Likewise.
* gdb.trace/ftrace.exp: Likewise.
* gdb.trace/infotrace.exp: Likewise.
* gdb.trace/packetlen.exp: Likewise.
* gdb.trace/passc-dyn.exp: Likewise.
* gdb.trace/qtro.exp: Likewise.
* gdb.trace/read-memory.exp: Likewise.
* gdb.trace/report.exp: Likewise.
* gdb.trace/signal.exp: Likewise.
* gdb.trace/status-stop.exp: Likewise.
* gdb.trace/strace.exp: Likewise.
* gdb.trace/tfind.exp: Likewise.
* gdb.trace/trace-break.exp: Likewise.
* gdb.trace/trace-condition.exp: Likewise.
* gdb.trace/trace-mt.exp: Likewise.
* gdb.trace/tstatus.exp: Likewise.
* gdb.trace/tsv.exp: Likewise.
* gdb.trace/unavailable-dwarf-piece.exp: Likewise.
* gdb.trace/unavailable.exp: Likewise.
* gdb.trace/while-dyn.exp: Likewise.
The tspeed test case does not execute correctly because libinproctrace.so
is not copied to the target. This is fixed.
gdb/testsuite/ChangeLog:
* gdb.trace/tspeed.exp: Add invocation of gdb_load_shlib to ensure
that libinproctrace is copied to the target.
Target descriptions are allocated lazily, that is fine in GDBserver,
but it is not safe to call malloc in gdb_collect in IPA, because we
can set a fast tracepoint in malloc, and when the tracepoint is hit,
gdb_collect/malloc is called, deadlock or memory corruption may be
triggered.
#0 0xf7cfc200 in malloc ()
#1 0xf7efdc07 in operator new(unsigned int) ()
#2 0xf7ef7636 in allocate_target_description() ()
#3 0xf7efcbe1 in i386_create_target_description(unsigned long long, bool) ()
#4 0xf7efb474 in i386_linux_read_description(unsigned long long) ()
#5 0xf7efb190 in get_ipa_tdesc(int) ()
#6 0xf7ef9baa in gdb_collect ()
The fix is to initialize all target descriptions earlier, when the
IPA is loaded. In order to guarantee malloc is not called in IPA
in gdb_collect, I change the test to set a breakpoint on malloc, if
IPA gdb_collect calls malloc, program will hit the breakpoint, and
test fail.
continue
Continuing.
Thread 1 "" hit Breakpoint 5, 0xf7cfc200 in malloc ()
(gdb) FAIL: gdb.trace/ftrace.exp: advance through tracing
gdb/gdbserver:
2017-12-07 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-ipa.c (initialize_low_tracepoint): Call
aarch64_linux_read_description.
* linux-amd64-ipa.c (idx2mask): New array.
(get_ipa_tdesc): Move idx2mask out.
(initialize_low_tracepoint): Initialize target descriptions.
* linux-i386-ipa.c (idx2mask): New array.
(get_ipa_tdesc): Move idx2mask out.
(initialize_low_tracepoint): Initialize target descriptions.
gdb/testsuite:
2017-12-07 Yao Qi <yao.qi@linaro.org>
* gdb.trace/ftrace.exp (run_trace_experiment): Set breakpoint on
malloc and catch syscall.
An earlier commit made GDB no longer assume no-debug-info functions
return int. This commit gives the same treatment to variables.
Currently, you can end misled by GDB over output like this:
(gdb) p var
$1 = -1
(gdb) p /x var
$2 = 0xffffffff
until you realize that GDB is assuming that the variable is an "int",
because:
(gdb) ptype var
type = <data variable, no debug info>
You may try to fix it by casting, but that doesn't really help:
(gdb) p /x (unsigned long long) var
$3 = 0xffffffffffffffff # incorrect
^^
That's incorrect output, because the variable was defined like this:
uint64_t var = 0x7fffffffffffffff;
^^
What happened is that with the cast, GDB did an int -> 'unsigned long
long' conversion instead of reinterpreting the variable as the cast-to
type. To get at the variable properly you have to reinterpret the
variable's address manually instead, with either:
(gdb) p /x *(unsigned long long *) &var
$4 = 0x7fffffffffffffff
(gdb) p /x {unsigned long long} &var
$5 = 0x7fffffffffffffff
After this commit GDB does it for you. This is what you'll get
instead:
(gdb) p var
'var' has unknown type; cast it to its declared type
(gdb) p /x (unsigned long long) var
$1 = 0x7fffffffffffffff
As in the functions patch, the "compile" machinery doesn't currently
have the cast-to type handy, so it continues assuming no-debug
variables have int type, though now at least it warns.
The change to gdb.cp/m-static.exp deserves an explanation:
- gdb_test "print 'gnu_obj_1::method()::sintvar'" "\\$\[0-9\]+ = 4" \
+ gdb_test "print (int) 'gnu_obj_1::method()::sintvar'" "\\$\[0-9\]+ = 4" \
That's printing the "sintvar" function local static of the
"gnu_obj_1::method()" method.
The problem with that test is that that "'S::method()::static_var'"
syntax doesn't really work in C++ as you'd expect. The way to make it
work correctly currently is to quote the method part, not the whole
expression, like:
(gdb) print 'gnu_obj_1::method()'::sintvar
If you wrap the whole expression in quotes, like in m-static.exp, what
really happens is that the parser considers the whole string as a
symbol name, but there's no debug symbol with that name. However,
local statics have linkage and are given a mangled name that demangles
to the same string as the full expression, so that's what GDB prints.
After this commit, and without the cast, the print in m-static.exp
would error out saying that the variable has unknown type:
(gdb) p 'gnu_obj_1::method()::sintvar'
'gnu_obj_1::method()::sintvar' has unknown type; cast it to its declared type
TBC, if currently (even before this series) you try to print any
function local static variable of type other than int, you'll get
bogus results. You can see that with m-static.cc as is, even.
Printing the "svar" local, which is a boolean (1 byte) still prints as
"int" (4 bytes):
(gdb) p 'gnu_obj_1::method()::svar'
$1 = 1
(gdb) ptype 'gnu_obj_1::method()::svar'
type = <data variable, no debug info>
This probably prints some random bogus value on big endian machines.
If 'svar' was of some aggregate type (etc.) we'd still print it as
int, so the problem would have been more obvious... After this
commit, you'll get instead:
(gdb) p 'gnu_obj_1::method()::svar'
'gnu_obj_1::method()::svar' has unknown type; cast it to its declared type
... so at least GDB is no longer misleading. Making GDB find the real
local static debug symbol is the subject of the following patches. In
the end, it'll all "Just Work".
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* ax-gdb.c: Include "typeprint.h".
(gen_expr_for_cast): New function.
(gen_expr) <OP_CAST, OP_CAST_TYPE>: Use it.
<OP_VAR_VALUE, OP_MSYM_VAR_VALUE>: Error out if the variable's
type is unknown.
* dwarf2read.c (new_symbol_full): Fallback to int instead of
nodebug_data_symbol.
* eval.c: Include "typeprint.h".
(evaluate_subexp_standard) <OP_VAR_VALUE, OP_VAR_MSYM_VALUE>:
Error out if symbol has unknown type.
<UNOP_CAST, UNOP_CAST_TYPE>: Common bits factored out to
evaluate_subexp_for_cast.
(evaluate_subexp_for_address, evaluate_subexp_for_sizeof): Handle
OP_VAR_MSYM_VALUE.
(evaluate_subexp_for_cast): New function.
* gdbtypes.c (init_nodebug_var_type): New function.
(objfile_type): Use it to initialize types of variables with no
debug info.
* typeprint.c (error_unknown_type): New.
* typeprint.h (error_unknown_type): New declaration.
* compile/compile-c-types.c (convert_type_basic): Handle
TYPE_CODE_ERROR; warn and fallback to int for variables with
unknown type.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.asm/asm-source.exp: Add casts to int.
* gdb.base/nodebug.c (dataglobal8, dataglobal32_1, dataglobal32_2)
(dataglobal64_1, dataglobal64_2): New globals.
* gdb.base/nodebug.exp: Test different expressions involving the
new globals, with print, whatis and ptype. Add casts to int.
* gdb.base/solib-display.exp: Add casts to int.
* gdb.compile/compile-ifunc.exp: Expect warning. Add cast to int.
* gdb.cp/m-static.exp: Add cast to int.
* gdb.dwarf2/dw2-skip-prologue.exp: Add cast to int.
* gdb.threads/tls-nodebug.exp: Check that gdb errors out printing
tls variable with no debug info without a cast. Test with a cast
to int too.
* gdb.trace/entry-values.exp: Add casts.
The test suite contains multiple instances of determining the target's
endianness with GDB's "show endian" command. This patch replaces these by
an invocation of a new convenience proc 'get_endianness'.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (get_endianness): New proc.
* gdb.arch/aarch64-fp.exp: Use it.
* gdb.arch/altivec-regs.exp: Likewise.
* gdb.arch/e500-regs.exp: Likewise.
* gdb.arch/vsx-regs.exp: Likewise.
* gdb.base/dump.exp: Likewise.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/gnu_vector.exp: Likewise.
* gdb.dwarf2/formdata16.exp: Likewise.
* gdb.dwarf2/implptrpiece.exp: Likewise.
* gdb.dwarf2/nonvar-access.exp: Likewise.
* gdb.python/py-inferior.exp: Likewise.
* gdb.trace/unavailable-dwarf-piece.exp: Likewise.
This commit adds a test for the fix of PR 21352.
gdb/testsuite/ChangeLog:
2017-04-05 Sergio Durigan Junior <sergiodj@redhat.com>
PR gdb/21352
* gdb.trace/tsv.exp: Add test for "tsave -r".
This applies the second part of GDB's End of Year Procedure, which
updates the copyright year range in all of GDB's files.
gdb/ChangeLog:
Update copyright year range in all GDB files.
This fixes offender testcases that have test names starting with uppercase
when using gdb_test_multiple in a single-line construct.
gdb/testsuite/ChangeLog
2016-12-01 Luis Machado <lgustavo@codesourcery.com>
Fix test names starting with uppercase throughout the files.
* gdb.arch/i386-bp_permanent.exp
* gdb.arch/i386-gnu-cfi.exp
* gdb.base/disasm-end-cu.exp
* gdb.base/macscp.exp
* gdb.base/pending.exp
* gdb.base/watch_thread_num.exp
* gdb.cp/exception.exp
* gdb.cp/gdb2495.exp
* gdb.cp/local.exp
* gdb.python/py-evsignal.exp
* gdb.python/python.exp
* gdb.trace/tracecmd.exp
This fixes a comment I forgot to update in the previous patch.
gdb/testsuite/ChangeLog:
* gdb.trace/mi-trace-save.exp (test_trace_save_wrong_num_args):
Update comment.
-trace-save doesn't check whether an argument is passed, leading to a
segfault if you pass nothing.
I added a small test, which only tests the error conditions of
-trace-save.
gdb/ChangeLog:
* mi/mi-main.c (mi_cmd_trace_save): Check if argument is present
before using it.
gdb/testsuite/ChangeLog:
* gdb.trace/mi-trace-save.exp: New file.
gdb.trace/mi-trace-frame-collected.exp has a couple failures on x32:
FAIL: gdb.trace/mi-trace-frame-collected.exp: live: -trace-frame-collected (register)
FAIL: gdb.trace/mi-trace-frame-collected.exp: tfile: -trace-frame-collected (register)
gdb.log:
-trace-frame-collected
^done,explicit-variables=[{name="gdb_char_test",value="0 '\\000'"}],computed-expressions=[],registers=[{number="16",value="0x4004dc"},{number="204",value="0x4004dc"}],tvars
=[],memory=[{address="0x00601060",length="1"}]
(gdb)
FAIL: gdb.trace/mi-trace-frame-collected.exp: live: -trace-frame-collected (register)
[...]
-trace-frame-collected
^done,explicit-variables=[{name="gdb_char_test",value="0 '\\000'"}],computed-expressions=[],registers=[{number="16",value="0x4004dc"},{number="204",value="0x4004dc"}],tvars
=[],memory=[{address="0x00601060",length="1"}]
(gdb)
FAIL: gdb.trace/mi-trace-frame-collected.exp: tfile: -trace-frame-collected (register)
This test only collects the PC, and thus expects to only see one
register in the output of -trace-frame-collected. However, while on
the 64-bit ABI gdb only exposes 64-bit $pc/$rip (register 16 above),
on x32, GDB exposes 32-bit $eip as well, as a pseudo-register
(register 204 above). Thus, collecting $pc/$rip automatically always
collects $eip as well.
gdb/testsuite/ChangeLog:
2016-08-19 Pedro Alves <palves@redhat.com>
* gdb.trace/mi-trace-frame-collected.exp
(test_trace_frame_collected): On x32, expect two registers.
This patch adds tests for emit operations with 64 bit values. It takes
special care to avoid mistakes that one could make on a 32bit architecture
using 64bit values.
gdb/testsuite/ChangeLog:
* gdb.trace/trace-condition.exp: Add 64bit tests.
This patch add variable length tests for emit_ref by reading the variable
passed as argument of 8 to 64 bit.
gdb/testsuite/ChangeLog:
* gdb.trace/trace-condition.c (marker): Adapt signature to 8 to 64
bits types.
(main): Adapt to 8 to 64 bits types.
* gdb.trace/trace-condition.exp: Add new tests.
This patch moves conditional tests that were done in ftrace.exp to
trace-condition.exp.
Note that emit_ref is now tested by the anarg local variable there is no
need to test the register directly.
All emit calls have been tested using asserts before / after the move, to
ensure that the tests cover the same functions.
Note that these function were not covered before and are still not:
emit_gt_goto, emit_lt_goto, emit_pop, emit_unsigned_less.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace.exp (test_ftrace_condition): Remove.
Move condition tests...
* gdb.trace/trace-condition.exp: Here.
In trace-condition.exp, tests are done by doing a conditional tracepoint
and validating that the trace contains all the frames that could be
collected if that condition is true.
E.g. test_tracepoints $trace_command "21 + 21 == 42" 10
This will always return true and collect the 10 frames possible to collect
with the test program.
However, if the condition evaluation is broken such that the condition is
unconditional we will not notice this problem.
This patch adds counter-cases to such conditions like so:
$trace_command "21 + 11 == 42" 0
This way such a problem would be noticed.
gdb/testsuite/ChangeLog:
* gdb.trace/trace-condition.exp: Add counter-case tests.
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.
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.
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.
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.
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".
When we build a shared library for testing, it is built differently
whether it is meant for the local system or a remote one. When it is
for the local system, the library is built with no SONAME. So when the
executable is built, roughly in this way:
$ gcc testfile.c /path/to/library.so
the executable will contain an absolute reference to the library. For
example:
$ readelf -a testsuite/gdb.python/py-shared | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [/home/emaisin/build/binutils-gdb/gdb/testsuite/gdb.python/py-shared-sl.sl]
When testing is done remotely, the absolute path obviously doesn't work.
Therefore, we build the library with an SONAME:
$ readelf -a testsuite/gdb.python/py-shared-sl.sl | grep SONAME
0x000000000000000e (SONAME) Library soname: [py-shared-sl.sl]
which ends up in the executable's NEEDED field:
$ readelf -a testsuite/gdb.python/py-shared | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [py-shared-sl.sl]
The executable and the library are then uploaded side-by-side on the
remote system. To allow the dynamic linker to find the shared library,
we have to add the special RPATH value $ORIGIN, which tells it to search
in the executable's directory:
$ readelf -a testsuite/gdb.python/py-shared | grep ORIGIN
0x000000000000000f (RPATH) Library rpath: [$ORIGIN]
The problem with the IPA library is that it doesn't have an SONAME,
making it very difficult to do testing on a remote board. When a
test executable is linked with it, it contains an absolute reference to
the library path. Therefore, unless the paths on the target are the
same as on the build system, it won't work.
To make it possible for tests using the IPA library to run test on
remote boards, I suggest adding an SONAME to libinproctrace.so. I don't
think it should be a big problem for users. All the libraries installed
on my system have an SONAME, so it should be fine if libinproctrace.so
does too.
As a consequence, native testing does not work anymore, since
executables do not contain the absolute path to the library anymore. To
keep them working, we can have gdb_load_shlibs copy the library to the
test directory when testing natively. That's done by modifying
gdb_load_shlibs. We also have to add RPATH=$ORIGIN to executables, even
when testing natively.
I think it's a good change in general, as it reduces the differences
between testing a native and a remote target. To further reduce those
differences, we can also always build test shared libraries with an
SONAME.
ftrace.exp and ftrace-lock.exp need to be modified slightly. The code
checks that the IPA library is loaded using the absolute path on the
build machine. That obviously doesn't work if the test is done
remotely, as the path will be different. I changed the tests to only
search for the library basename (e.g. libinproctrace.so).
gdb/gdbserver/ChangeLog:
* Makefile.in ($(IPA_LIB)): Set SONAME of the IPA lib.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace-lock.exp: Check for IPA basename instead of
absolute.
* gdb.trace/ftrace.exp: Likewise.
* lib/gdb.exp (gdb_compile): Set rpath $ORIGIN for non-remote
targets as well.
(gdb_compile_shlib): Set SONAME for non-remote targets as well.
(gdb_load_shlibs): Copy libraries to test directory when testing
natively. Only set solib-search-path if testing remotely.
* lib/mi-support.exp (mi_load_shlibs): Likewise.
Also adds s390 support to gdb.trace testsuite.
gdb/gdbserver/ChangeLog:
* linux-s390-low.c (s390_supports_tracepoints): New function.
(struct linux_target_ops): Fill supports_tracepoints hook.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace.exp: Set arg0exp for s390.
* gdb.trace/mi-trace-frame-collected.exp: Expect 4 registers on s390.
* gdb.trace/mi-trace-unavailable.exp: Set pcnum for s390, add gpr0num
variable for GPR 0 instead of assuming it is register 0.
* gdb.trace/trace-common.h: Add s390 fast tracepoint placeholder.
* lib/trace-support.exp: Add s390 registers.
gdb/gdbserver/ChangeLog:
* linux-ppc-low.c (ppc_supports_tracepoints): New function.
(struct linux_target_ops): Wire in the above.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace.exp: Set arg0exp for ppc.
* gdb.trace/mi-trace-unavailable.exp: Set pcnum for ppc.
* gdb.trace/pending.exp: Accept leading dot before function name.
* gdb.trace/trace-common.h: Add fast tracepoint dummy insn for ppc.
* lib/trace-support.exp: Set registers for ppc.
On powerpc64, "disassemble foo" doesn't work properly on object files
(it can't process the relocations in .opd section) - instead, let's
link it into an executable and load that.
Also, backtrace displays .main, not main. Accept both.
gdb/testsuite/ChangeLog:
* gdb.trace/entry-values.exp: Link ${binfile}1.o to ${binfile}1 and
use it for disassembly; accept .main in addition to main in backtrace.
tfind.exp sets a breakpoint on *gdb_recursion_test, which is the global
entry point on ppc64le, and won't be hit, since the call uses
the local entry. Fix by calling the function via a pointer in a global
variable, forcing use of the global entry.
This patch is a slightly modified hunk extracted from
https://sourceware.org/ml/gdb-patches/2015-07/msg00353.html
gdb/testsuite/ChangeLog:
2016-03-09 Wei-cheng Wang <cole945@gmail.com>
Marcin Kościelnicki <koriakin@0x04.net>
* gdb.trace/actions.c (gdb_recursion_test_fp): New typedef.
(gdb_recursion_test_ptr): New global variable.
(gdb_recursion_test): Call gdb_recursion_test_ptr instead of
gdb_recursion_test.
(gdb_c_test): Ditto.
powerpc (32-bit) loads shared libraries below the main executable, so
the PENDING location is the first one, which the current regex doesn't
match. Split it into two tests instead, one looking for the pending
tracepoint location, and the other for two installed locations.
gdb/testsuite/ChangeLog:
* gdb.trace/change-loc.exp: Don't depend on tracepoint location
ordering.
On powerpc64, foo/bar point to a function descriptor, not to function code.
Since there are no global labels pointing at the actual function code,
let's make our own.
Regression-tested on x86_64.
gdb/testsuite/ChangeLog:
* gdb.trace/unavailable-dwarf-piece.c (foo): Add foo_start_lbl label.
(bar): Add bar_start_lbl label.
* gdb.trace/unavailable-dwarf-piece.exp: Use foo/bar_start_lbl instead
of foo/bar for emitting DWARF and tracing.
Fixes, on F23:
.../src/gdb/testsuite/gdb.trace/ftrace-lock.c: In function 'gdb_agent_gdb_collect':
.../src/gdb/testsuite/gdb.trace/ftrace-lock.c:50:3: warning: implicit declaration of function 'sleep' [-Wimplicit-function-declaration]
sleep (1);
^
gdb/testsuite/ChangeLog:
2016-03-01 Pedro Alves <palves@redhat.com>
* gdb.trace/ftrace-lock.c: Include <unistd.h>.
If gdbserver and IPA are using different tdesc, they will disagree
about 'R' trace packet size. This results in mangled traces.
To make sure they pick the same tdesc, gdbserver pokes the tdesc
(specified as an index in a target-specific list) into a global
variable in IPA. In theory, IPA could find out the tdesc on its
own, but that may be complex (in particular, I don't know how to
tell whether we have LAST_BREAK on s390 without messing with ptrace),
and we'd have to duplicate the logic.
Tested on i386 and x86_64. On i386, it fixes two FAILs in ftrace.exp.
On x86_64, these failures have been KFAILed - one of them works now,
but the other now fails due to an unrelated reason (ugh).
gdb/gdbserver/ChangeLog:
PR gdb/13808
* Makefile.in: Add i386-*-linux-ipa.o and amd64-*-linux-ipa.o.
* configure.srv: Ditto.
* linux-aarch64-ipa.c (get_ipa_tdesc): New function.
(initialize_low_tracepoint): Remove ipa_tdesc assignment.
* linux-amd64-ipa.c: Add "linux-x86-tdesc.h" include.
(init_registers_amd64_linux): Remove prototype.
(tdesc_amd64_linux): Remove declaration.
(get_ipa_tdesc): New function.
(initialize_low_tracepoint): Remove ipa_tdesc assignment,
initialize remaining tdescs.
* linux-i386-ipa.c: Add "linux-x86-tdesc.h" include.
(init_registers_i386_linux): Remove prototype.
(tdesc_i386_linux): Remove declaration.
(get_ipa_tdesc): New function.
(initialize_low_tracepoint): Remove ipa_tdesc assignment,
initialize remaining tdescs.
* linux-low.c (linux_get_ipa_tdesc_idx): New function.
(linux_target_ops): wire in linux_get_ipa_tdesc_idx.
* linux-low.h (struct linux_target_ops): Add get_ipa_tdesc_idx.
* linux-x86-low.c: Move tdesc declarations to linux-x86-tdesc.h.
(x86_get_ipa_tdesc_idx): New function.
(the_low_target): Wire in x86_get_ipa_tdesc_idx.
* linux-x86-tdesc.h: New file.
* target.h (struct target_ops): Add get_ipa_tdesc_idx.
(target_get_ipa_tdesc_idx): New macro.
* tracepoint.c (ipa_tdesc_idx): New macro.
(struct ipa_sym_addresses): Add addr_ipa_tdesc_idx.
(symbol_list): Add ipa_tdesc_idx.
(cmd_qtstart): Write ipa_tdesc_idx in the target.
(ipa_tdesc): Remove.
(ipa_tdesc_idx): New variable.
(get_context_regcache): Use get_ipa_tdesc.
(gdb_collect): Ditto.
(gdb_probe): Ditto.
* tracepoint.h (get_ipa_tdesc): New prototype.
(ipa_tdesc): Remove.
gdb/testsuite/ChangeLog:
PR gdb/13808
* gdb.trace/ftrace.exp (test_fast_tracepoints): Remove kfail.
The check used hardcoded targets and wasn't doing anything useful anyway,
since unsupported architectures blow up on link due to missing the IPA
library before they ever get to that check.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace.exp: Remove unnecessary target check.
The PPC64 tracepoint patch added \y at the end of the call_insn pattern -
without that, it embarassed itself and matched the 'bl' in "Dump of
assem*bl*er code for function" as the powerpc call opcode. Since that
sounds like a generally good idea, I've added \y before and after
call_insn for every target. As a result, I had to change x86_64's mnemonic
to 'callq'.
gdb/testsuite/ChangeLog:
* gdb.trace/entry-values.exp: Surround $call_insn with '\y',
change x86_64 call_insn to 'callq'.
As it is planned to add more architectures to this test, rename to a more
generic name.
gdb/testsuite/ChangeLog:
* gdb.trace/tfile-avx.c: Move to...
* gdb.trace/tracefile-pseudo-reg.c: Here.
* gdb.trace/tfile-avx.exp: Move to...
* gdb.trace/tracefile-pseudo-reg.exp: Here.
unavailable.exp executes "info registers", expecting to find at least
two instances of "<unavailable>". However, it uses
"<unavailable>.*<unavailable>" as the pattern, which doesn't match
when the last register happens to be available (eg. PC). Change it
to ".*<unavailable>.*<unavailable>.*" instead.
Noticed on s390, no regression on x86_64.
gdb/testsuite/ChangeLog:
* gdb.trace/unavailable.exp (gdb_unavailable_registers_test_1): Fix
info registers pattern.
gdb/testsuite/ChangeLog:
2016-02-18 Wei-cheng Wang <cole945@gmail.com>
* gdb.trace/tspeed.c (myclock): Return wallclock instead of
user+system time.
(trace_speed_test): Determine the iteration count for a time
between 15..30 seconds.
In save-trace.exp, we want to test loading of a tracepoint definition
file with a relative path (I am not sure why in fact). We currently use
"savetrace-relative.tr", which ends up directly in testsuite/. If we
use [standard_output_file] on that path, it becomes absolute. I decided
to just replace [pwd] with . (a dot) in the path given by
standard_output_file to make it relative. However, this trick only
works because [pwd] is a prefix of the standard output directory. So I
added a check to verify that precondition.
gdb/testsuite/ChangeLog:
* gdb.trace/save-trace.exp: Change relative path to be in the
standard output directory.
gcc older than 4.9 doesn't understand ymm15 as a register name. Use
xmm15 instead.
gdb/testsuite/ChangeLog:
* gdb.trace/tfile-avx.c (main): Change ymm15 to xmm15.
This tests whether $ymm15 can be correctly collected and printed from
tfile. It covers:
- storing tdesc in tfile (without that, $ymm15 doesn't exist)
- ax_pseudo_register_collect for x86 (without that, $ymm15 cannot be
collected)
- register order in tfile_fetch_registers (without that, $ymm15h is
fetched from wrong position)
- off-by-one in tfile_fetch_registers (without that, $ymm15h is
incorrectly considered to be out of bounds)
- using proper tdesc in encoding tracepoint actions (without that,
internal error happens due to $ymm15h being considered unavailable)
gdb/testsuite/ChangeLog:
* gdb.trace/tfile-avx.c: New test.
* gdb.trace/tfile-avx.exp: New test.
When running tests in parallel, each test puts its generated files in a
different directory, under "outputs". I think it would be nice if it
was always the case, as it would isolate the test cases a bit more. An
artifact created by a test wouldn't get overwritten by another test.
Also, it makes it easier to clean up. A lot of executables are left all
over the place because their names do not appear in gdb.*/Makefile. If
everything is in "outputs", then we just have to delete that directory
(which we already do).
At the same time it makes the gdb.foo directories and their Makefiles
useless in the build directory, since they are pretty much only used for
cleaning.
What do you think?
gdb/testsuite/ChangeLog:
* Makefile.in (ALL_SUBDIRS): Remove.
(clean mostlyclean): Do not recurse in ALL_SUBDIRS.
(distclean maintainer-clean realclean): Likewise.
* configure.ac (AC_OUTPUT): Remove gdb.*/Makefile.
* configure: Regenerate.
* gdb.ada/Makefile.in: Delete.
* gdb.arch/Makefile.in: Likewise.
* gdb.asm/Makefile.in: Likewise.
* gdb.base/Makefile.in: Likewise.
* gdb.btrace/Makefile.in: Likewise.
* gdb.cell/Makefile.in: Likewise.
* gdb.compile/Makefile.in: Likewise.
* gdb.cp/Makefile.in: Likewise.
* gdb.disasm/Makefile.in: Likewise.
* gdb.dlang/Makefile.in: Likewise.
* gdb.dwarf2/Makefile.in: Likewise.
* gdb.fortran/Makefile.in: Likewise.
* gdb.gdb/Makefile.in: Likewise.
* gdb.go/Makefile.in: Likewise.
* gdb.guile/Makefile.in: Likewise.
* gdb.java/Makefile.in: Likewise.
* gdb.linespec/Makefile.in: Likewise.
* gdb.mi/Makefile.in: Likewise.
* gdb.modula2/Makefile.in: Likewise.
* gdb.multi/Makefile.in: Likewise.
* gdb.objc/Makefile.in: Likewise.
* gdb.opencl/Makefile.in: Likewise.
* gdb.opt/Makefile.in: Likewise.
* gdb.pascal/Makefile.in: Likewise.
* gdb.perf/Makefile.in: Likewise.
* gdb.python/Makefile.in: Likewise.
* gdb.reverse/Makefile.in: Likewise.
* gdb.server/Makefile.in: Likewise.
* gdb.stabs/Makefile.in: Likewise.
* gdb.threads/Makefile.in: Likewise.
* gdb.trace/Makefile.in: Likewise.
* gdb.xml/Makefile.in: Likewise.
* lib/gdb.exp (make_gdb_parallel_path): Add check for
GDB_PARALLEL.
(standard_output_file): Remove check for GDB_PARALLEL, always
return path in outputs/$subdir/$testname.
Andrew Burgess
Tom Tromey
Andreas Arnez
Joel Brobecker
Yao Qi
Pedro Alves
Sergio Durigan Junior
Luis Machado
Simon Marchi
Antoine Tremblay
Marcin Kościelnicki
Wei-cheng Wang