This is the portion of gdb_test which performs the match against
the RE (regular expression) passed to it:
return [gdb_test_multiple $command $message {
-re "\[\r\n\]*($pattern)\[\r\n\]+$gdb_prompt $" {
if ![string match "" $message] then {
pass "$message"
}
}
In a test that I've been working on recently, I wanted to use
a backreference - that's the \1 in the the RE below:
gdb_test "info threads" \
{.*[\r\n]+\* +([0-9]+) +Thread[^\r\n]* do_something \(n=\1\) at.*}
Put into English, I wanted to make sure that the value of n passed to
do_something() is the same as the thread number shown in the "info
threads" Id column. (I've structured the test case so that this
*should* be the case.)
It didn't work though. It turned out that ($pattern) in the RE
noted above is capturing the attempted backreference. So, in this
case, the backreference does not refer to ([0-9]+) as intended, but
instead refers to ($pattern). This is wrong because it's not what I
intended, but is also wrong because, if allowed, it could only match a
string of infinite length.
This problem can be fixed by using parens for a "noncapturing
subpattern". The way that this is done, syntactically, is to use
(?:$pattern) instead of ($pattern).
My research shows that this feature has been present since tcl8.1 which
was released in 1999.
The current tcl version is 8.6 - at least that's what I have on my
machine. It appears to me that mingw uses some subversion of tcl8.4
which will also have this feature (since 8.4 > 8.1).
So it seems to me that any platform upon which we might wish to test
GDB will have a version of tcl which has this feature. That being the
case, my hope is that there won't be any objections to its use.
When I looked at the implementation of gdb_test, I wondered whether
the parens were needed at all. I've concluded that they are. In the
event that $pattern is an RE which uses alternation at the top level,
e.g. a|b, we need to make $pattern a subpattern (via parens) to limit
the extend of the alternation. I.e, we don't want the alternation to
extend to the other portions of the RE which gdb_test uses to match
potential blank lines at the beginning of the pattern or the gdb
prompt at the end.
gdb/testsuite/ChangeLog:
* gdb.exp (gdb_test): Using noncapturing parens for the $pattern
subpattern.
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 adds a test for read/write access to variables with various types of
DWARF locations. It uses register- and memory locations and composite
locations with register- and memory pieces.
Since the new test calls gdb_test_no_output with commands that contain
braces, it is necessary for string_to_regexp to quote braces as well.
This was not done before.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/var-access.c: New file.
* gdb.dwarf2/var-access.exp: New test.
* lib/gdb-utils.exp (string_to_regexp): Quote braces as well.
This patch fixes an internal error exposed by a test that does
something like:
define kill-and-remove
kill inferiors 2
remove-inferiors 2
end
# Start one inferior.
start
# Start another inferior.
add-inferior 2
inferior 2
start
# Kill and remove inferior 1 while inferior 2 is selected.
thread apply 1.1 kill-and-remove
The internal error looks like this:
Thread 1.1 (Thread 0x7ffff7fc2700 (LWP 20677)):
[Switching to inferior 1 [process 20677] (gdb/testsuite/outputs/gdb.threads/threadapply/threadapply)]
[Switching to thread 1.1 (Thread 0x7ffff7fc2700 (LWP 20677))]
#0 main () at src/gdb/testsuite/gdb.threads/threadapply.c:38
38 for (i = 0; i < NUM; i++)
src/gdb/inferior.c:66: internal-error: void set_current_inferior(inferior*): Assertion `inf != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/threadapply.exp: kill_and_remove_inferior: try kill-and-remove: thread apply 1.1 kill-and-remove (GDB internal error)
There are several problems around this area of the code. One is that
in do_restore_current_thread_cleanup, we do a look up of inferior by
ptid, which can find the wrong inferior if the previously selected
inferior exited and some other inferior was started with a reused pid
(rare, but still...).
The other problem is that the "remove-inferiors" command rejects
attempts to remove the current inferior, but when we get to
"remove-inferiors" in a "thread apply THR remove-inferiors 2" command,
the current inferior is the inferior of thread THR, not the previously
selected inferior, so if the previously selected inferior was inferior
2, that command still manages to wipe it, and then gdb restores the
old selected inferior, which is now a dangling pointer...
So the fix here is:
- Make make_cleanup_restore_current_thread store a pointer to the
previously selected inferior directly, and use it directly instead
of doing ptid look ups.
- Add a refcount to inferiors, very similar to thread_info's refcount,
that is incremented/decremented by
make_cleanup_restore_current_thread, and checked before deleting an
inferior. To avoid duplication, a new refcounted_object type is
added, that both thread_info and inferior inherit from.
gdb/ChangeLog:
2017-04-19 Pedro Alves <palves@redhat.com>
* common/refcounted-object.h: New file.
* gdbthread.h: Include "common/refcounted-object.h".
(thread_info): Inherit from refcounted_object and add comments.
(thread_info::incref, thread_info::decref)
(thread_info::m_refcount): Delete.
(thread_info::deletable): Use the refcounted_object::refcount()
method.
* inferior.c (current_inferior_): Add comment.
(set_current_inferior): Increment/decrement refcounts.
(prune_inferiors, remove_inferior_command): Skip inferiors marked
not-deletable instead of comparing with the current inferior.
(initialize_inferiors): Increment the initial inferior's refcount.
* inferior.h (struct inferior): Forward declare.
Include "common/refcounted-object.h".
(current_inferior, set_current_inferior): Move declaration to
before struct inferior's definition, and fix comment.
(inferior): Inherit from refcounted_object. Add comments.
* thread.c (switch_to_thread_no_regs): Reference the thread's
inferior pointer directly instead of doing a ptid lookup.
(switch_to_no_thread): New function.
(switch_to_thread(thread_info *)): New function, factored out
from ...
(switch_to_thread(ptid_t)): ... this.
(restore_current_thread): Delete.
(current_thread_cleanup): Remove 'inf_id' and 'was_removable'
fields, and add 'inf' field.
(do_restore_current_thread_cleanup): Check whether old->inf is
alive instead of looking up an inferior by ptid. Use
switch_to_thread and switch_to_no_thread.
(restore_current_thread_cleanup_dtor): Use old->inf directly
instead of lookup up an inferior by id. Decref the inferior.
Don't restore 'removable'.
(make_cleanup_restore_current_thread): Same the inferior pointer
in old, instead of the inferior number. Incref the inferior.
Don't save/clear 'removable'.
gdb/testsuite/ChangeLog:
2017-04-19 Pedro Alves <palves@redhat.com>
* gdb.threads/threadapply.exp (kill_and_remove_inferior): New
procedure.
(top level): Call it.
* lib/gdb.exp (gdb_define_cmd): New procedure.
When using mi_gdb_test, if it fails because of the presence of
unexpected output, the error message is only the message passed as
the argument with no indication that there was an unexpected output.
This change adds an additional text to the failure message to
indicate that there was an unexpected output.
gdb/testsuite/ChangeLog:
* lib/mi-support.exp (mi_gdb_test): Add additional message
for unexpected output.
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Recently I fixed a bug that caused a DW_OP_implicit_pointer with non-zero
offset into a DW_OP_implicit_value to be handled incorrectly on big-endian
targets. GDB ignored the offset and copied the wrong bytes:
https://sourceware.org/ml/gdb-patches/2017-01/msg00251.html
But there is still a similar issue when a DW_OP_implicit_pointer points
into a DW_OP_stack_value instead; and again, the offset is ignored. There
is an important difference, though: While implicit values are treated like
blocks of data and anchored at the lowest-addressed byte, stack values
traditionally contain integer numbers and are anchored at the *least
significant* byte. Also, stack values do not come in varying sizes, but
are cut down appropriately when used. Thus, on big-endian targets the
scenario looks like this (higher addresses shown right):
|<- - - - - Stack value - - - - - - ->|
| |
|<- original object ->|
|
| offset ->|####|
^^^^
de-referenced
implicit pointer
(Note how the original object's size influences the position of the
de-referenced implicit pointer within the stack value. This is not the
case for little-endian targets, where the original object starts at offset
zero within the stack value.)
This patch implements the logic indicated in the above diagram and adds an
appropriate test case. A new function dwarf2_fetch_die_type_sect_off is
added; it is used for retrieving the original object's type, so its size
can be determined. That type is passed to dwarf2_evaluate_loc_desc_full
via a new parameter.
gdb/ChangeLog:
* dwarf2loc.c (indirect_synthetic_pointer): Get data type of
pointed-to DIE and pass it to dwarf2_evaluate_loc_desc_full.
(dwarf2_evaluate_loc_desc_full): New parameter subobj_type; rename
byte_offset to subobj_byte_offset. Fix the handling of
DWARF_VALUE_STACK on big-endian targets when coming via an
implicit pointer.
(dwarf2_evaluate_loc_desc): Adjust call to
dwarf2_evaluate_loc_desc_full.
* dwarf2loc.h (dwarf2_fetch_die_type_sect_off): New declaration.
* dwarf2read.c (dwarf2_fetch_die_type_sect_off): New function.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp: Add support for DW_OP_implicit_pointer.
* gdb.dwarf2/nonvar-access.exp: Add test for stack value location
and implicit pointer into such a location.
An optional parameter TEST has been added to get_hexadecimal_valueof in commit:
https://sourceware.org/ml/gdb-patches/2016-06/msg00469.html
This patch adds a similar optional parameter to other related methods that
retrieve expression values: get_valueof, get_integer_valueof and get_sizeof.
Thus tests that evaluate same expression multiple times can provide custom
test names, ensuring that test names will be unique.
gdb/testsuite/ChangeLog:
2017-03-14 Anton Kolesov <anton.kolesov@synopsys.com>
* lib/gdb.exp (get_valueof, get_integer_valueof, get_sizeof):
Add optional 'test' parameter.
The next patch will require checking the DejaGnu version. There is
already a test that does this,
gdb.threads/attach-many-short-lived-threads.exp. This patch introduces
a new procedure, dejagnu_version, and makes that test use it.
The version number is "right-padded" with zeroes, to make sure that we
always return a triplet (major, minor, patch).
The procedure does not consider the DejaGnu versions from git. For
example, if you used DejaGnu from its current master branch, the version
would be "1.6.1-git", meaning that 1.6.1 will be the next release. I
figured we'll cross that bridge when (and if) we get there.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (dejagnu_version): New proc.
* gdb.threads/attach-many-short-lived-threads.exp (bad_dejagnu):
Use dejagnu_version.
DWARF-5 has new form DW_FORM_data16. The problem is that GDB cannot pass
16-byte constant as a constant value as that would require GDB to use GCC
extension __int128.
Formerly such data was coded as DW_FORM_block* so GDB still decodes
DW_FORM_data16 like DW_FORM_block*.
gdb/ChangeLog
2017-02-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* dwarf2read.c (skip_one_die, read_attribute_value)
(dwarf2_const_value_attr, dump_die_shallow)
(dwarf2_get_attr_constant_value, dwarf2_fetch_constant_bytes)
(skip_form_bytes, attr_form_is_constant): Handle DW_FORM_data16.
gdb/testsuite/ChangeLog
2017-02-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.dwarf2/formdata16.c: New file.
* gdb.dwarf2/formdata16.exp: New file.
* lib/dwarf.exp (Dwarf): Add DW_FORM_data16.
If GDB is running when gdb_skip_xml_tests is called with
--target_board=native-extended-gdbserer.exp, it fails with:
(gdb) FAIL: ....exp: set tdesc filename .../trivial.xml (got interactive prompt)
monitor exit
Diagnose this in gdb_skip_xml_tests to generate a more meaningful error message:
ERROR: tcl error sourcing ....exp.
ERROR: GDB must not be running in gdb_skip_xml_tests.
while executing
[...]
testsuite/
* lib/gdb.exp (gdb_skip_xml_tests): Error if GDB is running.
Exercising aarch64-elf with a custom debug stub i noticed a few failures in
both gdb.base/breakpoint-in-ro-region.exp and gdb.base/memattr.exp:
FAIL: gdb.base/breakpoint-in-ro-region.exp: create read-only mem region covering main
FAIL: gdb.base/breakpoint-in-ro-region.exp: writing to read-only memory fails
FAIL: gdb.base/breakpoint-in-ro-region.exp: inserting software breakpoint in read-only memory fails
FAIL: gdb.base/memattr.exp: create mem region 1
FAIL: gdb.base/memattr.exp: create mem region 2
FAIL: gdb.base/memattr.exp: create mem region 3
FAIL: gdb.base/memattr.exp: create mem region 4
FAIL: gdb.base/memattr.exp: create mem region 5
FAIL: gdb.base/memattr.exp: info mem (1)
FAIL: gdb.base/memattr.exp: mem1 cannot be read
FAIL: gdb.base/memattr.exp: mem2 cannot be written
FAIL: gdb.base/memattr.exp: mem2 can be read
FAIL: gdb.base/memattr.exp: disable mem 1
FAIL: gdb.base/memattr.exp: mem 1 was disabled
FAIL: gdb.base/memattr.exp: enable mem 1
FAIL: gdb.base/memattr.exp: mem 1 was enabled
FAIL: gdb.base/memattr.exp: disable mem 2 4
FAIL: gdb.base/memattr.exp: mem 2 and 4 were disabled
FAIL: gdb.base/memattr.exp: enable mem 2-4
FAIL: gdb.base/memattr.exp: mem 2-4 were enabled
FAIL: gdb.base/memattr.exp: mem 1 to 5 were disabled
FAIL: gdb.base/memattr.exp: mem 1 to 5 were enabled
FAIL: gdb.base/memattr.exp: delete mem 1
FAIL: gdb.base/memattr.exp: mem 1 was deleted
FAIL: gdb.base/memattr.exp: delete mem 2 4
FAIL: gdb.base/memattr.exp: mem 2 and 4 were deleted
FAIL: gdb.base/memattr.exp: mem 2-4 were deleted
These failures don't show up with gdbserver or native gdb on Linux because
they don't export any memory maps, therefore the vector of memory regions is
empty.
Outside of that scenario, we can't guarantee the absence of memory regions
reported by the target upon a connection. In our particular target, we
provide a memory map and the memory regions vector ceases to be empty.
With a non-empty memory regions vector, manipulating memory regions will cause
gdb to be more verbose and output text. For example:
memattr.c:require_user_regions
/* Otherwise, let the user know how to get back. */
if (from_tty)
warning (_("Switching to manual control of memory regions; use "
"\"mem auto\" to fetch regions from the target again."));
memattr.c:create_mem_region
if ((lo >= n->lo && (lo < n->hi || n->hi == 0))
|| (hi > n->lo && (hi <= n->hi || n->hi == 0))
|| (lo <= n->lo && ((hi >= n->hi && n->hi != 0) || hi == 0)))
{
printf_unfiltered (_("overlapping memory region\n"));
return;
}
In my particular case i got both of the above messages.
In order to fix this, i've moved the delete_memory proc from
gdb.base/memattr.exp to a new file lib/memory.exp and made lib/gdb.exp
load that file.
For both gdb.base/breakpoint-in-ro-region.exp and gdb.base/memattr.exp the
patch clears all existing memory regions after running to main. That way we
are guaranteed to have a clean state for memory regions so the tests can
exercise whatever they want and have an expected output pattern.
Regression checked on x86-64/Ubuntu 16.04.
gdb/testsuite/ChangeLog:
2017-01-26 Luis Machado <lgustavo@codesourcery.com>
* lib/memory.exp: New file.
* lib/gdb.exp: Load memory.exp.
* gdb.base/memattr.exp (delete_memory): Move proc to
lib/memory.exp and rename to delete_memory_regions.
Replace delete_memory with delete_memory_regions.
Cleanup memory regions before tests.
* gdb.base/breakpoint-in-ro-region.exp: Cleanup memory regions
before tests.
This patch adds a DW_OP_implicit_value in dwarf assembler, and uses
dwarf assembler in implptr-64bit.exp. Using dwarf assembler in
implptr-64bit.exp exposes some limitations in dwarf assembler,
- some variables are not evaluated in the caller's context, so we
can not pass variable to assembler, like this
Dwarf::assemble $asm_file {
cu {
version $dwarf_version
addr_size $addr_size
is_64 $is_64
} {
}
and
{DW_AT_type :$struct_label "DW_FORM_ref$ref_addr_size"}
this limitation is fixed by adding "uplevel" and "subst".
- dwarf assembler doesn't emit DW_FORM_ref_addr for label referencing.
this limitation is fixed by adding a new character "%",
{ type %$int_label }
this means we want to emit DW_FORM_ref_addr for label referencing.
- we can't set the form of label referencing offset in dwarf assembler.
Nowadays, dwarf assembler guesses the form of labels, which is
DW_FORM_ref4. However, in implptr-64bit.exp, both DW_FORM_ref4
and DW_FORM_ref8 is used (see REF_ADDR in implptr-64bit.S). This
patch adds the flexibility of setting the form of label reference.
Both of them below are valid,
{DW_AT_type :$struct_label}
{DW_AT_type :$struct_label DW_FORM_ref8}
the former form is the default DW_FORM_ref4.
I compared the .debug_info of objects without and with this patch
applied. There is no changes except abbrev numbers.
gdb/testsuite:
2017-01-25 Andreas Arnez <arnez@linux.vnet.ibm.com>
Yao Qi <yao.qi@linaro.org>
* gdb.dwarf2/implptr-64bit.exp: Use dwarf assembler.
* gdb.dwarf2/implptr-64bit.S: Remove.
* lib/dwarf.exp (Dwarf): Handle character "%". Evaluate some
variables in caller's context. Add DW_OP_implicit_value.
DW_OP_GNU_implicit_pointer refers to a DIE with an offset of different
sizes in different dwarf versions. In v2, the size is the pointer size,
while in v3 and above, it is the ref_addr size. This patch fixes
dwarf assembler to emit the correct size of offset. We've already fixed
this size issue in gdb,
https://sourceware.org/ml/gdb-patches/2011-09/msg00451.html
gdb/testsuite:
2017-01-25 Yao Qi <yao.qi@linaro.org>
* lib/dwarf.exp (Dwarf::_location): Handle
DW_OP_GNU_implicit_pointer with proper size.
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.
- Use multi_line for matching multi-line GDB output.
- Add a multi_line_input variant of multi_line to build GDB input and
use it throughout.
(The two changes above make the tests much more readable, IMO.)
- Add a new valnum_re global to get rid of the multiple "\\\$\[0-9\]*".
- Remove gdb_stop_suppressing_tests uses.
- tighten a few regexps.
- Replace send_gdb/gdb_expect with gdb_test_multiple and simplify,
making pass/fail messages the same.
gdb/ChangeLog:
2016-11-09 Pedro Alves <palves@redhat.com>
* gdb.base/commands.exp (runto_or_return): New procedure.
(gdbvar_simple_if_test, gdbvar_simple_while_test)
(gdbvar_complex_if_while_test, progvar_simple_if_test)
(progvar_simple_while_test, progvar_complex_if_while_test)
(if_while_breakpoint_command_test)
(infrun_breakpoint_command_test, breakpoint_command_test)
(user_defined_command_test, watchpoint_command_test)
(test_command_prompt_position, redefine_hook_test)
(stray_arg0_test, error_clears_commands_left, redefine_hook_test)
(redefine_backtrace_test): Use runto_or_return, $valnum_re,
multi_line_input and multi_line. Remove gdb_expect and
gdb_stop_suppressing_tests uses.
* lib/gdb.exp (valnum_re): New global.
* lib/gdb.exp (valnum_re): New global.
(multi_line_input): New procedure.
While adding new tests to gdb.base/commands.exp, I noticed that the
file includes a bunch of individual testcases split into their own
procedures, and that none have ever been adjusted to use
with_test_prefix. Instead, each gdb_test/gdb_test_multiple/etc
invocation takes care of including the procedure name in the test
message, in order to make sure test messages are unique.
Simon convinced me that using the procedure name as prefix is not that
bad of an idea:
https://sourceware.org/ml/gdb-patches/2016-10/msg00020.html
This commit adds an IMO simpler alternative to
with_test_prefix_procname added by that patch -- a new
"proc_with_prefix" convenience proc that is meant to be used in place
of "proc", and then uses it in commands.exp. Procedures defined with
this automatically run their bodies under with_test_prefix $proc_name.
Here's a sample of the resulting gdb.sum diff:
[...]
-PASS: gdb.base/commands.exp: break factorial #3
-PASS: gdb.base/commands.exp: set value to 5 in test_command_prompt_position
-PASS: gdb.base/commands.exp: if test in test_command_prompt_position
-PASS: gdb.base/commands.exp: > OK in test_command_prompt_position
+PASS: gdb.base/commands.exp: test_command_prompt_position: break factorial
+PASS: gdb.base/commands.exp: test_command_prompt_position: set value to 5
+PASS: gdb.base/commands.exp: test_command_prompt_position: if test
+PASS: gdb.base/commands.exp: test_command_prompt_position: > OK
[...]
gdb/testsuite/ChangeLog:
2016-11-09 Pedro Alves <palves@redhat.com>
* gdb.base/commands.exp (gdbvar_simple_if_test)
(gdbvar_simple_while_test, gdbvar_complex_if_while_test)
(progvar_simple_if_test, progvar_simple_while_test)
(progvar_complex_if_while_test, if_while_breakpoint_command_test)
(infrun_breakpoint_command_test, breakpoint_command_test)
(user_defined_command_test, watchpoint_command_test)
(test_command_prompt_position, deprecated_command_test)
(bp_deleted_in_command, temporary_breakpoint_commands)
(stray_arg0_test, source_file_with_indented_comment)
(recursive_source_test, if_commands_test)
(error_clears_commands_left, redefine_hook_test)
(redefine_backtrace_test): Use proc_with_prefix.
* lib/gdb.exp (proc_with_prefix): New proc.
If the target doesn't support float, we don't run float complex types
tests.
gdb/testsuite:
2016-10-05 Yao Qi <yao.qi@linaro.org>
* lib/gdb.exp (support_complex_tests): Return zero if
gdb_skip_float_test return true.
In commit 6423214f (testsuite: Don't use expect_background to reap
gdbserver), we override gdb_exit in lib/gdbserver-support.exp, so
that we can close gdbserver first. However, we don't close gdbserver
in mi_gdb_exit. This makes a problem in my aarch64 mulit-arch testing,
in which I run some mi tests, mi-watch.exp for example, in different
variations (aarch64 and arm),
Schedule of variations:
junor0-2
junor0-2-arm/-marm
junor0-2-arm/-mthumb
When the test is done in the first variation (aarch64), test case is
recompiled for arm, but GDBserver with aarch64 program is still
running. When the second variation is started, GDB loads arm program,
but GDBserver still loads aarch64 program because the old GDBserver
process is using it. We'll get,
47-target-select remote junor0-2:2350^M
&"warning: Selected architecture arm is not compatible with reported target architecture aarch64\n"^M
&"warning: Architecture rejected target-supplied description\n"
This patch fixes this problem by closing GDBserver in mi_gdb_exit.
gdb/testsuite:
2016-09-22 Yao Qi <yao.qi@linaro.org>
* lib/gdbserver-support.exp: Rename mi_gdb_exit.
(gdb_exit): Rename it to ...
(gdbserver_gdb_exit): ... Close GDBserver.
(gdb_exit): New proc, call gdbserver_gdb_exit.
(mi_gdb_exit): Likewise.
In lib/gdbserver-support.exp, we rename gdb_exit to
gdbserver_orig_gdb_exit, but we check the existence gdbserver_gdb_exit.
We should check gdbserver_orig_gdb_exit instead. Looks it is a typo
or an oversight.
gdb/testsuite:
2016-09-22 Yao Qi <yao.qi@linaro.org>
* lib/gdbserver-support.exp: Check the existence of
gdbserver_orig_gdb_exit rather than gdbserver_gdb_exit.
There were always various problems with compatibility with ccache:
https://bugzilla.redhat.com/show_bug.cgi?id=488863https://bugzilla.redhat.com/show_bug.cgi?id=759592https://sourceware.org/ml/gdb-patches/2009-02/msg00397.html
IMO in a summary ccache finds more a benefit of faster compilation despite the
debug info is no longer exactly the same (as without ccache).
Although for example in this case ccache helped to find a real GDB bug:
https://sourceware.org/ml/gdb-patches/2015-01/msg00497.html
For the GDB testcases ccache has (IMO) no real performance advantage and it
just brings heisenbugs - false FAILs - from time to time:
Breakpoint 1, main () at gdb/testsuite/gdb.base/vdso-warning.c:21^M
21 return 0;^M
(gdb) PASS: gdb.base/vdso-warning.exp: run: startup
->
Breakpoint 1, main () at gdb/testsuite/gdb.base/hbreak-unmapped.c:21^M
21 return 0;^M
(gdb) FAIL: gdb.base/vdso-warning.exp: run: startup
So I find most safe and easy to just disable ccache for all testsuites.
gdb/testsuite/ChangeLog
2016-09-15 Jan Kratochvil <jan.kratochvil@redhat.com>
* lib/future.exp: Set CCACHE_DISABLE, clear CCACHE_NODISABLE.
I noticed that if input is already pending on the new-ui TTY, gdb
internal-errors.
E.g., create /dev/pts/2, and type anything there (even just <return>
is sufficient).
Now start GDB creating a new UI on that TTY, while at the same time,
running a synchronous execution command. Something like:
$ gdb program -ex "new-ui console /dev/pts/2" -ex "start"
Back on /dev/pts/2, we get:
(gdb) .../src/gdb/event-top.c:360: internal-error: double prompt
A problem internal to GDB has been detected,
further debugging may prove unreliable.
While the main UI was waiting for "start" to finish, gdb kepts pumping
events, including the input fd of the extra console. The problem is
that stdin_event_handler doesn't restore the current UI back to what
it was, assuming that it's only ever called from the top level event
loop. However, in this case, it's being called from the nested event
loop from within maybe_wait_sync_command_done.
When finally the "start" command is done, we reach the code that
prints the prompt in the main UI, just before starting the main event
loop. Since now the current UI is pointing at the extra console (by
mistake), we find ourselves printing a double prompt on the extra
console. This is caught by the assertion that fails, as shown above.
Since other event handlers also don't restore the UI (e.g., signal
event handlers), I think it's better if whatever is pumping events to
take care to restore the UI, if it cares. That's what this patch
does. New test included.
gdb/ChangeLog:
2016-09-06 Pedro Alves <palves@redhat.com>
* top.c (wait_sync_command_done): Don't assume current_ui doesn't
change across events. Restore the current UI before returning.
(gdb_readline_wrapper): Restore the current UI before returning.
gdb/testsuite/ChangeLog:
2016-09-06 Pedro Alves <palves@redhat.com>
* gdb.base/new-ui-pending-input.c: New file.
* gdb.base/new-ui-pending-input.exp: New file.
* gdb.exp (clear_gdb_spawn_id): New procedure.
(with_spawn_id): Check whether gdb_spawn_id exists before
referencing it. If gdb_spawn_id didn't exist on entry, clear it
on exit.
We recently found a ARM kernel ptrace bug
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-May/431962.html
Details can be found in the comment in gdb_skip_float_test. We can
skip floating point tests if the kernel bug is detected.
This patch adds more code in gdb_skip_float_test to detect the broken
ptrace on arm-linux. Such detection should be done at the beginning
of the test, because it starts a fresh GDB, so change the test cases
to invoke gdb_skip_float_test at the beginning of test, and use its
return value afterwards.
Since gdb_skip_float_test becomes a gdb_caching_proc, so it can't
have an argument, this patch also removes argument "msg", which isn't
useful.
gdb/testsuite:
2016-09-02 Yao Qi <yao.qi@linaro.org>
* gdb.arch/arm-neon.exp: Skip it if gdb_skip_float_test returns
true.
* gdb.base/call-ar-st.exp: Invoke gdb_skip_float_test.
* gdb.base/call-rt-st.exp: Likewise.
* gdb.base/call-sc.exp: Invoke gdb_skip_float_test and use its
return value instead of gdb,skip_float_test.
* gdb.base/callfuncs.exp: Invoke gdb_skip_float_test.
(do_function_calls): Use its return value instead of
gdb,skip_float_test.
* gdb.base/finish.exp: Likewise.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/return.exp: Likewise.
* gdb.base/return2.exp: Likewise.
* gdb.base/varargs.exp: Likewise.
* lib/gdb.exp (gdb_skip_float_test): Change it to
gdb_caching_proc. Detect the broken ptrace on arm-linux.
When executing commands on a secondary UI running the MI interpreter,
some commands that should be synchronous are not. MI incorrectly
continues processing input right after the synchronous command is
sent, before the target stops.
The problem happens when we emit MI async events (=library-loaded,
etc.), and we go about restoring the previous terminal state, we end
up calling target_terminal_ours, which incorrectly always installs the
current UI's input_fd in the event loop... That is, code like this:
old_chain = make_cleanup_restore_target_terminal ();
target_terminal_ours_for_output ();
fprintf_unfiltered (mi->event_channel, "library-loaded");
...
do_cleanups (old_chain);
The fix is to move the add_file_handler/delete_file_handler calls out
of target_terminal_$foo, making these completely no-ops unless called
with the main UI as current UI.
gdb/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR gdb/20418
* event-top.c (ui_register_input_event_handler)
(ui_unregister_input_event_handler): New functions.
(async_enable_stdin): Register input in the event loop.
(async_disable_stdin): Unregister input from the event loop.
(gdb_setup_readline): Register input in the event loop.
* infrun.c (check_curr_ui_sync_execution_done): Register input in
the event loop.
* target.c (target_terminal_inferior): Don't unregister input from
the event loop.
(target_terminal_ours): Don't register input in the event loop.
* target.h (target_terminal_inferior)
(target_terminal_ours_for_output, target_terminal_ours): Update
comments.
* top.h (ui_register_input_event_handler)
(ui_unregister_input_event_handler): New declarations.
* utils.c (ui_unregister_input_event_handler_cleanup)
(prepare_to_handle_input): New functions.
(defaulted_query, prompt_for_continue): Use
prepare_to_handle_input.
gdb/testsuite/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@ericsson.com>
PR gdb/20418
* gdb.mi/new-ui-mi-sync.c, gdb.mi/new-ui-mi-sync.exp: New files.
* lib/mi-support.exp (mi_expect_interrupt): Remove anchors.
I recently see some gdb.server/*.exp fails in my native gdb testing,
in which libexpat isn't available, so GDB isn't able to parse xml file.
It causes gdb.server/ tests fails because GDB can't get registers
correctly from GDBserver.
(gdb) PASS: gdb.server/connect-without-multi-process.exp: multiprocess=off: break main
target remote localhost:2352^M
Remote debugging using localhost:2352^M
warning: Can not parse XML target description; XML support was disabled at compile time^M
Reading /lib/ld-linux-armhf.so.3 from remote target...^M
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.^M
Reading /lib/ld-linux-armhf.so.3 from remote target...^M
Reading symbols from target:/lib/ld-linux-armhf.so.3...Reading /lib/ld-2.17.so.debug from remote target...^M
Reading /lib/.debug/ld-2.17.so.debug from remote target...^M
(no debugging symbols found)...done.^M
Remote 'g' packet reply is too long: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000efffbe00000000808d0f4d100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000^
0x4d0f8d80 in _start () from target:/lib/ld-linux-armhf.so.3^M
Without XML support in GDB, it can't parse xml sent by GDBserver, and has
to fall back to the oldest arch. However, GDBserver doesn't know this
(IMO, this is a defect in RSP), and still choose the right target
description to create regcache and 'g' packet. If the port only has
one target description or coincidentally two sides choose the same
target description, there is no such issue. Otherwise, GDB is broken
on read registers.
This patch is to skip gdbserver tests if XML is not support and the
target has multiple target descriptions.
gdb/testsuite:
2016-07-21 Yao Qi <yao.qi@linaro.org>
* lib/gdbserver-support.exp (skip_gdbserver_tests): Return 1
if gdb_skip_xml_test is true on some targets.
In gdb.gdb/observer.exp, I see the following fail,
(gdb) break captured_main^M
Breakpoint 1 at 0x57e409: file ../../binutils-gdb/gdb/main.c, line 492.^M
(gdb) PASS: gdb.gdb/observer.exp: breakpoint in captured_main
run -nw -nx -data-directory /home/yao.qi/SourceCode/gnu/build/gdb/testsuite/../data-directory^M
Starting program: /home/yao.qi/SourceCode/gnu/build/gdb/testsuite/outputs/gdb.gdb/observer/xgdb -nw -nx -data-directory /home/yao.qi/SourceCode/gnu/build/gdb/testsuite/../data-directory^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".^M
^M
Breakpoint 1, gdb_main (args=args@entry=0x7fffffffdca0) at ../../binutils-gdb/gdb/main.c:1157^M
1157 captured_main (args);^M
(gdb) FAIL: gdb.gdb/observer.exp: run until breakpoint at captured_main
looks the test sets breakpoint on captured_main, and expects program
stops at captured_main. However, program stops at the place where
captured_main is called, because captured_main is inlined,
<1><8519e3>: Abbrev Number: 58 (DW_TAG_subprogram)
<8519e4> DW_AT_name : (indirect string, offset: 0x880d3): captured_main
<8519e8> DW_AT_decl_file : 1
<8519e9> DW_AT_decl_line : 444
<8519eb> DW_AT_type : <0x846e48>
<8519ef> DW_AT_inline : 1 (inlined)
<8519f0> DW_AT_sibling : <0x851c01>
The test passes if I build GDB with '-O0 -g3', because captured_main
isn't inlined. This patch is to match the output when captured_main
is inlined.
gdb/testsuite:
2016-07-12 Yao Qi <yao.qi@linaro.org>
* lib/selftest-support.exp (selftest_setup): Match the output
when captured_main is inlined.
The output of Ada tests create a layout where the test name
("formatted_ref" in this example) appears twice:
outputs
└── gdb.ada
└── formatted_ref
└── formatted_ref
├── b~formatted_ref.adb
├── b~formatted_ref.ads
├── b~formatted_ref.ali
├── b~formatted_ref.o
├── defs.ali
├── defs.o
├── formatted_ref
├── formatted_ref.ali
└── formatted_ref.o
This causes a problem when testing with the native-gdbserver board, when
the binary has the same name as the test. When gdb_remote_download is
called to upload the compiled binary, the implementation for
native-gdbserver copies it in the standard output directory (in
outputs/gdb.ada/formatted_ref). However, there is already a directory
named formatted_ref in there, so the copy fails and gdbserver isn't able
to load the binary.
This patch bypasses the problem by removing the extra directory level.
The compiled binary will already be in its final location in the
standard output directory, so the copy will effectively be a no-op.
gdb/testsuite/ChangeLog:
* lib/ada.exp: Remove extra directory level in build directory.
* gdb.ada/cond_lang.exp: Likewise.
* gdb.ada/exec_changed.exp: Likewise.
* gdb.ada/lang_switch.exp: Likewise.
The jit-reader.exp test isn't really exercising the jit-reader's
unwinder API at all. This commit address that, and then fixes GDB
problems exposed.
- The custom JIT reader provided for the jit-reader.exp testcase
always rejects the jitted function's frame...
This is because the custom JIT reader in the testcase never ever
sets state->code_begin/end, so the bounds check in
gdb.base/jitreader.c:unwind_frame:
if (this_ip >= state->code_end || this_ip < state->code_begin)
return GDB_FAIL;
tends to fail, unless you're "lucky" (because it references
uninitialized data).
The result is that GDB is always actually using a built-in unwinder
for the jitted function.
- The provided unwinder doesn't do anything that GDB's built-in
unwinder can't do.
IOW, we can't really tell whether the JIT reader's unwinder is
working or not.
I fixed that by making the jitted function mangle its own stack
pointer with a xor, and then teaching the jit unwinder to demangle
it back (another xor). So now "backtrace" with GDB's built-in
unwinder fails while with the jit unwinder, it succeeds.
- GDB crashes after unloading the JIT reader, and flushing frames...
I made the testcase use the "flushregs" command after unloading the
JIT reader, to force the JIT frames to be flushed. However, that
crashes GDB...
When reinit_frame_cache tears down a frame's cache, it calls its
unwinder's dealloc_cache method, which for JIT frames ends up in
jit.c:jit_dealloc_cache. This function calls each of the frame's
gdb_reg_value's "free" pointer:
for (i = 0; i < gdbarch_num_regs (frame_arch); i++)
if (priv_data->registers[i] && priv_data->registers[i]->free)
priv_data->registers[i]->free (priv_data->registers[i]);
and the problem is these gdb_reg_value instances have been returned
by the JIT reader that has been already unloaded, and their "free"
function pointers likely point to functions in the DSO that has
already been unloaded...
A fix for that could be to call reinit_frame_cache in
jit_reader_unload_command _before_ unloading the jit reader DSO so
that the jit reader is given a chance to clean up the gdb_reg_values
before it is unloaded. However, the fix for the point below makes
this unnecessary, because it stops jit.c from keeping around
gdb_reg_values in the first place.
- However, it still makes sense to clear the frame cache when loading
or unloading a JIT unwinder.
This makes testing a JIT unwinder a bit simpler.
- Not only the frame cache actually -- gdb is not unloading the
jit-registered objfiles when the JIT reader is unloaded, and not
loading the already-registered descriptors when a JIT reader is
loaded.
The new test exercises unloading the jit reader, loading it back
again, and then making sure the JIT reader's unwinder works again.
Without the unload/re-load of already-read descriptors, the newly
loaded JIT would have no idea where the new function is, because
it's stored at symbol read time.
- I added a couple "info frame" calls to the test, and that
crashes GDB...
The problem is that jit_frame_prev_register assumes it'll only be
called for raw registers, so when it gets a pseudo register number,
the "priv->registers[reg]" access is really an out-of-bounds access.
To fix that, I made jit_frame_prev_register use
gdbarch_pseudo_register_read_value for reading the pseudo-registers.
However, that works with a regcache and we don't have one. To fix
that, I made the JIT unwinder store a regcache in its cache instead
of an array of gdb_reg_value pointers.
gdb/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
Tom Tromey <tom@tromey.com>
* jit.c (jit_reader_load_command): Call reinit_frame_cache and
jit_inferior_created_hook.
(jit_reader_unload_command): Call reinit_frame_cache and
jit_inferior_exit_hook.
* jit.c (struct jit_unwind_private) <registers>: Delete field.
<regcache>: New field.
(jit_unwind_reg_set_impl): Set the register's value in the
regcache. Free the passed-in gdb_reg_value.
(jit_dealloc_cache): Adjust to free the regcache.
(jit_frame_sniffer): Allocate a regcache instead of an array of
gdb_reg_value pointers.
(jit_frame_this_id): Adjust.
(jit_frame_prev_register): Read raw registers off of the regcache
instead of from the gdb_reg_value pointer array. Use
gdbarch_pseudo_register_read_value to read pseudo registers.
* regcache.c (regcache_raw_set_cached_value): New function,
factored out from ...
(regcache_raw_write): ... here.
* regcache.h (regcache_raw_set_cached_value): Declare.
gdb/testsuite/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
* gdb.base/jit-reader.exp (info_registers_current_frame): New
procedure.
(jit_reader_test): Test the jit reader's unwinder.
* gdb.base/jithost.c (jit_function_00_code): New global.
(main): Use memcpy to fill in the mmapped code, instead of poking
bytes manually here.
* gdb.base/jitreader.c (enum register_mapping) <AMD64_RBP>: New
value.
(read_debug_info): Save the function's range.
(read_sp): New function.
(unwind_frame): Use it. Also unwind RBP.
(get_frame_id): Use read_sp.
(gdb_init_reader): Use calloc instead of malloc.
* lib/gdb.exp (get_hexadecimal_valueof): Add optional 'test'
parameter. Use gdb_test_multiple.
Commit 51f77c3704 ("Add testing infrastruture bits for running with
MI on a separate UI") broke MI testing with native-gdbserver:
$ make check RUNTESTFLAGS="--target_board=native-gdbserver mi-var-child.exp"
...
Running .../src/binutils-gdb/gdb/testsuite/gdb.mi/mi-var-child.exp ...
can't unset "inferior_spawn_id": no such variable
while executing
"unset inferior_spawn_id"
(procedure "close_gdbserver" line 20)
invoked from within
"close_gdbserver"
...
When testing with gdbserver, gdb_exit is overridden with a special
version that calls close_gdbserver, which clears inferior_spawn_id.
The problem is that the commit mentioned above made
gdb_exit/mi_gdb_exit clear inferior_spawn_id too, and clearing a
non-existing variable is a tcl error.
Since gdb_exit/mi_gdb_exit always clears inferior_spawn_id now, the
fix is simply to stop clearing it in close_gdbserver.
gdb/testsuite/
2016-06-30 Pedro Alves <palves@redhat.com>
* lib/gdbserver-support.exp (close_gdbserver, gdb_exit): Don't
unset inferior_spawn_id.
Runing the whole gdb testsuite with MI on a separate tty, with:
make check RUNTESTFLAGS="FORCE_SEPARATE_MI_TTY=1"
Doesn't actually work because commit 51f77c3704 ("Add testing
infrastruture bits for running with MI on a separate UI") included a
last-minute rename typo, now fixed with this commit.
gdb/testsuite/ChangeLog:
2016-06-30 Pedro Alves <palves@redhat.com>
* lib/mi-support.exp (default_mi_gdb_start): Declare global
FORCE_SEPARATE_MI_TTY, not SEPARATE_MI_TTY.
This adds a test that uses new-ui to create a secondary console, and
then runs some basic smoke tests. It ensures that:
- synchronous commands send output to the UI that initiated it
- asynchronous events like breakpoint hits are reported on all
consoles.
- "new-ui" without arguments doesn't crash.
- The "new-ui" command doesn't repeat.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.base/new-ui.exp: New file.
* lib/mi-support.exp (switch_gdb_spawn_id): Move to ...
* lib/gdb.exp (switch_gdb_spawn_id): ... here.
(with_spawn_id): New procedure.
With this, a specific test may can start GDB with MI on a separate UI
by using:
mi_gdb_start separate-mi-tty
In addition, it's also possible to run the whole testsuite with MI on
a separate tty, with:
make check RUNTESTFLAGS="FORCE_SEPARATE_MI_TTY=1"
gdb_main_spawn_id and mi_spawn_id are added so that tests may expect
output from either channel.
While at it, inferior_spawn_id was not being cleared when gdb exits,
unlike the other spawn ids, thus a test that starts gdb more than once
would end up using a stale spawn id.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* README (Testsuite Parameters): Document FORCE_SEPARATE_MI_TTY.
* lib/gdb.exp (default_gdb_exit): Clear inferior_spawn_id.
* lib/mi-support.exp (mi_uncatched_gdb_exit): Unset
gdb_main_spawn_id, mi_spawn_id, unset inferior_spawn_id.
(gdb_main_spawn_id, mi_spawn_id): Declare and
comment.
(mi_create_inferior_pty): New procedure,
factored out from default_mi_gdb_start.
(switch_gdb_spawn_id, mi_gdb_start_separate_mi_tty): New
procedures.
(default_mi_gdb_start): Call mi_gdb_start_separate_mi_tty if the
separate-mi-tty option is specified, or SEPARATE_MI_TTY is set.
Use mi_create_inferior_pty.
(mi_gdb_start): Use eval to pass down args list.
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.
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 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.
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.
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 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.
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.
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.
Kevin Buettner
Andreas Arnez
Pedro Alves
Marc-Andre Laperle
Anton Kolesov
Simon Marchi
Jan Kratochvil
Markus Metzger
Luis Machado
Yao Qi
Joel Brobecker
Tom Tromey
Jon Beniston
Doug Evans
Bernhard Heckel