The dwarf attribute DW_AT_count specifies the elements of a subrange.
This test covers subranges with present count but absent upper bound
attribute, both with static and dynamic attribute values.
testsuite/ChangeLog:
* gdb.dwarf2/count.exp: New file.
The c99 standard in "6.5.3.4 The sizeof operator" states:
If the type of the operand is a variable length array type, the operand
is evaluated;[...]
This patch mirrors the following c99 semantic in gdb:
1| int vla[n][m];
2| int i = 1;
3| sizeof(vla[i++][0]); // No sideffect
4| assert (i == 1);
5| sizeof(vla[i++]); // With sideffect
6| assert (i == 2);
Note: ptype/whatis still do not allow any sideeffects.
This patch was motivated by:
https://sourceware.org/ml/gdb-patches/2014-01/msg00732.html
gdb/ChangeLog:
* eval.c (evaluate_subexp_for_sizeof): Add enum noside argument.
(evaluate_subexp_standard): Pass noside argument.
(evaluate_subexp_for_sizeof) <BINOP_SUBSCRIPT>: Handle subscript case
if noside equals EVAL_NORMAL. If the subscript yields a vla type
re-evaluate subscript operation with EVAL_NORMAL to enable sideffects.
* gdbtypes.c (resolve_dynamic_bounds): Mark bound as evaluated.
* gdbtypes.h (enum range_flags): Add RANGE_EVALUATED case.
testsuite/ChangeLog:
* gdb.base/vla-sideeffect.c: New file.
* gdb.base/vla-sideeffect.exp: New file.
Clang defaults this warning to an error, breaking the build & causing
these tests not to run.
gdb/testsuite/
* gdb.mi/non-stop.c: Add return value for non-void function return
statement.
* gdb.threads/staticthreads.c: Ditto.
* guile/scm-value.c (gdbscm_value_dynamic_type): Use coerce_ref to
dereference TYPE_CODE_REF values.
testsuite/
* gdb.guile/scm-value.c: Improve test case.
* gdb.guile/scm-value.exp: Add new test.
This reverts the following patch series, as they cause some regresssions.
commit 37c1ab67a3
type: add c99 variable length array support
gdb/
* dwarf2loc.c (dwarf2_locexpr_baton_eval): New function.
(dwarf2_evaluate_property): New function.
* dwarf2loc.h (dwarf2_evaluate_property): New function prototype.
* dwarf2read.c (attr_to_dynamic_prop): New function.
(read_subrange_type): Use attr_to_dynamic_prop to read high bound
attribute.
* gdbtypes.c: Include dwarf2loc.h.
(is_dynamic_type): New function.
(resolve_dynamic_type): New function.
(resolve_dynamic_bounds): New function.
(get_type_length): New function.
(check_typedef): Use get_type_length to compute type length.
* gdbtypes.h (TYPE_HIGH_BOUND_KIND): New macro.
(TYPE_LOW_BOUND_KIND): New macro.
(is_dynamic_type): New function prototype.
* value.c (value_from_contents_and_address): Call resolve_dynamic_type
to resolve dynamic properties of the type. Update comment.
* valops.c (get_value_at, value_at, value_at_lazy): Update comment.
commit 26cb189f8b
vla: enable sizeof operator to work with variable length arrays
gdb/
* eval.c (evaluate_subexp_for_sizeof) <OP_VAR_VALUE>: If the type
passed to sizeof is dynamic evaluate the argument to compute the length.
commit 04b19544ef
vla: enable sizeof operator for indirection
gdb/
* eval.c (evaluate_subexp_for_sizeof) <UNOP_IND>: Create an indirect
value and retrieve the dynamic type size.
commit bcd629a44f
vla: update type from newly created value
gdb/
* ada-lang.c (ada_value_primitive_packed_val): Re-fetch type from value.
(ada_template_to_fixed_record_type_1): Likewise.
(ada_to_fixed_type_1): Likewise.
* cp-valprint.c (cp_print_value_fields_rtti): Likewise.
(cp_print_value): Likewise.
* d-valprint.c (dynamic_array_type): Likewise.
* eval.c (evaluate_subexp_with_coercion): Likewise.
* findvar.c (address_of_variable): Likewise.
* jv-valprint.c (java_value_print): Likewise.
* valops.c (value_ind): Likewise.
* value.c (coerce_ref): Likewise.
commit b86138fb04
vla: print "variable length" for unresolved dynamic bounds
gdb/
* c-typeprint.c (c_type_print_varspec_suffix): Added
check for not yet resolved high bound. If unresolved, print
"variable length" string to the console instead of random
length.
commit e1969afbd4
vla: support for DW_AT_count
gdb/
* dwarf2read.c (read_subrange_type): Convert DW_AT_count to a dynamic
property and store it as the high bound and flag the range accordingly.
* gdbtypes.c (resolve_dynamic_bounds): If range is flagged as
RANGE_UPPER_BOUND_IS_COUNT assign low + high - 1 as the new high bound.
* gdbtypes.h (enum range_flags): New enum.
(struct range_bounds): Add flags member.
commit 92b09522dc
vla: resolve dynamic bounds if value contents is a constant byte-sequence
gdb/
* findvar.c (default_read_var_value): Resolve dynamic bounds if location
points to a constant blob.
commit 3bce82377f
vla: evaluate operand of sizeof if its type is a vla
gdb/
* eval.c (evaluate_subexp_for_sizeof): Add enum noside argument.
(evaluate_subexp_standard): Pass noside argument.
(evaluate_subexp_for_sizeof) <BINOP_SUBSCRIPT>: Handle subscript case
if noside equals EVAL_NORMAL. If the subscript yields a vla type
re-evaluate subscript operation with EVAL_NORMAL to enable sideffects.
* gdbtypes.c (resolve_dynamic_bounds): Mark bound as evaluated.
* gdbtypes.h (enum range_flags): Add RANGE_EVALUATED case.
gdb/testsuite
* gdb.base/vla-sideeffect.c: New file.
* gdb.base/vla-sideeffect.exp: New file.
commit 504f34326e
test: cover subranges with present DW_AT_count attribute
gdb/testsuite/
* gdb.dwarf2/count.exp: New file.
commit 1a237e0ee5
test: multi-dimensional c99 vla.
gdb/testsuite/
* gdb.base/vla-multi.c: New file.
* gdb.base/vla-multi.exp: New file.
commit 024e13b46f
test: evaluate pointers to C99 vla correctly.
gdb/testsuite/
* gdb.base/vla-ptr.c: New file.
* gdb.base/vla-ptr.exp: New file.
commit c8655f75e2
test: basic c99 vla tests for C primitives
gdb/testsuite/
* gdb.base/vla-datatypes.c: New file.
* gdb.base/vla-datatypes.exp: New file.
commit 58a84dcf29
test: add mi vla test
gdb/testsuite/
* gdb.mi/mi-vla-c99.exp: New file.
* gdb.mi/vla.c: New file.
The dwarf attribute DW_AT_count specifies the elements of a subrange.
This test covers subranges with present count but absent upper bound
attribute, both with static and dynamic attribute values.
testsuite:
* gdb.dwarf2/count.exp: New file.
The c99 standard in "6.5.3.4 The sizeof operator" states:
If the type of the operand is a variable length array type, the operand
is evaluated;[...]
This patch mirrors the following c99 semantic in gdb:
1| int vla[n][m];
2| int i = 1;
3| sizeof(vla[i++][0]); // No sideffect
4| assert (i == 1);
5| sizeof(vla[i++]); // With sideffect
6| assert (i == 2);
Note: ptype/whatsis still do not allow any sideeffects.
This patch was motivated by:
https://sourceware.org/ml/gdb-patches/2014-01/msg00732.html
* eval.c (evaluate_subexp_for_sizeof): Add enum noside argument.
(evaluate_subexp_standard): Pass noside argument.
(evaluate_subexp_for_sizeof) <BINOP_SUBSCRIPT>: Handle subscript case
if noside equals EVAL_NORMAL. If the subscript yields a vla type
re-evaluate subscript operation with EVAL_NORMAL to enable sideffects.
* gdbtypes.c (resolve_dynamic_bounds): Mark bound as evaluated.
* gdbtypes.h (enum range_flags): Add RANGE_EVALUATED case.
testsuite/gdb.base/
* vla-sideeffect.c: New file.
* vla-sideeffect.exp: New file.
Doug told me that there are some regressions in gdb.base/completion.exp.
They are caused by my recent change, and can be reproduced via:
$ make check-parallel TESTS=gdb.base/completion.exp
FAIL: gdb.base/completion.exp: complete target core ./gdb.base/completion
FAIL: gdb.base/completion.exp: complete target tfile ./gdb.base/completion
FAIL: gdb.base/completion.exp: complete target exec ./gdb.base/completion
Current tests assume that gdb.base/completion exists but that is wrong
in a parallel run, because binary file and object files are placed
in outputs/gdb.base/completion/.
This patch is to check file exists on two candidate directories,
"gdb.base" and "outputs/gdb.base/completion/", and run tests with files
existed in either of them.
gdb/testsuite:
2014-04-11 Yao Qi <yao@codesourcery.com>
* gdb.base/completion.exp: Check file exists before running tests
on file completion.
While trying to fix hbreak2.exp against GDBserver I noticed this...
(gdb) hbreak main if 1
Sending packet: $m400580,40#2e...Packet received: e8d2ffffff5dc3554889e54883ec10c745fc00000000eb0eb800000000e8c1ffffff8345fc01817dfce70300007ee9b800000000c9c3662e0f1f840000000000
Sending packet: $m40058f,1#31...Packet received: c7
Hardware assisted breakpoint 1 at 0x40058f: file ../../../src/gdb/testsuite/gdb.base/break-idempotent.c, line 46.
Sending packet: $Z1,40058f,1;X3,220127#9b...
*hangs forever*
The issue is that nothing advances the packet pointer if
add_breakpoint_condition either fails to parse the agent expression,
or fails to find the breakpoint, resulting in an infinite loop in
process_point_options. The latter case should really be fixed by
GDBserver tracking GDB Z1 breakpoints in its breakpoint structures
like Z0 breakpoints are, but the latter case still needs handling.
add_breakpoint_commands has the same issue, though at present I don't
know any way to trigger it other than sending a manually cooked
packet.
Unbelievably, it doesn't look like we have any test that tries setting
a conditional hardware breakpoint. Looking at cond-eval-mode.exp, it
looks like the file was meant to actually test something, but it's
mostly empty today. This patch adds tests that tries all sorts of
conditional breakpoints and watchpoints. The test hangs/fails without
the GDBserver fix.
Tested on x86_64 Fedora 17.
gdb/gdbserver/
2014-04-10 Pedro Alves <palves@redhat.com>
* mem-break.c (add_breakpoint_condition, add_breakpoint_commands):
Check if the condition or command is NULL before checking if the
breakpoint is known. On success, return true.
* mem-break.h (add_breakpoint_condition): Document return.
(add_breakpoint_commands): Add describing comment.
* server.c (skip_to_semicolon): New function.
(process_point_options): Use it.
gdb/testsuite/
2014-04-10 Pedro Alves <palves@redhat.com>
* gdb.base/cond-eval-mode.c: New file.
* gdb.base/cond-eval-mode.exp: Use standard_testfile. Adjust
prepare_for_testing to build the new file. Check result of
runto_main.
(test_break, test_watch): New procedures.
(top level): Use them.
On mingw host, we have seen two fails as below,
p int1dim[0]^V@2
Invalid character '^V' in expression.
(gdb) FAIL: gdb.base/printcmds.exp: p int1dim[0]@2
p int1dim[0]^V@2^V@3
Invalid character '^V' in expression.
(gdb) FAIL: gdb.base/printcmds.exp: p int1dim[0]@2@3
In the test, the comment says "# Send \026@ instead of just @ in case
the kill character is @". Historically, kill character was @, and
Ctrl-V (\026) is to escape the next character. However, we don't have
to do so on mingw. This patch is to disable ctrl-v usage on mingw
hots. With this patch applied, it becomes:
p int1dim[0]@2
$607 = {0, 1}
(gdb) PASS: gdb.base/printcmds.exp: p int1dim[0]@2
p int1dim[0]@2@3
$608 = {{0, 1}, {2, 3}, {4, 5}}
Note that this patch is picked from Pierre's submission,
[RFC 6/6] Fix remaining failures in gdb.base/printcmds.exp for mingw hosts.
https://www.sourceware.org/ml/gdb-patches/2013-09/msg00943.html
gdb/testsuite:
2014-04-08 Pierre Muller <muller@sourceware.org>
* gdb.base/printcmds.exp (test_artificial_arrays): Disable
Ctrl-V use for mingw hosts.
gdb.Value.dynamic_type is supposed to work for reference and pointer
values. However, the value object in the function 'valpy_get_dynamic_type'
was being dereferenced using 'value_ind' irrespective of the value type
being TYPE_CODE_PTR or TYPE_CODE_REF. This patch fixes that to use
'coerce_ref' for TYPE_CODE_REF values.
ChangeLog:
* python/py-value.c (valpy_get_dynamic_type): Use coerce_ref to
dereference TYPE_CODE_REF values.
testsuite/
* gdb.python/py-value.c: Improve test case.
* gdb.python/py-value.exp: Add new test.
Hi,
On windows host, we see the following ERROR,
(gdb) PASS: gdb.base/setshow.exp: set history filename ~/foobar.baz
ERROR OCCURED: couldn't compile regular expression pattern: invalid escape \ seq
uence
while executing
"expect -nobrace -i exp13 -timeout 10 -re {.*A problem internal to GDB has been
detected} {
fail "$message (GDB internal error)"
gdb_internal..."
invoked from within
"expect {
-i exp13 -timeout 10
-re ".*A problem internal to GDB has been detected" {
fail "$message (GDB internal error)"
gdb_internal_erro..."
("uplevel" body line 1)
invoked from within
"uplevel $body" REGEXP REG_EESCAPE {invalid escape \ sequence} couldn't compile
regular expression pattern: invalid escape \ sequenceERROR: Process no longer ex
ists
which leads to
UNRESOLVED: gdb.base/setshow.exp: show history filename (~/foobar.baz)
and this error is thrown from this test below:
gdb_test "show history filename" \
"The filename in which to record the command history is \"$HOME/foobar.baz\"..*" \
"show history filename (~/foobar.baz)"
HOME is a windows path, like C:\foo\bar. When it is used in gdb_test to match
output, the error is thrown because backslash is a special character in
regular expression. This patch is to escape backslash to fix this
error by using string_to_regexp.
gdb/testsuite:
2014-04-03 Yao Qi <yao@codesourcery.com>
* gdb.base/setshow.exp: Invoke string_to_regexp to HOME and PWD.
The current ppc64 single step over atomic sequence testcase is written
in C and breaks with some versions of gcc. Convert the test to
assembly and use stepi to step through it.
gdb/testsuite/
2014-04-01 Anton Blanchard <anton@samba.org>
* gdb.arch/ppc64-atomic-inst.c: Remove.
* gdb.arch/ppc64-atomic-inst.S: New file.
* gdb.arch/ppc64-atomic-inst.exp: Adapt for asm based testcase.
* NEWS: Mention it.
* solib.c (solib_read_symbols): Only print symbol loading messages
if requested.
(solib_add): If symbol loading is in "brief" mode, notify user
symbols are being loaded.
(reload_shared_libraries_1): Ditto.
* symfile.c (print_symbol_loading_off): New static global.
(print_symbol_loading_brief): New static global.
(print_symbol_loading_full): New static global.
(print_symbol_loading_enums): New static global.
(print_symbol_loading): New static global.
(print_symbol_loading_p): New function.
(symbol_file_add_with_addrs): Only print symbol loading messages
if requested.
(_initialize_symfile): Register "print symbol-loading" set/show
command.
* symfile.h (print_symbol_loading_p): Declare.
doc/
* gdb.texinfo (Symbols): Document set/show print symbol-loading.
testsuite/
* gdb.base/print-symbol-loading-lib.c: New file.
* gdb.base/print-symbol-loading-main.c: New file.
* gdb.base/print-symbol-loading.exp: New file.
Hi,
I find two fails in source-dir.exp on mingw32 host.
(gdb) directory /nOtExStInG/a /nOtExStInG/b /nOtExStInG/c^M
Warning: /nOtExStInG/a: No such file or directory.^M
Warning: /nOtExStInG/b: No such file or directory.^M
Warning: /nOtExStInG/c: No such file or directory.^M
Source directories searched: /nOtExStInG/a;/nOtExStInG/b;/nOtExStInG/c;$cdir;$cwd^M
(gdb) FAIL: gdb.base/source-dir.exp: directory /nOtExStInG/a /nOtExStInG/b /nOtExStInG/c
directory /nOtExStInG/b /nOtExStInG/d /nOtExStInG/c^M
Warning: /nOtExStInG/b: No such file or directory.^M
Warning: /nOtExStInG/d: No such file or directory.^M
Warning: /nOtExStInG/c: No such file or directory.^M
Source directories searched: /nOtExStInG/b;/nOtExStInG/d;/nOtExStInG/c;/nOtExStInG/a;$cdir;$cwd^M
(gdb) FAIL: gdb.base/source-dir.exp: directory /nOtExStInG/b /nOtExStInG/d /nOtExStInG/c
The regular expression expects ':' and ';' is path separator on Windows.
This patch is to allow ';' as a path separator in regular expression.
This patch is similar to Dan's patch to fix a similar problem here
Re: directory separators on minGW hosts
https://sourceware.org/ml/gdb-patches/2006-02/msg00359.html
It is obvious. Pushed it in.
gdb/testsuite:
2014-03-31 Yao Qi <yao@codesourcery.com>
* gdb.base/source-dir.exp: Allow ';' as a directory separator.
Given the following variable...
BT : Bounded := New_Bounded (Low => 1, High => 3);
... where type Bounded is defined as a simple unconstrained array:
type Bounded is array (Integer range <>) of Integer;
Creating a varobj for that variable, and immediately asking for
varobj updates, GDB says that our varobj changed types!
(gdb)
-var-create bt * bt
^done,name="bt",numchild="3",value="[3]",type="<ref> array (1 .. 3) of integer",has_more="0"
(gdb)
-var-update 1 *
^done,changelist=[{name="bt",value="[3]",in_scope="true",type_changed="true",new_type="<ref> array (1 .. 3) of integer",new_num_children="3",has_more="0"}]
The expected output for the -var-update command is, in this case:
(gdb)
-var-update 1 *
^done,changelist=[]
The problem occurs because the ada-varobj module does not handle
references, and while the references gets stripped when the varobj
gets created, it doesn't when computing varobj updates.
More specifically, when creating the varobj, varobj_create creates
a new value which is a reference to a TYPE_CODE_ARRAY. It then calls
install_new_value which calls coerce_ref with the following comment:
/* We are not interested in the address of references, and given
that in C++ a reference is not rebindable, it cannot
meaningfully change. So, get hold of the real value. */
if (value)
value = coerce_ref (value);
This leaves the varobj's type component still a ref, while
the varobj's value is now our array, without the ref. This explains
why the "value" field in the varobj indicates an array with 3 elements
"[3]" while the "type" field shows a ref to an array. Generally
speaking, most users have said that showing the ref was a useful
piece of information, so this patch is not touching this part.
Next, when the user issues the -var-update request, varobj_update
calls value_of_root to compute the varobj's new value as well as
determine whether the value's type has changed or not. What happens
in a nutshell is that it calls value_of_root_1 (which re-evaluates
the expression and returns the corresponding new value), finds that
the new value is not NULL, and thus asks whether it has mutated:
else if (varobj_value_has_mutated (var, value, value_type (value)))
This then indirectly delegates the determination to the language-specific
callback, which fails, because it does not handle references.
This patch fixes the issue by adjusting varobj_value_has_mutated to
expect references, and strip them when seen. This allows the various
language-specific implementations to remain unaware of references.
gdb/ChangeLog:
* varobj.c (varobj_value_has_mutated): If NEW_VALUE is
a reference, strip the reference layer before calling
the lang_ops value_has_mutated callback.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_dyn_arr: New testcase.
nios2 uses software single step, so GDB is unable to single step to
the signal handler. In order to reflect this, teach
can_single_step_to_signal_handler to return zero for nios2 target.
gdb/testsuite:
2014-03-27 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (can_single_step_to_signal_handler): Return zero
if target is nios2-*-*.
The completion feature and other features on readline depend on the
readline library. However, readline library is not always used, for
example, running testsuite like
make check RUNTESTFLAGS="--host_board=local-remote-host"
the input stream is not a tty, and GDB doesn't use readline library
as a result.
This patch is to skip tests on completion and readline if
'show editing' is off, which means readline isn't used. Note that
some tests in gdb.base/completion.exp test command complete, which
isn't related to readline, so these tests aren't affected by readline
library. This patch also moves these tests up, run them
unconditionally, and run the rest if readline library is used.
gdb/testsuite:
2014-03-26 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (readline_is_used): New proc.
* gdb.base/completion.exp: Move tests on command complete up.
Skip the rest of tests if readline is not used.
* gdb.ada/complete.exp: Skp the test if readline is not
used.
* gdb.base/filesym.exp: Likewise.
* gdb.base/macscp.exp: Likewise.
* gdb.base/readline-ask.exp: Likewise.
* gdb.base/readline.exp: Likewise.
* gdb.python/py-cmd.exp: Likewise.
* gdb.trace/tfile.exp: Likewise.
When I do something else, I find code format in gdb.base/macscp.exp is
messy. This patch is to fix various code format issues in it.
Pushed as it is obvious.
gdb/testsuite:
2014-03-26 Yao Qi <yao@codesourcery.com>
* gdb.base/macscp.exp: Fix code format issues.
Add new powerpc64le.inc file appropriate for the ELFv2 ABI and
use it to support the asm-source.exp test case on powerpc64le.
gdb/testsuite/
2014-03-25 Ulrich Weigand <uweigand@de.ibm.com>
* gdb.asm/asm-source.exp: Handle powerpc64le-* targets.
* gdb.asm/powerpc64le.inc: New file.
Sourcing a GDB script that runs foreground execution commands in
succession fails if the target can async:
Breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.base/source-execution.c:36
36 func1 ();
(gdb) source ../../../src/gdb/testsuite/gdb.base/source-execution.gdb
../../../src/gdb/testsuite/gdb.base/source-execution.gdb:21: Error in sourced command file:
Cannot execute this command while the selected thread is running.
(gdb) FAIL: gdb.base/source-execution.exp: source source-execution.gdb
That is, after a foreground execution command, GDB moves on to the
following command immediately before waiting for the previous command
to complete.
https://sourceware.org/ml/gdb-patches/2011-09/msg00037.html (b4a14fd0)
addressed this for command lists, Python's gdb.execute, etc., but
missed "source". Fixed now in the same way.
gdb/
2014-03-25 Pedro Alves <palves@redhat.com>
* cli/cli-script.c (script_from_file): Force the interpreter to
sync mode.
gdb/testsuite/
2014-03-25 Pedro Alves <palves@redhat.com>
Doug Evans <dje@google.com>
* gdb.base/source-execution.c: New file.
* gdb.base/source-execution.exp: New file.
* gdb.base/source-execution.gdb: New file.
After a previous patch that was committed by Pedro (0000e5cc), trying
to set a dprintf with with a GDBserver that doesn't support agent
commands at all now throws an error. But the dprintf tests still fail
with some GDBserver targets because they doesn't try to handle the
case of the server reporting support for breakpoint commands, but not
be able to use those in combination with Z0 (because Z0 isn't actually
supported, for example):
FAIL: gdb.base/dprintf.exp: 1st dprintf, agent
FAIL: gdb.base/dprintf.exp: 2nd dprintf, agent
FAIL: gdb.base/dprintf.exp: dprintf info 2 (pattern 4)
Similarly for the MI test.
This patch makes the tests handle this scenario.
Tested with native, and native gdbserver on x86_64 Fedora 17.
Also tested with the native-gdbserver.exp board hacked with:
set GDBFLAGS "${GDBFLAGS} -ex \"set remote breakpoint-commands off\""
(actually, "set remote breakpoint-commands off" is presently broken,
so this was on top of a fix for that command.)
which results in:
(gdb) PASS: gdb.base/dprintf.exp: 2nd dprintf, gdb
set dprintf-style agent
warning: Target cannot run dprintf commands, falling back to GDB printf
warning: Target cannot run dprintf commands, falling back to GDB printf
(gdb) UNSUPPORTED: gdb.base/dprintf.exp: set dprintf style to agent
gdb.sum:
Running target native-gdbserver
Running ../../../src/gdb/testsuite/gdb.base/dprintf.exp ...
PASS: gdb.base/dprintf.exp: dprintf
PASS: gdb.base/dprintf.exp: dprintf foo
PASS: gdb.base/dprintf.exp: dprintf 29
PASS: gdb.base/dprintf.exp: dprintf foo,"At foo entry\n"
PASS: gdb.base/dprintf.exp: ignore $bpnum 1
PASS: gdb.base/dprintf.exp: dprintf 26,"arg=%d, g=%d\n", arg, g
PASS: gdb.base/dprintf.exp: dprintf info 1
PASS: gdb.base/dprintf.exp: break 27
PASS: gdb.base/dprintf.exp: 1st dprintf, gdb
PASS: gdb.base/dprintf.exp: 2nd dprintf, gdb
UNSUPPORTED: gdb.base/dprintf.exp: set dprintf style to agent
PASS: gdb.base/dprintf.exp: Set dprintf style to an unrecognized type
And also with the native-gdbserver.exp board hacked with:
set GDBFLAGS "${GDBFLAGS} -ex \"set remote Z-packet off\""
which results in:
(gdb) continue
Continuing.
Warning:
Cannot insert breakpoint 3: Target doesn't support breakpoints that have target side commands.
Cannot insert breakpoint 4: Target doesn't support breakpoints that have target side commands.
(gdb) UNSUPPORTED: gdb.base/dprintf.exp: 1st dprintf, agent
gdb.sum:
Running target native-gdbserver
Running ../../../src/gdb/testsuite/gdb.base/dprintf.exp ...
PASS: gdb.base/dprintf.exp: dprintf
PASS: gdb.base/dprintf.exp: dprintf foo
PASS: gdb.base/dprintf.exp: dprintf 29
PASS: gdb.base/dprintf.exp: dprintf foo,"At foo entry\n"
PASS: gdb.base/dprintf.exp: ignore $bpnum 1
PASS: gdb.base/dprintf.exp: dprintf 26,"arg=%d, g=%d\n", arg, g
PASS: gdb.base/dprintf.exp: dprintf info 1
PASS: gdb.base/dprintf.exp: break 27
PASS: gdb.base/dprintf.exp: 1st dprintf, gdb
PASS: gdb.base/dprintf.exp: 2nd dprintf, gdb
PASS: gdb.base/dprintf.exp: set dprintf style to agent
UNSUPPORTED: gdb.base/dprintf.exp: 1st dprintf, agent
PASS: gdb.base/dprintf.exp: Set dprintf style to an unrecognized type
(One of the new comments mentions breakpoint always-inserted mode.
Actually testing with breakpoint always-inserted mode fails these
dprintf tests, due to the way they are written. But that'll take a
more substancial rewrite of the tests, so I'm leaving that for another
day.)
gdb/testsuite/
2014-03-24 Hui Zhu <hui@codesourcery.com>
Pedro Alves <palves@redhat.com>
PR breakpoints/16101
* gdb.base/dprintf.exp: Use unsupported rather than changing the
test pass/fail messages. Detect missing support for dprintf when
breakpoints are actually inserted.
* gdb.base/mi-dprintf.exp: Detect missing support for dprintf when
breakpoints are actually inserted.
* lib/mi-support.exp (mi_run_cmd_full): Return -1 if continue
fails.
That "set debug lin-lwp 1" command even is not needed for the functionality of
this testcase.
This patch does fix a testcase error on aarch64-none-elf.
gdb/testsuite/
2014-03-24 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/gdb-sigterm.exp (do_test): Remove "set debug lin-lwp 1".
Message-ID: <20140323165745.GA23830@host2.jankratochvil.net>
This fixes:
FAIL: gdb.threads/thread-specific.exp: continue to thread-specific breakpoint (timeout)
ERROR: tcl error sourcing .../gdb/testsuite/gdb.threads/thread-specific.exp.
ERROR: can't read "this_breakpoint": no such variable
while executing
"gdb_test_multiple "info breakpoint $this_breakpoint" "info on bp" {
-re ".*stop only in thread (\[0-9\]*).*$gdb_prompt $" {
set this_thread $expe..."
(file ".../gdb/testsuite/gdb.threads/thread-specific.exp" line 108)
invoked from within
"source .../gdb/testsuite/gdb.threads/thread-specific.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source .../gdb/testsuite/gdb.threads/thread-specific.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
and then:
FAIL: gdb.threads/thread-specific.exp: continue to thread-specific breakpoint (timeout)
UNTESTED: gdb.threads/thread-specific.exp: info on bp
ERROR: tcl error sourcing .../gdb/testsuite/gdb.threads/thread-specific.exp.
ERROR: can't read "this_thread": no such variable
while executing
"gdb_test {print $_thread} ".* = $this_thread" "thread var at break""
(file ".../gdb/testsuite/gdb.threads/thread-specific.exp" line 119)
invoked from within
"source .../gdb/testsuite/gdb.threads/thread-specific.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source .../gdb/testsuite/gdb.threads/thread-specific.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
Final results:
FAIL: gdb.threads/thread-specific.exp: continue to thread-specific breakpoint (timeout)
UNTESTED: gdb.threads/thread-specific.exp: info on bp
UNTESTED: gdb.threads/thread-specific.exp: thread var at break
Of course the first failure best wasn't there, but failing that the script
shouldn't crash.
* gdb.threads/thread-specific.exp: Handle the lack of usable
$this_breakpoint and $this_thread.
When target-async is enabled, dprintf.exp fails:
Running ../../../src/gdb/testsuite/gdb.base/dprintf.exp ...
FAIL: gdb.base/dprintf.exp: 1st dprintf, call
FAIL: gdb.base/dprintf.exp: 2nd dprintf, call
FAIL: gdb.base/dprintf.exp: Set dprintf function
FAIL: gdb.base/dprintf.exp: 1st dprintf, fprintf
FAIL: gdb.base/dprintf.exp: 2nd dprintf, fprintf
Breakpoint 2, main (argc=1, argv=0x7fffffffd3f8) at ../../../src/gdb/testsuite/gdb.base/dprintf.c:33
33 int loc = 1234;
(gdb) continue
Continuing.
kickoff 1234
also to stderr 1234
At foo entry
(gdb) FAIL: gdb.base/dprintf.exp: 1st dprintf, call
The problem is that GDB gave the prompt back to the user too early.
This happens when calling functions while handling an event that
doesn't cause a user visible stop. dprintf with "set dprintf-style
gdb" is one such case. This patch adds a test case that has a
breakpoint with a condition that calls a function that returns false,
so that regression testing isn't dependent on the implementation of
dprintf.
The problem happens because run_inferior_call causes GDB to forget
that it is running in sync_execution mode, so any event that runs an
inferior call causes fetch_inferior_event to display the prompt, even
if the event should not result in a user visible stop (that is, gdb
resumes the inferior and waits for the next event).
This patch fixes the issue by noticing when GDB was in sync_execution
mode in run_inferior_call, and taking care to restore this state
afterward.
gdb/
2014-03-20 Tom Tromey <tromey@redhat.com>
PR cli/15718
* infcall.c: Include event-top.h.
(run_inferior_call): Call async_disable_stdin if needed.
gdb/testsuite/
2014-03-20 Tom Tromey <tromey@redhat.com>
Pedro Alves <palves@redhat.com>
PR cli/15718
* gdb.base/condbreak-call-false.c: New file.
* gdb.base/condbreak-call-false.exp: New file.
This test now uses pthread_kill instead of the host's kill command, so
no longer need to block signals, or store the the inferior's PID.
gdb/testsuite/
2014-03-20 Pedro Alves <palves@redhat.com>
* gdb.threads/signal-while-stepping-over-bp-other-thread.c (pid):
Delete.
(block_signals, unblock_signals): Delete.
(child_function_2, main): Remove references to deleted variable
and functions.
Use pthread_kill instead of the host's "kill". The reason the test
wasn't written that way to begin with, is that done this way, before
the previous fixes to make GDB step-over all other threads before the
stepping thread, the test would fail...
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/testsuite/
2014-03-20 Pedro Alves <palves@redhat.com>
* gdb.threads/signal-while-stepping-over-bp-other-thread.c (main):
Use pthread_kill to signal thread 2.
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
Adjust to make the test send itself a signal rather than using the
host's "kill" command.
This test fails with current mainline.
If the program stopped for a breakpoint in thread 1, and then the user
switches to thread 2, and resumes the program, GDB first switches back
to thread 1 to step it over the breakpoint, in order to make progress.
However, that logic only considers the last reported event, assuming
only one thread needs that stepping over dance.
That's actually not true when we play with scheduler-locking. The
patch adds an example to the testsuite of multiple threads needing a
step-over before the stepping thread can be resumed. With current
mainline, the program re-traps the same breakpoint it had already
trapped before.
E.g.:
Breakpoint 2, main () at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:99
99 wait_threads (); /* set wait-threads breakpoint here */
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: continue to breakpoint: run to breakpoint
info threads
Id Target Id Frame
3 Thread 0x7ffff77c9700 (LWP 4310) "multiple-step-o" 0x00000000004007ca in child_function_3 (arg=0x1) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:43
2 Thread 0x7ffff7fca700 (LWP 4309) "multiple-step-o" 0x0000000000400827 in child_function_2 (arg=0x0) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:60
* 1 Thread 0x7ffff7fcb740 (LWP 4305) "multiple-step-o" main () at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:99
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: info threads shows all threads
set scheduler-locking on
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: set scheduler-locking on
break 44
Breakpoint 3 at 0x4007d3: file ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c, line 44.
(gdb) break 61
Breakpoint 4 at 0x40082d: file ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c, line 61.
(gdb) thread 3
[Switching to thread 3 (Thread 0x7ffff77c9700 (LWP 4310))]
#0 0x00000000004007ca in child_function_3 (arg=0x1) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:43
43 (*myp) ++;
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: thread 3
continue
Continuing.
Breakpoint 3, child_function_3 (arg=0x1) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:44
44 callme (); /* set breakpoint thread 3 here */
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: continue to breakpoint: run to breakpoint in thread 3
p *myp = 0
$1 = 0
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: unbreak loop in thread 3
thread 2
[Switching to thread 2 (Thread 0x7ffff7fca700 (LWP 4309))]
#0 0x0000000000400827 in child_function_2 (arg=0x0) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:60
60 (*myp) ++;
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: thread 2
continue
Continuing.
Breakpoint 4, child_function_2 (arg=0x0) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:61
61 callme (); /* set breakpoint thread 2 here */
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: continue to breakpoint: run to breakpoint in thread 2
p *myp = 0
$2 = 0
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: unbreak loop in thread 2
thread 1
[Switching to thread 1 (Thread 0x7ffff7fcb740 (LWP 4305))]
#0 main () at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:99
99 wait_threads (); /* set wait-threads breakpoint here */
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: thread 1
set scheduler-locking off
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: set scheduler-locking off
At this point all thread are stopped for a breakpoint that needs stepping over.
(gdb) step
Breakpoint 2, main () at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:99
99 wait_threads (); /* set wait-threads breakpoint here */
(gdb) FAIL: gdb.threads/multiple-step-overs.exp: step
But that "step" retriggers the same breakpoint instead of making
progress.
The patch teaches GDB to step over all breakpoints of all threads
before resuming the stepping thread.
Tested on x86_64 Fedora 17, against pristine mainline, and also my
branch that implements software single-stepping on x86.
gdb/
2014-03-20 Pedro Alves <palves@redhat.com>
* infrun.c (prepare_to_proceed): Delete.
(thread_still_needs_step_over): New function.
(find_thread_needs_step_over): New function.
(proceed): If the current thread needs a step-over, set its
steping_over_breakpoint flag. Adjust to use
find_thread_needs_step_over instead of prepare_to_proceed.
(process_event_stop_test): For BPSTAT_WHAT_STOP_NOISY and
BPSTAT_WHAT_STOP_SILENT, assume the thread stopped for a
breakpoint.
(switch_back_to_stepped_thread): Step over breakpoints of all
threads not the stepping thread, before switching back to the
stepping thread.
gdb/testsuite/
2014-03-20 Pedro Alves <palves@redhat.com>
* gdb.threads/multiple-step-overs.c: New file.
* gdb.threads/multiple-step-overs.exp: New file.
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
Adjust expected infrun debug output.
Even with deferred_step_ptid out of the way, GDB can still lose
watchpoints.
If a watchpoint triggers and the PC points to an address where a
thread-specific breakpoint for another thread is set, the thread-hop
code triggers, and we lose the watchpoint:
if (ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_TRAP)
{
int thread_hop_needed = 0;
struct address_space *aspace =
get_regcache_aspace (get_thread_regcache (ecs->ptid));
/* Check if a regular breakpoint has been hit before checking
for a potential single step breakpoint. Otherwise, GDB will
not see this breakpoint hit when stepping onto breakpoints. */
if (regular_breakpoint_inserted_here_p (aspace, stop_pc))
{
if (!breakpoint_thread_match (aspace, stop_pc, ecs->ptid))
thread_hop_needed = 1;
^^^^^^^^^^^^^^^^^^^^^
}
And on software single-step targets, even without a thread-specific
breakpoint in the way, here in the thread-hop code:
else if (singlestep_breakpoints_inserted_p)
{
...
if (!ptid_equal (singlestep_ptid, ecs->ptid)
&& in_thread_list (singlestep_ptid))
{
/* If the PC of the thread we were trying to single-step
has changed, discard this event (which we were going
to ignore anyway), and pretend we saw that thread
trap. This prevents us continuously moving the
single-step breakpoint forward, one instruction at a
time. If the PC has changed, then the thread we were
trying to single-step has trapped or been signalled,
but the event has not been reported to GDB yet.
There might be some cases where this loses signal
information, if a signal has arrived at exactly the
same time that the PC changed, but this is the best
we can do with the information available. Perhaps we
should arrange to report all events for all threads
when they stop, or to re-poll the remote looking for
this particular thread (i.e. temporarily enable
schedlock). */
CORE_ADDR new_singlestep_pc
= regcache_read_pc (get_thread_regcache (singlestep_ptid));
if (new_singlestep_pc != singlestep_pc)
{
enum gdb_signal stop_signal;
if (debug_infrun)
fprintf_unfiltered (gdb_stdlog, "infrun: unexpected thread,"
" but expected thread advanced also\n");
/* The current context still belongs to
singlestep_ptid. Don't swap here, since that's
the context we want to use. Just fudge our
state and continue. */
stop_signal = ecs->event_thread->suspend.stop_signal;
ecs->event_thread->suspend.stop_signal = GDB_SIGNAL_0;
ecs->ptid = singlestep_ptid;
ecs->event_thread = find_thread_ptid (ecs->ptid);
ecs->event_thread->suspend.stop_signal = stop_signal;
stop_pc = new_singlestep_pc;
}
else
{
if (debug_infrun)
fprintf_unfiltered (gdb_stdlog,
"infrun: unexpected thread\n");
thread_hop_needed = 1;
stepping_past_singlestep_breakpoint = 1;
saved_singlestep_ptid = singlestep_ptid;
}
}
}
we either end up with thread_hop_needed, ignoring the watchpoint
SIGTRAP, or switch to the stepping thread, again ignoring that the
SIGTRAP could be for some other event.
The new test added by this patch exercises both paths.
So the fix is similar to the deferred_step_ptid fix -- defer the
thread hop to _after_ the SIGTRAP had a change of passing through the
regular bpstat handling. If the wrong thread hits a breakpoint, we'll
just end up with BPSTAT_WHAT_SINGLE, and if nothing causes a stop,
keep_going starts a step-over.
Most of the stepping_past_singlestep_breakpoint mechanism is really
not necessary -- setting the thread to step over a breakpoint with
thread->trap_expected is sufficient to keep all other threads locked.
It's best to still keep the flag in some form though, because when we
get to keep_going, the software single-step breakpoint we need to step
over is already gone -- an optimization done by a follow up patch will
check whether a step-over is still be necessary by looking to see
whether the breakpoint is still there, and would find the thread no
longer needs a step-over, while we still want it.
Special care is still needed to handle the case of PC of the thread we
were trying to single-step having changed, like in the old code. We
can't just keep_going and re-step it, as in that case we can over-step
the thread (if it was already done with the step, but hasn't reported
it yet, we'd ask it to step even further). That's now handled in
switch_back_to_stepped_thread. As bonus, we're now using a technique
that doesn't lose signals, unlike the old code -- we now insert a
breakpoint at PC, and resume, which either reports the breakpoint
immediately, or any pending signal.
Tested on x86_64 Fedora 17, against pristine mainline, and against a
branch that implements software single-step on x86.
gdb/
2014-03-20 Pedro Alves <palves@redhat.com>
* breakpoint.c (single_step_breakpoint_inserted_here_p): Make
extern.
* breakpoint.h (single_step_breakpoint_inserted_here_p): Declare.
* infrun.c (saved_singlestep_ptid)
(stepping_past_singlestep_breakpoint): Delete.
(resume): Remove stepping_past_singlestep_breakpoint handling.
(proceed): Store the prev_pc of the stepping thread too.
(init_wait_for_inferior): Adjust. Clear singlestep_ptid and
singlestep_pc.
(enum infwait_states): Delete infwait_thread_hop_state.
(struct execution_control_state) <hit_singlestep_breakpoint>: New
field.
(handle_inferior_event): Adjust.
(handle_signal_stop): Delete stepping_past_singlestep_breakpoint
handling and the thread-hop code. Before removing single-step
breakpoints, check whether the thread hit a single-step breakpoint
of another thread. If it did, the trap is not a random signal.
(switch_back_to_stepped_thread): If the event thread hit a
single-step breakpoint, unblock it before switching to the
stepping thread. Handle the case of the stepped thread having
advanced already.
(keep_going): Handle the case of the current thread moving past a
single-step breakpoint.
gdb/testsuite/
2014-03-20 Pedro Alves <palves@redhat.com>
* gdb.threads/step-over-trips-on-watchpoint.c: New file.
* gdb.threads/step-over-trips-on-watchpoint.exp: New file.
Say the program is stopped at a breakpoint, and the user sets a
watchpoint. When the program is next resumed, GDB will first step
over the breakpoint, as explained in the manual:
@value {GDBN} normally ignores breakpoints when it resumes
execution, until at least one instruction has been executed. If it
it did not do this, you would be unable to proceed past a breakpoint
without first disabling the breakpoint. This rule applies whether
or not the breakpoint already existed when your program stopped.
However, GDB currently also removes watchpoints, catchpoints, etc.,
and that means that the first instruction off the breakpoint does not
trigger the watchpoint, catchpoint, etc.
testsuite/gdb.base/watchpoint.exp has a kfail for this.
The PR proposes installing watchpoints only when stepping over a
breakpoint, but that misses catchpoints, etc.
A better fix would instead work from the opposite direction -- remove
only real breakpoints, leaving all other kinds of breakpoints
inserted.
But, going further, it's really a waste to constantly remove/insert
all breakpoints when stepping over a single breakpoint (generating a
pair of RSP z/Z packets for each breakpoint), so the fix goes a step
further and makes GDB remove _only_ the breakpoint being stepped over,
leaving all others installed. This then has the added benefit of
reducing breakpoint-related RSP traffic substancialy when there are
many breakpoints set.
gdb/
2014-03-20 Pedro Alves <palves@redhat.com>
PR breakpoints/7143
* breakpoint.c (should_be_inserted): Don't insert breakpoints that
are being stepped over.
(breakpoint_address_match): Make extern.
* breakpoint.h (breakpoint_address_match): New declaration.
* inferior.h (stepping_past_instruction_at): New declaration.
* infrun.c (struct step_over_info): New type.
(step_over_info): New global.
(set_step_over_info, clear_step_over_info)
(stepping_past_instruction_at): New functions.
(handle_inferior_event): Clear the step-over info when
trap_expected is cleared.
(resume): Remove now stale comment.
(clear_proceed_status): Clear step-over info.
(proceed): Adjust step-over handling to set or clear the step-over
info instead of removing all breakpoints.
(handle_signal_stop): When setting up a thread-hop, don't remove
breakpoints here.
(stop_stepping): Clear step-over info.
(keep_going): Adjust step-over handling to set or clear step-over
info and then always inserting breakpoints, instead of removing
all breakpoints when stepping over one.
gdb/testsuite/
2014-03-20 Pedro Alves <palves@redhat.com>
PR breakpoints/7143
* gdb.base/watchpoint.exp: Mention bugzilla bug number instead of
old gnats gdb/38. Remove kfail. Adjust to use gdb_test instead
of gdb_test_multiple.
* gdb.cp/annota2.exp: Remove kfail for gdb/38.
* gdb.cp/annota3.exp: Remove kfail for gdb/38.
Consider the case of the user doing "step" in thread 2, while thread 1
had previously stopped for a breakpoint. In order to make progress,
GDB makes thread 1 step over its breakpoint first (with all other
threads stopped), and once that is over, thread 2 then starts stepping
(with thread 1 and all others running free, by default). If GDB
didn't do that, thread 1 would just trip on the same breakpoint
immediately again. This is what the prepare_to_proceed /
deferred_step_ptid code is all about.
However, deferred_step_ptid code resumes the target with:
resume (1, GDB_SIGNAL_0);
prepare_to_wait (ecs);
return;
Recall we were just stepping over a breakpoint when we get here. That
means that _nothing_ had installed breakpoints yet! If there's
another breakpoint just after the breakpoint that was just stepped,
we'll miss it. The fix for that would be to use keep_going instead.
However, there are more problems. What if the instruction that was
just single-stepped triggers a watchpoint? Currently, GDB just
happily resumes the thread, losing that too...
Missed watchpoints will need yet further fixes, but we should keep
those in mind.
So the fix must be to let the trap fall through the regular bpstat
handling, and only if no breakpoint, watchpoint, etc. claims the trap,
shall we switch back to the stepped thread.
Now, nowadays, we have code at the tail end of trap handling that does
exactly that -- switch back to the stepped thread
(switch_back_to_the_stepped_thread).
So the deferred_step_ptid code is just standing in the way, and can
simply be eliminated, fixing bugs in the process. Sweet.
The comment about spurious "Switching to ..." made me pause, but is
actually stale nowadays. That isn't needed anymore.
previous_inferior_ptid used to be re-set at each (internal) event, but
now it's only touched in proceed and normal stop.
The two tests added by this patch fail without the fix.
Tested on x86_64 Fedora 17 (also against my software single-stepping
on x86 branch).
gdb/
2014-03-20 Pedro Alves <palves@redhat.com>
* infrun.c (previous_inferior_ptid): Adjust comment.
(deferred_step_ptid): Delete.
(infrun_thread_ptid_changed, prepare_to_proceed)
(init_wait_for_inferior): Adjust.
(handle_signal_stop): Delete deferred_step_ptid handling.
gdb/testsuite/
2014-03-20 Pedro Alves <palves@redhat.com>
* gdb.threads/step-over-lands-on-breakpoint.c: New file.
* gdb.threads/step-over-lands-on-breakpoint.exp: New file.
There's no reason not to enable this test anymore.
Even if the current output isn't ideal (we mess up the prompt), it's what
we have today. We can adjust the test if the output improves.
gdb/testsuite/
2014-03-19 Pedro Alves <palves@redhat.com>
* gdb.base/async.exp: Remove early return.
This test is currently racy:
PASS: gdb.base/async.exp: step&
stepi&
(gdb) 0x0000000000400547 14 x = 5; x = 5;
completed.
PASS: gdb.base/async.exp: stepi&
nexti&
(gdb) 15 y = 3;
completed.FAIL: gdb.base/async.exp: nexti&
The problem is here:
-re "^$command\r\n${before_prompt}${gdb_prompt}${after_prompt}completed\.\r\n" {
pass "$command"
}
-re "$gdb_prompt.*completed\.$" {
fail "$command"
}
Note how the fail pattern is a subset of the pass pattern. If the
expect buffer happens to end up with:
"^$command\r\n${before_prompt}${gdb_prompt}${after_prompt}completed\."
that is, the final "\r\n" has't reached the expect buffer yet, but
"completed." has, then the fail pattern matches...
gdb/testsuite/
2014-03-19 Pedro Alves <palves@redhat.com>
* gdb.base/async.exp (test_background): Expect \r\n after
"completed." in the fail pattern.
All the tests here follow the same pattern (and they all have the same
problem, not fixed here yet). Add a new procedure, factoring out the
pattern to a simple place.
gdb/testsuite/
2014-03-19 Pedro Alves <palves@redhat.com>
* gdb.base/async.exp (test_background): New procedure.
Use it for all background execution command tests.
Currently the test assumes that "stepi" over:
13 x = 5;
end up somewhere midline. But, (at least) on x86, that assignment
ends up compiled as just one movl instruction, so a stepi stops at the
next line already:
completed.
PASS: gdb.base/async.exp: step &
step&
(gdb) foo () at ../../../src/gdb/testsuite/gdb.base/async.c:13
13 x = 5;
completed.
PASS: gdb.base/async.exp: step &
stepi&
(gdb) 14 y = 3;
completed.
FAIL: gdb.base/async.exp: (timeout) stepi &
nexti&
(gdb) 16 return x + y;
completed.
FAIL: gdb.base/async.exp: (timeout) nexti &
finish&
Run till exit from #0 foo () at ../../../src/gdb/testsuite/gdb.base/async.c:16
This patch fixes it, by making sure there's more than one instruction
in that line.
gdb/testsuite/
2014-03-19 Pedro Alves <palves@redhat.com>
* gdb.base/async.c (foo): Make 'x' volatile. Write to it twice in
the same line.
gdb/testsuite/
2014-03-19 Pedro Alves <palves@redhat.com>
* gdb.base/async.c (main): Add "jump here" and "until here" line
marker comments.
* gdb.base/async.exp (jump_here): New global.
(jump& test): Use it.
(until_here): New global.
(until& test): Use it.
Many eons ago, async was only implemented in the remote target, and
you'd activate it by doing "target async" rather than "target remote".
That's long gone now, replaced by "set target-async on".
gdb/testsuite/
2014-03-19 Pedro Alves <palves@redhat.com>
* gdb.base/async.exp: Don't frob gdb_protocol.
gdb/
2014-03-18 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/15358
* defs.h (sync_quit_force_run): New declaration.
(QUIT): Check also SYNC_QUIT_FORCE_RUN.
* event-top.c (async_sigterm_handler): New declaration.
(async_sigterm_token): New variable.
(async_init_signals): Create also async_sigterm_token.
(async_sigterm_handler): New function.
(sync_quit_force_run): New variable.
(handle_sigterm): Replace quit_force call by other calls.
* utils.c (quit): Call quit_force if SYNC_QUIT_FORCE_RUN.
gdb/testsuite/
2014-03-18 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/15358
* gdb.base/gdb-sigterm.c: New file.
* gdb.base/gdb-sigterm.exp: New file.
Message-ID: <20140316135334.GA30698@host2.jankratochvil.net>
Part of PR gdb/13860 is about the mi-solib.exp test's output being
different in sync vs async modes.
sync:
>./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async off" -i=mi
=thread-group-added,id="i1"
~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..."
~"done.\n"
(gdb)
&"start\n"
~"Temporary breakpoint 1 at 0x400608: file ../../../src/gdb/testsuite/gdb.mi/solib-main.c, line 21.\n"
=breakpoint-created,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400608",func="main",file="../../../src/gdb/testsuite/gdb.mi/solib-main.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/solib-main.c",line="21",times="0",original-location="main"}
~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n"
=thread-group-started,id="i1",pid="17724"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
~"Stopped due to shared library event (no libraries added or removed)\n"
*stopped,reason="solib-event",frame={addr="0x000000379180f990",func="_dl_debug_state",args=[],from="/lib64/ld-linux-x86-64.so.2"},thread-id="1",stopped-threads="all",core="3"
(gdb)
async:
>./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async on" -i=mi
=thread-group-added,id="i1"
~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..."
~"done.\n"
(gdb)
start
&"start\n"
~"Temporary breakpoint 1 at 0x400608: file ../../../src/gdb/testsuite/gdb.mi/solib-main.c, line 21.\n"
=breakpoint-created,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400608",func="main",file="../../../src/gdb/testsuite/gdb.mi/solib-main.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/solib-main.c",line="21",times="0",original-location="main"}
~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n"
=thread-group-started,id="i1",pid="17729"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
(gdb)
*stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="1"
For now, let's focus only on the *stopped event. We see that the
async output is missing frame info. And this causes a test failure in
async mode, as "mi_expect_stop solib-event" wants to see the frame
info.
However, if we compare the event output when a real MI execution
command is used, compared to a CLI command (e.g., run vs -exec-run,
next vs -exec-next, etc.), we see:
>./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async off" -i=mi
=thread-group-added,id="i1"
~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..."
~"done.\n"
(gdb)
r
&"r\n"
~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n"
=thread-group-started,id="i1",pid="17751"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
~"Stopped due to shared library event (no libraries added or removed)\n"
*stopped,reason="solib-event",frame={addr="0x000000379180f990",func="_dl_debug_state",args=[],from="/lib64/ld-linux-x86-64.so.2"},thread-id="1",stopped-threads="all",core="3"
(gdb)
-exec-run
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1"
=library-unloaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",thread-group="i1"
=thread-group-started,id="i1",pid="17754"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
*stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="1"
=thread-selected,id="1"
(gdb)
As seen above, with MI commands, the *stopped event _doesn't_ have
frame info. This is because normal_stop, as commanded by the result
of bpstat_print, skips printing frame info in this case (it's an
"event", not a "breakpoint"), and when the interpreter is MI,
mi_on_normal_stop skips calling print_stack_frame, as the normal_stop
call was already done with the MI uiout. This explains why the async
output is different even with a CLI command. Its because in async
mode, the mi_on_normal_stop path is always taken; it is always reached
with the MI uiout, because the stop is handled from the event loop,
instead of from within `proceed -> wait_for_inferior -> normal_stop'
with the interpreter overridden, as in sync mode.
This patch fixes the issue by making all cases output the same
*stopped event, by factoring out the print code from normal_stop, and
using it from mi_on_normal_stop as well. I chose the *stopped output
without a frame, mainly because that is what you already get if you
use MI execution commands, the commands frontends are supposed to use
(except when implementing a console). This patch makes it simpler to
tweak the MI output differently if desired, as we only have to change
the centralized print_stop_event (taking into account whether the
uiout is MI-like), and all different modes will change accordingly.
Tested on x86_64 Fedora 17, no regressions. The mi-solib.exp test no
longer fails in async mode with this patch, so the patch removes the
kfail.
2014-03-18 Pedro Alves <palves@redhat.com>
PR gdb/13860
* inferior.h (print_stop_event): Declare.
* infrun.c (print_stop_event): New, factored out from ...
(normal_stop): ... this.
* mi/mi-interp.c (mi_on_normal_stop): Use print_stop_event instead
of bpstat_print/print_stack_frame.
2014-03-18 Pedro Alves <palves@redhat.com>
PR gdb/13860
* gdb.mi/mi-solib.exp: Remove gdb/13860 kfail.
* lib/mi-support.exp (mi_expect_stop): Add special handling for
solib-event.
* guile/scm-type.c (tyscm_copy_type_recursive): Move type to its
new eq?-hashtab.
testsuite/
* gdb.guile/scm-value.ep (test_value_after_death): Do a garbage
collect after discarding symbols.
* value.c (record_latest_value): Call release_value_or_incref
instead of release_value.
testsuite/
* gdb.guile/scm-value.exp (test_value_in_inferior): Verify value added
to history survives a gc.
Note that "target procfs" is used by QNX, but the test must be failing
there, as nto-procfs.c overrides to_open with a method that doesn't
throw the error being tested. So I'm just removing the test
completely.
gdb/
2014-03-13 Pedro Alves <palves@redhat.com>
* procfs.c (procfs_target): Don't override to_shortname,
to_longname or to_doc.
gdb/testsuite/
2014-03-13 Pedro Alves <palves@redhat.com>
* gdb.base/default.exp: Don't test "target procfs".
I find the mention of "Unix" unnecessary (and really slightly a lie)
on GNU/Linux in a couple of places:
(gdb) maint print target-stack
The current target stack is:
- multi-thread (multi-threaded child process.)
- child (Unix child process)
- exec (Local exec file)
- None (None)
(gdb) help target child
Unix child process (started by the "run" command).
(gdb) target child
Use the "run" command to start a Unix child process.
It's also odd that e.g., the Windows port says "Unix" in reaction to
"target child" (it was already that way before Windows used
inf-child.c):
(gdb) target child
Use the "run" command to start a Unix child process.
(gdb)
So drop "Unix", going in the direction of saying mostly the same on
all native targets:
(gdb) maint print target-stack
The current target stack is:
- multi-thread (multi-threaded child process.)
- - child (Unix child process)
+ - child (Child process)
- exec (Local exec file)
- None (None)
(gdb) help target child
- Unix child process (started by the "run" command).
+ Child process (started by the "run" command).
(gdb) target child
-Use the "run" command to start a Unix child process.
+Use the "run" command to start a child process.
gdb/
2014-03-13 Pedro Alves <palves@redhat.com>
* inf-child.c (inf_child_open, inf_child_target): Don't mention
Unix in user visible strings.
gdb/testsuite/
2014-03-13 Pedro Alves <palves@redhat.com>
* gdb.base/default.exp: Update "target child" and "target procfs"
tests to not expect "Unix".
A patch in the target cleanup series caused a regression when using
record with target-async. Version 4 of the patch is here:
https://sourceware.org/ml/gdb-patches/2014-03/msg00159.html
The immediate problem is that record supplies to_can_async_p and
to_is_async_p methods, but does not supply a to_async method. So,
when target-async is set, record claims to support async -- but if the
underlying target does not support async, then the to_async method
call will end up in that method's default implementation, namely
tcomplain.
This worked previously because the record target used to provide a
to_async method; one that (erroneously, only at push time) checked the
other members of the target stack, and then simply dropped to_async
calls in the "does not implement async" case.
My first thought was to simply drop tcomplain as the default for
to_async. This works, but Pedro pointed out that the only reason
record has to supply to_can_async_p and to_is_async_p is that these
default to using the find_default_run_target machinery -- and these
defaults are only needed by "run" and "attach".
So, a nicer solution presents itself: change run and attach to
explicitly call into the default run target when needed; and change
to_is_async_p and to_can_async_p to default to "return 0". This makes
the target stack simpler to use and lets us remove the method
implementations from record. This is also in harmony with other plans
for the target stack; namely trying to reduce the impact of
find_default_run_target. This approach makes it clear that
find_default_is_async_p is not needed -- it is asking whether a target
that may not even be pushed is actually async, which seems like a
nonsensical question.
While an improvement, this approach proved to introduce the same bug
when using the core target. Looking a bit deeper, the issue is that
code in "attach" and "run" may need to use either the current target
stack or the default run target -- but different calls into the target
API in those functions could wind up querying different targets.
This new patch makes the target to use more explicit in "run" and
"attach". Then these commands explicitly make the needed calls
against that target. This ensures that a single target is used for
all relevant operations. This lets us remove a couple find_default_*
functions from various targets, including the dummy target. I think
this is a decent understandability improvement.
One issue I see with this patch is that the new calls in "run" and
"attach" are not very much like the rest of the target API. I think
fundamentally this is due to bad factoring in the target API, which
may need to be fixed for multi-target. Tackling that seemed ambitious
for a regression fix.
While working on this I noticed that there don't seem to be any test
cases that involve both target-async and record, so this patch changes
break-precsave.exp to add some. It also changes corefile.exp to add
some target-async tests; these pass with current trunk and with this
patch applied, but fail with the v1 patch.
This patch differs from v4 in that it moves initialization of
to_can_async_p and to_supports_non_stop into inf-child, adds some
assertions to complete_target_initialization, and adds some comments
to target.h.
Built and regtested on x86-64 Fedora 20.
2014-03-12 Tom Tromey <tromey@redhat.com>
* inf-child.c (return_zero): New function.
(inf_child_target): Set to_can_async_p, to_supports_non_stop.
* aix-thread.c (aix_thread_inferior_created): New function.
(aix_thread_attach): Remove.
(init_aix_thread_ops): Don't set to_attach.
(_initialize_aix_thread): Register inferior_created observer.
* corelow.c (init_core_ops): Don't set to_attach or
to_create_inferior.
* exec.c (init_exec_ops): Don't set to_attach or
to_create_inferior.
* infcmd.c (run_command_1): Use find_run_target. Make direct
target calls.
(attach_command): Use find_attach_target. Make direct target
calls.
* record-btrace.c (init_record_btrace_ops): Don't set
to_create_inferior.
* record-full.c (record_full_can_async_p, record_full_is_async_p):
Remove.
(init_record_full_ops, init_record_full_core_ops): Update. Don't
set to_create_inferior.
* target.c (complete_target_initialization): Add assertion.
(target_create_inferior): Remove.
(find_default_attach, find_default_create_inferior): Remove.
(find_attach_target, find_run_target): New functions.
(find_default_is_async_p, find_default_can_async_p)
(target_supports_non_stop, target_attach): Remove.
(init_dummy_target): Don't set to_create_inferior or
to_supports_non_stop.
* target.h (struct target_ops) <to_attach>: Add comment. Remove
TARGET_DEFAULT_FUNC.
<to_create_inferior>: Add comment.
<to_can_async_p, to_is_async_p, to_supports_non_stop>: Use
TARGET_DEFAULT_RETURN.
<to_can_async_p, to_supports_non_stop, to_can_run>: Add comments.
(find_attach_target, find_run_target): Declare.
(target_create_inferior): Remove.
(target_has_execution_1): Update comment.
(target_supports_non_stop): Remove.
* target-delegates.c: Rebuild.
2014-03-12 Tom Tromey <tromey@redhat.com>
* gdb.base/corefile.exp (corefile_test_run, corefile_test_attach):
New procs. Add target-async tests.
* gdb.reverse/break-precsave.exp (precsave_tests): New proc.
Add target-async tests.
On PPC64, 'func' and 'main' are function descriptors and don't point
to the actual code. Thus the usage of these symbols in the DWARF
assembler source was broken. The patch introduces new labels
func_start and func_end for this purpose.
A "side effect" of the migration to Dwarf::assemble is that the DWARF
address size is now automatically adjusted to the target architecture.
The original assembler source hard-coded the DWARF address size to 4,
even on 64-bit architectures. This address size mismatch caused a
test case failure on s390x due to a wrong result from DW_OP_deref.
Now that prepare_for_testing etc. can cope with absolute path names,
this can be exploited for test cases with generated source files.
This is just to simplify the code and shouldn't cause any functional
change.
Test cases that produce source files in the build directory have not
been able to use prepare_for_testing and friends. This was because
build_executable_from_specs unconditionally prepended the source
directory path name to its arguments.
When evaluating an expression, if it is of a tagged type, GDB reads
the tag in memory and deduces the full view. At parsing time, however,
this operation is done only in the case of OP_VAR_VALUE. ptype does
not go through a full evaluation of expressions so it may return some
odd results:
(gdb) print c.menu_name
$1 = 0x0
(gdb) ptype $
type = system.strings.string_access
(gdb) ptype c.menu_name
type = <void>
This change removes this peculiarity by extending the tag resolution
to UNOP_IND and STRUCTOP_STRUCT. As in the case of OP_VAR_VALUE, this
implies switching from EVAL_AVOID_SIDE_EFFECTS to EVAL_NORMAL when a
tagged type is dereferenced.
gdb/
* ada-lang.c (ada_evaluate_subexp): Resolve tagged types to
full view in the case of UNOP_IND and STRUCTOP_STRUCT.
gdb/testsuite/
* gdb.ada/tagged_access: New testcase.
This patch fixes PR16508, which is about MI "-trace-find frame-number 0"
behaves differently from CLI "tfind 0". In CLI, we check both
status->running and status->filename, but in MI, we only check
status->running, which looks wrong to me. This patch moves the code
of checking to a new function check_trace_running, and use it in
both CLI and MI.
This patch also adds a test case pr16508.exp, which fails without this
fix, and passes with the fix applied.
FAIL: gdb.trace/pr16508.exp: interpreter-exec mi "-trace-find frame-number 0"
gdb:
2014-03-06 Yao Qi <yao@codesourcery.com>
PR breakpoints/16508
* tracepoint.c (check_trace_running): New function.
(trace_find_command): Move code to check_trace_running and
call check_trace_running.
(trace_find_pc_command): Likewise.
(trace_find_tracepoint_command): Likewise.
(trace_find_line_command): Likewise.
(trace_find_range_command): Likewise.
* tracepoint.h (check_trace_running): Likewise.
* mi/mi-main.c (mi_cmd_trace_find): Call check_trace_running.
gdb/testsuite:
2014-03-06 Yao Qi <yao@codesourcery.com>
* gdb.trace/pr16508.exp: New file.
In non-stop mode, or rather, breakpoints always-inserted mode, the
code cache can easily end up with stale breakpoint instructions:
All it takes is filling a cache line when breakpoints already exist in
that memory region, and then delete the breakpoint.
Vis. (from the new test):
(gdb) set breakpoint always-inserted on
(gdb) b 23
Breakpoint 2 at 0x400540: file ../../../src/gdb/testsuite/gdb.base/breakpoint-shadow.c, line 23.
(gdb) b 24
Breakpoint 3 at 0x400547: file ../../../src/gdb/testsuite/gdb.base/breakpoint-shadow.c, line 24.
disass main
Dump of assembler code for function main:
0x000000000040053c <+0>: push %rbp
0x000000000040053d <+1>: mov %rsp,%rbp
=> 0x0000000000400540 <+4>: movl $0x1,-0x4(%rbp)
0x0000000000400547 <+11>: movl $0x2,-0x4(%rbp)
0x000000000040054e <+18>: mov $0x0,%eax
0x0000000000400553 <+23>: pop %rbp
0x0000000000400554 <+24>: retq
End of assembler dump.
So far so good. Now flush the code cache:
(gdb) set code-cache off
(gdb) set code-cache on
Requesting a disassembly works as expected, breakpoint shadowing is
applied:
(gdb) disass main
Dump of assembler code for function main:
0x000000000040053c <+0>: push %rbp
0x000000000040053d <+1>: mov %rsp,%rbp
=> 0x0000000000400540 <+4>: movl $0x1,-0x4(%rbp)
0x0000000000400547 <+11>: movl $0x2,-0x4(%rbp)
0x000000000040054e <+18>: mov $0x0,%eax
0x0000000000400553 <+23>: pop %rbp
0x0000000000400554 <+24>: retq
End of assembler dump.
However, now delete the breakpoints:
(gdb) delete
Delete all breakpoints? (y or n) y
And disassembly shows the old breakpoint instructions:
(gdb) disass main
Dump of assembler code for function main:
0x000000000040053c <+0>: push %rbp
0x000000000040053d <+1>: mov %rsp,%rbp
=> 0x0000000000400540 <+4>: int3
0x0000000000400541 <+5>: rex.RB cld
0x0000000000400543 <+7>: add %eax,(%rax)
0x0000000000400545 <+9>: add %al,(%rax)
0x0000000000400547 <+11>: int3
0x0000000000400548 <+12>: rex.RB cld
0x000000000040054a <+14>: add (%rax),%al
0x000000000040054c <+16>: add %al,(%rax)
0x000000000040054e <+18>: mov $0x0,%eax
0x0000000000400553 <+23>: pop %rbp
0x0000000000400554 <+24>: retq
End of assembler dump.
Those breakpoint instructions are no longer installed in target memory
they're stale in the code cache. Easily confirmed by just disabling
the code cache:
(gdb) set code-cache off
(gdb) disass main
Dump of assembler code for function main:
0x000000000040053c <+0>: push %rbp
0x000000000040053d <+1>: mov %rsp,%rbp
=> 0x0000000000400540 <+4>: movl $0x1,-0x4(%rbp)
0x0000000000400547 <+11>: movl $0x2,-0x4(%rbp)
0x000000000040054e <+18>: mov $0x0,%eax
0x0000000000400553 <+23>: pop %rbp
0x0000000000400554 <+24>: retq
End of assembler dump.
I stumbled upon this when writing a patch to infrun.c, that made
handle_inferior_event & co fill in the cache before breakpoints were
removed from the target. Recall that wait_for_inferior flushes the
dcache for every event. So in that case, always-inserted mode was not
necessary to trigger this. It's just a convenient way to expose the
issue.
The dcache works at the raw memory level. We need to update it
whenever memory is written, no matter what kind of target memory
object was originally passed down by the caller. The issue is that
the dcache update code isn't reached when a caller explicitly writes
raw memory. Breakpoint insertion/removal is one such case --
mem-break.c uses target_write_read_memory/target_write_raw_memory.
The fix is to move the dcache update code from memory_xfer_partial_1
to raw_memory_xfer_partial so that it's always reachable.
When we do that, we can actually simplify a series of things.
memory_xfer_partial_1 no longer needs to handle writes for any kind of
memory object, and therefore dcache_xfer_memory no longer needs to
handle writes either. So the latter (dcache_xfer_memory) and its
callees can be simplified to only care about reads. While we're
touching dcache_xfer_memory's prototype, might as well rename it to
reflect that fact that it only handles reads, and make it follow the
new target_xfer_status/xfered_len style. This made me notice that
dcache_xfer_memory loses the real error status if a memory read fails:
we could have failed to read due to TARGET_XFER_E_UNAVAILABLE, for
instance, but we always return TARGET_XFER_E_IO, hence the FIXME note.
I felt that fixing that fell out of the scope of this patch.
Currently dcache_xfer_memory handles the case of a write failing. The
whole cache line is invalidated when that happens. However,
dcache_update, the sole mechanism for handling writes that will remain
after the patch, does not presently handle that scenario. That's a
bug. The patch makes it handle that, by passing down the
target_xfer_status status from the caller, so that it can better
decide what to do itself. While I was changing the function's
prototype, I constified the myaddr parameter, getting rid of the need
for the cast as seen in its existing caller.
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/
2014-03-05 Pedro Alves <palves@redhat.com>
PR gdb/16575
* dcache.c (dcache_poke_byte): Constify ptr parameter. Return
void. Update comment.
(dcache_xfer_memory): Delete.
(dcache_read_memory_partial): New, based on the read bits of
dcache_xfer_memory.
(dcache_update): Add status parameter. Use ULONGEST for len, and
adjust. Discard cache lines if the reason for the update was
error.
* dcache.h (dcache_xfer_memory): Delete declaration.
(dcache_read_memory_partial): New declaration.
(dcache_update): Update prototype.
* target.c (raw_memory_xfer_partial): Update the dcache here.
(memory_xfer_partial_1): Don't handle dcache writes here.
gdb/testsuite/
2014-03-05 Pedro Alves <palves@redhat.com>
PR gdb/16575
* gdb.base/breakpoint-shadow.exp (compare_disassembly): New
procedure.
(top level): Adjust to use it. Add tests that exercise breakpoint
interaction with the code-cache.
Starting with DWARF version 4, the description of the DW_AT_high_pc
attribute was amended to say:
if it is of class constant, the value is an unsigned integer offset
which when added to the low PC gives the address of the first
location past the last instruction associated with the entity.
A change was made in Apr 27th, 2012 to reflect that change:
| commit 91da14142c
| Author: Mark Wielaard <mjw@redhat.com>
| Date: Fri Apr 27 18:55:19 2012 +0000
|
| * dwarf2read.c (dwarf2_get_pc_bounds): Check DW_AT_high_pc form to
| see whether it is an address or a constant offset from DW_AT_low_pc.
| (dwarf2_record_block_ranges): Likewise.
| (read_partial_die): Likewise.
Unfortunately, this new interpretation is now used regardless of
the CU's DWARF version. It turns out that one of WindRiver's compilers
(FTR: Diabdata 4.4) is generating DWARF version 2 info with
DW_AT_high_pc attributes improperly using the data4 form. Because of
that, we miscompute all high PCs incorrectly. This leads to a lot of
symtabs having overlapping ranges, which in turn causes havoc in
pc-to-symtab-and-line translations.
One visible effect is when inserting a breakpoint on a given function:
(gdb) b world
Breakpoint 1 at 0x4005c4
The source location of the breakpoint is missing. The output should be:
(gdb) b world
Breakpoint 1 at 0x4005c8: file dw2-rel-hi-pc-world.c, line 24.
What happens in this case is that the pc-to-SAL translation first
starts be trying to find the symtab associated to our PC using
each symtab's ranges. Because of the high_pc miscomputation,
many symtabs end up matching, and the heuristic trying to select
the most probable one unfortunately returns one that is unrelated
(it really had no change in this case to do any better). Once we
have the wrong symtab, the start searching the associated linetable,
where the addresses are correct, thus finding no match, and therefore
no SAL.
This patch is an attempt at handling the situation as gracefully
as we can, without guarantees. It introduces a new function
"attr_value_as_address" which uses the correct accessor for getting
the value of a given attribute. It then adjust the code throughout
this unit to use this function instead of assuming that addresses always
have the DW_FORM_addr format.
It also fixes the original issue of miscomputing the high_pc
by limiting the new interpretation of constant form DW_AT_high_pc
attributes to units using DWARF version 4 or later.
gdb/ChangeLog:
* dwarf2read.c (attr_value_as_address): New function.
(dwarf2_find_base_address, read_call_site_scope): Use
attr_value_as_address in place of DW_ADDR.
(dwarf2_get_pc_bounds): Use attr_value_as_address to get
the low and high addresses. Slight rework of the handling
of the high pc being a constant form, and limit it to
DWARF verson 4 or higher.
(dwarf2_record_block_ranges): Likewise.
(read_partial_die): Likewise.
(new_symbol_full): Use attr_value_as_address in place of DW_ADDR.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-abs-hi-pc-hello-dbg.S: New file.
* gdb.dwarf2/dw2-abs-hi-pc-hello.c: New file.
* gdb.dwarf2/dw2-abs-hi-pc-world-dbg.S: New file.
* gdb.dwarf2/dw2-abs-hi-pc-world.c: New file.
* gdb.dwarf2/dw2-abs-hi-pc.c: New file.
* gdb.dwarf2/dw2-abs-hi-pc.exp: New file.
Tested on x86_64-linux.
Consider the following type for which we would like to provide
a pretty-printer and manage it via RegexpCollectionPrettyPrinter:
typedef long time_t;
Currently, this does not work because this framework only considers
the type's tag name:
typename = gdb.types.get_basic_type(val.type).tag
if not typename:
return None
This patch extends it to use the type's name if the basic type
does not have a tag name, thus allowing the framework to also
work with typedefs like the above.
gdb/ChangeLog:
* python/lib/gdb/printing.py (RegexpCollectionPrettyPrinter):
Use the type's name if its basic type does not have a tag.
gdb/testsuite/ChangeLog:
* testsuite/gdb.python/py-pp-re-notag.c: New file.
* testsuite/gdb.python/py-pp-re-notag.ex: New file.
* testsuite/gdb.python/py-pp-re-notag.p: New file.
Consider the following Ada code:
-- An array whose index is an enumeration type with 128 enumerators.
type Enum_T is (Enum_000, Enum_001, [...], Enum_128);
type Table is array (Enum_T) of Boolean;
When the compiler is configured to generate pure DWARF debugging info,
trying to print type Table's description yields:
ptype pck.table
type = array (enum_000 .. -128) of boolean
The expected output was:
ptype pck.table
type = array (enum_000 .. enum_128) of boolean
The DWARF debugging info for our array looks like this:
<1><44>: Abbrev Number: 5 (DW_TAG_array_type)
<45> DW_AT_name : pck__table
<50> DW_AT_type : <0x28>
<2><54>: Abbrev Number: 6 (DW_TAG_subrange_type)
<55> DW_AT_type : <0x5c>
<59> DW_AT_lower_bound : 0
<5a> DW_AT_upper_bound : 128
The array index type is, by construction with the DWARF standard,
a subrange of our enumeration type, defined as follow:
<2><5b>: Abbrev Number: 0
<1><5c>: Abbrev Number: 7 (DW_TAG_enumeration_type)
<5d> DW_AT_name : pck__enum_t
<69> DW_AT_byte_size : 1
<2><6b>: Abbrev Number: 8 (DW_TAG_enumerator)
<6c> DW_AT_name : pck__enum_000
<7a> DW_AT_const_value : 0
[etc]
Therefore, while processing these DIEs, the array index type ends
up being a TYPE_CODE_RANGE whose target type is our enumeration type.
But the problem is that we read the upper bound as a negative value
(-128), which is then used as is by the type printer to print the
array upper bound. This negative value explains the "-128" in the
output.
To understand why the range type's upper bound is read as a negative
value, one needs to look at how it is determined, in read_subrange_type:
orig_base_type = die_type (die, cu);
base_type = check_typedef (orig_base_type);
[... high is first correctly read as 128, but then ...]
if (!TYPE_UNSIGNED (base_type) && (high & negative_mask))
high |= negative_mask;
The negative_mask is applied, here, because BASE_TYPE->FLAG_UNSIGNED
is not set. And the reason for that is because the base_type was only
partially constructed during the call to die_type. While the enum
is constructed on the fly by read_enumeration_type, its flag_unsigned
flag is only set later on, while creating the symbols corresponding to
the enum type's enumerators (see process_enumeration_scope), after
we've already finished creating our range type - and therefore too
late.
My first naive attempt at fixing this problem consisted in extracting
the part in process_enumeration_scope which processes all enumerators,
to generate the associated symbols, but more importantly set the type's
various flags when necessary. However, this does not always work well,
because we're still in the subrange_type's scope, and it might be
different from the scope where the enumeration type is defined.
So, instead, what this patch does to fix the issue is to extract
from process_enumeration_scope the part that determines whether
the enumeration type should have the flag_unsigned and/or the
flag_flag_enum flags set. It turns out that, aside from the code
implementing the loop, this part is fairly independent of the symbol
creation. With that part extracted, we can then use it at the end
of our enumeration type creation, to produce a type which should now
no longer need any adjustment.
Once the enumeration type produced is correctly marked as unsigned,
the subrange type's upper bound is then correctly read as an unsigned
value, therefore giving us an upper bound of 128 instead of -128.
gdb/ChangeLog:
* dwarf2read.c (update_enumeration_type_from_children): New
function, mostly extracted from process_structure_scope.
(read_enumeration_type): Call update_enumeration_type_from_children.
(process_enumeration_scope): Do not set THIS_TYPE's flag_unsigned
and flag_flag_enum fields.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/arr-subrange.c, gdb.dwarf2/arr-subrange.exp: New files.
Consider the following declarations in Ada...
type Item is range -32 .. 31;
for Item'Size use 6;
type Table is array (Natural range 0 .. 4) of Item;
pragma Pack (Table);
... which declare a packed array whose elements are 6 bits long.
The debugger currently does not notice that the array is packed,
and thus prints values of this type incorrectly. This can be seen
in the "ptype" output:
(gdb) ptype table
type = array (0 .. 4) of foo.item
Normally, the debugger should print:
(gdb) ptype table
type = array (0 .. 4) of foo.item <packed: 6-bit elements>
The debugging information for this array looks like this:
.uleb128 0xf # (DIE (0x15c) DW_TAG_array_type)
.long .LASF9 # DW_AT_name: "pck__table"
.byte 0x6 # DW_AT_bit_stride
.long 0x1a9 # DW_AT_type
.uleb128 0x10 # (DIE (0x16a) DW_TAG_subrange_type)
.long 0x3b # DW_AT_type
.byte 0 # DW_AT_lower_bound
.byte 0x4 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x15c
The interesting part is the DW_AT_bit_stride attribute, which tells
the size of the array elements is 6 bits, rather than the normal
element type's size.
This patch adds support for this attribute by first creating
gdbtypes.c::create_array_type_with_stride, which is an enhanced
version of create_array_type taking an extra parameter as the stride.
The old create_array_type can then be re-implemented very simply
by calling the new create_array_type_with_stride.
We can then use this new function from dwarf2read, to create
arrays with or without stride.
gdb/ChangeLog:
* gdbtypes.h (create_array_type_with_stride): Add declaration.
* gdbtypes.c (create_array_type_with_stride): New function,
renaming create_array_type, but with an added parameter
called "bit_stride".
(create_array_type): Re-implement using
create_array_type_with_stride.
* dwarf2read.c (read_array_type): Add support for DW_AT_byte_stride
and DW_AT_bit_stride attributes.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/arr-stride.c: New file.
* gdb.dwarf2/arr-stride.exp: New file.
The test, relying purely on generating an assembly file, only
verifies the type description of our array. But I was also
able to verify manually that the debugger print values of these
types correctly as well (which was not the case prior to this
patch).
With the test changed as in the patch, against current mainline, we get:
(gdb) PASS: gdb.ada/tasks.exp: info tasks before inserting breakpoint
break break_me task 1
Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 1
break break_me task 3
Note: breakpoint 2 also set at pc 0x4030b0.
Breakpoint 3 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
continue
Continuing.
[Switching to Thread 0x7ffff7dc7700 (LWP 27133)]
Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
27 null;
(gdb) FAIL: gdb.ada/tasks.exp: continue to breakpoint
info tasks
ID TID P-ID Pri State Name
1 63b010 48 Waiting on RV with 3 main_task
2 63bd80 1 48 Accept or Select Term task_list(1)
* 3 63f510 1 48 Accepting RV with 1 task_list(2)
4 642ca0 1 48 Accept or Select Term task_list(3)
(gdb) PASS: gdb.ada/tasks.exp: info tasks after hitting breakpoint
The breakpoint that caused a stop is breakpoint 3, but GDB end up
reporting (and running breakpoint commands of) "Breakpoint 2" instead.
The issue is that the bpstat_check_breakpoint_conditions logic of
"wrong thread" is missing the "wrong task" check. This is usually
harmless, because the thread hop code in infrun.c code that handles
wrong-task-hitting-breakpoint does check for task-specific breakpoints
(within breakpoint_thread_match):
/* Check if a regular breakpoint has been hit before checking
for a potential single step breakpoint. Otherwise, GDB will
not see this breakpoint hit when stepping onto breakpoints. */
if (regular_breakpoint_inserted_here_p (aspace, stop_pc))
{
if (!breakpoint_thread_match (aspace, stop_pc, ecs->ptid))
thread_hop_needed = 1;
}
IOW, usually, when one only has a task specific breakpoint at a given
address, things work correctly. Put another task-specific or
non-task-specific breakpoint there, and things break.
A patch that eliminates the special thread hop code in infrun.c is
what exposed this, as after that GDB solely relies on
bpstat_check_breakpoint_conditions to know whether the right or wrong
task hit a breakpoint. IOW, given the latent bug, Ada task-specific
breakpoints become non-task-specific, and that is caught by the
testsuite, as:
break break_me task 3
Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
continue
Continuing.
[Switching to Thread 0x7ffff7fcb700 (LWP 17122)]
Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
27 null;
(gdb) PASS: gdb.ada/tasks.exp: continue to breakpoint
info tasks
ID TID P-ID Pri State Name
1 63b010 48 Waiting on RV with 2 main_task
* 2 63bd80 1 48 Accepting RV with 1 task_list(1)
3 63f510 1 48 Accept or Select Term task_list(2)
4 642ca0 1 48 Accept or Select Term task_list(3)
(gdb) FAIL: gdb.ada/tasks.exp: info tasks after hitting breakpoint
It was after seeing this that I thought of how to expose the bug with
current mainline.
Tested on x86_64 Fedora 17.
gdb/
2014-02-26 Pedro Alves <palves@redhat.com>
* breakpoint.c (bpstat_check_breakpoint_conditions): Handle
task-specific breakpoints.
gdb/testsuite/
2014-02-26 Pedro Alves <palves@redhat.com>
* gdb.ada/tasks.exp: Set a task-specific breakpoint at break_me
that won't ever trigger. Make sure that GDB reports the correct
breakpoint that caused the stop.
Fix auto-load 7.7 regression,
the regression affects any loading from /usr/share/gdb/auto-load .
5b2bf9471f is the first bad commit
commit 5b2bf9471f
Author: Doug Evans <xdje42@gmail.com>
Date: Fri Nov 29 21:29:26 2013 -0800
Move .debug_gdb_script processing to auto-load.c.
Simplify handling of auto-loaded objfile scripts.
Fedora 20 x86_64
$ gdb -q /usr/lib64/libgobject-2.0.so
Reading symbols from /usr/lib64/libglib-2.0.so.0.3800.2...Reading symbols from
/usr/lib/debug/usr/lib64/libglib-2.0.so.0.3800.2.debug...done.
done.
(gdb) _
Fedora Rawhide x86_64
$ gdb -q /usr/lib64/libgobject-2.0.so
Reading symbols from /usr/lib64/libglib-2.0.so...Reading symbols from
/usr/lib/debug/usr/lib64/libglib-2.0.so.0.3990.0.debug...done.
done.
warning: File "/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py" auto-loading has been declined by your `auto-load safe-path'
set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py".
To enable execution of this file add
add-auto-load-safe-path /usr/lib64/libglib-2.0.so.0.3990.0-gdb.py
line to your configuration file "/home/jkratoch/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/jkratoch/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
(gdb) _
That is it tries to load "forbidden"
/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py
but it should load instead
/usr/share/gdb/auto-load/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py*
Although that is also not exactly this way, there does not exist any
/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py
despite regressed GDB says so.
gdb/
2014-02-24 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/16626
* auto-load.c (auto_load_objfile_script_1): Change filename to
debugfile.
gdb/testsuite/
2014-02-24 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/16626
* gdb.base/auto-load-script: New file.
* gdb.base/auto-load.c: New file.
* gdb.base/auto-load.exp: New file.
Message-ID: <20140223212400.GA8831@host2.jankratochvil.net>
I realized that the name of this test only made sense when considering
the old (never committed) implementation of the fix that came along
with the test originally, that forced a schedlock while a step-resume
(to get over the signal handler) was inserted. The final solution
that went into the tree does not force that locking.
So this renames it to something more descriptive.
gdb/testsuite/
2014-02-21 Pedro Alves <palves@redhat.com>
* gdb.threads/step-after-sr-lock.c: Rename to ...
* gdb.threads/signal-while-stepping-over-bp-other-thread.c: ... this.
* gdb.threads/step-after-sr-lock.exp: Rename to ...
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
... this.
This is the continuation of what Joel proposed on:
<https://sourceware.org/ml/gdb-patches/2013-12/msg00977.html>
Now that I have already submitted and pushed the patch to split
i386_stap_parse_special_token into two smaller functions, it is indeed
simpler to understand this patch.
It occurs because, on x86, triplet displacement operands are allowed
(like "-4+8-20(%rbp)"), and the current parser for this expression is
buggy. It does not correctly extract the register name from the
expression, which leads to incorrect evaluation. The parser was also
being very "generous" with the expression, so I included a few more
checks to ensure that we're indeed dealing with a triplet displacement
operand.
This patch also includes testcases for the two different kind of
expressions that can be encountered on x86: the triplet displacement
(explained above) and the three-argument displacement (as in
"(%rbx,%ebx,-8)"). The tests are obviously arch-dependent and are
placed under gdb.arch/.
Message-ID: <m3mwj1j12v.fsf@redhat.com>
URL: <https://sourceware.org/ml/gdb-patches/2014-01/msg00310.html>
gdb/
2014-02-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR tdep/16397
* i386-tdep.c (i386_stap_parse_special_token_triplet): Check if a
number comes after the + or - signs. Adjust length of register
name to be extracted.
gdb/testsuite/
2014-02-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR tdep/16397
* gdb.arch/amd64-stap-special-operands.exp: New file.
* gdb.arch/amd64-stap-three-arg-disp.S: Likewise.
* gdb.arch/amd64-stap-three-arg-disp.c: Likewise.
* gdb.arch/amd64-stap-triplet.S: Likewise.
* gdb.arch/amd64-stap-triplet.c: Likewise.
The arm-elf assembler chokes on the extra parameters in the .section
pseudo-op, so this patch removes them.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-icycle.S: Remove second and third parameters
in .section pseudo-op.
* dwarf2read.c (struct die_info): New member in_process.
(reset_die_in_process): New function.
(process_die): Set it at the start, reset when returning.
(inherit_abstract_dies): Only call process_die if origin_child_die
not already being processed.
testsuite/
* gdb.dwarf2/dw2-icycle.S: New file.
* gdb.dwarf2/dw2-icycle.c: New file.
* gdb.dwarf2/dw2-icycle.exp: New file.
* NEWS: Add entry for the new feature
* python/py-value.c (valpy_binop): Call value_x_binop for struct
and class values.
testsuite/
* gdb.python/py-value-cc.cc: Improve test case to enable testing
operations on gdb.Value objects.
* gdb.python/py-value-cc.exp: Add new test to test operations on
gdb.Value objects.
doc/
* python.texi (Values From Inferior): Add description about the
new feature.
* Makefile.in (TESTS): New variable.
(expanded_tests, expanded_tests_or_none): New variables
(check-single): Pass $(expanded_tests_or_none) to runtest.
(check-parallel): Only run tests in $(TESTS) if non-empty.
(check/no-matching-tests-found): New rule.
* README: Document TESTS makefile variable.
If GDB has crashed then gdb_spawn_id still exists (although it does not work).
So my patch does not change anything. And also currently it will leave the
stale gdbserver running anyway.
In general if gdb_spawn_id does not exist then send_gdb + gdb_expect just do
not make sense anyway. So this patch just prevents the error in such case.
The killing of stale gdbserver could be improved multiple ways (also as
suggested by Pedro in the original thread) but that is IMO outside of the
scope of this patch. Apparently if there is no good response from GDB then
gdb_finish() should try to call gdb_start just to kill that gdbserver, IIUC.
gdb/testsuite/
2014-02-16 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix "ERROR: no fileid for" in the testsuite.
* lib/gdb.exp (gdb_finish): Check gdb_spawn_id.
Message-ID: <20140206205814.GA18495@host2.jankratochvil.net>
* gdb.dwarf2/Makefile.in (EXECUTABLES): Add dwp-symlink.
(MISCELLANEOUS): New variable.
(clean): rm -rf $(MISCELLANEOUS).
* gdb.dwarf2/dwp-symlink.exp: Test the case where the executable and
dwp live in the same directory as symlinks, with each symlink pointed
to a differently named file in a different directory.
Consider the following code:
type Color is (Black, Red, Green, Blue, White);
type Primary_Table is array (Color range Red .. Blue) of Boolean;
Prim : Primary_Table := (True, False, False);
GDB prints the length of arrays in a fairly odd way:
(gdb) p prim'length
$2 = blue
The length returned should be an integer, not the array index type,
and this patch fixes this.
gdb/ChangeLog:
* ada-lang.c (ada_evaluate_subexp): Set the type of the value
returned by the 'Length attribute to integer.
testsuite/ChangeLog:
* gdb.ada/tick_length_array_enum_idx: New testcase.
Tests in gdb.gdb fail because directory gdb/testsuite/gdb.gdb doesn't
exist in build tree. This patch appends gdb.gdb/Makefile in AC_OUTPUT,
and adds new Makefile.in in gdb.gdb, so that directory gdb.gdb can be
created during configure.
With this patch applied, tests under gdb.gdb can be run,
$ make check RUNTESTFLAGS='--directory=gdb.gdb'
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ../../../../git/gdb/testsuite/config/unix.exp as tool-and-target-specific interface file.
Running ../../../../git/gdb/testsuite/gdb.gdb/complaints.exp ...
Running ../../../../git/gdb/testsuite/gdb.gdb/observer.exp ...
Running ../../../../git/gdb/testsuite/gdb.gdb/python-interrupts.exp ...
FAIL: gdb.gdb/python-interrupts.exp: signal SIGINT
Running ../../../../git/gdb/testsuite/gdb.gdb/python-selftest.exp ...
FAIL: gdb.gdb/python-selftest.exp: call catch_command_errors(execute_command, "python print 5", 0, RETURN_MASK_ALL)
Running ../../../../git/gdb/testsuite/gdb.gdb/selftest.exp ...
Running ../../../../git/gdb/testsuite/gdb.gdb/xfullpath.exp ...
=== gdb Summary ===
gdb/testsuite:
2014-02-10 Yao Qi <yao@codesourcery.com>
PR testsuite/16543
* configure.ac: Append gdb.gdb/Makefile in AC_OUTPUT.
* configure: Regenerated.
* Makefile.in: New file.
As design, =breakpoint-modified isn't emitted when breakpoints are modified
by MI commands. This patch is to add tests for this.
gdb/testsuite:
2014-02-08 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-breakpoint-changed.exp (test_insert_delete_modify): Test
that no =breakpoint-modified is emitted when breakpoints are
modified through MI commands.
Say:
<stopped at a breakpoint in thread 2>
(gdb) thread 3
(gdb) step
The above triggers the prepare_to_proceed/deferred_step_ptid process,
which switches back to thread 2, to step over its breakpoint before
getting back to thread 3 and "step" it.
If while stepping over the breakpoint in thread 2, a signal arrives,
and it is set to pass/nostop, we'll set a step-resume breakpoint at
the supposed signal-handler resume address, and call keep_going. The
problem is that we were supposedly stepping thread 3, and that
keep_going delivers a signal to thread 2, and due to scheduler-locking
off, resumes everything else, _including_ thread 3, the thread we want
stepping. This means that we lose control of thread 3 until the next
event, when we stop everything. The end result for the user, is that
GDB lost control of the "step".
Here's the current infrun debug output of the above, with the testcase
in the patch below:
infrun: clear_proceed_status_thread (Thread 0x2aaaab8f5700 (LWP 11663))
infrun: clear_proceed_status_thread (Thread 0x2aaaab6f4700 (LWP 11662))
infrun: clear_proceed_status_thread (Thread 0x2aaaab4f2b20 (LWP 11659))
infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1)
infrun: prepare_to_proceed (step=1), switched to [Thread 0x2aaaab6f4700 (LWP 11662)]
infrun: resume (step=1, signal=0), trap_expected=1, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)],
infrun: status->kind = stopped, signal = SIGUSR1
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40098f
infrun: random signal 30
Program received signal SIGUSR1, User defined signal 1.
infrun: signal arrived while stepping over breakpoint
infrun: inserting step-resume breakpoint at 0x40098f
infrun: resume (step=0, signal=30), trap_expected=0, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f
^^^ this is a wildcard resume.
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40098f
infrun: BPSTAT_WHAT_STEP_RESUME
infrun: resume (step=1, signal=0), trap_expected=1, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f
^^^ step-resume hit, meaning the handler returned, so we go back to stepping thread 3.
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40088b
infrun: switching back to stepped thread
infrun: Switching context from Thread 0x2aaaab6f4700 (LWP 11662) to Thread 0x2aaaab8f5700 (LWP 11663)
infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x2aaaab8f5700 (LWP 11663)] at 0x400938
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab8f5700 (LWP 11663)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40093a
infrun: keep going
infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x2aaaab8f5700 (LWP 11663)] at 0x40093a
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab8f5700 (LWP 11663)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40091e
infrun: stepped to a different line
infrun: stop_stepping
[Switching to Thread 0x2aaaab8f5700 (LWP 11663)]
69 (*myp) ++; /* set breakpoint child_two here */
^^^ we stopped at the wrong line. We still stepped a bit because the
test is running in a loop, and when we got back to stepping thread 3,
it happened to be in the stepping range. (The loop increments a
counter, and the test makes sure it increments exactly once. Without
the fix, the counter increments a bunch, since the user-stepped thread
runs free without GDB noticing.)
The fix is to switch to the stepping thread before continuing for the
step-resume breakpoint.
gdb/
2014-02-07 Pedro Alves <palves@redhat.com>
* infrun.c (handle_signal_stop) <signal arrives while stepping
over a breakpoint>: Switch back to the stepping thread.
gdb/testsuite/
2014-02-07 Pedro Alves <pedro@codesourcery.com>
Pedro Alves <palves@redhat.com>
* gdb.threads/step-after-sr-lock.c: New file.
* gdb.threads/step-after-sr-lock.exp: New file.
Currently on software single-step Linux targets we get:
(gdb) PASS: gdb.threads/stepi-random-signal.exp: before stepi: get hexadecimal valueof "$pc"
stepi
infrun: clear_proceed_status_thread (Thread 0x7ffff7fca700 (LWP 7073))
infrun: clear_proceed_status_thread (Thread 0x7ffff7fcb740 (LWP 7069))
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 7069)] at 0x400700
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 7069 [Thread 0x7ffff7fcb740 (LWP 7069)],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400704
infrun: software single step trap for Thread 0x7ffff7fcb740 (LWP 7069)
infrun: stepi/nexti
infrun: stop_stepping
44 while (counter != 0)
(gdb) FAIL: gdb.threads/stepi-random-signal.exp: stepi (no random signal)
Vs hardware-step targets:
(gdb) PASS: gdb.threads/stepi-random-signal.exp: before stepi: get hexadecimal valueof "$pc"
stepi
infrun: clear_proceed_status_thread (Thread 0x7ffff7fca700 (LWP 9565))
infrun: clear_proceed_status_thread (Thread 0x7ffff7fcb740 (LWP 9561))
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 9561)] at 0x400700
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 9561 [Thread 0x7ffff7fcb740 (LWP 9561)],
infrun: status->kind = stopped, signal = GDB_SIGNAL_CHLD
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400700
infrun: random signal (GDB_SIGNAL_CHLD)
infrun: random signal, keep going
infrun: resume (step=1, signal=GDB_SIGNAL_CHLD), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 9561)] at 0x400700
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 9561 [Thread 0x7ffff7fcb740 (LWP 9561)],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400704
infrun: stepi/nexti
infrun: stop_stepping
44 while (counter != 0)
(gdb) PASS: gdb.threads/stepi-random-signal.exp: stepi
The test turns on infrun debug, does a stepi while a SIGCHLD is
pending, and checks whether the "random signal" paths in infrun.c are
taken.
On the software single-step variant above, those paths were not taken.
This is a test bug.
The Linux backend short-circuits reporting signals that are set to
pass/nostop/noprint. But _only_ if the thread is _not_
single-stepping. So on hardware-step targets, even though the signal
is set to pass/nostop/noprint by default, the thread is indeed told to
single-step, and so the core sees the signal. On the other hand, on
software single-step architectures, the backend never actually gets a
single-step request (steps are emulated by setting a breakpoint at the
next pc, and then the target told to continue, not step). So the
short-circuiting code triggers and the core doesn't see the signal.
The fix is to make the test be sure the target doesn't bypass
reporting the signal to the core.
Tested on x86_64 Fedora 17, both with and without a series that
implements software single-step for x86_64.
gdb/testsuite/
2014-02-07 Pedro Alves <palves@redhat.com>
* gdb.threads/stepi-random-signal.exp: Set SIGCHLD to print.
gdb/testsuite/
2014-02-06 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix i386-sse-stack-align.exp regression since GDB_PARALLEL.
* gdb.arch/i386-sse-stack-align.exp: Use standard_output_file.
* configure.ac (libpython checking): Remove all but python.o from
CONFIG_OBS. Remove all but python.c from CONFIG_SRCS.
* configure: Regenerate.
* Makefile.in (SFILES): Add extension.c.
(HFILES_NO_SRCDIR): Add extension.h, extension-priv.h
(COMMON_OBS): Add extension.o.
* extension.h: New file.
* extension-priv.h: New file.
* extension.c: New file.
* python/python-internal.h: #include "extension.h".
(gdbpy_auto_load_enabled): Declare.
(gdbpy_apply_val_pretty_printer): Declare.
(gdbpy_apply_frame_filter): Declare.
(gdbpy_preserve_values): Declare.
(gdbpy_breakpoint_cond_says_stop): Declare.
(gdbpy_breakpoint_has_cond): Declare.
(void source_python_script_for_objfile): Delete.
* python/python.c: #include "extension-priv.h".
Delete inclusion of "observer.h".
(extension_language_python): Moved here and renamed from
script_language_python in py-auto-load.c.
Redefined to be of type extension_language_defn.
(python_extension_script_ops): New global.
(python_extension_ops): New global.
(struct python_env): New member previous_active.
(restore_python_env): Call restore_active_ext_lang.
(ensure_python_env): Call set_active_ext_lang.
(gdbpy_clear_quit_flag): Renamed from clear_quit_flag, made static.
New arg extlang.
(gdbpy_set_quit_flag): Renamed from set_quit_flag, made static.
New arg extlang.
(gdbpy_check_quit_flag): Renamed from check_quit_flag, made static.
New arg extlang.
(gdbpy_eval_from_control_command): Renamed from
eval_python_from_control_command, made static. New arg extlang.
(gdbpy_source_script) Renamed from source_python_script, made static.
New arg extlang.
(gdbpy_before_prompt_hook): Renamed from before_prompt_hook. Change
result to int. New arg extlang.
(gdbpy_source_objfile_script): Renamed from
source_python_script_for_objfile, made static. New arg extlang.
(gdbpy_start_type_printers): Renamed from start_type_printers, made
static. New args extlang, extlang_printers. Change result type to
"void".
(gdbpy_apply_type_printers): Renamed from apply_type_printers, made
static. New arg extlang. Rename arg printers to extlang_printers
and change type to ext_lang_type_printers *.
(gdbpy_free_type_printers): Renamed from free_type_printers, made
static. Replace argument arg with extlang, extlang_printers.
(!HAVE_PYTHON, eval_python_from_control_command): Delete.
(!HAVE_PYTHON, source_python_script): Delete.
(!HAVE_PYTHON, gdbpy_should_stop): Delete.
(!HAVE_PYTHON, gdbpy_breakpoint_has_py_cond): Delete.
(!HAVE_PYTHON, start_type_printers): Delete.
(!HAVE_PYTHON, apply_type_printers): Delete.
(!HAVE_PYTHON, free_type_printers): Delete.
(_initialize_python): Delete call to observer_attach_before_prompt.
(finalize_python): Set/restore active extension language.
(gdbpy_finish_initialization) Renamed from
finish_python_initialization, made static. New arg extlang.
(gdbpy_initialized): New function.
* python/python.h: #include "extension.h". Delete #include
"value.h", "mi/mi-cmds.h".
(extension_language_python): Declare.
(GDBPY_AUTO_FILE_NAME): Delete.
(enum py_bt_status): Moved to extension.h and renamed to
ext_lang_bt_status.
(enum frame_filter_flags): Moved to extension.h.
(enum py_frame_args): Moved to extension.h and renamed to
ext_lang_frame_args.
(finish_python_initialization): Delete.
(eval_python_from_control_command): Delete.
(source_python_script): Delete.
(apply_val_pretty_printer): Delete.
(apply_frame_filter): Delete.
(preserve_python_values): Delete.
(gdbpy_script_language_defn): Delete.
(gdbpy_should_stop, gdbpy_breakpoint_has_py_cond): Delete.
(start_type_printers, apply_type_printers, free_type_printers): Delete.
* auto-load.c: #include "extension.h".
(GDB_AUTO_FILE_NAME): Delete.
(auto_load_gdb_scripts_enabled): Make public. New arg extlang.
(script_language_gdb): Delete, moved to extension.c and renamed to
extension_language_gdb.
(source_gdb_script_for_objfile): Delete.
(auto_load_pspace_info): New member unsupported_script_warning_printed.
(loaded_script): Change type of language member to
struct extension_language_defn *.
(init_loaded_scripts_info): Initialize
unsupported_script_warning_printed.
(maybe_add_script): Make static. Change type of language arg to
struct extension_language_defn *.
(clear_section_scripts): Reset unsupported_script_warning_printed.
(auto_load_objfile_script_1): Rewrite to use extension language API.
(auto_load_objfile_script): Make public. Remove support-compiled-in
and auto-load-enabled checks, moved to auto_load_scripts_for_objfile.
(source_section_scripts): Rewrite to use extension language API.
(load_auto_scripts_for_objfile): Rewrite to use
auto_load_scripts_for_objfile.
(collect_matching_scripts_data): Change type of language member to
struct extension_language_defn *.
(auto_load_info_scripts): Change type of language arg to
struct extension_language_defn *.
(unsupported_script_warning_print): New function.
(script_not_found_warning_print): Make static.
(_initialize_auto_load): Rewrite construction of scripts-directory
help.
* auto-load.h (struct objfile): Add forward decl.
(struct script_language): Delete.
(struct auto_load_pspace_info): Add forward decl.
(struct extension_language_defn): Add forward decl.
(maybe_add_script): Delete.
(auto_load_objfile_script): Declare.
(script_not_found_warning_print): Delete.
(auto_load_info_scripts): Update prototype.
(auto_load_gdb_scripts_enabled): Declare.
* python/py-auto-load.c (gdbpy_auto_load_enabled): Renamed from
auto_load_python_scripts_enabled and made public.
(script_language_python): Delete, moved to python.c.
(gdbpy_script_language_defn): Delete.
(info_auto_load_python_scripts): Update to use
extension_language_python.
* breakpoint.c (condition_command): Replace call to
gdbpy_breakpoint_has_py_cond with call to get_breakpoint_cond_ext_lang.
(bpstat_check_breakpoint_conditions): Replace call to gdbpy_should_stop
with call to breakpoint_ext_lang_cond_says_stop.
* python/py-breakpoint.c (gdbpy_breakpoint_cond_says_stop): Renamed
from gdbpy_should_stop. Change result type to enum scr_bp_stop.
New arg slang. Return SCR_BP_STOP_UNSET if py_bp_object is NULL.
(gdbpy_breakpoint_has_cond): Renamed from gdbpy_breakpoint_has_py_cond.
New arg slang.
(local_setattro): Print name of extension language with existing
stop condition.
* valprint.c (val_print, value_print): Update to call
apply_ext_lang_val_pretty_printer.
* cp-valprint.c (cp_print_value): Update call to
apply_ext_lang_val_pretty_printer.
* python/py-prettyprint.c: Remove #ifdef HAVE_PYTHON.
(gdbpy_apply_val_pretty_printer): Renamed from
apply_val_pretty_printer. New arg extlang.
(!HAVE_PYTHON, apply_val_pretty_printer): Delete.
* cli/cli-cmds.c (source_script_from_stream): Rewrite to use
extension language API.
* cli/cli-script.c (execute_control_command): Update to call
eval_ext_lang_from_control_command.
* mi/mi-cmd-stack.c (mi_cmd_stack_list_frames): Update to use
enum ext_lang_bt_status values. Update call to
apply_ext_lang_frame_filter.
(mi_cmd_stack_list_locals): Ditto.
(mi_cmd_stack_list_args): Ditto.
(mi_cmd_stack_list_variables): Ditto.
* mi/mi-main.c: Delete #include "python/python-internal.h".
Add #include "extension.h".
(mi_cmd_list_features): Replace reference to python internal variable
gdb_python_initialized with call to ext_lang_initialized_p.
* stack.c (backtrace_command_1): Update to use enum ext_lang_bt_status.
Update to use enum ext_lang_frame_args. Update to call
apply_ext_lang_frame_filter.
* python/py-framefilter.c (extract_sym): Update to use enum
ext_lang_bt_status.
(extract_value, py_print_type, py_print_value): Ditto.
(py_print_single_arg, enumerate_args, enumerate_locals): Ditto.
(py_mi_print_variables, py_print_locals, py_print_args): Ditto.
(py_print_frame): Ditto.
(gdbpy_apply_frame_filter): Renamed from apply_frame_filter.
New arg extlang. Update to use enum ext_lang_bt_status.
* top.c (gdb_init): Delete #ifdef HAVE_PYTHON call to
finish_python_initialization. Replace with call to
finish_ext_lang_initialization.
* typeprint.c (do_free_global_table): Update to call
free_ext_lang_type_printers.
(create_global_typedef_table): Update to call
start_ext_lang_type_printers.
(find_global_typedef): Update to call apply_ext_lang_type_printers.
* typeprint.h (struct ext_lang_type_printers): Add forward decl.
(type_print_options): Change type of global_printers from "void *"
to "struct ext_lang_type_printers *".
* value.c (preserve_values): Update to call preserve_ext_lang_values.
* python/py-value.c: Remove #ifdef HAVE_PYTHON.
(gdbpy_preserve_values): Renamed from preserve_python_values.
New arg extlang.
(!HAVE_PYTHON, preserve_python_values): Delete.
* utils.c (quit_flag): Delete, moved to extension.c.
(clear_quit_flag, set_quit_flag, check_quit_flag): Delete, moved to
extension.c.
* eval.c: Delete #include "python/python.h".
* main.c: Delete #include "python/python.h".
* defs.h: Update comment.
testsuite/
* gdb.python/py-breakpoint.exp (test_bkpt_eval_funcs): Update expected
output.
* gdb.gdb/python-interrupts.exp: New file.
This patch creates inferior when GDB opens a ctf trace data, to be
consistent with tfile target. A test case is added to test for
live target, tfile and ctf target.
gdb:
2014-02-05 Yao Qi <yao@codesourcery.com>
* ctf.c: Include "inferior.h" and "gdbthread.h".
(CTF_PID): A new macro.
(ctf_open): Call inferior_appeared and add_thread_silent.
(ctf_close): Call exit_inferior_silent and set inferior_ptid.
(ctf_thread_alive): New function.
(init_ctf_ops): Install ctf_thread_alive to to_thread_alive.
gdb/testsuite:
2014-02-05 Yao Qi <yao@codesourcery.com>
* gdb.trace/report.exp (use_collected_data): Test the output
of "info threads" and "info inferiors".
When a trace file is loaded in Eclipse, it is expected to see thread
and process (=thread-group-started and =thread-created). Create an
inferior and add a thread for this purpose.
This patch just reverts my previous patch.
gdb/testsuite:
2014-02-05 Yao Qi <yao@codesourcery.com>
Revert this patch:
2013-05-24 Yao Qi <yao@codesourcery.com>
* gdb.trace/tfile.exp: Test inferior and thread.
gdb:
2014-02-05 Yao Qi <yao@codesourcery.com>
Revert this patch:
2013-05-24 Yao Qi <yao@codesourcery.com>
* tracepoint.c (TFILE_PID): Remove.
(tfile_open): Don't add thread and inferior.
(tfile_close): Don't set 'inferior_ptid'. Don't call
exit_inferior_silent.
(tfile_thread_alive): Remove.
(init_tfile_ops): Don't set field 'to_thread_alive' of
tfile_ops.
This patch handles another aspect of the ELFv2 ABI, which unfortunately
requires common code changes.
In ELFv2, functions may provide both a global and a local entry point.
The global entry point (where the function symbol points to) is intended
to be used for function-pointer or cross-module (PLT) calls, and requires
r12 to be set up to the entry point address itself. The local entry
point (which is found at a fixed offset after the global entry point,
as defined by bits in the symbol table entries' st_other field), instead
expects r2 to be set up to the current TOC.
Now, when setting a breakpoint on a function by name, you really want
that breakpoint to trigger either way, no matter whether the function
is called via its local or global entry point. Since the global entry
point will always fall through into the local entry point, the way to
achieve that is to simply set the breakpoint at the local entry point.
One way to do that would be to have prologue parsing skip the code
sequence that makes up the global entry point. Unfortunately, this
does not work reliably, since -for optimized code- GDB these days
will not actuall invoke the prologue parsing code but instead just
set the breakpoint at the symbol address and rely on DWARF being
correct at any point throughout the function ...
Unfortunately, I don't really see any way to express the notion of
local entry points with the current set of gdbarch callbacks.
Thus this patch adds a new callback, skip_entrypoint, that is
somewhat analogous to skip_prologue, but is called every time
GDB needs to determine a function start address, even in those
cases where GDB decides to not call skip_prologue.
As a side effect, the skip_entrypoint implementation on ppc64
does not need to perform any instruction parsing; it can simply
rely on the local entry point flags in the symbol table entry.
With this implemented, two test cases would still fail to set
the breakpoint correctly, but that's because they use the construct:
gdb_test "break *hello"
Now, using "*hello" explicitly instructs GDB to set the breakpoint
at the numerical value of "hello" treated as function pointer, so
it will by definition only hit the global entry point.
I think this behaviour is unavoidable, but acceptable -- most people
do not use this construct, and if they do, they get what they
asked for ...
In one of those two test cases, use of this construct is really
not appropriate. I think this was added way back when as a means
to work around prologue skipping problems on some platforms. These
days that shouldn't really be necessary any more ...
For the other (step-bt), we really want to make sure backtracing
works on the very first instruction of the routine. To enable that
test also on powerpc64le-linux, we can modify the code to call the
test function via function pointer (which makes it use the global
entry point in the ELFv2 ABI).
gdb/ChangeLog:
* gdbarch.sh (skip_entrypoint): New callback.
* gdbarch.c, gdbarch.h: Regenerate.
* symtab.c (skip_prologue_sal): Call gdbarch_skip_entrypoint.
* infrun.c (fill_in_stop_func): Likewise.
* ppc-linux-tdep.c: Include "elf/ppc64.h".
(ppc_elfv2_elf_make_msymbol_special): New function.
(ppc_elfv2_skip_entrypoint): Likewise.
(ppc_linux_init_abi): Install them for ELFv2.
gdb/testsuite/ChangeLog:
* gdb.base/sigbpt.exp: Do not use "*" when setting breakpoint
on a function.
* gdb.base/step-bt.c: Call hello via function pointer to make
sure its first instruction is executed on powerpc64le-linux.
The powerpc64le-linux ABI specifies that when a 128-bit DFP value is
passed in a pair of floating-point registers, the first register holds
the most-significant part of the value. This is as opposed to the
usual rule on little-endian systems, where the first register would
hold the least-significant part.
This affects two places in GDB, the read/write routines for the
128-bit DFP pseudo-registers, and the function call / return
sequence. For the former, current code already distinguishes
between big- and little-endian targets, but gets the latter
wrong. This is presumably because *GCC* also got it wrong,
and GDB matches the old GCC behavior. But GCC is now fixed:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02145.html
so GDB needs to be fixed too. (Old code shouldn't really be
an issue since there is no code "out there" so far that uses
dfp128 on little-endian ...)
gdb/ChangeLog:
* ppc-sysv-tdep.c (ppc64_sysv_abi_push_freg): Use correct order
within a register pair holding a DFP 128-bit value on little-endian.
(ppc64_sysv_abi_return_value_base): Likewise.
* rs6000-tdep.c (dfp_pseudo_register_read): Likewise.
(dfp_pseudo_register_write): Likewise.
gdb/testsuite/ChangeLog:
* gdb.arch/powerpc-d128-regs.exp: Enable on powerpc64*-*.
Many VSX test were failing on powerpc64le-linux, since -as opposed to the
AltiVec tests- there never were little-endian versions of the test patterns.
This patch adds such patterns, along the lines of altivec-regs.exp.
In addition, there is an actual code change required: For those VSX
registers that overlap a floating-point register, the FP register
overlaps the most-significant half of the VSX register both on big-
and little-endian systems. However, on little-endian systems, that
half is stored at an offset of 8 bytes (not 0). This works already
for the "real" FP registers, but current code gets it wrong for
the "extended" pseudo FP register GDB generates for the second
half of the VSX register bank.
This patch updates the corresponding pseudo read/write routines
to take the appropriate offset into consideration.
gdb/ChangeLog:
* rs6000-tdep.c (efpr_pseudo_register_read): Use correct offset
of the overlapped FP register within the VSX register on little-
endian platforms.
(efpr_pseudo_register_write): Likewise.
gdb/testsuite/ChangeLog:
* gdb.arch/vsx-regs.exp: Check target endianness. Provide variants
of the test patterns for use on little-endian systems.
A couple of AltiVec tests fail spuriously on powerpc64le-linux, because
they compare against an incorrect pattern. Note that those tests already
contain little-endian variants of the patterns, but those seem to have
bit-rotted a bit: when outputting a vector, GDB no longer omits trailing
zero elements (as it used to do in the past).
This patch updates the pattern to the new GDB output behavior.
In addition, the patch updates the endian test to use the new
gdb_test_multiple logic instead of gdb_expect.
gdb/testsuite/ChangeLog:
* gdb.arch/altivec-regs.exp: Use gdb_test_multiple for endian test.
(decimal_vector): Fix for little-endian.
breakpoint is set in a `ta 0x6d´ which is not a sigreturn syscall. In
these cases no rt_frame exists in the stack and thus the read PC is
wrong.
ChangeLog
2014-01-29 Jose E. Marchesi <jose.marchesi@oracle.com>
* sparc64-linux-tdep.c (sparc64_linux_step_trap): Get PC from
the sigreturn register save area only if the syscall is
sigreturn.
testsuite/ChangeLog
2014-01-29 Jose E. Marchesi <jose.marchesi@oracle.com>
* gdb.arch/sparc-sysstep.exp: New file.
* gdb.arch/sparc-sysstep.c: Likewise.
* gdb.arch/Makefile.in (EXECUTABLES): Add sparc-sysstep.
type Char_Table is array (Character range Character'First .. Character'Last)
of Natural;
Trying to print the type description of this type currently yields:
(gdb) ptype char_table
type = array ('["00"]' .. '["ff"]') of natural
Although technically correct, it seemed more useful to print the array
range as:
(gdb) ptype char_table
type = array (character) of natural
This patch implements this suggestion.
gdb/ChangeLog:
* ada-typeprint (type_is_full_subrange_of_target_type):
New function.
(print_range): Add parameter bounds_prefered_p. If not set,
try printing range types using the name of their base type.
(print_range_type): Add parameter bounds_prefered_p.
Use it in call to print_range.
(print_array_type, ada_print_type): Update calls to print_range
and print_range_type.
gdb/testsuite/ChangeLog:
* gdb.ada/array_char_idx: New testcase.
This fixes PR python/16487.
The bug here is that the function-name-handling code in py_print_frame
had a small logic error (really a misplaced closing brace). This
error could lead to a Py_DECREF(NULL), which crashes.
This patch fixes the bug in the obvious way.
Built and regtested on x86-64 Fedora 18. New test case included.
2014-01-23 Tom Tromey <tromey@redhat.com>
PR python/16487:
* python/py-framefilter.c (py_print_frame): Don't call Py_DECREF
on a NULL pointer. Move "goto error" to correct place.
2014-01-23 Tom Tromey <tromey@redhat.com>
PR python/16487:
* gdb.python/py-framefilter.exp: Add test using "Error" filter.
* gdb.python/py-framefilter.py (ErrorInName, ErrorFilter): New
classes.
apply_frame_filter calls ensure_python_env before computing the
gdbarch to use. This means that python_gdbarch can be NULL while in
Python code, and if a frame filter depends on this somehow (easy to
do), gdb will crash.
The fix is to compute the gdbarch first.
Built and regtested on x86-64 Fedora 18.
New test case included.
2014-01-23 Tom Tromey <tromey@redhat.com>
PR python/16491:
* python/py-framefilter.c (apply_frame_filter): Call
ensure_python_env after computing gdbarch.
2014-01-23 Tom Tromey <tromey@redhat.com>
PR python/16491:
* gdb.python/py-framefilter.py (Reverse_Function.function): Read a
string from an inferior frame.
* gdb.python/py-framefilter-mi.exp: Update.
* syscalls/s390x-linux.xml: New file.
* syscalls/s390-linux.xml: New file.
* s390-linux-tdep.c (XML_SYSCALL_FILENAME_S390): New macro.
(XML_SYSCALL_FILENAME_S390X): Likewise.
(op_svc): New enum value for SVC opcode.
(s390_sigtramp_frame_sniffer): Replace literal by 'op_svc'.
(s390_linux_get_syscall_number): New function.
(s390_gdbarch_init): Register '*get_syscall_number' and the
syscall xml file name.
* data-directory/Makefile.in (SYSCALLS_FILES): Add
"s390-linux.xml" and "s390x-linux.xml".
* NEWS: Announce new feature.
gdb/testsuite/ChangeLog:
* gdb.base/catch-syscall.exp: Activate test on s390*-linux.
The trace-specific test case 'entry-values' concludes fairly late in
the process that this platform doesn't support trace. Before that,
there are some platform specifics that don't work on s390x. The fix
addresses two aspects:
(1) Removal of an excess space character in the regex for the
disassembly. This is needed when there is a function alignment
gap, because then the hex address is immediately followed by a
colon, like in the first 'nopr' line below:
(gdb) disassemble foo+50,+10
Dump of assembler code from 0x32 to 0x3c:
0x0000000000000032 <foo+50>: br %r4
0x0000000000000034: nopr %r7
0x0000000000000036: nopr %r7
0x0000000000000038 <bar+0>: stmg %r11,%r15,88(%r15)
End of assembler dump.
(2) Handling for the s390-specific call instruction.
gdb/testsuite/ChangeLog:
* gdb.trace/entry-values.exp: Remove excess space character from
regex patterns. Handle s390 call instruction.
On ppc64-linux a function symbol does not point to code, but to the
function descriptor. Thus the previous change for this test case
broke it:
https://sourceware.org/ml/gdb-patches/2014-01/msg00275.html
This patch reverts to the original method, re-introducing '_start'
symbols. In addition, it adds sufficient alignment before the label,
such that the label never points into an alignment gap.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-dir-file-name.c (FUNC): Insert alignment and
define "*_start" label. Make "name" static.
* gdb.dwarf2/dw2-dir-file-name.exp: Replace references to
${name} by references to ${name}_start.
When upstream gcc is given a command line with the "-g" option after
"-g3", it doesn't generate a ".debug_macro" section. This is because
the last option wins, thus downgrading the debug level again. Without
any macro debug information in the executable, info-macros.exp
obviously produces many failures.
Since the "-g" option is appended by DejaGnu's target_compile whenever
the "debug" option is set, the fix just removes that option.
gdb/testsuite/ChangeLog:
* gdb.base/info-macros.exp: Remove "debug" from the compile
options.
Provide to_resume and to_wait target methods for the btrace record target
to allow reverse stepping and replay support.
Replay is limited in the sense that only stepping and source correlation
are supported. We do not record data and thus can not show variables.
Non-stop mode is not working. Do not allow record-btrace in non-stop mode.
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* btrace.h (btrace_thread_flag): New.
(struct btrace_thread_info) <flags>: New.
* record-btrace.c (record_btrace_resume_thread)
(record_btrace_find_thread_to_move, btrace_step_no_history)
(btrace_step_stopped, record_btrace_start_replaying)
(record_btrace_step_thread, record_btrace_decr_pc_after_break)
(record_btrace_find_resume_thread): New.
(record_btrace_resume, record_btrace_wait): Extend.
(record_btrace_can_execute_reverse): New.
(record_btrace_open): Fail in non-stop mode.
(record_btrace_set_replay): Split into this, ...
(record_btrace_stop_replaying): ... this, ...
(record_btrace_clear_histories): ... and this.
(init_record_btrace_ops): Init to_can_execute_reverse.
* NEWS: Announce it.
testsuite/
* gdb.btrace/delta.exp: Check reverse stepi.
* gdb.btrace/tailcall.exp: Update. Add stepping tests.
* gdb.btrace/finish.exp: New.
* gdb.btrace/next.exp: New.
* gdb.btrace/nexti.exp: New.
* gdb.btrace/record_goto.c: Add comments.
* gdb.btrace/step.exp: New.
* gdb.btrace/stepi.exp: New.
* gdb.btrace/multi-thread-step.c: New.
* gdb.btrace/multi-thread-step.exp: New.
* gdb.btrace/rn-dl-bind.c: New.
* gdb.btrace/rn-dl-bind.exp: New.
* gdb.btrace/data.c: New.
* gdb.btrace/data.exp: New.
* gdb.btrace/Makefile.in (EXECUTABLES): Add new.
doc/
* gdb.texinfo: Document limited reverse/replay support
for target record-btrace.
The btrace record target shows the branch trace from the location of the first
branch destination. This is the first BTS records.
After adding incremental updates, we can now add a dummy record for the current
PC when we enable tracing so we show the trace from the location where branch
tracing has been enabled.
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* btrace.c: Include regcache.h.
(btrace_add_pc): New.
(btrace_enable): Call btrace_add_pc.
(btrace_is_empty): New.
* btrace.h (btrace_is_empty): New.
* record-btrace.c (require_btrace, record_btrace_info): Call
btrace_is_empty.
testsuite/
* gdb.btrace/Makefile.in (EXECUTABLES): Add delta.
* gdb.btrace/exception.exp: Update.
* gdb.btrace/instruction_history.exp: Update.
* gdb.btrace/record_goto.exp: Update.
* gdb.btrace/tailcall.exp: Update.
* gdb.btrace/unknown_functions.exp: Update.
* gdb.btrace/delta.exp: New.
Extend the always failing unwinder to provide the PC based on the call
structure detected in the branch trace.
The unwinder supports normal frames and tailcall frames.
Inline frames are not supported.
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* record.h (record_btrace_frame_unwind)
(record_btrace_tailcall_frame_unwind): New declarations.
* dwarf2-frame: Include record.h
(dwarf2_frame_cfa): Throw an error for btrace frames.
* record-btrace.c: Include hashtab.h.
(btrace_get_bfun_name): New.
(btrace_call_history): Call btrace_get_bfun_name.
(struct btrace_frame_cache): New.
(bfcache): New.
(bfcache_hash, bfcache_eq, bfcache_new): New.
(btrace_get_frame_function): New.
(record_btrace_frame_unwind_stop_reason): Allow unwinding.
(record_btrace_frame_this_id): Compute own id.
(record_btrace_frame_prev_register): Provide PC, throw_error
for all other registers.
(record_btrace_frame_sniffer): Detect btrace frames.
(record_btrace_tailcall_frame_sniffer): New.
(record_btrace_frame_dealloc_cache): New.
(record_btrace_frame_unwind): Add new functions.
(record_btrace_tailcall_frame_unwind): New.
(_initialize_record_btrace): Allocate cache.
* btrace.c (btrace_clear): Call reinit_frame_cache.
* NEWS: Announce it.
testsuite/
* gdb.btrace/record_goto.exp: Add backtrace test.
* gdb.btrace/tailcall.exp: Add backtrace test.
The "record function-call-history" and "record instruction-history" commands
accept a range "begin, end". End is not included in both cases. Include it.
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* record-btrace.c (record_btrace_insn_history_range): Include
end.
(record_btrace_insn_history_from): Adjust range.
(record_btrace_call_history_range): Include
end.
(record_btrace_call_history_from): Adjust range.
* NEWS: Announce changes.
testsuite/
* gdb.btrace/function_call_history.exp: Update tests.
* gdb.btrace/instruction_history.exp: Update tests.
doc/
* gdb.texinfo (Process Record and Replay): Update documentation.
Add a new modifier /c to the "record function-call-history" command to
indent the function name based on its depth in the call stack.
Also reorder the optional fields to have the indentation at the very beginning.
Prefix the insn range (/i modifier) with "inst ".
Prefix the source line (/l modifier) with "at ".
Change the range syntax from "begin-end" to "begin,end" to allow copy&paste to
the "record instruction-history" and "list" commands.
Adjust the respective tests and add new tests for the /c modifier.
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* record.h (enum record_print_flag)
<record_print_indent_calls>: New.
* record.c (get_call_history_modifiers): Recognize /c modifier.
(_initialize_record): Document /c modifier.
* record-btrace.c (btrace_call_history): Add btinfo parameter.
Reorder fields. Optionally indent the function name. Update
all users.
* NEWS: Announce changes.
testsuite/
* gdb.btrace/function_call_history.exp: Fix expected field
order for "record function-call-history".
Add new tests for "record function-call-history /c".
* gdb.btrace/exception.cc: New.
* gdb.btrace/exception.exp: New.
* gdb.btrace/tailcall.exp: New.
* gdb.btrace/x86-tailcall.S: New.
* gdb.btrace/x86-tailcall.c: New.
* gdb.btrace/unknown_functions.c: New.
* gdb.btrace/unknown_functions.exp: New.
* gdb.btrace/Makefile.in (EXECUTABLES): Add new.
doc/
* gdb.texinfo (Process Record and Replay): Document new /c
modifier accepted by "record function-call-history".
Add /i modifier to "record function-call-history" example.
The record instruction-history and record-function-call-history commands start
counting instructions at zero. This is somewhat unintuitive when we start
navigating in the recorded instruction history. Start at one, instead.
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* btrace.c (ftrace_new_function): Start counting at one.
* record-btrace.c (record_btrace_info): Adjust number of calls
and insns.
* NEWS: Announce it.
testsuite/
* gdb.btrace/instruction_history.exp: Update.
* gdb.btrace/function_call_history.exp: Update.
The branch trace is represented as 3 vectors:
- a block vector
- a instruction vector
- a function vector
Each vector (except for the first) is computed from the one above.
Change this into a graph where a node represents a sequence of instructions
belonging to the same function and where we have three types of edges to connect
the function segments:
- control flow
- same function (instance)
- call stack
This allows us to navigate in the branch trace. We will need this for "record
goto" and reverse execution.
This patch introduces the data structure and computes the control flow edges.
It also introduces iterator structs to simplify iterating over the branch trace
in control-flow order.
It also fixes PR gdb/15240 since now recursive calls are handled correctly.
Fix the test that got the number of expected fib instances and also the
function numbers wrong.
The current instruction had been part of the branch trace. This will look odd
once we start support for reverse execution. Remove it. We still keep it in
the trace itself to allow extending the branch trace more easily in the future.
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* btrace.h (struct btrace_func_link): New.
(enum btrace_function_flag): New.
(struct btrace_inst): Rename to ...
(struct btrace_insn): ...this. Update all users.
(struct btrace_func) <ibegin, iend>: Remove.
(struct btrace_func_link): New.
(struct btrace_func): Rename to ...
(struct btrace_function): ...this. Update all users.
(struct btrace_function) <segment, flow, up, insn, insn_offset)
(number, level, flags>: New.
(struct btrace_insn_iterator): Rename to ...
(struct btrace_insn_history): ...this.
Update all users.
(struct btrace_insn_iterator, btrace_call_iterator): New.
(struct btrace_target_info) <btrace, itrace, ftrace>: Remove.
(struct btrace_target_info) <begin, end, level>
<insn_history, call_history>: New.
(btrace_insn_get, btrace_insn_number, btrace_insn_begin)
(btrace_insn_end, btrace_insn_prev, btrace_insn_next)
(btrace_insn_cmp, btrace_find_insn_by_number, btrace_call_get)
(btrace_call_number, btrace_call_begin, btrace_call_end)
(btrace_call_prev, btrace_call_next, btrace_call_cmp)
(btrace_find_function_by_number, btrace_set_insn_history)
(btrace_set_call_history): New.
* btrace.c (btrace_init_insn_iterator)
(btrace_init_func_iterator, compute_itrace): Remove.
(ftrace_print_function_name, ftrace_print_filename)
(ftrace_skip_file): Change
parameter to const.
(ftrace_init_func): Remove.
(ftrace_debug): Use new btrace_function fields.
(ftrace_function_switched): Also consider gaining and
losing symbol information).
(ftrace_print_insn_addr, ftrace_new_call, ftrace_new_return)
(ftrace_new_switch, ftrace_find_caller, ftrace_new_function)
(ftrace_update_caller, ftrace_fixup_caller, ftrace_new_tailcall):
New.
(ftrace_new_function): Move. Remove debug print.
(ftrace_update_lines, ftrace_update_insns): New.
(ftrace_update_function): Check for call, ret, and jump.
(compute_ftrace): Renamed to ...
(btrace_compute_ftrace): ...this. Rewritten to compute call
stack.
(btrace_fetch, btrace_clear): Updated.
(btrace_insn_get, btrace_insn_number, btrace_insn_begin)
(btrace_insn_end, btrace_insn_prev, btrace_insn_next)
(btrace_insn_cmp, btrace_find_insn_by_number, btrace_call_get)
(btrace_call_number, btrace_call_begin, btrace_call_end)
(btrace_call_prev, btrace_call_next, btrace_call_cmp)
(btrace_find_function_by_number, btrace_set_insn_history)
(btrace_set_call_history): New.
* record-btrace.c (require_btrace): Use new btrace thread
info fields.
(record_btrace_info, btrace_insn_history)
(record_btrace_insn_history, record_btrace_insn_history_range):
Use new btrace thread info fields and new iterator.
(btrace_func_history_src_line): Rename to ...
(btrace_call_history_src_line): ...this. Use new btrace
thread info fields.
(btrace_func_history): Rename to ...
(btrace_call_history): ...this. Use new btrace thread info
fields and new iterator.
(record_btrace_call_history, record_btrace_call_history_range):
Use new btrace thread info fields and new iterator.
testsuite/
* gdb.btrace/function_call_history.exp: Fix expected function
trace.
* gdb.btrace/instruction_history.exp: Initialize traced.
Remove traced_functions.
For testing multi-line test output, gdb.btrace tests used the following
pattern:
gdb_test "..." "
...\r
..."
Change this to:
gdb_test "..." [join [list \
"..." \
"..."] "\r\n"]
Also extract repeated tests into a test function and shorten or remove
test messages.
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
testsuite/
* gdb.btrace/function_call_history.exp: Update
* gdb.btrace/instruction_history.exp: Update.
The error message for starting recording twice changed.
Update the expected text to fix resulting regressions.
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/enable.exp: Update expected text.
This test currently fails on ARM:
(gdb) PASS: gdb.dwarf2/dw2-dos-drive.exp: set breakpoint pending off
break 'z:file.c':func
Cannot access memory at address 0x0
The error is GDB trying to read the prologue at the breakpoint's
address, and failing:
38 throw_error() exceptions.c:444 0x0016728c
37 memory_error() corefile.c:204 0x001d1fcc
36 read_memory() corefile.c:223 0x001d201a
35 read_memory_unsigned_integer() corefile.c:312 0x001d2166
34 arm_skip_prologue() arm-tdep.c:1452 0x00054270
static CORE_ADDR
arm_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR pc)
{
...
for (skip_pc = pc; skip_pc < limit_pc; skip_pc += 4)
{
inst = read_memory_unsigned_integer (skip_pc, 4, byte_order_for_code);
The test doesn't execute the compiled object's code, so GDB will try
to read memory from the binary's sections. Instructions on ARM are
4-byte wide, and thus ARM's prologue scanner reads in 4-byte chunks.
As the section 'func' is put at is only 1 byte long, and no other
section is allocated contiguously:
...
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000001 00000000 00000000 00000034 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
...
... the exec target fails the read the 4 bytes.
Fix this by increasing the function's size.
gdb/testsuite/ChangeLog:
2014-01-16 Omair Javaid <Omair.Javaid@linaro.org>
* gdb.dwarf2/dw2-dos-drive.S: Increase text section size to 4
bytes.
PR python/15464
PR python/16113
* valops.c (value_struct_elt_bitpos): New function
* py-type.c (convert_field): Set 'name' attribute of a gdb.Field
object to 'None' if the field name is an empty string ("").
* python/py-value.c (valpy_getitem): Use 'bitpos' and 'type'
attribute to look for a field when 'name' is 'None'.
(get_field_type): New function
testsuite/
* gdb.python/py-type.c: Enhance test case.
* gdb.python/py-value-cc.cc: Likewise
* gdb.python/py-type.exp: Add new tests.
* gdb.python/py-value-cc.exp: Likewise
S390, the dw2-dir-file-name test case fails in the first
gdb_continue_to_breakpoint. Indeed, the breakpoint is now placed into
the alignment gap *before* the actual function.
This happens because the test case declares the respective "*_start"
symbol as a "loose" label before the function definition, and the
compiler inserts the alignment between that label and the function
itself.
The "*_start" symbols were only necessary because FUNC made the
function static. The fix makes the functions extern instead, thus
making the "*_start" labels unnecessary.
testsuite/
2014-01-10 Andreas Arnez <arnez@linux.vnet.ibm.com>
Pedro Alves <palves@redhat.com>
* gdb.dwarf2/dw2-dir-file-name.c (FUNC): Remove "*_start" symbol.
Make "name" extern.
* gdb.dwarf2/dw2-dir-file-name.exp (out_cu, out_line): Replace
references to ${name}_start by references to ${name}.
A live target is required for `-info-os' to work in non-native
configurations.
(gdb)
Expecting: ^(-info-os[
]+)?(.*\^done,OSDataTable=.*[
]+[(]gdb[)]
[ ]*)
-info-os
^error,msg="Don't know how to get OS data. Try \"help target\"."
(gdb)
FAIL: gdb.mi/mi-info-os.exp: -info-os
If GDB does have a native configuration included, but we're testing
remote, it'll be worse, as if we're not connected yet, -info-os will
run against the default run target, and pass, falsely giving the
impression the remote bits were exercised.
gdb/testsuite/
2014-01-09 Maciej W. Rozycki <macro@codesourcery.com>
Pedro Alves <palves@redhat.com>
* gdb.mi/mi-info-os.exp: Connect to the target with
mi_gdb_target_load.
Currently, when GDB connects in all-stop mode, GDBserver always
responds to the status packet with a GDB_SIGNAL_TRAP, even if the
program is actually stopped for some other signal.
(gdb) tar rem ...
...
(gdb) c
Program received signal SIGUSR1, User defined signal 1.
(gdb) disconnect
(gdb) tar rem ...
(gdb) c
(Or a GDB crash instead of an explicit disconnect.)
This results in the program losing that signal on that last continue,
because gdb will tell the target to resume with no signal (to suppress
the GDB_SIGNAL_TRAP, due to 'handle SISGTRAP nopass'), and that will
actually suppress the real signal the program had stopped for
(SIGUSR1). To fix that, I think we should make GDBserver report the
real signal the thread had stopped for in response to the status
packet:
@item ?
@cindex @samp{?} packet
Indicate the reason the target halted. The reply is the same as for
step and continue.
But, that raises the question -- which thread are we reporting the
status for? Due to how the RSP in all-stop works, we can only report
one status. The status packet's response is a stop reply packet, so
it includes the thread identifier, so it's not a problem packet-wise.
However, GDBserver is currently always reporting the status for first
thread in the thread list, even though that may well not be the thread
that got the signal that caused the program to stop. So the next
logical step would be to report the status for the
last_ptid/last_status thread (the last event reported to gdb), if it's
still around; and if not, fallback to some other thread.
There's an issue on the GDB side with that, though...
GDB currently always adds the thread reported in response to the
status query as the first thread in its list. That means that if we
start with e.g.,
(gdb) info threads
3 Thread 1003 ...
* 2 Thread 1002 ...
1 Thread 1001 ...
And reconnect:
(gdb) disconnect
(gdb) tar rem ...
We end up with:
(gdb) info threads
3 Thread 1003 ...
2 Thread 1001 ...
* 1 Thread 1002 ...
Not a real big issue, but it's reasonably fixable, by having GDB
fetch/sync the thread list before fetching the status/'?', and then
using the status to select the right thread as current on the GDB
side. Holes in the thread numbers are squashed before/after
reconnection (e.g., 2,3,5 becomes 1,2,3), but the order is preserved,
which I think is both good, and good enough.
However (yes, there's more...), the previous GDB that was connected
might have had gdbserver running in non-stop mode, or could have left
gdbserver doing disconnected tracing (which also forces non-stop), and
if the new gdb/connection is in all-stop mode, we can end up with more
than one thread with a signal to report back to gdb. As we can only
report one thread/status (in the all-stop RSP variant; the non-stop
variant doesn't have this issue), we get to do what we do at every
other place we have this situation -- leave events we can't report
right now as pending, so that the next resume picks them up.
Note all this ammounts to a QoI change, within the existing framework.
There's really no RSP change here.
The only user visible change (other than that the signal is program is
stopped at isn't lost / is passed to the program), is in "info
program", that now can show the signal the program stopped for. Of
course, the next resume will respect the pass/nopass setting for the
signal in question. It'd be reasonable to have the initial connection
tell the user the program was stopped with a signal, similar to when
we load a core to debug, but I'm leaving that out for a future change.
I think we'll need to either change how handle_inferior_event & co
handle stop_soon, or maybe bypass them completely (like
fork-child.c:startup_inferior) for that.
Tested on x86_64 Fedora 17.
gdb/gdbserver/
2014-01-08 Pedro Alves <palves@redhat.com>
* gdbthread.h (struct thread_info) <status_pending_p>: New field.
* server.c (visit_actioned_threads, handle_pending_status): New
function.
(handle_v_cont): Factor out parts to ...
(resume): ... this new function. If in all-stop, and a thread
being resumed has a pending status, report it without actually
resuming.
(myresume): Adjust to use the new 'resume' function.
(clear_pending_status_callback, set_pending_status_callback)
(find_status_pending_thread_callback): New functions.
(handle_status): Handle the case of multiple threads having
interesting statuses to report. Report threads' real last signal
instead of always reporting GDB_SIGNAL_TRAP. Look for a thread
with an interesting thread to report the status for, instead of
always reporting the status of the first thread.
gdb/
2014-01-08 Pedro Alves <palves@redhat.com>
* remote.c (remote_add_thread): Add threads silently if starting
up.
(remote_notice_new_inferior): If in all-stop, and starting up,
don't call notice_new_inferior.
(get_current_thread): New function, factored out from ...
(add_current_inferior_and_thread): ... this. Adjust.
(remote_start_remote) <all-stop>: Fetch the thread list. If we
found any thread, then select the remote's current thread as GDB's
current thread too.
gdb/testsuite/
2014-01-08 Pedro Alves <palves@redhat.com>
* gdb.threads/reconnect-signal.c: New file.
* gdb.threads/reconnect-signal.exp: New file.
gdb/ChangeLog:
2014-01-07 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
* source.c (add_path): Fix check for duplicated paths in the previously
included paths.
gdb/testsuite/ChangeLog:
2014-01-07 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/source-dir.exp: New file.
Consider the following code:
type Element is abstract tagged null record;
type GADataType is interface;
type Data_Type is new Element and GADataType with record
I : Integer := 42;
end record;
Result1 : Data_Type;
GGG1 : GADataType'Class := GADataType'Class (Result1);
When trying to create a varobj for variable ggg1, GDB currently
returns an object which has no child:
-var-create ggg1 * ggg1
^done,name="ggg1",numchild="0",[...]
This is incorrect, it should return an object which has one child
(field "i"). This is because tagged-type objects are dynamic, and
we need to apply a small transformation in order to get their actual
type. This is already done on the GDB/CLI side in ada-valprint,
and it needs to be done on the ada-varobj side as well.
gdb/ChangeLog:
* ada-varobj.c (ada_varobj_adjust_for_child_access): Convert
tagged type objects to their actual type.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_interface: New testcase.
Consider the following types:
type Time_T is record
Secs : Integer;
end record;
Before : Time_T := (Secs => 1384395743);
In this example, we assume that type Time_T is the number of seconds
since Epoch, and so added a Python pretty-printer, to print this
type in a more human-friendly way. For instance:
(gdb) print before
$1 = Thu Nov 14 02:22:23 2013 (1384395743)
However, we've noticed that things stop working when this type is
embedded inside another record, and we try to print that record.
For instance, with the following declarations:
type Composite is record
Id : Integer;
T : Time_T;
end record;
Afternoon : Composite := (Id => 1, T => (Secs => 1384395865));
(gdb) print afternoon
$2 = (id => 1, t => (secs => 1384395865))
We expected instead:
(gdb) print afternoon
$2 = (id => 1, t => Thu Nov 14 02:24:25 2013 (1384395865))
This patch fixes the problem by making sure that we try to print
each field via a call to val_print, rather than calling ada_val_print
directly. We need to go through val_print, as the val_print
handles all language-independent features such as calling the
pretty-printer, knowing that ada_val_print will get called eventually
if actual Ada-specific printing is required (which should be the
most common scenario).
And because val_print takes the language as parameter, we enhanced
the print_field_values and print_variant_part to also take a language.
As a bonus, this allows us to remove a couple of references to
current_language.
gdb/ChangeLog:
* ada-valprint.c (print_field_values): Add "language" parameter.
Update calls to print_field_values and print_variant_part.
Pass new parameter "language" in call to val_print instead
of "current_language". Replace call to ada_val_print by call
to val_print.
(print_variant_part): Add "language" parameter.
(ada_val_print_struct_union): Update call to print_field_values.
gdb/testsuite/ChangeLog:
* gdb.ada/pp-rec-component.exp, gdb.ada/pp-rec-component.py,
gdb.ada/pp-rec-component/foo.adb, gdb.ada/pp-rec-component/pck.adb,
gdb.ada/pp-rec-component/pck.ads: New files.
Consider the following declarations:
typedef long our_time_t;
our_time_t current_time = 1384395743;
The purpose of this patch is to allow the use of a pretty-printer
for variables of type our_time_t. Normally, pretty-printing sniffers
use the tag name in order to determine which, if any, pretty-printer
should be used. But in the case above, the tag name is not set, since
it does not apply to integral types.
This patch extends the gdb.Type list of attributes to also include
the name of the type, thus allowing the sniffer to match against
that name. With that change, I was able to write a pretty-printer
which displays our variable as follow:
(gdb) print current_time
$1 = Thu Nov 14 02:22:23 2013 (1384395743)
gdb/ChangeLog:
* python/py-type.c (typy_get_name): New function.
(type_object_getset): Add entry for attribute "name".
* NEWS: Add entry mentioning this new attribute.
gdb/doc/ChangeLog:
* gdb.texinfo (Types In Python): Document new attribute Types.name.
gdb/testsuite:
* gdb.python/py-pp-integral.c: New file.
* gdb.python/py-pp-integral.py: New file.
* gdb.python/py-pp-integral.exp: New file.
Tested on x86_64-linux.
Code rationale
==============
by: Gabriel Krisman Bertazi
This is a fix for bug 16297. The problem occurs when the user attempts
to catch any syscall 0 (such as syscall read on Linux/x86_64). GDB was
not able to catch the syscall and was missing the breakpoint.
Now, breakpoint_hit_catch_syscall returns immediately when it finds the
correct syscall number, avoiding a following check for the end of the
search vector, that returns a no hit if the syscall number was zero.
Testcase rationale
==================
by: Sergio Durigan Junior
This testcase is a little difficult to write. By doing a quick
inspection at the Linux source, one can see that, in many targets, the
syscall number 0 is restart_syscall, which is forbidden to be called
from userspace. Therefore, on many targets, there's just no way to test
this safely.
My decision was to take the simpler route and just adds the "read"
syscall on the default test. Its number on x86_64 is zero, which is
"good enough" since many people here do their tests on x86_64 anyway and
it is a popular architecture.
However, there was another little gotcha. When using "read" passing 0
as the third parameter (i.e., asking it to read 0 bytes), current libc
implementations could choose not to effectively call the syscall.
Therefore, the best solution was to create a temporary pipe, write 1
byte into it, and then read this byte from it.
gdb/ChangeLog
2013-12-19 Gabriel Krisman Bertazi <gabriel@krisman.be>
PR breakpoints/16297
* breakpoint.c (breakpoint_hit_catch_syscall): Return immediately
when expected syscall is hit.
gdb/testsuite/ChangeLog
2013-12-19 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/16297
* gdb.base/catch-syscall.c (read_syscall, pipe_syscall)
(write_syscall): New variables.
(main): Create a pipe, write 1 byte in it, and read 1 byte from
it.
* gdb.base/catch-syscall.exp (all_syscalls): Include "pipe,
"write" and "read" syscalls.
(fill_all_syscalls_numbers): Improve the way to obtain syscalls
numbers.
Added new domain MODULE_DOMAIN for fortran modules to avoid
issues with sharing namespaces (e.g. when a variable currently
in scope has the same name as a module).
(gdb) ptype modname
old> No symbol "modname" in current context.
new> type = module modname
This fixes PR 15209 and also addresses the issue
with sharing namespaces:
https://sourceware.org/ml/gdb-patches/2013-02/msg00643.html
2013-11-19 Keven Boell <keven.boell@intel.com>
Sanimir Agovic <sanimir.agovic@intel.com>
* cp-namespace.c (cp_lookup_nested_symbol): Enable
nested lookups for fortran modules.
* dwarf2read.c (read_module): Add fortran module to
the symbol table.
(add_partial_symbol, add_partial_module): Add fortran
module to the partial symbol table.
(new_symbol_full): Create full symbol for fortran module.
* f-exp.y (yylex): Add new module domain to be parsed.
* symtab.h: New domain for fortran modules.
testsuite/
* gdb.fortran/module.exp: Completion matches fortran module
names as well. ptype/whatis on modules return a proper type.
Add new check for having the correct scope.
(gdb) ptype type
old> No symbol "type" in current context.
new> type = Type type
integer(kind=4) :: t_i
End Type type
2013-11-19 Sanimir Agovic <sanimir.agovic@intel.com>
Keven Boell <keven.boell@intel.com>
* f-exp.y (yylex): Add domain array to enable lookup
in multiple domains. Loop over lookup domains and try
to find requested symbol. Add STRUCT_DOMAIN to lookup
domains to be able to query for user defined types.
testsuite/
* gdb.fortran/type.f90: New file.
* gdb.fortran/whatis_type.f90: New file.
While fixing another bug, I found that the current
gdb.base/catch-syscall.exp is kind of messy, could use some
improvements, and is not correctly testing some things.
I've made the following patch to address all the issues I found. On the
organization side, it does a cleanup and removes unecessary imports of
gdb_prompt, uses prepare_for_testing and clean_restart where needed, and
fixes some comments. The testcase was also not correctly testing
catching syscalls using only numbers, or catching many syscalls at
once. I fixed that.
The patch also uses a new method for obtaining the syscalls numbers: it
relies on the C source file to get them, via <sys/syscall.h> and SYS_*
macros. This makes the .exp file simpler because there is no need to
include target conditionals there.
I tested this on x86_64 Fedora 18.
gdb/testsuite/ChangeLog:
2013-12-18 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/catch-syscall.c: Include <sys/syscall.h>.
(close_syscall, chroot_syscall, exit_group_syscall): New
variables.
* gdb.base/catch-syscall.exp: Replace gdb_compile by
prepare_for_testing. Call fill_all_syscalls_numbers before
starting. Replace gdb_exit, gdb_start, gdb_reinitialize_dir and
gdb_load by clean_restart.
(check_info_bp_any_syscall, check_info_bp_specific_syscall)
(check_info_bp_many_syscalls): Remove global gdb_prompt.
(check_call_to_syscall): Likewise. Add global decimal. Improve
testing regex.
(check_return_from_syscall): Likewise.
(check_continue, insert_catch_syscall_with_arg): Remove global
gdb_prompt.
(insert_catch_syscall_with_many_args): Likewise. Add global
decimal. Fix $filter_str. Improve testing regex.
(check_for_program_end): Remove global gdb_prompt.
(test_catch_syscall_without_args): Likewise. Add global decimal.
Improve testing regex.
(test_catch_syscall_with_args, test_catch_syscall_with_many_args)
(test_catch_syscall_with_wrong_args)
(test_catch_syscall_restarting_inferior)
(test_catch_syscall_fail_nodatadir): Remove global gdb_prompt.
(do_syscall_tests): Likewise. Remove global srcdir.
(test_catch_syscall_without_args_noxml): Remove global gdb_prompt.
Add global last_syscall_number. Test for the exact syscall number
to be caught.
(test_catch_syscall_with_args_noxml): Remove global gdb_prompt.
Add global all_syscalls_numbers. Test each syscall number to be
caught, instead of only testing "close".
(test_catch_syscall_with_wrong_args_noxml): Remove global gdb_prompt.
(do_syscall_tests_without_xml): Likewise. Remove global srcdir.
Remove stale comment.
(fill_all_syscalls_numbers): Add global last_syscall_number. Fill
the correct syscall numbers using information from the inferior.
Like when stepping, the current stack frame location is expected to be
printed as result of tfind command, if that results in moving to a
different function. In tfind_1 we see:
if (from_tty
&& (has_stack_frames () || traceframe_number >= 0))
{
enum print_what print_what;
/* NOTE: in imitation of the step command, try to determine
whether we have made a transition from one function to
another. If so, we'll print the "stack frame" (ie. the new
function and it's arguments) -- otherwise we'll just show the
new source line. */
if (frame_id_eq (old_frame_id,
get_frame_id (get_current_frame ())))
print_what = SRC_LINE;
else
print_what = SRC_AND_LOC;
print_stack_frame (get_selected_frame (NULL), 1, print_what, 1);
do_displays ();
}
However, when we haven't collected any registers in the tracepoint
(collect $regs), that doesn't actually work:
(gdb) tstart
(gdb) info tracepoints
Num Type Disp Enb Address What
1 tracepoint keep y 0x080483b7 in func0
at ../.././../git/gdb/testsuite/gdb.trace/circ.c:28
collect testload
installed on target
2 tracepoint keep y 0x080483bc in func1
at ../.././../git/gdb/testsuite/gdb.trace/circ.c:32
collect testload
installed on target
(gdb) c
Continuing.
Breakpoint 3, end () at ../.././../git/gdb/testsuite/gdb.trace/circ.c:72
72 }
(gdb) tstop
(gdb) tfind start
Found trace frame 0, tracepoint 1
#0 func0 () at ../.././../git/gdb/testsuite/gdb.trace/circ.c:28
28 }
(gdb) tfind
Found trace frame 1, tracepoint 2
32 }
(gdb)
When we don't have info about the stack available
(UNWIND_UNAVAILABLE), frames end up with outer_frame_id as frame ID.
And in the scenario above, the issue is that both frames before and
after the second tfind (the frames for func0 an func1) have the same
id (outer_frame_id), so the frame_id_eq check returns false, even
though the frames were of different functions. GDB knows that,
because the PC is inferred from the tracepoint's address, even if no
registers were collected.
To fix this, this patch adds support for frame ids with a valid code
address, but <unavailable> stack address, and then makes the unwinders
use that instead of the catch-all outer_frame_id for such frames. The
frame_id_eq check in tfind_1 then automatically does the right thing
as expected.
I tested with --directory=gdb.trace/ , before/after the patch, and
compared the resulting gdb.logs, then adjusted the tests to expect the
extra output that came out. Turns out that was only circ.exp, the
original test that actually brought this issue to light.
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/
2013-12-17 Pedro Alves <palves@redhat.com>
* frame.h (enum frame_id_stack_status): New enum.
(struct frame_id) <stack_addr>: Adjust comment.
<stack_addr_p>: Delete field, replaced with ...
<stack_status>: ... this new field.
(frame_id_build_unavailable_stack): Declare.
* frame.c (frame_addr_hash, fprint_field, outer_frame_id)
(frame_id_build_special): Adjust.
(frame_id_build_unavailable_stack): New function.
(frame_id_build, frame_id_build_wild): Adjust.
(frame_id_p, frame_id_eq, frame_id_inner): Adjust to take into
account frames with unavailable stack.
* amd64-tdep.c (amd64_frame_this_id)
(amd64_sigtramp_frame_this_id, amd64_epilogue_frame_this_id): Use
frame_id_build_unavailable_stack.
* dwarf2-frame.c (dwarf2_frame_this_id): Likewise.
* i386-tdep.c (i386_frame_this_id, i386_epilogue_frame_this_id)
(i386_sigtramp_frame_this_id): Likewise.
gdb/testsuite/
2013-12-17 Pedro Alves <palves@redhat.com>
* gdb.trace/circ.exp: Expect frame info to be printed when
switching between frames with unavailable stack, but different
functions.
https://sourceware.org/ml/gdb-patches/2013-12/msg00144.html
The vector of unavailable parts of a value is currently byte based. Given
that we can model a value down to the bit level, we can potentially loose
information with the current implementation. After this patch we model the
unavailable information in bits.
gdb/ChangeLog
* dwarf2loc.c (read_pieced_value): Mark bits, not bytes
unavailable, use correct bit length.
* value.c (struct value): Extend comment on unavailable to
indicate that it is bit based.
(value_bits_available): New function.
(value_bytes_available): Call value_bits_available.
(value_entirely_available): Check against the bit length, not byte
length.
(mark_value_bits_unavailable): New function.
(mark_value_bytes_unavailable): Move contents to
mark_value_bits_unavailable, call to same.
(memcmp_with_bit_offsets): New function.
(value_available_contents_bits_eq): New function, takes the
functionality from value_available_contents_eq but uses
memcmp_with_bit_offsets now, and is bit not byte based.
(value_available_contents_eq): Move implementation into
value_available_contents_bits_eq, call to same.
(value_contents_copy_raw): Work on bits, not bytes.
(unpack_value_bits_as_long_1): Check availability in bits, not
bytes.
* value.h (value_bits_available): Declare new function.
(mark_value_bits_unavailable): Declare new function.
gdb/testsuite/ChangeLog
* gdb.trace/unavailable-dwarf-piece.c: New file.
* gdb.trace/unavailable-dwarf-piece.exp: New file.
This patch add a perf test case on skip-prologue by inserting
breakpoints on two functions many times, in order to exercise
skip-prologue.
gdb/testsuite:
2013-12-15 Yao Qi <yao@codesourcery.com>
* gdb.perf/skip-prologue.c: New.
* gdb.perf/skip-prologue.exp: New.
* gdb.perf/skip-prologue.py: New.
This function has the following code:
elt_type = type;
for (i = n; i > 1; i--)
elt_type = TYPE_TARGET_TYPE (type);
For multi-dimension arrays, the code above tries to find the array
type corresponding to the dimension we're trying to inspect.
The problem is that, past the second dimension, the loop does
nothing other than repeat the first iteration. There is a little
thinko where it got the TYPE_TARGET_TYPE of TYPE instead of ELT_TYPE!
To my surprise, I was unable to produce an Ada exemple that demonstrated
the problem. That's because the examples I created all trigger a parallel
___XA type which we then use in place of the ELT_TYPE in order to
determine the bounds - see the code that immediately follows our
loop above:
index_type_desc = ada_find_parallel_type (type, "___XA");
ada_fixup_array_indexes_type (index_type_desc);
if (index_type_desc != NULL)
[...]
So, in order to avoid depending on an Ada example where the compiler
can potentially decide one way or the other, I decided to use an
artificial example, written in C. With ...
int multi[1][2][3];
... forcing the language to Ada, and trying to print the 'last,
we get:
(gdb) p multi'last(1)
$1 = 0
(gdb) p multi'last(2)
$2 = 1
(gdb) p multi'last(3)
$3 = 1 <<<--- This should be 2!
Additionally, I noticed that a couple of check_typedef's were missing.
This patch adds them. And since the variable in question only gets
used within an "else" block, I moved the variable declaration and
use inside that block - making it clear what the scope of the variable
is.
gdb/ChangeLog:
* ada-lang.c (ada_array_bound_from_type): Move the declaration
and assignment of variable "elt_type" inside the else block
where it is used. Add two missing check_typedef calls.
Fix bug where we got TYPE's TYPE_TARGET_TYPE, where in fact
we really wanted to get ELT_TYPE's TYPE_TARGET_TYPE.
gdb/testsuite/ChangeLog:
* gdb.ada/arraydim: New testcase.
PR python/16113
* NEWS (Python Scripting): Add entry for the new feature and the
new attribute of gdb.Field objects.
* python/py-type.c (gdbpy_is_field): New function
(convert_field): Add 'parent_type' attribute to gdb.Field
objects.
* python/py-value.c (valpy_getitem): Allow subscript value to be
a gdb.Field object.
(value_has_field): New function
(get_field_flag): New function
* python/python-internal.h (gdbpy_is_field): Add declaration.
testsuite/
* gdb.python/py-value-cc.cc: Improve test case.
* gdb.python/py-value-cc.exp: Add new tests to test usage of
gdb.Field objects as subscripts on gdb.Value objects.
doc/
* gdb.texinfo (Values From Inferior): Add a note about using
gdb.Field objects as subscripts on gdb.Value objects.
(Types In Python): Add description about the new attribute
"parent_type" of gdb.Field objects.
* c-lang.c (c_get_string): Ignore the declared size of the object
if a specific length is requested.
testsuite/
* gdb.python/py-value.c: #include stdlib.h, string.h.
(str): New struct.
(main): New local xstr.
* gdb.python/py-value.exp (test_value_in_inferior): Add test to
fetch a value as a string with a length beyond the declared length
of the array.
This helps with the following issue: Given an Ada program defining
a global variable:
package Pck is
Watch : Integer := 1974;
end Pck;
When printing the address of this variable, GDB also tries to print
the associated symbol name:
(gdb) p watch'address
$1 = (access integer) 0x6139d8 <pck__watch>
^^
||
The problem is that GDB prints the variable's linkage name, instead
of its natural name. This is because the language of the associated
minimal symbol never really gets set.
This patch adds handling for Ada symbols in symbol_find_demangled_name.
After this patch, we now get:
(gdb) p watch'address
$1 = (access integer) 0x6139d8 <pck.watch>
^
|
gdb/ChangeLog:
* symtab.c (symbol_find_demangled_name): Add handling of
Ada symbols.
gdb/testsuite/ChangeLog:
* gdb.ada/int_deref.exp: Add test verifying that we print
the decoded symbol name when printing the address of Ada
symbols.
This adds "exec-run-start-option" in the output of the -list-features
commands, allowing front-ends to easily determine whether -exec-run
supports the --start option.
gdb/ChangeLog:
* mi/mi-main.c (mi_cmd_list_features): add "exec-run-start-option".
* NEWS: Expand the entry documenting the new -exec-run --start
option to mention the corresponding new entry in the output of
"-list-features".
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Miscellaneous Commands): Document the new
"exec-run-start-option" entry in the output of the "-list-features"
command.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-start.exp: Add test verifying that -list-features
contains "exec-run-start-option".
We added a new proc gdb_produce_source recently, and it can be used
more widely in lib/gdb.exp to generate source file.
gdb/testsuite:
2013-12-08 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (support_complex_tests): Use gdb_produce_source.
(is_elf_target, is_ilp32_target, is_ilp64_target): Likewise.
(is_64_target, is_amd64_regs_target): Likewise.
(skip_altivec_tests, skip_vsx_tests, skip_btrace_tests): Likewise.
These files are source files and have no business being +x. We couldn't
easily fix it in CVS (you need login+write access to the raw rcs files),
but we can fix this w/git.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
These scripts use /bin/ksh, but they're dirt simple and can be used with
/bin/sh, so just change the shebang.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Doing "info frame" in the outermost frame, when that was indicated by
the next frame saying the unwound PC is undefined/not saved, results
in error and incomplete output:
(gdb) bt
#0 thread_function0 (arg=0x0) at threads.c:63
#1 0x00000034cf407d14 in start_thread (arg=0x7ffff7fcb700) at pthread_create.c:309
#2 0x000000323d4f168d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) frame 2
#2 0x000000323d4f168d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
115 call *%rax
(gdb) info frame
Stack level 2, frame at 0x0:
rip = 0x323d4f168d in clone (../sysdeps/unix/sysv/linux/x86_64/clone.S:115); saved rip Register 16 was not saved
(gdb)
Not saved register values are treated as optimized out values
internally throughout. stack.c:frame_info is handing unvailable
values, but not optimized out ones. The patch deletes the
frame_unwind_caller_pc_if_available wrapper function and instead lets
errors propagate to frame_info (it's only user).
As frame_unwind_pc now needs to be able to handle and cache two
different error scenarios, the prev_pc.p variable is replaced with an
enumeration.
(FWIW, I looked into making gdbarch_unwind_pc or a variant return
struct value's instead, but it results in lots of boxing and unboxing
for no real gain -- e.g., the mips and arm implementations need to do
computation on the unboxed PC value. Might as well throw an error on
first attempt to get at invalid contents.)
After the patch, we get:
(gdb) info frame
Stack level 2, frame at 0x0:
rip = 0x323d4f168d in clone (../sysdeps/unix/sysv/linux/x86_64/clone.S:115); saved rip = <not saved>
Outermost frame: outermost
caller of frame at 0x7ffff7fcafc0
source language asm.
Arglist at 0x7ffff7fcafb8, args:
Locals at 0x7ffff7fcafb8, Previous frame's sp is 0x7ffff7fcafc8
(gdb)
A new test is added. It's based off dw2-reg-undefined.exp, and tweaked to
mark the return address (rip) of "stop_frame" as undefined.
Tested on x86_64 Fedora 17.
gdb/
2013-12-06 Pedro Alves <palves@redhat.com>
* frame.c (enum cached_copy_status): New enum.
(struct frame_info) <prev_pc.p>: Change type to enum
cached_copy_status.
(fprint_frame): Handle not saved and unavailable prev_pc values.
(frame_unwind_pc_if_available): Delete and merge contents into ...
(frame_unwind_pc): ... here. Handle OPTIMIZED_OUT_ERROR. Adjust
to use enum cached_copy_status.
(frame_unwind_caller_pc_if_available): Delete.
(create_new_frame): Adjust.
* frame.h (frame_unwind_caller_pc_if_available): Delete
declaration.
* stack.c (frame_info): Use frame_unwind_caller_pc instead of
frame_unwind_caller_pc_if_available, and handle
NOT_AVAILABLE_ERROR and OPTIMIZED_OUT_ERROR errors.
* valprint.c (val_print_optimized_out): Use val_print_not_saved.
(val_print_not_saved): New function.
* valprint.h (val_print_not_saved): Declare.
gdb/testsuite/
2013-12-06 Pedro Alves <palves@redhat.com>
* gdb.dwarf2/dw2-undefined-ret-addr.S: New file.
* gdb.dwarf2/dw2-undefined-ret-addr.c: New file.
* gdb.dwarf2/dw2-undefined-ret-addr.exp: New file.
In some languages, e.g. fortran, arrays start with index 1
instead 0. This patch changes the MI library to support testing
varobj children of fortran arrays.
2013-11-21 Keven Boell <keven.boell@intel.com>
testsuite/
* lib/mi-support.exp (mi_list_varobj_children_range): Add
call to mi_list_array_varobj_children_with_index.
(mi_list_array_varobj_children_with_index): New function.
Add parameter to specify array start.
2013-10-03 Jose E. Marchesi <jose.marchesi@oracle.com>
* gdb.base/sigall.exp (test_one_sig): gdb identifies SIGLOST as a
SIGPWR in sparc64.
* gdb.base/sigall.c (main): In some targets SIGLOST and SIGPWR
have the same signal number. Handle this situation.
Consider the following code:
type Ptr is access all Integer;
IP : Ptr := new Integer'(123);
IP is the Ada exception of a pointer to an integer. To dereference
the pointer and get its value, the user uses the reserved word "all"
as follow:
(gdb) p ip.all
$1 = 123
Ada being a case-insensitive language, the casing should not matter.
Unfortunately, for the reserved word "all", things don't work. For
instance:
(gdb) p ip.ALL
Type integer is not a structure or union type
This patch fixes the problem.
gdb/ChangeLog:
* ada-lex.l (find_dot_all): Use strncasecmp instead of strncmp.
gdb/testsuite/ChangeLog:
* gdb.ada/dot_all: New testcase.
... when trying to execute an undefined GDB/MI command. When trying
to execute a GDB/MI command which does not exist, the current error
result record looks like this:
-unsupported
^error,msg="Undefined MI command: unsupported"
The only indication that the command does not exist is the error
message. It would be a little fragile for a consumer to rely solely
on the contents of the error message in order to determine whether
a command exists or not.
This patch improves the situation by adding concept of error
code, starting with one well-defined error code ("undefined-command")
identifying errors due to a non-existant command. Here is the new
output:
-unsupported
^error,msg="Undefined MI command: unsupported",code="undefined-command"
This error code is only displayed when the corresponding error
condition is met. Otherwise, the error record remains unchanged.
For instance:
-symbol-list-lines foo.adb
^error,msg="-symbol-list-lines: Unknown source file name."
For frontends to be able to know whether they can rely on this
variable, a new entry "undefined-command-error-code" has been
added to the "-list-features" command. Another option would be
to always generate an error="..." variable (for the default case,
we could decide for instance that the error code is the empty string).
But it seems more efficient to provide that info in "-list-features"
and then only add the error code when meaningful.
gdb/ChangeLog:
(from Pedro Alves <palves@redhat.com>)
(from Joel Brobecker <brobecker@adacore.com>)
* exceptions.h (enum_errors) <UNDEFINED_COMMAND_ERROR>: New enum.
* mi/mi-parse.c (mi_parse): Throw UNDEFINED_COMMAND_ERROR instead
of a regular error when the GDB/MI command does not exist.
* mi/mi-main.c (mi_cmd_list_features): Add
"undefined-command-error-code".
(mi_print_exception): Print an "undefined-command"
error code if EXCEPTION.ERROR is UNDEFINED_COMMAND_ERROR.
* NEWS: Add entry documenting the new "code" variable in
"^error" result records.
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Result Records): Fix the syntax of the
"^error" result record concerning the error message. Document
the error code that may also be part of that result record.
(GDB/MI Miscellaneous Commands): Document the
"undefined-command-error-code" element in the output of
the "-list-features" GDB/MI command.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-undefined-cmd.exp: New testcase.
This patch adds a new GDB/MI command meant for graphical frontends
trying to determine whether a given GDB/MI command exists or not.
Examples:
-info-gdb-mi-command unsupported-command
^done,command={exists="false"}
(gdb)
-info-gdb-mi-command symbol-list-lines
^done,command={exists="true"}
(gdb)
At the moment, this is the only piece of information that this
command returns.
Eventually, and if needed, we can extend it to provide
command-specific pieces of information, such as updates to
the command's syntax since inception. This could become,
for instance:
-info-gdb-mi-command symbol-list-lines
^done,command={exists="true",features=[]}
(gdb)
-info-gdb-mi-command catch-assert
^done,command={exists="true",features=["conditions"]}
In the first case, it would mean that no extra features,
while in the second, it announces that the -catch-assert
command in this version of the debugger supports a feature
called "condition" - exact semantics to be documented with
combined with the rest of the queried command's documentation.
But for now, we start small, and only worry about existance.
And to bootstrap the process, I have added an entry in the
output of the -list-features command as well ("info-gdb-mi-command"),
allowing the graphical frontends to go through the following process:
1. Send -list-features, collect info from there as before;
2. Check if the output contains "info-gdb-mi-command".
If it does, then support for various commands can be
queried though -info-gdb-mi-command. Newer commands
will be expected to always be checked via this new
-info-gdb-mi-command.
gdb/ChangeLog:
* mi/mi-cmds.h (mi_cmd_info_gdb_mi_command): Declare.
* mi/mi-cmd-info.c (mi_cmd_info_gdb_mi_command): New function.
* mi/mi-cmds.c (mi_cmds): Add -info-gdb-mi-command command.
* mi/mi-main.c (mi_cmd_list_features): Add "info-gdb-mi-command"
field to output of "-list-features".
* NEWS: Add entry for new -info-gdb-mi-command.
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Miscellaneous Commands): Document
the new -info-gdb-mi-command GDB/MI command. Document
the meaning of "-info-gdb-mi-command" in the output of
-list-features.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-i-cmd.exp: New file.
gdb/
2013-12-02 Doug Evans <dje@google.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
* objfiles.c (allocate_objfile): Save original_name as an absolute
path.
* objfiles.h (struct objfile): Expand comment on original_name.
* source.c (openp): Call gdb_abspath.
* utils.c (gdb_abspath): New function.
* utils.h (gdb_abspath): Declare.
gdb/testsuite/
2013-12-02 Doug Evans <dje@google.com>
* gdb.dwarf/dwp-symlink.c: Fake out gdb to not load debug info
at start.
* gdb.dwarf/dwp-symlink.exp: Test trying to load dwp when the binary
has been specified with a relative path and we have chdir'd before
accessing the debug info.
When printing an entirely optimized out structure/class/union, we
print a single <optimized out> instead of printing <optimized out> for
each field.
This patch makes an entirely unavailable structure/class/union be
likewise displayed with a single "<unavailable>" rather than the whole
object with all fields <unavailable>.
This seems good because this way the user can quickly tell whether the
whole value is unavailable, rather than having to skim all fields.
Consistency with optimized out values also seems to be a good thing to
have.
A few updates to gdb.trace/unavailable.exp where required.
Tested on x86_64 Fedora 17, native gdbserver.
gdb/
2013-11-28 Andrew Burgess <aburgess@broadcom.com>
Pedro Alves <palves@redhat.com>
* valprint.c (value_check_printable): If the value is entirely
unavailable, print a single "<unavailable>" instead of printing
all subfields.
gdb/testsuite/
2013-11-28 Andrew Burgess <aburgess@broadcom.com>
* gdb.trace/unavailable.exp (gdb_collect_args_test): Update
expected results.
(gdb_collect_locals_test): Likewise.
(gdb_collect_globals_test): Likewise.
This patch adds a test case to test the performance of GDB doing
disassembly.
gdb/testsuite/
2013-11-28 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (with_gdb_prompt): New proc.
* gdb.perf/disassemble.exp: New.
* gdb.perf/disassemble.py: New.
This reverts da2b2fdf57 and some
follow-up patches. They were incorrect.
2013-11-26 Tom Tromey <tromey@redhat.com>
* dwarf2-frame.c (dwarf2_frame_cache): Revert patch from
2013-11-22.
2013-11-26 Tom Tromey <tromey@redhat.com>
* gdb.dwarf2/dw2-unspecified-ret-addr.S: Remove.
* gdb.dwarf2/dw2-unspecified-ret-addr.c: Remove.
* gdb.dwarf2/dw2-unspecified-ret-addr.exp: Remove.
* gdb.python/py-value.exp (test_lazy_strings): Tweak test names.
(test_subscript_regression): Ditto.
(top level): Run test_subscript_regression for c++ with "c++" prefix.
Pedro asked me to add a comment to dw2-bad-cfi.S explaining the nature
of the badness.
I'm checking this in.
2013-11-22 Tom Tromey <tromey@redhat.com>
* gdb.dwarf2/dw2-bad-cfi.S: Update comment.
Debugging PR 16155 further, I found that the DWARF unwinder found the
function in question, but thought it had no registers saved
(fs->regs.num_regs == 0).
It seems to me that if a frame does not specify the return address
column, or if the return address column is explicitly marked as
DWARF2_FRAME_REG_UNSPECIFIED, then we should set the
"undefined_retaddr" flag and let the DWARF unwinder gracefully stop.
This patch implements that idea.
With this patch the backtrace works properly:
(gdb) bt
#0 0x0000007fb7ed485c in nanosleep () from /lib64/libc.so.6
#1 0x0000007fb7ed4508 in sleep () from /lib64/libc.so.6
#2 0x00000000004008bc in thread_function (arg=0x4) at threadapply.c:73
#3 0x0000007fb7fad950 in start_thread () from /lib64/libpthread.so.0
#4 0x0000007fb7f0956c in clone () from /lib64/libc.so.6
2013-11-22 Tom Tromey <tromey@redhat.com>
PR backtrace/16155:
* dwarf2-frame.c (dwarf2_frame_cache): Set undefined_retaddr if
the return address column is unspecified.
2013-11-22 Tom Tromey <tromey@redhat.com>
* gdb.dwarf2/dw2-bad-cfi.c: New file.
* gdb.dwarf2/dw2-bad-cfi.exp: New file.
* gdb.dwarf2/dw2-bad-cfi.S: New file.
The UNWIND_SAME_ID check is done between THIS_FRAME and the next frame
when we go try to unwind the previous frame. But at this point, it's
already too late -- we ended up with two frames with the same ID in
the frame chain. Each frame having its own ID is an invariant assumed
throughout GDB. This patch applies the UNWIND_SAME_ID detection
earlier, right after the previous frame is unwound, discarding the dup
frame if a cycle is detected.
The patch includes a new test that fails before the change. Before
the patch, the test causes an infinite loop in GDB, after the patch,
the UNWIND_SAME_ID logic kicks in and makes the backtrace stop with:
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
The test uses dwarf CFI to emulate a corrupted stack with a cycle. It
has a function with registers marked DW_CFA_same_value (most
importantly RSP/RIP), so that GDB computes the same ID for that frame
and its caller. IOW, something like this:
#0 - frame_id_1
#1 - frame_id_2
#2 - frame_id_3
#3 - frame_id_4
#4 - frame_id_4 <<<< outermost (UNWIND_SAME_ID).
(The test's code is just a copy of dw2-reg-undefined.S /
dw2-reg-undefined.c, adjusted to use DW_CFA_same_value instead of
DW_CFA_undefined, and to mark a different set of registers.)
The infinite loop is here, in value_fetch_lazy:
while (VALUE_LVAL (new_val) == lval_register && value_lazy (new_val))
{
frame = frame_find_by_id (VALUE_FRAME_ID (new_val));
...
new_val = get_frame_register_value (frame, regnum);
}
get_frame_register_value can return a lazy register value pointing to
the next frame. This means that the register wasn't clobbered by
FRAME; the debugger should therefore retrieve its value from the next
frame.
To be clear, get_frame_register_value unwinds the value in question
from the next frame:
struct value *
get_frame_register_value (struct frame_info *frame, int regnum)
{
return frame_unwind_register_value (frame->next, regnum);
^^^^^^^^^^^
}
In other words, if we get a lazy lval_register, it should have the
frame ID of the _next_ frame, never of FRAME.
At this point in value_fetch_lazy, the whole relevant chunk of the
stack up to frame #4 has already been unwound. The loop always
"unlazies" lval_registers in the "next/innermost" direction, not in
the "prev/unwind further/outermost" direction.
So say we're looking at frame #4. get_frame_register_value in frame
#4 can return a lazy register value of frame #3. So the next
iteration, frame_find_by_id tries to read the register from frame #3.
But, since frame #4 happens to have same id as frame #3,
frame_find_by_id returns frame #4 instead. Rinse, repeat, and we have
an infinite loop.
This is an old latent problem, exposed by the recent addition of the
frame stash. Before we had a stash, frame_find_by_id(frame_id_4)
would walk over all frames starting at the current frame, and would
always find #3 first. The stash happens to return #4 instead:
struct frame_info *
frame_find_by_id (struct frame_id id)
{
struct frame_info *frame, *prev_frame;
...
/* Try using the frame stash first. Finding it there removes the need
to perform the search by looping over all frames, which can be very
CPU-intensive if the number of frames is very high (the loop is O(n)
and get_prev_frame performs a series of checks that are relatively
expensive). This optimization is particularly useful when this function
is called from another function (such as value_fetch_lazy, case
VALUE_LVAL (val) == lval_register) which already loops over all frames,
making the overall behavior O(n^2). */
frame = frame_stash_find (id);
if (frame)
return frame;
for (frame = get_current_frame (); ; frame = prev_frame)
{
gdb/
2013-11-22 Pedro Alves <palves@redhat.com>
PR 16155
* frame.c (get_prev_frame_1): Do the UNWIND_SAME_ID check between
this frame and the new previous frame, not between this frame and
the next frame.
gdb/testsuite/
2013-11-22 Pedro Alves <palves@redhat.com>
PR 16155
* gdb.dwarf2/dw2-dup-frame.S: New file.
* gdb.dwarf2/dw2-dup-frame.c: New file.
* gdb.dwarf2/dw2-dup-frame.exp: New file.
The UNWIND_SAME_ID check is done between THIS_FRAME and the next frame
when we go try to unwind the previous frame. But at this point, it's
already too late -- we ended up with two frames with the same ID in
the frame chain. Each frame having its own ID is an invariant assumed
throughout GDB. This patch applies the UNWIND_SAME_ID detection
earlier, right after the previous frame is unwound, discarding the dup
frame if a cycle is detected.
The patch includes a new test that fails before the change. Before
the patch, the test causes an infinite loop in GDB, after the patch,
the UNWIND_SAME_ID logic kicks in and makes the backtrace stop with:
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
The test uses dwarf CFI to emulate a corrupted stack with a cycle. It
has a function with registers marked DW_CFA_same_value (most
importantly RSP/RIP), so that GDB computes the same ID for that frame
and its caller. IOW, something like this:
#0 - frame_id_1
#1 - frame_id_2
#2 - frame_id_3
#3 - frame_id_4
#4 - frame_id_4 <<<< outermost (UNWIND_SAME_ID).
(The test's code is just a copy of dw2-reg-undefined.S /
dw2-reg-undefined.c, adjusted to use DW_CFA_same_value instead of
DW_CFA_undefined, and to mark a different set of registers.)
The infinite loop is here, in value_fetch_lazy:
while (VALUE_LVAL (new_val) == lval_register && value_lazy (new_val))
{
frame = frame_find_by_id (VALUE_FRAME_ID (new_val));
...
new_val = get_frame_register_value (frame, regnum);
}
get_frame_register_value can return a lazy register value pointing to
the next frame. This means that the register wasn't clobbered by
FRAME; the debugger should therefore retrieve its value from the next
frame.
To be clear, get_frame_register_value unwinds the value in question
from the next frame:
struct value *
get_frame_register_value (struct frame_info *frame, int regnum)
{
return frame_unwind_register_value (frame->next, regnum);
^^^^^^^^^^^
}
In other words, if we get a lazy lval_register, it should have the
frame ID of the _next_ frame, never of FRAME.
At this point in value_fetch_lazy, the whole relevant chunk of the
stack up to frame #4 has already been unwound. The loop always
"unlazies" lval_registers in the "next/innermost" direction, not in
the "prev/unwind further/outermost" direction.
So say we're looking at frame #4. get_frame_register_value in frame
#4 can return a lazy register value of frame #3. So the next
iteration, frame_find_by_id tries to read the register from frame #3.
But, since frame #4 happens to have same id as frame #3,
frame_find_by_id returns frame #4 instead. Rinse, repeat, and we have
an infinite loop.
This is an old latent problem, exposed by the recent addition of the
frame stash. Before we had a stash, frame_find_by_id(frame_id_4)
would walk over all frames starting at the current frame, and would
always find #3 first. The stash happens to return #4 instead:
struct frame_info *
frame_find_by_id (struct frame_id id)
{
struct frame_info *frame, *prev_frame;
...
/* Try using the frame stash first. Finding it there removes the need
to perform the search by looping over all frames, which can be very
CPU-intensive if the number of frames is very high (the loop is O(n)
and get_prev_frame performs a series of checks that are relatively
expensive). This optimization is particularly useful when this function
is called from another function (such as value_fetch_lazy, case
VALUE_LVAL (val) == lval_register) which already loops over all frames,
making the overall behavior O(n^2). */
frame = frame_stash_find (id);
if (frame)
return frame;
for (frame = get_current_frame (); ; frame = prev_frame)
{
gdb/
2013-11-22 Pedro Alves <palves@redhat.com>
PR 16155
* frame.c (get_prev_frame_1): Do the UNWIND_SAME_ID check between
this frame and the new previous frame, not between this frame and
the next frame.
gdb/testsuite/
2013-11-22 Pedro Alves <palves@redhat.com>
PR 16155
* gdb.dwarf2/dw2-dup-frame.S: New file.
* gdb.dwarf2/dw2-dup-frame.c: New file.
* gdb.dwarf2/dw2-dup-frame.exp: New file.
Hi,
I find "has_more" is not checked when a dynamic varobj is created in
proc mi_create_dynamic_varobj. This patch adds the check to
"has_more".
gdb/testsuite:
2013-11-22 Yao Qi <yao@codesourcery.com>
* lib/mi-support.exp (mi_create_dynamic_varobj): Update
comment and add one more argument "has_more".
* gdb.python/py-mi.exp: Callers update.
In gdb.python/py-mi.exp, two varobjs container and nscont are created
when pretty-printing is still not enabled, so they are not dynamic
varobj, IIUC. In this patch, we use mi_create_floating_varobj instead
of mi_create_dynamic_varobj.
gdb/testsuite:
2013-11-22 Yao Qi <yao@codesourcery.com>
* gdb.python/py-mi.exp: Use mi_create_floating_varobj instead
of mi_create_dynamic_varobj.
2013-11-20 Pedro Alves <palves@redhat.com>
* gdb.base/maint.exp (maint print objfiles): Consume one line at a
time, and run it through all three milestone regexes.
I was "lucky" enough that an unrelated patch changed how many symtabs
GDB expands in a plain run to main, and that triggered a latent issue
in this test:
PASS: gdb.base/maint.exp: maint print objfiles: header
PASS: gdb.base/maint.exp: maint print objfiles: psymtabs
FAIL: gdb.base/maint.exp: maint print objfiles: symtabs
The problem is in my case, expect is managing to alway put in the
buffer chunks like this:
Psymtabs:
../../../src/gdb/testsuite/gdb.base/break1.c at 0x1ed2280, ../../../src/gdb/testsuite/gdb.base/break.c at 0x1ed21d0,
Symtabs:
../../../src/gdb/testsuite/gdb.base/break.c at 0x1f044f0, /usr/include/stdio.h at 0x1ed25a0, /usr/include/libio.h at 0x1ed2510, /usr/include/bits/types.h at 0x1ed2480, /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/stddef.h at 0x1ed23f0,
Object file /usr/lib/debug/lib64/ld-2.15.so.debug: Objfile at 0x1f4bff0, bfd at 0x1f2d940, 0 minsyms
Psymtabs:
bsearch.c at 0x1f65340, ../sysdeps/x86_64/multiarch/init-arch.c at
0x1f65290, ...
Note: Psymtabs:/Symtabs:/Psymtabs:.
So, the loop matches the first Psymtabs in the buffer. Then we're
left with
../../../src/gdb/testsuite/gdb.base/break1.c at 0x1ed2280, ../../../src/gdb/testsuite/gdb.base/break.c at 0x1ed21d0,
Symtabs:
../../../src/gdb/testsuite/gdb.base/break.c at 0x1f044f0, /usr/include/stdio.h at 0x1ed25a0, /usr/include/libio.h at 0x1ed2510, /usr/include/bits/types.h at 0x1ed2480, /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/stddef.h at 0x1ed23f0,
Object file /usr/lib/debug/lib64/ld-2.15.so.debug: Objfile at 0x1f4bff0, bfd at 0x1f2d940, 0 minsyms
Psymtabs:
bsearch.c at 0x1f65340, ../sysdeps/x86_64/multiarch/init-arch.c at
0x1f65290, ...
In the next iteration, because the psymtabs regex comes first, we
match with the Psymtabs: line, then of course, end up with just
bsearch.c at 0x1f65340, ../sysdeps/x86_64/multiarch/init-arch.c at
0x1f65290, ...
in the buffer. The "Symtabs:" line is lost. expect then reads more
gdb output, and manages to again retrieve the same pattern. Rinse,
repeat, and the test never matches any "Symtab:" line.
We don't know the order the matches lines will appear, so the fix is
to consume one line at a time, and run it through all three milestone
regexes.
gdb/testsuite/
2013-11-20 Pedro Alves <palves@redhat.com>
* gdb.base/maint.exp (maint print objfiles): Consume one line at a
time, and run it through all three milestone regexes.
Ensure that certain commands (e.g. whatis/ptype) and sizeof intrinsic
have no side effects (variables cannot be altered).
2013-11-20 Sanimir Agovic <sanimir.agovic@intel.com>
testsuite/
* gdb.base/eval-avoid-side-effects.exp: New test.
Boundary length is simpler implemented by means of a pretty
printer. This simplifies users life when examining a bound register.
Changelog:
2013-11-20 Walfred Tedeschi <walfred.tedeschi@intel.com>
* python/lib/gdb/command/bound_register.py: New file.
* gdb/data-directory/Makefile.in: copy bond_register.py to the right path to
be initialized at gdb startup.
testsuite/
* gdb.python/py-pp-maint.exp: Consider new pretty-print added for registers.
Change-Id: Id4f39845e5ece56c370a1fd4343648909f08b731
Signed-off-by: Walfred Tedeschi <walfred.tedeschi@intel.com>
Conflicts:
gdb/ChangeLog
Bitfields are represented by intervals [start, begin]. It means that for an
interval comprised by only one bit start and end will be equal.
The present condition does not always hold. On the other hand in target-description.c
(tdesc_gdb_type) bitfield is created when "f->type" is null. The routine
maint_print_maint_print_c_tdesc_cmd is modified to follow the same strategy.
2013-11-20 Walfred Tedeschi <walfred.tedeschi@intel.com>
* target-descriptions.c (maint_print_maint_print_c_tdesc_cmd):
Modified logic of creating a bitfield to be in sync with
tdesc_gdb_type.
testsuite/
* gdb.xml/maint_print_struct.xml (bitfield): Added bitfield having
start and end equal 0.
Change-Id: I8c62db049995f0c0c30606d9696b86afe237cbb9
Hi,
In proc mi_child_regexp, \(,thread-id=\"\[0-9\]+\") is appended to
children_exp, while the first '\' is not necessary. This patch
is to remove it. With this patch applied, Emacs can find the right
left paren.
gdb/testsuite:
2013-11-19 Yao Qi <yao@codesourcery.com>
* lib/mi-support.exp (mi_child_regexp): Remove unnecessary '\'.
There are some format issues in lib/mi-support.exp, such as using
spaces instead of tab and trailing spaces. This patch is to fix them.
gdb/testsuite:
2013-11-19 Yao Qi <yao@codesourcery.com>
* lib/mi-support.exp: Fix format.
Variable 'whatever' is not used at all. This patch is to remove it.
gdb/testsuite:
2013-11-19 Yao Qi <yao@codesourcery.com>
* lib/mi-support.exp (mi_child_regexp): Remove 'whatever'.
(mi_list_varobj_children_range): Likewise.
Consider the following variable:
type Small is range -128 .. 127;
SR : Small := 48;
Trying to get its value as an integer within Python code yields:
(gdb) python sr = gdb.parse_and_eval('sr')
(gdb) python print int(sr)
Traceback (most recent call last):
File "<string>", line 1, in <module>
gdb.error: Cannot convert value to int.
Error while executing Python code.
This is happening because our variable is a range type, and
py-value's is_intlike does not handle TYPE_CODE_RANGE. This
patch fixes this.
gdb/ChangeLog:
* python/py-value.c (is_intlike): Add TYPE_CODE_RANGE handling.
gdb/testsuite/ChangeLog:
* gdb.ada/py_range: New testcase.
In the case where the GNAT runtime was built with full debugging info,
several of the exceptions defined there might have a name contain
the word "global". To make this less likely, this patch renames
the exception name, replacing "Global" by "Global_GDB". It still
keeps the exeption name relatively short, while it is unlikely that
the GNAT runtime has an exception whose name explicitly mentions GDB,
and even less likely that it contains "Global_GDB".
gdb/testsuite/ChangeLog:
* info_exc/const.ads (Aint_Global_GDB_E): Renames Aint_Global_E.
* info_exc/foo.adb: Adjust to new exception name.
* info_exc.exp: Adjust after exception renaming in const.ads.
Update "info exception global" test to test "info exceptions
global_gdb" instead.
* mi_exc_info/const.ads (Aint_Global_GDB_E): Renames Aint_Global_E.
* mi_exc_info/foo.adb (Adjust to new exception name.
* mi_exc_info.exp: Adjust after exception renaming in const.ads.
Update "-info-ada-exceptions global" test to test
"-info-ada-exceptions global_gdb" instead.
of inferior output for remote and native sessions.
* gdb.mi/mi-console.exp: Remove obsolete comment.
Check for semihosted inferior output pattern.
(semihosted_string): New function.
If the runtime has full debug info, then the non-standard exceptions
declared in the GNAT runtime will appear in the list of exceptions
printed by GDB ("info exceptions" or "-info-ada-exceptions").
This is valid output, so this patch allows for it.
gdb/testsuite/ChangeLog:
* gdb.ada/info_exc.exp: Allow other global exceptions to be
listed in the output of "info exceptions".
* gdb.ada/mi_exc_info.exp: Allow other global exceptions to be
listed in the output of "-info-ada-exceptions".
This patch fixes some spurious failures when the inferior is linked
against the shared version of libgnat by default, as appears to be
the case on many GNU/Linux distributions. When that happens, we have
to start the program in order to ensure that the GNAT runtime is
mapped to memory, in order for us to find the standard exceptions
(defined within the runtime). Otherwise, they will not be shown,
as expected, by the debugger.
gdb/testsuite/ChangeLog:
* gdb.ada/info_exc.exp: Start inferior before starting
the "info exceptions" tests.
* gdb.ada/mi_exc_info.exp: Start inferior before starting
the "-info-ada-exceptions" tests.
This patch fixes PR c++/16117.
gdb has an extension so that users can use expressions like FILE::NAME
to choose a variable of the given name from the given file. The bug
is that this extension takes precedence over ordinary C++ expressions
of the same form. You might think this is merely hypothetical, but
now that C++ headers commonly do not use an extension, it is more
common.
This patch fixes the bug by making two related changes. First, it
changes gdb to prefer the ordinary C++ meaning of a symbol over the
extended meaning. Second, it arranges for single-quoting of the
symbol to indicate a preference for the extension.
Built and regtested on x86-64 Fedora 18.
New test case included.
2013-11-15 Tom Tromey <tromey@redhat.com>
PR c++/16117:
* c-exp.y (lex_one_token): Add "is_quoted_name" argument.
(classify_name): Likewise. Prefer a field of "this" over a
filename.
(classify_inner_name, yylex): Update.
2013-11-15 Tom Tromey <tromey@redhat.com>
* gdb.texinfo (Variables): Note gdb rules for ambiguous cases.
Add example.
2013-11-15 Tom Tromey <tromey@redhat.com>
* gdb.cp/includefile: New file.
* gdb.cp/filename.exp: New file.
* gdb.cp/filename.cc: New file.
Consider the following code, compiled at -O2 on ppc-linux:
procedure Increment (Val : in out Float; Msg : String);
The implementation does not really matter in this case). In our example,
this function is being called from a function with Param_1 set to 99.0.
Trying to break inside that function, and running until reaching that
breakpoint yields:
(gdb) b increment
Breakpoint 1 at 0x100014b4: file callee.adb, line 6.
(gdb) run
Starting program: /[...]/foo
Breakpoint 1, callee.increment (val=99.0, val@entry=0.0, msg=...)
at callee.adb:6
6 if Val > 200.0 then
The @entry value for parameter "val" is incorrect, it should be 99.0.
The associated call-site parameter DIE looks like this:
.uleb128 0xc # (DIE (0x115) DW_TAG_GNU_call_site_parameter)
.byte 0x2 # DW_AT_location
.byte 0x90 # DW_OP_regx
.uleb128 0x21
.byte 0x3 # DW_AT_GNU_call_site_value
.byte 0xf5 # DW_OP_GNU_regval_type
.uleb128 0x3f
.uleb128 0x25
The DW_AT_GNU_call_site_value uses a DW_OP_GNU_regval_type
operation, referencing register 0x3f=63, which is $f31,
an 8-byte floating register. In that register, the value is
stored using the usual 8-byte float format:
(gdb) info float
f31 99.0 (raw 0x4058c00000000000)
The current code evaluating DW_OP_GNU_regval_type operations
currently is (dwarf2expr.c:execute_stack_op):
result = (ctx->funcs->read_reg) (ctx->baton, reg);
result_val = value_from_ulongest (address_type, result);
result_val = value_from_contents (type,
value_contents_all (result_val));
What the ctx->funcs->read_reg function does is read the contents
of the register as if it contained an address. The rest of the code
continues that assumption, thinking it's OK to then use that to
create an address/ulongest struct value, which we then re-type
to the type specified by DW_OP_GNU_regval_type.
We're getting 0.0 above because the read_reg implementations
end up treating the contents of the FP register as an integral,
reading only 4 out of the 8 bytes. Being a big-endian target,
we read the high-order ones, which gives us zero.
This patch fixes the problem by introducing a new callback to
read the contents of a register as a given type, and then adjust
the handling of DW_OP_GNU_regval_type to use that new callback.
gdb/ChangeLog:
* dwarf2expr.h (struct dwarf_expr_context_funcs) <read_reg>:
Extend the documentation a bit.
<get_reg_value>: New field.
* dwarf2loc.c (dwarf_expr_get_reg_value)
(needs_frame_get_reg_value): New functions.
(dwarf_expr_ctx_funcs, needs_frame_ctx_funcs): Add "get_reg_value"
callback.
* dwarf2-frame.c (get_reg_value): New function.
(dwarf2_frame_ctx_funcs): Add "get_reg_value" callback.
* dwarf2expr.c (execute_stack_op) <DW_OP_GNU_regval_type>:
Use new callback to compute result_val.
gdb/testsuite/ChangeLog:
* gdb.ada/O2_float_param: New testcase.
Pedro pointed out that it is handy for "make check" to print a summary
of the results. This happens in the check-single case and also if you
invoke runtest by hand.
This patch implements the same thing for check-parallel.
2013-11-14 Tom Tromey <tromey@redhat.com>
* Makefile.in (check-parallel): Print summary from gdb.sum.
dw2-case-insensitive.exp: p fuNC_lang fails on arm. The problem occurs
when thumb mode code is generated. On ARM last bit of function pointer
value indicates whether the target function is an ARM (if 0) or Thumb
(if 1) routine. The PC address should refer to actual address in
either case. This patch adds new compile unit and function labels to
code which act as address ranges of compile unit and functions in
debug information. Therefore address ranges will have correct
addresses and not the ones with an incremented least significant bit.
This patch has been tested on x86_64 and arm machines.
gdb/testsuite/ChangeLog:
2013-11-14 Omair Javaid <Omair.Javaid@linaro.org>
* gdb.dwarf2/dw2-case-insensitive-debug.S: Updated compile unit
and function label names.
* gdb.dwarf2/dw2-case-insensitive.c: Created function and
compile unit labels.
Frontend sometimes need to evaluate expressions that are
language-specific. For instance, Eclipse uses the following
expression to determine the size of an address on the target:
-data-evaluate-expression "sizeof (void*)"
Unfortunately, if the main of the program being debugged is not C,
this may not work. For instance, if the main is in Ada, you get...
-data-evaluate-expression "sizeof (void*)"
^error,msg="No definition of \"sizeof\" in current context."
... and apparently decides to stop the debugging session as a result.
The recommendation sent was to specifically set the language to C
before trying to evaluate the expression. Something such as:
1. save current language
2. set language c
3. -data-evaluate-expression "sizeof (void*)"
4. Restore language
This has the same disadvantages as the ones outlined in the "Context
Management" section of the GDB/MI documentation regarding setting
the current thread or the current frame, thus recommending the use of
general command-line switches such as --frame, or --thread instead.
This patch follows the same steps for the language, adding a similar
new command option: --language LANG. Example of use:
-data-evaluate-expression --language c "sizeof (void*)"
^done,value="4"
gdb/ChangeLog:
* mi/mi-parse.h (struct mi_parse) <language>: New field.
* mi/mi-main.c (mi_cmd_execute): Temporarily set language to
PARSE->LANGUAGE during command execution, if set.
* mi/mi-parse.c: Add "language.h" #include.
(mi_parse): Add parsing of "--language" command option.
* NEWS: Add entry mentioning the new "--language" command option.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-language.exp: New file.
gdb/doc/ChangeLog:
* gdb.texinfo (Show): Add xref anchor for "show language" command.
(Context management): Place current subsection text into its own
subsubsection. Add new subsubsection describing the "--language"
command option.
I noticed today that multi-arch-exec.exp was failing in parallel mode.
The bug is that multi-arch-exec.c assumes the non-parallel directory
layout.
This patch fixes the problem using the same "BASEDIR" approach used in
other tests.
Tested both ways on x86-64 Fedora 18.
I'm checking this in.
2013-11-13 Tom Tromey <tromey@redhat.com>
* gdb.multi/multi-arch-exec.exp: Define BASEDIR when compiling.
* gdb.multi/multi-arch-exec.c (main): Use BASEDIR.
This patch implements a new GDB/MI command implementing the equivalent
of the "info exceptions" CLI command. The command syntax is:
-info-ada-exceptions [REGEXP]
Here is an example of usage (slightly formatted by hand to make it
easier to read):
-info-ada-exceptions ions\.a_
^done,ada-exceptions=
{nr_rows="2",nr_cols="2",
hdr=[{width="1",alignment="-1",col_name="name",colhdr="Name"},
{width="1",alignment="-1",col_name="address",colhdr="Address"}],
body=[{name="global_exceptions.a_global_exception",
address="0x0000000000613a80"},
{name="global_exceptions.a_private_exception",
address="0x0000000000613ac0"}]}
Also, in order to allow graphical frontends to easily determine
whether this command is available or not, the output of the
"-list-features" command has been augmented to contain
"info-ada-exceptions".
gdb/Changelog:
* mi/mi-cmds.h (mi_cmd_info_ada_exceptions): Add declaration.
* mi/mi-cmds.c (mi_cmds): Add entry for -info-ada-exceptions
command.
* mi/mi-cmd-info.c: #include "ada-lang.c" and "arch-utils.c".
(mi_cmd_info_ada_exceptions): New function.
* mi/mi-main.c (mi_cmd_list_features): Add "info-ada-exceptions".
gdb/testsuite/ChangeLog:
* gdb.ada/mi_exc_info: New testcase.
This patch adds a new command "info exceptions" whose purpose is to
provide the list of exceptions currently defined in the inferior.
The usage is:
(gdb) info exceptions [REGEXP]
Without argument, the command lists all exceptions. Otherwise,
only those whose name match REGEXP are listed.
For instance:
(gdb) info exceptions
All defined Ada exceptions:
constraint_error: 0x613dc0
program_error: 0x613d40
storage_error: 0x613d00
tasking_error: 0x613cc0
global_exceptions.a_global_exception: 0x613a80
global_exceptions.a_private_exception: 0x613ac0
The name of the command, as well as its output is part of a legacy
I inherited long ago. It's output being parsed by frontends such as
GPS, I cannot easily change it. Same for the command name.
The implementation is mostly self-contained, and is written in a way
that should make it easy to implement the GDB/MI equivalent. The
careful reviewer will notice that the code added in ada-lang.h could
normally be made private inside ada-lang.c. But these will be used
by the GDB/MI implementation. Rather than making those private now,
only to move them later, I've made them public right away.
gdb/ChangeLog:
* ada-lang.h: #include "vec.h".
(struct ada_exc_info): New.
(ada_exc_info): New typedef.
(DEF_VEC_O(ada_exc_info)): New vector.
(ada_exceptions_list): Add declaration.
* ada-lang.c (ada_is_exception_sym)
(ada_is_non_standard_exception_sym, compare_ada_exception_info)
(sort_remove_dups_ada_exceptions_list)
(ada_exc_search_name_matches, ada_add_standard_exceptions)
(ada_add_exceptions_from_frame, ada_add_global_exceptions)
(ada_exceptions_list_1, ada_exceptions_list)
(info_exceptions_command): New function.
(_initialize_ada_language): Add "info exception" command.
gdb/testsuite/ChangeLog:
* gdb.ada/info_exc: New testcase.
When using the GDB/MI commands to insert a catchpoint on a specific
Ada exception, any re-evaluation of that catchpoint (for instance
a re-evaluation performed after a shared library got mapped by the
inferior) fails. For instance, with any Ada program:
(gdb)
-catch-exception -e program_error
^done,bkptno="1",bkpt={[...]}
(gdb)
-exec-run
=thread-group-started,id="i1",pid="28315"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,[...]
&"warning: failed to reevaluate internal exception condition for catchpoint 1: No definition of \"exec\" in current context.\n"
&"warning: failed to reevaluate internal exception condition for catchpoint 1: No definition of \"exec\" in current context.\n"
[...]
The same is true if using an Ada exception catchpoint.
The problem comes from the fact that that we deallocate the strings
given as arguments to create_ada_exception_catchpoint, while the latter
just makes shallow copies of those strings, thus creating dandling
pointers.
This patch fixes the issue by passing freshly allocated strings to
create_ada_exception_catchpoint, while at the same time updating
create_ada_exception_catchpoint's documentation to make it clear
that deallocating the strings is no longer the responsibility of
the caller.
gdb/ChangeLog:
* ada-lang.c (create_ada_exception_catchpoint): Enhance
the documentation of fields "except_string" and "condition".
* mi/mi-cmd-catch.c (mi_cmd_catch_assert): Reallocate
CONDITION on the heap before passing it to
create_ada_exception_catchpoint.
(mi_cmd_catch_exception): Likewise for EXCEPTION_NAME and
CONDITION.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_ex_cond: New testcase.
Tested on x86_64-linux. The "-break-list" test FAILs without
this patch.
* python/py-breakpoint.c (bppy_get_temporary): New function.
(bppy_init): New keyword: temporary. Parse it and set breakpoint
to temporary if True.
2013-11-07 Phil Muldoon <pmuldoon@redhat.com>
* gdb.python/py-breakpoint.exp: Add temporary breakpoint tests.
2013-11-07 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Breakpoints In Python): Document temporary
option in breakpoint constructor, and add documentation to the
temporary attribute.
This patch is to add a test case to on the performance of GDB handling
load and unload of shared library.
In V4:
- Handle malloc and dlopen failure,
- Document test parameters.
In V3, there are some changes,
- Adapt to perf test framework changes.
- Measure load and unload separately.
In V2, there are some changes,
- A new proc gdb_produce_source to produce source files. I tried to
move all source file generation code out of solib.exp, but
compilation step still needs to know the generated file names. I
have to hard-code the file names in compilation step, which is not
good to me, so I give up on this moving.
- SOLIB_NUMBER -> SOLIB_COUNT
- New variable SOLIB_DLCLOSE_REVERSED_ORDER to control the order of
iterating a list of shared libs to dlclose them.
- New variable GDB_PERFORMANCE to enable these perf test cases.
- Remove dlsym call in solib.c.
- Update solib.py for the updated framework.
gdb/testsuite/
* lib/gdb.exp (gdb_produce_source): New procedure.
* gdb.perf/solib.c: New.
* gdb.perf/solib.exp: New.
* gdb.perf/solib.py: New.
This patch adds a basic framework to do performance testing for GDB.
perftest.py is about the test case, testresult.py is about test
results, and how are they saved. reporter.py is about how results
are reported (in what format). measure.py is about measuring the
execution of tests by a collection of measurements.
In V5:
- Simplify perftest.exp.
In V4:
- Rename MeasurementCPUTime to MeasurementCpuTime,
- Add 'pass' in empty method,
- Simplify string comparison in perftest.exp.
- Rename GDB_PERFORMANCE to GDB_PERFTEST_MODE and rename
GDB_PERFORMANCE_TIMEOUT to GDB_PERFTEST_TIMEOUT.
In V3, there are some changes,
- Add wall time measurement, cpu time measurement and vmsize
measurement.
- Rename SingleStatisticTestCase to TestCaseWithBasicMeasurements,
which measures cpu time, wall time, and memory (vmsize).
- GDB_PERFORMANCE=run|compile|both to control the mode of perf
testing.
- New GDB_PERFORMANCE_TIMEOUT to specify the timeout.
- Split proc prepare to proc compile and startup.
- Disable GC while doing measurements.
In V2, there are several changes to address Doug and Sanimir's
comments.
- Add copyright header and docstring in perftest/__init__.py
- Remove config.py.
- Fix docstring format.
- Rename classes "SingleVariable" to "SingleStatistic".
- Don't extend gdb.Function in class TestCase. Add a new method run
to run the test case so that we can pass parameters to test.
- Allow to customize whether to warm up and to append test log.
- Move time measurement into test harness. Add a new class
Measurement for a specific measurement and a new class Measure to
measure them for a given test case.
- A new class ResultFactory to create instances of TestResult.
- New file lib/perftest.exp, which is to do some preparations and
cleanups to simplify each *.exp file.
- Skip compilation step if GDB_PERFORMANCE_SKIP_COMPILE is set.
gdb/testsuite/
2013-11-06 Yao Qi <yao@codesourcery.com>
* lib/perftest.exp: New.
* gdb.perf/lib/perftest/__init__.py: New.
* gdb.perf/lib/perftest/measure.py: New.
* gdb.perf/lib/perftest/perftest.py: New.
* gdb.perf/lib/perftest/reporter.py: New.
* gdb.perf/lib/perftest/testresult.py: New.
We add a new dir gdb.perf in testsuite for all performance tests.
However, current 'make check' logic will either run dejagnu in
directory testsuite or iterate all gdb.* directories which has *.exp
files. Both of them will run tests in gdb.perf. We want to achieve:
1) typical 'make check' should not run performance tests. In each perf
test case, GDB_PERFTEST_MODE is checked. If it doesn't exist, return.
2) run perf tests easily. We add a new makefile target 'check-perf'.
gdb:
2013-11-06 Yao Qi <yao@codesourcery.com>
* Makefile.in (check-perf): New target.
gdb/testsuite:
2013-11-06 Yao Qi <yao@codesourcery.com>
* Makefile.in (check-perf): New target.
* configure.ac (AC_OUTPUT): Output Makefile in gdb.perf.
* configure: Re-generated.
* gdb.perf/Makefile.in: New.
This switches "make check" to fully parallel mode.
One primary issue facing full parallelization is the overhead of
"runtest". On my machine, if I "touch gdb.base/empty.exp", making a
new file, and then "time runtest.exp", it takes 0.08 seconds.
Multiply this by the 1008 (in my configuration) tests and you get ~80
seconds. This is the overhead that would theoretically be present if
all tests were run in parallel.
However, the problem isn't nearly as bad as this, for two reasons.
First, you must divide by the number of jobs, assuming perfect
parallelization -- reasonably true for small -j numbers, based on the
results I see.
Second, the current test suite parallelization approach bundles the
tests, largely by directory, but also splitting up gdb.base into two
halves.
I was curious to see how the current bundling played out in practice,
so I ran "make -j1 check RUNTEST='/bin/time runtest'". This invokes
the parallel mode (thus the bundling) and then shows the time taken by
each invocation of runtest.
Then, I ran "/bin/time make -j3 check". (See below about -j2.)
The time for the entire -j3 test run was the same as the time for
"gdb.base1". What this means is that gdb.base1 is currently the
time-limiting run, preventing further parallelization gains.
So, I reason, whatever overhead we see from full parallelization will
only be seen by "-j1" and "-j2".
I then tried a -j2 test run. This does take longer than a -j3 build,
meaning that the gdb.base1 job finishes and then proceeds to other
runtest invocations.
Finally I tried a -j2 test run with the appended patch.
This was 9% slower than the -j2 run without the patch.
I think that is a reasonable slowdown for what is probably a rare
case. I believe this patch will yield faster test results for all -j
values greater than 2. For -j3 on my machine, the test suite is a few
seconds faster; I didn't try any larger -j values.
For -j1, I went ahead and changed the Makefile so that, if no -j
option is given, then the "check-single" mode is used. You can still
use "make -j1 check" to get single-job parallel-mode, though of course
there's no good reason to do so.
This change is likely to speed up the plain "make check" scenario a
little as we will now bypass dg-extract-results.sh.
One drawback of this change is that "make -jN check" is now much more
verbose. I generally only look at the .sum and .log files, but
perhaps this will bother some.
Another interesting question is scalability of the result. The
slowest test, which limits the scalability, took 80.78 seconds. The
mean of the remaining tests is 1.08 seconds. (Note that this is just
a rough estimate, since there are still outliers.)
This means we can run 80.78 / 1.08 =~ 74 tests in the time available.
And, in this data set (slightly older than the above, but materially
the same) there were 948 tests. So, I think the current test suite
should scale ok up to about -j12.
We could improve this number if need be by breaking up the biggest
tests.
2013-11-04 Tom Tromey <tromey@redhat.com>
* Makefile.in (TEST_DIRS): Remove.
(TEST_TARGETS, check-parallel): Rewrite.
(check-gdb.%, BASE1_FILES, BASE2_FILES, check-gdb.base%)
(subdir_do, subdirs): Remove.
(do-check-parallel, check/%): New targets.
(clean): Remove outputs, temp, and cache directories.
(saw_dash_j): New variable.
(CHECK_TARGET): Use it.
(check): Depend on all, site.exp. Rewrite.
(check-single): Remove dependencies.
(slow_tests, all_tests, reordered_tests): New variables.
A couple of Fission tests rely on the current directory layout. This
assumption is not valid in parallel mode.
This patch fixes the problem by removing the relative directory from
the .S files and instead having the tests set debug-file-directory
before opening the main file.
2013-11-04 Tom Tromey <tromey@redhat.com>
* gdb.dwarf2/fission-base.S: Remove "gdb.dwarf/".
* gdb.dwarf2/fission-base.exp: Set debug-file-directory
before loading binfile.
* gdb.dwarf2/fission-loclists.S: Remove "gdb.dwarf/".
* gdb.dwarf2/fission-loclists.exp: Set debug-file-directory
before loading binfile.
A few tests run an inferior that execs some other program. The name
of this exec'd program is compiled in. These tests assume the current
test suite directory layout, but fail in parallel mode.
This patch fixes these tests by letting the .exp files pass in the
directory names at compile time.
2013-11-04 Tom Tromey <tromey@redhat.com>
* gdb.base/foll-exec.c (main): Use BASEDIR.
* gdb.base/foll-exec.exp: Define BASEDIR during compilation.
* gdb.base/foll-vfork.c (main): Use BASEDIR.
* gdb.base/foll-vfork.exp: Define BASEDIR during compilation.
* gdb.multi/bkpt-multi-exec.c (main): Use BASEDIR.
* gdb.multi/bkpt-multi-exec.exp: Define BASEDIR during compilation.
argv0-symlink.exp doesn't work properly if standard_output_file puts
files into a per-test subdirectory. That's because it assumes that
files appear in $subdir, which is no longer true.
This patch fixes the problem by computing the correct directory at
runtime.
Tested both with and without GDB_PARALLEL on x86-64 Fedora 18.
2013-11-04 Tom Tromey <tromey@redhat.com>
* gdb.base/argv0-symlink.exp: Compute executable's directory
dynamically.
This introduces a new relative_filename proc to gdb.exp and changes
some tests to use it. This helps make these tests parallel-safe.
2013-11-04 Tom Tromey <tromey@redhat.com>
* gdb.base/fullname.exp: Use standard_output_file,
relative_filename.
* gdb.base/hashline1.exp: Use standard_testfile,
standard_output_file, relative_filename, clean_restart.
* gdb.base/hashline2.exp: Use standard_testfile,
standard_output_file.
* gdb.base/hashline3.exp: Use standard_testfile,
standard_output_file, relative_filename.
* lib/gdb.exp (relative_filename): New proc.
This updates the fileio test to be parallel-safe.
2013-11-04 Tom Tromey <tromey@redhat.com>
* gdb.base/fileio.c (test_open, test_write, test_read)
(test_lseek, test_close, test_stat, test_fstat)
(test_isatty, test_system, test_rename, test_unlink):
Use OUTDIR define.
* gdb.base/fileio.exp: Define OUTDIR during compilation.
Use standard_output_file.
This fixes the "checkpoint" test to use the standard output directory.
This makes the test be parallel-safe.
2013-11-04 Tom Tromey <tromey@redhat.com>
* gdb.base/checkpoint.c (main): Use PI_TXT and COPY1_TXT
defines.
* gdb.base/checkpoint.exp: Define PI_TXT and COPY1_TXT during
compilation. Use prepare_for_testing, standard_output_file.
This makes more changes in gdb.base to make it parallel-safe. I think
the changes in this particular patch are relatively straightforward,
so I've grouped them all together.
2013-11-04 Tom Tromey <tromey@redhat.com>
* gdb.base/advance.exp: Use standard_testfile and
prepare_for_testing.
* gdb.base/bigcore.exp: Use standard_output_file. "cd" to
appropriate directory when local.
* gdb.base/dump.exp: Use standard_output_file. Update all
"dump" and "restore" filenames.
* gdb.base/interact.exp: Use standard_output_file.
* gdb.base/jit-so.exp: Don't download file when local.
* gdb.base/jit.exp (compile_jit_test): Don't download file
when local.
* gdb.base/list.exp: Use gdb_remote_download.
* gdb.base/maint.exp: Use standard_output_file.
* gdb.base/prelink.exp: Use standard_output_file.
* gdb.base/save-bp.exp: Use standard_output_file.
* gdb.base/sepdebug.exp: Use standard_testfile,
standard_output_file.
(test_different_dir): Don't declare objdir.
* gdb.base/solib-search.exp: Use standard_output_file.
* gdb.base/step-line.exp: Use gdb_remote_download.
* gdb.base/trace-commands.exp: Use standard_output_file.
This fixes gdb.trace to be parallel-safe.
2013-11-04 Tom Tromey <tromey@redhat.com>
* gdb.trace/mi-traceframe-changed.exp: Pass -DTFILE_DIR
to compilation. Use standard_output_file.
(test_tfind_tfile): Update.
* gdb.trace/tfile.c (write_basic_trace_file)
(write_error_trace_file): Use TFILE_DIR.
* gdb.trace/tfile.exp: Pass -DTFILE_DIR to compilation. Use
standard_output_file.
This fixes gdb.mi to be parallel-safe.
2013-11-04 Tom Tromey <tromey@redhat.com>
* gdb.mi/mi-cmd-param-changed.exp (test_command_param_changed):
Use "dwarf2 always-disassemble" for the "maint set" test.
* gdb.mi/mi-file-transfer.exp (test_file_transfer): Use
standard_output_file.
* gdb.mi/mi-logging.exp: Use standard_output_file.
This fixes the gdb.xml tests to be parallel-safe.
2013-11-04 Tom Tromey <tromey@redhat.com>
* gdb.xml/tdesc-arch.exp: Use standard_output_file. Make
downloads conditional on remote host.
(set_arch): Likewise.
* gdb.xml/tdesc-regs.exp: Use gdb_remote_download.
(load_description): Use standard_output_file.
This fixes the gdb.gdb tests to be parallel-safe, by ensuring that the
new "xgdb" file ends up in the standard output directory during the
tests.
2013-11-04 Tom Tromey <tromey@redhat.com>
* gdb.gdb/selftest.exp: Use standard_output_file.
* lib/selftest-support.exp (do_self_tests): Use
standard_output_file.
This fixes up gdb.stabs/weird.exp for parallel testing. This just
means using gdb_remote_download and standard_output_file, so that the
tests end up in the right place.
2013-11-04 Tom Tromey <tromey@redhat.com>
* gdb.stabs/weird.exp: Use gdb_remote_download and
standard_output_file.
This fixes some parallelization thinkos from a while ago. I'm not
sure how the problems ever slipped through. In addition to a thinko
fix in twice.exp, this also finishes fixing it up for parallelization.
2013-11-04 Tom Tromey <tromey@redhat.com>
* gdb.base/gcore-buffer-overflow.exp: Use
standard_output_file, not standard_testfile.
* gdb.base/twice.exp: Use standard_testfile, not
standard_output_file. Use gdb_remote_download.
Currently a proc in gdb.exp toggles the expect (and thus dejagnu)
logging. This is not a super idea, but it is there to avoid putting
some preprocessor output into the log.
In the right circumstances, this can result in the log file being
mysteriously truncated. I think this happens because it doesn't
necessarily write to the correct log file again.
The fix is to use "log_file -info" to save the previous log file.
2013-11-04 Tom Tromey <tromey@redhat.com>
* lib/gdb.exp (get_compiler_info): Use log_file -info and
restore from that.
Correct the patterns in the gdb_test_multiple invocation.
testsuite/
2013-10-30 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.arch/s390-multiarch.exp (test_linux_v2): Add $gdb_prompt to
the patterns in gdb_test_multiple.
These references to ChangeLog-mi are stale.
testsuite/gdb.mi/ChangeLog-mi doesn't exist anymore, since:
...
commit 2dd627049d
Author: Andrew Cagney <cagney@redhat.com>
Date: Sat Jun 23 21:47:09 2001 +0000
Rename gdb.mi/ChangeLog-mi to gdb.mi/ChangeLog. Update everything.
...
commit 48efe7049b
Author: Andrew Cagney <cagney@redhat.com>
Date: Mon Jan 12 15:16:44 2004 +0000
Eliminate the old mi/tui specific ChangeLog files as in ...
Added Files:
mi/ChangeLog-1999-2003 testsuite/gdb.mi/ChangeLog-1999-2003
tui/ChangeLog-1998-2003
Removed Files:
mi/ChangeLog testsuite/gdb.mi/ChangeLog tui/ChangeLog
Tested with 'make check RUNTESTFLAGS="--directory=gdb.mi"' on x86_64 Fedora 17.
gdb/testsuite/
2013-10-29 Pedro Alves <palves@redhat.com>
* gdb.mi/mi-console.c, gdb.mi/mi-stack.c: Remove local emacs
variable setting change-log-default-name to ChangeLog-mi.
https://sourceware.org/ml/gdb-patches/2013-08/msg00171.html
gdb/ChangeLog
* infcmd.c (default_print_one_register_info): Use val_print to
print all values even optimized out or unavailable ones. Don't
try to print a raw form of optimized out or unavailable values.
gdb/testsuite/ChangeLog
* gdb.trace/unavailable.exp (gdb_unavailable_registers_test):
Expect <unavailable> pattern.
This test exercises the commands 'add-symbol-file'
and 'remove-symbol-file'.
2013-10-29 Nicolas Blanc <nicolas.blanc@intel.com>
gdb/testsuite
* gdb.base/sym-file-lib.c: New file.
* gdb.base/sym-file-loader.c: New file.
* gdb.base/sym-file-loader.h: New file.
* gdb.base/sym-file-main.c: New file.
* gdb.base/sym-file.exp: New file.
Signed-off-by: Nicolas Blanc <nicolas.blanc@intel.com>
2013-10-29 Nicolas Blanc <nicolas.blanc@intel.com>
gdb/testsuite
* lib/gdb.exp (is_elf_target): New function.
Signed-off-by: Nicolas Blanc <nicolas.blanc@intel.com>
Some remote stubs do not have a proper exit() function implementation.
gdb.base/bang.exp was failing on those targets due to timeout. With
this patch bang.exp uses already defined library procedures to handle
this situation gracefully without breaking native targets.
Tested with x86_64 (unix, native-gdbserver) and with arc-*-elf32.
gdb/testsuite/ChangeLog:
2013-10-25 Anton Kolesov <Anton.Kolesov@synopsys.com> (tiny change)
* gdb.base/bang.exp: Use gdb_continue_to_end to properly support
remote stubs where exit() behaviour is unreliable.
With:
struct static_struct { static int aaa; };
struct static_struct sss;
int main () { return 0; }
We get:
(gdb) p sss
$1 = {static aaa = <optimized out>}
(gdb) p sss.aaa
field aaa is nonexistent or has been optimized out
Note that the "field aaa ..." message is an error being thrown.
GDB is graceful everywhere else when printing optimized out values.
IOW it usually prints an <optimized out> value and puts that in the
value history. I see no reason for here to be different, more so that
when the print the whole "containing" object (well, it's a static
field, so it's not really a container), we already print <optimized
out>.
After the patch:
(gdb) p sss
$1 = {static aaa = <optimized out>}
(gdb) p sss.aaa
$2 = <optimized out>
The value_entirely_optimized_out checks are there to preserve
behavior. Without those, if the static field is a struct/union, GDB
would go and print its fields one by one (and print <optimized out>
for each).
Tested on x86_64 Fedora 17.
gdb/
2013-10-25 Pedro Alves <palves@redhat.com>
* cp-valprint.c (cp_print_value_fields): No longer handle a NULL
static field value.
(cp_print_static_field): If the value is entirely optimized out,
print <optimized out> here.
* jv-valprint.c (java_print_value_fields): No longer handle a NULL
static field value.
* p-valprint.c (pascal_object_print_static_field): If the value is
entirely optimized out, print <optimized out> here.
* valops.c (do_search_struct_field)
(value_struct_elt_for_reference): No longer handle a NULL static
field value.
* value.c (value_static_field): Return an optimized out value
instead of NULL.
gdb/testsuite/
2013-10-25 Pedro Alves <palves@redhat.com>
* gdb.cp/m-static.exp: Adjust expected output of printing a
nonexistent or optimized out static field. Also test printing the
the "container" object.
* lib/gdb.exp (gdb_finish): Send a kill request to `gdbserver'
if in the persistent mode.
* gdb.trace/disconnected-tracing.exp: Reconnect before completion.
gdb/
* linux-tdep.c (linux_corefile_thread_callback): Propagate any
failure from register information collection.
gdb/testsuite/
* lib/gdb.exp (gdb_gcore_cmd): Also handle a "Target does not
support core file generation" reply.
PR gdb/15986
* gdb.base/run.c (main): gdb_get_line_number tag added for
commands.exp.
(factorial): Likewise.
* gdb.base/commands.exp (watchpoint_command_test): Use
gdb_get_line_number in order to determine the locations in run.c
where local_var is detected to go out of scope.
https://sourceware.org/ml/gdb-patches/2013-10/msg00477.html
gdb/ChangeLog
* breakpoint.c (update_watchpoint): If hardware watchpoints are
forced off, downgrade them to software watchpoints if possible,
and error out if not possible.
(watch_command_1): Move watchpoint type selection closer to
watchpoint creation, and extend the comments.
gdb/testsuite/ChangeLog
* gdb.base/watchpoints.exp: Add test for setting software
watchpoints of different types before starting the inferior.
I noticed something odd while doing "stepi" over a fork syscall:
...
(gdb) set disassemble-next-line on
...
(gdb) si
0x000000323d4ba7c2 131 pid = ARCH_FORK ();
0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00 mov %fs:0x10,%r8
0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx
0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea 0x2d0(%r8),%r10
0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi
0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov $0x1200011,%edi
0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov $0x38,%eax
=> 0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall
0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax
0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja 0x323d4ba8fb <__libc_fork+475>
(gdb) si
0x000000323d4ba7c4 131 pid = ARCH_FORK ();
0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00 mov %fs:0x10,%r8
0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx
0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea 0x2d0(%r8),%r10
0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi
0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov $0x1200011,%edi
0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov $0x38,%eax
0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall
=> 0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax
0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja 0x323d4ba8fb <__libc_fork+475>
(gdb) si
0x000000323d4ba7c4 131 pid = ARCH_FORK ();
0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00 mov %fs:0x10,%r8
0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx
0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea 0x2d0(%r8),%r10
0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi
0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov $0x1200011,%edi
0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov $0x38,%eax
0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall
=> 0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax
0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja 0x323d4ba8fb <__libc_fork+475>
(gdb) si
0x000000323d4ba7ca 131 pid = ARCH_FORK ();
0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00 mov %fs:0x10,%r8
0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx
0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea 0x2d0(%r8),%r10
0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi
0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov $0x1200011,%edi
0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov $0x38,%eax
0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall
0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax
=> 0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja 0x323d4ba8fb <__libc_fork+475>
Notice how the third "si" didn't actually make progress.
Turning on infrun and lin-lwp debug, we see:
(gdb)
infrun: clear_proceed_status_thread (process 5252)
infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1)
infrun: resume (step=1, signal=0), trap_expected=0, current thread [process 5252] at 0x323d4ba7c4
LLR: Preparing to step process 5252, 0, inferior_ptid process 5252
RC: Not resuming sibling process 5252 (not stopped)
LLR: PTRACE_SINGLESTEP process 5252, 0 (resume event thread)
sigchld
infrun: wait_for_inferior ()
linux_nat_wait: [process -1], []
LLW: enter
LNW: waitpid(-1, ...) returned 5252, No child processes
LLW: waitpid 5252 received Child exited (stopped)
LLW: Candidate event Child exited (stopped) in process 5252.
SEL: Select single-step process 5252
LLW: exit
infrun: target_wait (-1, status) =
infrun: 5252 [process 5252],
infrun: status->kind = stopped, signal = SIGCHLD
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x323d4ba7c4
infrun: random signal 20
infrun: stepi/nexti
infrun: stop_stepping
So the inferior got a SIGCHLD (because the fork child exited while
we're doing 'si'), and since that signal is set to "nostop noprint
pass" (by default), it's considered a random signal, so it should not
cause a stop. But, it resulted in an immediate a stop_stepping call
anyway. So the single-step never really finished.
This is a regression caused by:
[[PATCH] Do not respawn signals, take 2.]
https://sourceware.org/ml/gdb-patches/2012-06/msg00702.html
Specifically, caused by this change (as mentioned in the "the lost
step issue first" part of that mail):
diff --git a/gdb/infrun.c b/gdb/infrun.c
index 53db335..3e8dbc8 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -4363,10 +4363,8 @@ process_event_stop_test:
(leaving the inferior at the step-resume-breakpoint without
actually executing it). Either way continue until the
breakpoint is really hit. */
- keep_going (ecs);
- return;
}
-
+ else
/* Handle cases caused by hitting a breakpoint. */
{
That made GDB fall through to the
> /* In all-stop mode, if we're currently stepping but have stopped in
> some other thread, we need to switch back to the stepped thread. */
> if (!non_stop)
part. However, if we don't have a stepped thread to get back to,
we'll now also fall through to all the "stepping" tests. For line
stepping, that'll turn out okay, as we'll just end up realizing the
thread is still in the stepping range, and needs to be re-stepped.
However, for stepi/nexti, we'll reach:
if (ecs->event_thread->control.step_range_end == 1)
{
/* It is stepi or nexti. We always want to stop stepping after
one instruction. */
if (debug_infrun)
fprintf_unfiltered (gdb_stdlog, "infrun: stepi/nexti\n");
ecs->event_thread->control.stop_step = 1;
print_end_stepping_range_reason ();
stop_stepping (ecs);
return;
}
and stop, even though the thread actually made no progress. The fix
is to restore the keep_going call, but put it after the "switch back
to the stepped thread" code, and before the stepping tests.
Tested on x86_64 Fedora 17, native and gdbserver. New test included.
gdb/
2013-10-18 Pedro Alves <palves@redhat.com>
PR gdb/16062
* infrun.c (handle_inferior_event): Keep going if we got a random
signal we should not stop for, instead of falling through to the
step tests.
gdb/testsuite/
2013-10-18 Pedro Alves <palves@redhat.com>
PR gdb/16062
* gdb.threads/stepi-random-signal.c: New file.
* gdb.threads/stepi-random-signal.exp: New file.
This patch fixes PR gdb/15995.
The bug here is that gdb's printf command does not flush the output
stream. This makes a printf that is not newline-terminated interleave
incorrectly with other forms of output, such as that generated via a
call to an external program using "shell".
I note that the "output" command already does this flushing.
The fix is to call gdb_flush in printf_command.
Built and regtested on x86-64 Fedora 18.
New test case included.
PR gdb/15995:
* printcmd.c (printcmd): Call gdb_flush.
* gdb.base/printcmds.exp (test_printf): Test printf flushing.
gdb/
2013-10-13 Jan Kratochvil <jan.kratochvil@redhat.com>
Canonicalize directories for EXEC_FILENAME.
* exec.c (exec_file_attach): Use gdb_realpath_keepfile for
exec_filename.
* utils.c (gdb_realpath_keepfile): New function.
* utils.h (gdb_realpath_keepfile): New declaration.
gdb/testsuite/
2013-10-13 Jan Kratochvil <jan.kratochvil@redhat.com>
Canonicalize directories for EXEC_FILENAME.
* gdb.base/argv0-symlink.exp
(kept file symbolic link name for info inferiors): New.
(kept directory symbolic link name): Setup kfail.
(kept directory symbolic link name for info inferiors): New.
... in place of the CLI "catch ..." commands. The latter were used
because the GDB/MI equivalents were not available at the time.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_catch_ex.exp: Adjusts all "catch ..." tests to
use the appropriate GDB/MI command instead, and verify
the test output.
Consider the following example:
% gdb -q -batch -ex 'source nonexistant-file'
[nothing]
One would have at least expected the debugger to warn about
not finding the file, similar to the error shown when using
a more interactive mode. Eg:
(gdb) source nonexistant-file
nonexistant-file: No such file or directory.
Not raising an error appears to be intentional, presumably in order
to prevent this situation from stoping the execution of a GDB script.
But the lack of at least a warning makes it harder for a user to
diagnose any issue, if the file was expected to be there and readable.
This patch adds a warning in that case:
% gdb -q -batch -ex 'source nonexistant-file'
warning: nonexistant-file: No such file or directory.
gdb/ChangeLog:
* utils.h (perror_warning_with_name): Add declaration.
* utils.c (perror_warning_with_name): New function.
* cli/cli-cmds.c (source_script_with_search): Add call to
perror_warning_with_name if from_tty is nul.
gdb/testsuite/ChangeLog:
* gdb.base/source-nofile.gdb: New file.
* gdb.base/source.exp: Add two tests verifying the behavior when
the "source" command is given a non-existant filename.
* gdb.mi/mi-catch-load.c: Remove the include of "dlfcn.h".
[__WIN32__]: Include "windows.h" and define macro 'dlopen'
and 'dlclose'.
[!__WIN32__]: Include "dlfcn.h".
* gdb.mi/mi-catch-load.exp: Set up kfail.
target_read_memory & friends build on top of target_read (thus on top
of the target_xfer machinery), but turn all errors to EIO, an errno
value. I think we'd better convert all these to return a
target_xfer_error too, like target_xfer_partial in a previous patch.
The patch starts by doing that.
(The patch does not add a enum target_xfer_error value for '0'/no
error, and likewise does not change the return type of several of
these functions to enum target_xfer_error, because different functions
return '0' with different semantics.)
I audited the tree for memory_error calls, EIO checks, places where
GDB hardcodes 'errno = EIO', and also for strerror calls. What I
found is that nowadays there's really no need to handle random errno
values, other than the EIOs gdb itself hardcodes. No doubt errno
values would appear in common code back in the day when
target_xfer_memory was the main interface to access memory, but
nowadays, any errno value that deprecated interface could return is
just absorved by default_xfer_partial:
else if (xfered == 0 && errno == 0)
/* "deprecated_xfer_memory" uses 0, cross checked against
ERRNO as one indication of an error. */
return 0;
else
return -1;
There are two places in the code that check for EIO and print "out of
bounds", and defer to strerror for other errors. That's
c-lang.c:c_get_string, and valprint.c.:val_print_string. AFAICT, the
strerror branch can never be reached nowadays, as the only error
possible to get at those points is EIO, given that it's GDB itself
that set that errno value (in target_read_memory, etc.).
breakpoint.c:insert_bp_location always prints the error val as if an
errno, returned by target_insert_breakpoint, with strerr. Now the
error here is either always EIO for mem-break.c targets (again
hardcoded by the target_read_memory/target_write_memory functions), so
this always prints "Input/output error" or similar (depending on
host), or, for remote targets (and probably others), this gem:
Error accessing memory address 0x80200400: Unknown error -1.
This patch makes these 3 places print the exact same error
memory_error prints. This changes output, but I think this is better,
for making memory error output consistent with other commands, and, it
means we have a central place to tweak for memory errors.
E.g., this changes:
Cannot insert breakpoint 1.
Error accessing memory address 0x5fc660: Input/output error.
to:
Cannot insert breakpoint 1.
Cannot access memory at address 0x5fc660
Which I find pretty much acceptable.
Surprisingly, only py-prettyprint.exp had a regression, for needing an
adjustment. I also grepped the testsuite for the old errors, and
found no other hits.
Now that errno values aren't used anywhere in any of these memory
access related routines, I made memory_error itself take a
target_xfer_error instead of an errno. The new
target_xfer_memory_error function added recently is no longer
necessary, and is thus removed.
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/
2013-10-09 Pedro Alves <palves@redhat.com>
* breakpoint.c (insert_bp_location): Use memory_error_message to
build the memory error string.
* c-lang.c: Include "gdbcore.h".
(c_get_string): Use memory_error to throw error.
(target_xfer_memory_error): Delete.
(memory_error_message): New, factored out from
target_xfer_memory_error.
(memory_error): Change parameter type to target_xfer_error.
Rewrite.
(read_memory): Use memory_error instead of
target_xfer_memory_error.
* gdbcore.h: Include "target.h".
(memory_error): Change parameter type to target_xfer_error.
(memory_error_message): Declare function.
* target.c (target_read_memory, target_read_stack)
(target_write_memory, target_write_raw_memory): Return
TARGET_XFER_E_IO on error. Adjust comments.
(get_target_memory): Pass TARGET_XFER_E_IO to memory_error,
instead of EIO.
* target.h (target_read, target_insert_breakpoint)
(target_remove_breakpoint): Adjust comments.
* valprint.c (partial_memory_read): Rename parameter, and adjust
comment.
(val_print_string): Use memory_error_message to build the memory
error string.
gdb/testsuite/
2013-10-09 Pedro Alves <palves@redhat.com>
* gdb.python/py-prettyprint.exp (run_lang_tests): Adjust expected
output.
catch-syscall.exp has a series of duplicated output in gdb.sum. This
patch makes sure all test names are unique, using with_test_prefix.
Tested on x86_64 Fedora 17.
gdb/testsuite/
2013-10-09 Pedro Alves <palves@redhat.com>
* gdb.base/catch-syscall.exp (test_catch_syscall_without_args)
(test_catch_syscall_with_args, test_catch_syscall_with_many_args)
(test_catch_syscall_with_wrong_args)
(test_catch_syscall_restarting_inferior)
(test_catch_syscall_fail_nodatadir)
(test_catch_syscall_without_args_noxml)
(test_catch_syscall_with_args_noxml)
(test_catch_syscall_with_wrong_args_noxml): Use with_test_prefix.
This patch fixes gdb PR symtab/15597.
The bug is that the .gnu_debugaltlink section includes the build-id of
the alt file, but gdb does not use it.
This patch fixes the problem by changing gdb to do what it ought to
always have done: verify the build id of the file found using the
filename in .gnu_debugaltlink; and if that does not match, try to find
the correct debug file using the build-id and debug-file-directory.
This patch touches BFD. Previously, gdb had its own code for parsing
.gnu_debugaltlink; I changed it to use the BFD functions after those
were introduced. However, the BFD functions are incorrect -- they
assume that .gnu_debugaltlink is formatted like .gnu_debuglink.
However, it it is not. Instead, it consists of a file name followed
by the build-id -- no alignment, and the build-id is not a CRC.
Fixing this properly is a bit of a pain. But, because
separate_alt_debug_file_exists just has a FIXME for the build-id case,
I did not fix it properly. Instead I introduced a hack. This leaves
BFD working just as well as it did before my patch.
I'm willing to do something better here but I could use some guidance
as to what. It seems that the build-id code in BFD is largely punted
on.
FWIW gdb is the only user of bfd_get_alt_debug_link_info outside of
BFD itself.
I moved the build-id logic out of elfread.c and into a new file.
This seemed cleanest to me.
Writing a test case was a bit of a pain. I added a couple new
features to the DWARF assembler to handle this.
Built and regtested on x86-64 Fedora 18.
* bfd-in2.h: Rebuild.
* opncls.c (bfd_get_alt_debug_link_info): Add buildid_len
parameter. Change type of buildid_out. Update.
(get_alt_debug_link_info_shim): New function.
(bfd_follow_gnu_debuglink): Use it.
* Makefile.in (SFILES): Add build-id.c.
(HFILES_NO_SRCDIR): Add build-id.h.
* build-id.c: New file, largely from elfread.c. Modified
most functions.
* build-id.h: New file.
* dwarf2read.c (dwarf2_get_dwz_file): Update for change to
bfd_get_alt_debug_link_info. Verify dwz file's build-id.
Search for dwz file using build-id.
* elfread.c (build_id_bfd_get, build_id_verify)
(build_id_to_debug_filename, find_separate_debug_file): Remove.
* gdb.dwarf2/dwzbuildid.exp: New file.
* lib/dwarf.exp (Dwarf::_section): Add "flags" and "type"
parameters.
(Dwarf::_defer_output): Change "section" parameter to
"section_spec"; update.
(Dwarf::gnu_debugaltlink, Dwarf::_note, Dwarf::build_id): New
procs.
will hold the signal number when the inferior terminates due to the
uncaught signal.
I've made modifications on infrun.c:handle_inferior_event such that
$_exitcode gets cleared when the inferior signalled, and vice-versa.
This assumption was made because the variables are mutually
exclusive, i.e., when the inferior terminates because of an uncaught
signal it is not possible for it to return. I have also made modifications
such that when a corefile is loaded, $_exitsignal gets set to the uncaught
signal that "killed" the inferior, and $_exitcode is cleared.
The patch also adds a NEWS entry, documentation bits, and a testcase. The
documentation entry explains how to use $_exitsignal and $_exitcode in a
GDB script, by making use of the new $_isvoid convenience function.
gdb/
2013-10-06 Sergio Durigan Junior <sergiodj@redhat.com>
* NEWS: Mention new convenience variable $_exitsignal.
* corelow.c (core_open): Reset exit convenience variables. Set
$_exitsignal to the uncaught signal which generated the corefile.
* infrun.c (handle_inferior_event): Reset exit convenience
variables. Set $_exitsignal for TARGET_WAITKIND_SIGNALLED.
(clear_exit_convenience_vars): New function.
* inferior.h (clear_exit_convenience_vars): New prototype.
gdb/testsuite/
2013-10-06 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/corefile.exp: Test whether $_exitsignal is set and
$_exitcode is void when opening a corefile.
* gdb.base/exitsignal.exp: New file.
* gdb.base/segv.c: Likewise.
* gdb.base/normal.c: Likewise.
gdb/doc/
2013-10-06 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.texinfo (Convenience Variables): Document $_exitsignal.
Update entry for $_exitcode.
gdb/ChangeLog:
* mi/mi-main.c (run_one_inferior): Add function description.
Make ARG a pointer to an integer whose value determines whether
we should "run" or "start" the program.
(mi_cmd_exec_run): Add handling of the "--start" option.
Reject all other command-line options.
* NEWS: Add entry for "-exec-run"'s new "--start" option.
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Program Execution): Document "-exec-run"'s
new "--start" option.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-start.c, gdb.mi/mi-start.exp: New files.
Currently, in some scenarios, GDB prints <optimized out> when printing
outer frame registers. An <optimized out> register is a confusing
concept. What this really means is that the register is
call-clobbered, or IOW, not saved by the callee. This patch makes GDB
say that instead.
Before patch:
(gdb) p/x $rax $1 = <optimized out>
(gdb) info registers rax
rax <optimized out>
After patch:
(gdb) p/x $rax
$1 = <not saved>
(gdb) info registers rax
rax <not saved>
However, if for some reason the debug info describes a variable as
being in such a register (**), we still want to print <optimized out>
when printing the variable. IOW, <not saved> is reserved for
inspecting registers at the machine level. The patch uses
lval_register+optimized_out to encode the not saved registers, and
makes it so that optimized out variables always end up in
!lval_register values.
** See <https://sourceware.org/ml/gdb-patches/2012-08/msg00787.html>.
Current/recent enough GCC doesn't mark variables/arguments as being in
call-clobbered registers in the ranges corresponding to function
calls, while older GCCs did. Newer GCCs will just not say where the
variable is, so GDB will end up realizing the variable is optimized
out.
frame_unwind_got_optimized creates not_lval optimized out registers,
so by default, in most cases, we'll see <optimized out>.
value_of_register is the function eval.c uses for evaluating
OP_REGISTER (again, $pc, etc.), and related bits. It isn't used for
anything else. This function makes sure to return lval_register
values. The patch makes "info registers" and the MI equivalent use it
too. I think it just makes a lot of sense, as this makes it so that
when printing machine registers ($pc, etc.), we go through a central
function.
We're likely to need a different encoding at some point, if/when we
support partially saved registers. Even then, I think
value_of_register will still be the spot to tag the intention to print
machine register values differently.
value_from_register however may also return optimized out
lval_register values, so at a couple places where we're computing a
variable's location from a dwarf expression, we convert the resulting
value away from lval_register to a regular optimized out value.
Tested on x86_64 Fedora 17
gdb/
2013-10-02 Pedro Alves <palves@redhat.com>
* cp-valprint.c (cp_print_value_fields): Adjust calls to
val_print_optimized_out.
* jv-valprint.c (java_print_value_fields): Likewise.
* p-valprint.c (pascal_object_print_value_fields): Likewise.
* dwarf2loc.c (dwarf2_evaluate_loc_desc_full)
<DWARF_VALUE_REGISTER>: If the register was not saved, return a
new optimized out value.
* findvar.c (address_from_register): Likewise.
* frame.c (put_frame_register): Tweak error string to say the
register was not saved, rather than optimized out.
* infcmd.c (default_print_one_register_info): Adjust call to
val_print_optimized_out. Use value_of_register instead of
get_frame_register_value.
* mi/mi-main.c (output_register): Use value_of_register instead of
get_frame_register_value.
* valprint.c (valprint_check_validity): Likewise.
(val_print_optimized_out): New value parameter. If the value is
lval_register, print <not saved> instead.
(value_check_printable, val_print_scalar_formatted): Adjust calls
to val_print_optimized_out.
* valprint.h (val_print_optimized_out): New value parameter.
* value.c (struct value) <optimized_out>: Extend comment.
(error_value_optimized_out): New function.
(require_not_optimized_out): Use it. Use a different string for
lval_register values.
* value.h (error_value_optimized_out): New declaration.
* NEWS: Mention <not saved>.
gdb/testsuite/
2013-10-02 Pedro Alves <palves@redhat.com>
* gdb.dwarf2/dw2-reg-undefined.exp <pattern_rax_rbx_rcx_print,
pattern_rax_rbx_rcx_info>: Set to "<not saved>".
* gdb.mi/mi-reg-undefined.exp (opt_out_pattern): Delete.
(not_saved_pattern): New.
Replace use of the former with the latter.
gdb/doc/
2013-10-02 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Registers): Expand description of saved registers
in frames. Explain <not saved>.
Running catch-syscall.exp against a gdbserver that actually supports
it, we get:
FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
FAIL: gdb.base/catch-syscall.exp: continue until exit at catch syscall with unused syscall (mlock) (the program exited)
FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
The fail pattern is:
Catchpoint 2 (call to syscall exit_group), 0x000000323d4baa29 in _exit () from /lib64/libc.so.6
(gdb) PASS: gdb.base/catch-syscall.exp: program has called exit_group
delete breakpoints
Delete all breakpoints? (y or n) y
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break exit
Breakpoint 3 at 0x323d438bf0
(gdb) continue
Continuing.
[Inferior 1 (process 21081) exited normally]
That "break exit" + "continue" comes from:
> # gdb_continue_to_end:
> # The case where the target uses stubs has to be handled specially. If a
> # stub is used, we set a breakpoint at exit because we cannot rely on
> # exit() behavior of a remote target.
> #
The native-gdbserver.exp board, used to test against gdbserver in
"target remote" mode, triggers that case ($use_gdb_stub is true). So
gdb_continue_to_end doesn't work for catch-syscall.exp as here we
catch the exit_group and continue from that, expecting to see a real
program exit. I was about to post a patch that changes
catch-syscall.exp to call a new function that just always does what
gdb_continue_to_end does in the !$use_gdb_stub case. But, since
GDBserver doesn't really need this, in the end I thought it better to
teach the testsuite that there are stubs that know how to report
program exits, by adding a new "exit_is_reliable" board variable that
then gdb_continue_to_end checks.
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/testsuite/
2013-10-02 Pedro Alves <palves@redhat.com>
* README (Board Settings): Document "exit_is_reliable".
* lib/gdb.exp (gdb_continue_to_end): Check whether the board says
running to exit reliably reports program exits.
* boards/native-gdbserver.exp: Set exit_is_reliable in the board
info.
* boards/native-stdio-gdbserver.exp: Likewise.
2013-09-25 Andreas Arnez <arnez@linux.vnet.ibm.com>
PR shlibs/8882
* solib-svr4.c (svr4_read_so_list): Skip the vDSO when reading
link map entries.
testsuite/ChangeLog:
2013-09-25 Andreas Arnez <arnez@linux.vnet.ibm.com>
PR shlibs/8882
* gdb.base/corefile.exp: Add a check to assure warning-free
core-file load.
