C++2a adds a "__VA_OPT__" feature that can be used to control the
pesky "," emission when the final (variable) argument of a variadic
macro is empty. This patch implements this feature for gdb. (A patch
to implement it for gcc is pending.)
gdb/ChangeLog
2017-09-27 Tom Tromey <tom@tromey.com>
* macroexp.c (get_next_token_for_substitution): New function.
(substitute_args): Call it. Check for __VA_OPT__.
gdb/testsuite/ChangeLog
2017-09-27 Tom Tromey <tom@tromey.com>
* gdb.base/macscp.exp: Add __VA_OPT__ tests.
compare-sections.exp has two cases that are not handled appropriately:
1) value read with msb set
2) error while patching that section
This patch adapts the "get value of read-only section" test to print
the value as an unsigned integer to fix 1) and test for the error
message to not set the written variable if read-only section cannot
be written to so as to solve 2).
2017-09-26 Thomas Preud'homme <thomas.preudhomme@arm.com>
Pedro Alves <palves@redhat.com>
gdb/testsuite/
* gdb.base/compare-sections.exp (get value of read-only section): Read
as unsigned value.
(corrupt read-only section): Likewise and don't set written if patching
failed.
As the title says, this is a test case for
Inferior.thread_from_thread_handle, a python method which will,
given a thread library dependent thread handle, find the GDB thread
which corresponds to that thread handle (in the inferior under
consideration).
The C file for this test case causes the thread handles for the
main thread and two child threads to be placed into an array. The
test case runs to one of the functions (do_something()) at which point,
it retrieves the thread handles from the array and attempts to find the
corresponding thread in GDB's internal thread list.
I use barriers to make sure that both threads have actually started;
execution will stop when one of the threads breaks at do_something.
Thanks to Simon Marchi for suggestions for forcing the thread
numbering to be stable.
gdb/testsuite/ChangeLog:
* gdb.python/py-thrhandle.c, gdb.python/py-thrhandle.exp: New
files.
Currently, with an ambiguous "list first,last", we get:
(gdb) list bar,main
Specified first line 'bar' is ambiguous:
file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 97
file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 98
This commit makes gdb's output above a bit clearer by printing the
symbol name as well:
(gdb) list bar,main
Specified first line 'bar' is ambiguous:
file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 97, symbol: "bar(A)"
file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 98, symbol: "bar(B)"
And while at it, makes gdb print the symbol name when actually listing
multiple locations too. I.e., before (with "set listsize 2"):
(gdb) list bar
file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 97
96
97 int bar (A) { return 11; }
file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 98
97 int bar (A) { return 11; }
98 int bar (B) { return 22; }
After:
(gdb) list bar
file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 97, symbol: "bar(A)"
96
97 int bar (A) { return 11; }
file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 98, symbol: "bar(B)"
97 int bar (A) { return 11; }
98 int bar (B) { return 22; }
Currently, the result of decoding a linespec loses information about
the original symbol that was found. All we end up with is an address.
This makes it difficult to find the original symbol again to get at
its print name. Fix that by storing a pointer to the symbol in the
sal. We already store the symtab and obj_section, so it feels like a
natural progression to me. This avoids having to do any extra symbol
lookup too.
gdb/ChangeLog:
2017-09-20 Pedro Alves <palves@redhat.com>
* cli/cli-cmds.c (list_command): Use print_sal_location.
(print_sal_location): New function.
(ambiguous_line_spec): Use print_sal_location.
* linespec.c (symbol_to_sal): Record the symbol in the sal.
* symtab.c (find_function_start_sal): Likewise.
* symtab.h (symtab_and_line::symbol): New field.
gdb/testsuite/ChangeLog:
2017-09-20 Pedro Alves <palves@redhat.com>
* gdb.base/list-ambiguous.exp (test_list_ambiguous_symbol): Expect
symbol names in gdb's output.
* gdb.cp/overload.exp ("list all overloads"): Likewise.
The "list" command allows specifying the name of variables as
argument, not just functions, so that users can type "list
a_global_variable".
That support is a broken when it comes to ambiguous locations though.
If there's more than one such global variable in the program, e.g.,
static globals in different compilation units, GDB ends up listing the
source of the first variable it finds, only.
linespec.c does find both symbol and minsym locations for all the
globals. The problem is that it ends up merging all the resulting
sals into one, because they all have address, zero. I.e., all sals
end up with sal.pc == 0, so maybe_add_address returns false for all
but the first.
The zero addresses appear because:
- in the minsyms case, linespec.c:minsym_found incorrectly treats all
minsyms as if they were function/text symbols. In list mode we can
end up with data symbols there, and we shouldn't be using
find_pc_sect_line on data symbols.
- in the debug symbols case, symbol_to_sal misses recording an address
(sal.pc) for non-block, non-label symbols.
gdb/ChangeLog:
2017-09-20 Pedro Alves <palves@redhat.com>
* linespec.c (minsym_found): Handle non-text minsyms.
(symbol_to_sal): Record a sal.pc for non-block, non-label symbols.
gdb/testsuite/ChangeLog:
2017-09-20 Pedro Alves <palves@redhat.com>
* gdb.base/list-ambiguous.exp (test_list_ambiguous_function):
Rename to ...
(test_list_ambiguous_symbol): ... this and add a symbol name
parameter. Adjust.
(test_list_ambiguous_function): Reimplement on top of
test_list_ambiguous_symbol and also test listing ambiguous
variables.
* gdb.base/list-ambiguous0.c (ambiguous): Rename to ...
(ambiguous_fun): ... this.
(ambiguous_var): New.
* gdb.base/list-ambiguous1.c (ambiguous): Rename to ...
(ambiguous_fun): ... this.
(ambiguous_var): New.
Test was running on a fault during code execution. Analysis have shown
that the wrong instruction had been used. An instruction that takes
not alligned memory is more appropriated for the task.
ChangeLog:
2017-09-20 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/testesuite/ChangeLog:
* gdb.arch/i386-avx512.c (move_zmm_data_to_reg): Use
vmovups instead vmovaps.
(move_zmm_data_to_memory): Use vmovups instead vmovaps.
Change-Id: I4a95560861ef1792ed6ce86578fdd726162863f1
This works like 'start' but it stops at the first instruction rather
than the first line in main(). This is useful if one wants to single
step through runtime linker startup.
While here, introduce a RUN_ARGS_HELP macro for shared help text
between run, start, and starti. This includes expanding the help for
start and starti to include details from run's help text.
gdb/ChangeLog:
* NEWS (Changes since GDB 8.0): Add starti.
* infcmd.c (enum run_break): New.
(run_command_1): Queue pending event for RUN_STOP_AT_FIRST_INSN
case.
(run_command): Use enum run_how.
(start_command): Likewise.
(starti_command): New function.
(RUN_ARGS_HELP): New macro.
(_initialize_infcmd): Use RUN_ARGS_HELP for run and start
commands. Add starti command.
gdb/doc/ChangeLog:
* gdb.texinfo (Starting your Program): Add description of
starti command. Mention starti command as an alternative for
debugging the elaboration phase.
gdb/testsuite/ChangeLog:
* gdb.base/starti.c: New file.
* gdb.base/starti.exp: New file.
* lib/gdb.exp (gdb_starti_cmd): New procedure.
I'm seeing these failures on my system:
FAIL: gdb.base/nodebug.exp: p (double) mult (2.0, 3.0)
FAIL: gdb.base/nodebug.exp: p ((double (*) (double, double)) mult)(2.0f, 3.0f)
FAIL: gdb.base/nodebug.exp: p ((double (*) (double, double)) mult)(2, 3)
The problem is simply that GDB is finding a symbol named "mult" from
glibc's debug info:
(gdb) ptype mult
type = enum expression_operator {var, num, lnot, mult, divide, module, plus, minus, less_than, greater_than, less_or_equal, greater_or_equal, equal, not_equal, land, lor, qmop}
(gdb) info types expression_operator
All types matching regular expression "expression_operator":
File plural-exp.h:
enum expression_operator;
Fix this by unloading symbols from shared libraries.
gdb/testsuite/ChangeLog:
2017-09-14 Pedro Alves <palves@redhat.com>
* gdb.base/nodebug.exp (nodebug_runto): New procedure.
(top level): Use it instead of runto.
Change extract_arg to return a std::string and fix up all the users.
I think string is mildly better than unique_xmalloc_ptr<char>, when
possible, because it provides a more robust API.
I changed the error messages emitted from find_location_by_number to
avoid either writing to a string or an extra allocation; this can be
changed but I thought that the new message was not any less clear.
You can see an example in the testsuite patch.
ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
* demangle.c (demangle_command): Update.
* breakpoint.c (disable_command): Update.
(enable_command): Update.
(find_location_by_number): Make "number" const. Use
get_number_trailer.
* cli/cli-utils.c (extract_arg): Return std::string.
* probe.c (parse_probe_linespec): Update. Change types.
(collect_probes): Take string arguments.
(parse_probe_linespec): Likewise.
(info_probes_for_ops): Update.
(enable_probes_command): Update.
(disable_probes_command): Update.
* break-catch-sig.c (catch_signal_split_args): Update.
* mi/mi-parse.c (mi_parse): Update.
testsuite/ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
* gdb.base/ena-dis-br.exp (test_ena_dis_br): Update test.
This adds a few new events to gdb's Python layer: new_inferior,
inferior_deleted, and new_thread. I wanted to be able to add a
combined inferior/thread display window to my GUI, and I needed a few
events to make this work. This is PR python/15622.
ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
PR python/15622:
* NEWS: Add entry.
* python/python.c (do_start_initialization): Initialize new event
types.
* python/python-internal.h (gdbpy_initialize_new_inferior_event)
(gdbpy_initialize_inferior_deleted_event)
(gdbpy_initialize_new_thread_event): Declare.
* python/py-threadevent.c (create_thread_event_object): Add option
"thread" parameter.
* python/py-inferior.c (new_thread_event_object_type)
(new_inferior_event_object_type)
(inferior_deleted_event_object_type): Declare.
(python_new_inferior, python_inferior_deleted): New functions.
(add_thread_object): Emit new_thread event.
(gdbpy_initialize_inferior): Attach new functions to corresponding
observers.
(new_thread, new_inferior, inferior_deleted): Define new event
types.
* python/py-evts.c (gdbpy_initialize_py_events): Add new
registries.
* python/py-events.h (events_object) <new_inferior,
inferior_deleted, new_thread>: New fields.
* python/py-event.h (create_thread_event_breakpoint): Add optional
"thread" parameter.
doc/ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
* python.texi (Events In Python): Document new events.
testsuite/ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
* gdb.python/py-infthread.exp: Add tests for new_thread event.
* gdb.python/py-inferior.exp: Add tests for new inferior events.
Remove code relevant for printing C/C++ Integer values in a
Fortran specific file to unify printing of Fortran values.
This does not change the output.
Printing the prefix "PTR TO -> (" resp. "REF TO ->(" ignored the active
indentation level. This caused inconsistent appearance of user-defined
Fortran types containing pointers. Fix by using "fprintfi_filtered" with the
current indentation level for outputting the prefix string. Add test case
ptr-indentation.
Example using 'ptype' on object of type:
type TypeWithPointer
integer i
integer, pointer:: p
end type TypeWithPointer
Before:
type = Type typewithpointer
integer(kind=4) :: i
PTR TO -> ( integer(kind=4) :: p)
End Type typewithpointer
After:
type = Type typewithpointer
integer(kind=4) :: i
PTR TO -> ( integer(kind=4) :: p)
End Type typewithpointer
PR gdb/22010 concerns a regression I introduced with the scalar
printing changes. The bug is that this code in sizeof.exp:
set signof_byte [get_integer_valueof "'\\377'" -1]
can incorrectly compute sizeof_byte. One underlying problem here is
that gdb's C parser doesn't treat a char constant as an int (this is
PR 19973).
However, it seems good to have an immediate fix for the regression.
The simplest is to cast to an int here.
testsuite/ChangeLog
2017-09-05 Tom Tromey <tom@tromey.com>
PR gdb/22010:
* gdb.base/sizeof.exp (check_valueof): Cast char constant to int.
Tests in gdb.arch/thumb2-it.exp call functions defined in assembly
without type debugging information. Since
7022349d5c ("Stop assuming no-debug-info
functions return int") this triggers an error which leads to many tests
to FAIL. This patch cast the call to indicate the return type of the
functions when calling them.
2017-09-06 Thomas Preud'homme <thomas.preudhomme@arm.com>
gdb/testsuite/
* gdb.arch/thumb2-it.exp: Cast call to assembly defined function.
Since 2273f0ac95 ("change minsyms not to be relocated at
read-time"), printing TLS symbols of objfiles with a non-zero base
address, without debug info, fails.
E.g., with:
$ mv /usr/lib/debug /usr/lib/debug-x
to get debug info out of the way, we get:
$ echo 'int main(){}' | gcc -pthread -x c -
$ ./gdb -q -ex start -ex 'p (int) errno' ./a.out
Cannot access memory at address 0xffffef7c0698
instead of the expected:
$1 = 0
The regression is not visible with glibc debuginfo installed.
The problem is that we compute the address of TLS minsyms incorrectly.
To trigger the problem, it is important that the variable is in an
objfile with a non-zero base address. While glibc is a shared library
for 'errno', it's easier for the testcase to use PIE instead of a
shlib. For TLS variables in PT_EXEC the regression obviously does not
happen.
gdb/ChangeLog
2017-09-06 Jan Kratochvil <jan.kratochvil@redhat.com>
* parse.c (find_minsym_type_and_address): Don't relocate addresses
of TLS symbols.
gdb/testsuite/ChangeLog
2017-09-06 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.threads/tls-nodebug-pie.c: New file.
* gdb.threads/tls-nodebug-pie.exp: New file.
I noticed that the gdb.rust tests fail because the test suite passes
-fdiagnostics-color=never to rustc. This is not a recognized rustc
option, and the test suite already handles passing the appropriate
option to the Rust compiler.
This patch fixes the problem.
testsuite/ChangeLog
2017-09-05 Tom Tromey <tom@tromey.com>
* lib/gdb.exp (gdb_compile): Don't use universal_compile_options
for rust.
Using follow-exec-mode "new" takes a different code path than "same", so
it's interesting to test this path in combination with a change in
architecture of the inferior. This test fails if you remove the
previous patch.
gdb/testsuite/ChangeLog:
* gdb.multi/multi-arch-exec.exp: Test with different
"follow-exec-mode" settings.
(do_test): New procedure.
Trying to print a function local static variable of a const-qualified
method still doesn't work after the previous fixes:
(gdb) p 'S::method() const'::static_var
$1 = {i1 = 1, i2 = 2, i3 = 3}
(gdb) p S::method() const::static_var
No symbol "static_var" in specified context.
The reason is that the expression parser/evaluator loses the "const",
and the above unquoted case is just like trying to print a variable of
the non-const overload, if it exists, even. As if the above unquoted
case had been written as:
(gdb) p S::method()::static_var
No symbol "static_var" in specified context.
We can see the problem without static vars in the picture. With:
struct S
{
void method ();
void method () const;
};
Compare:
(gdb) print 'S::method(void) const'
$1 = {void (const S * const)} 0x400606 <S::method() const>
(gdb) print S::method(void) const
$2 = {void (S * const)} 0x4005d8 <S::method()> # wrong method!
That's what we need to fix. If we fix that, the function local static
case starts working.
The grammar production for function/method types is this one:
exp: exp '(' parameter_typelist ')' const_or_volatile
This results in a TYPE_INSTANCE expression evaluator operator. For
the example above, we get something like this ("set debug expression 1"):
...
0 TYPE_INSTANCE 1 TypeInstance: Type @0x560fda958be0 (void)
5 OP_SCOPE Type @0x560fdaa544d8 (S) Field name: `method'
...
While evaluating TYPE_INSTANCE, we end up in
value_struct_elt_for_reference, trying to find the method named
"method" that has the prototype recorded in TYPE_INSTANCE. In this
case, TYPE_INSTANCE says that we're looking for a method that has
"(void)" as parameters (that's what "1 TypeInstance: Type
@0x560fda958be0 (void)" above means. The trouble is that nowhere in
this mechanism do we communicate to value_struct_elt_for_reference
that we're looking for the _const_ overload.
value_struct_elt_for_reference only compared parameters, and the
non-const "method()" overload has matching parameters, so it's
considered the right match...
Conveniently, the "const_or_volatile" production in the grammar
already records "const" and "volatile" info in the type stack. The
type stack is not used in this code path, but we can borrow the
information. The patch converts the info in the type stack to an
"instance flags" enum, and adds that as another element in
TYPE_INSTANCE operators. This type instance flags is then applied to
the temporary type that is passed to value_struct_elt_for_reference
for matching.
The other side of the problem is that methods in the debug info aren't
marked const/volatile, so with that in place, the matching never finds
const/volatile-qualified methods.
The problem is that in the DWARF, there's no indication at all whether
a method is const/volatile qualified... For example (c++filt applied
to the linkage name for convenience):
<2><d3>: Abbrev Number: 6 (DW_TAG_subprogram)
<d4> DW_AT_external : 1
<d4> DW_AT_name : (indirect string, offset: 0x3df): method
<d8> DW_AT_decl_file : 1
<d9> DW_AT_decl_line : 58
<da> DW_AT_linkage_name: (indirect string, offset: 0x5b2): S::method() const
<de> DW_AT_declaration : 1
<de> DW_AT_object_pointer: <0xe6>
<e2> DW_AT_sibling : <0xec>
I see the same with both GCC and Clang. The patch works around this
by extracting the cv qualification from the "const" and "volatile" in
the demangled name. This will need further tweaking for "&" and
"const &" overloads, but we don't support them in the parser yet,
anyway.
The TYPE_CONST changes were necessary otherwise the comparisons in valops.c:
if (TYPE_CONST (intype) != TYPE_FN_FIELD_CONST (f, j))
continue;
would fail, because when both TYPE_CONST() TYPE_FN_FIELD_CONST() were
true, their values were different.
BTW, I'm recording the const/volatile-ness of methods in the
TYPE_FN_FIELD info because #1 - I'm not sure it's kosher to change the
method's type directly (vs having to call make_cv_type to create a new
type), and #2 it's what stabsread.c does:
...
case 'A': /* Normal functions. */
new_sublist->fn_field.is_const = 0;
new_sublist->fn_field.is_volatile = 0;
(*pp)++;
break;
case 'B': /* `const' member functions. */
new_sublist->fn_field.is_const = 1;
new_sublist->fn_field.is_volatile = 0;
...
After all this, this finally all works:
print S::method(void) const
$1 = {void (const S * const)} 0x400606 <S::method() const>
(gdb) p S::method() const::static_var
$2 = {i1 = 1, i2 = 2, i3 = 3}
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* c-exp.y (function_method, function_method_void): Add current
instance flags to TYPE_INSTANCE.
* dwarf2read.c (check_modifier): New.
(compute_delayed_physnames): Assert that only C++ adds delayed
physnames. Mark fn_fields as const/volatile depending on
physname.
* eval.c (make_params): New type_instance_flags parameter. Use
it as the new type's instance flags.
(evaluate_subexp_standard) <TYPE_INSTANCE>: Extract the instance
flags element and pass it to make_params.
* expprint.c (print_subexp_standard) <TYPE_INSTANCE>: Handle
instance flags element.
(dump_subexp_body_standard) <TYPE_INSTANCE>: Likewise.
* gdbtypes.h: Include "enum-flags.h".
(type_instance_flags): New enum-flags type.
(TYPE_CONST, TYPE_VOLATILE, TYPE_RESTRICT, TYPE_ATOMIC)
(TYPE_CODE_SPACE, TYPE_DATA_SPACE): Return boolean.
* parse.c (operator_length_standard) <TYPE_INSTANCE>: Adjust.
(follow_type_instance_flags): New function.
(operator_check_standard) <TYPE_INSTANCE>: Adjust.
* parser-defs.h (follow_type_instance_flags): Declare.
* valops.c (value_struct_elt_for_reference): const/volatile must
match too.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/func-static.c (S::method const, S::method volatile)
(S::method volatile const): New methods.
(c_s, v_s, cv_s): New instances.
(main): Call method() on them.
* gdb.base/func-static.exp (syntax_re, cannot_resolve_re): New variables.
(cannot_resolve): New procedure.
(cxx_scopes_list): Test cv methods. Add print-scope-quote and
print-quote-unquoted columns.
(do_test): Test printing each scope too.
While the previous commit made "p method()::static_var" (no
single-quotes) Just Work, if users (or frontends) try wrapping the
expression with quotes, they'll get:
(gdb) p 'S::method()::static_var'
'S::method()::static_var' has unknown type; cast it to its declared type
even if we _do_ have debug info for that variable. That's better than
the bogus/confusing value what GDB would print before the
stop-assuming-int patch:
(gdb) p 'S::method()::static_var'
$1 = 1
but I think it'd still be nice to make this case Just Work too.
In this case, due to the quoting, the C/C++ parser (c-exp.y)
interprets the whole expression/string as a single symbol name, and we
end up calling lookup_symbol on that name. There's no debug symbol
with that fully-qualified name, but since the compiler gives the
static variable a mangled linkage name exactly like the above, it
appears in the mininal symbols:
$ nm -A local-static | c++filt | grep static_var
local-static:0000000000601040 d S::method()::static_var
... and that's what GDB happens to find/print. This only happens in
C++, note, since for C the compiler uses different linkage names:
local-static-c:0000000000601040 d static_var.1848
So while (in C++, not C) function local static variables are given a
mangled name that demangles to the same syntax that GDB
documents/expects as the way to access function local statics, there's
no global symbol in the debug info with that name at all. The debug
info for a static local variable for a non-inline function looks like
this:
<1><2a1>: Abbrev Number: 19 (DW_TAG_subprogram)
...
<2><2f7>: Abbrev Number: 20 (DW_TAG_variable)
<2f8> DW_AT_name : (indirect string, offset: 0x4e9): static_var
<2fc> DW_AT_decl_file : 1
<2fd> DW_AT_decl_line : 64
<2fe> DW_AT_type : <0x25>
<302> DW_AT_location : 9 byte block: 3 40 10 60 0 0 0 0 0 (DW_OP_addr: 601040)
and for an inline function, it looks like this (linkage name run
through c++filt for convenience):
<2><21b>: Abbrev Number: 16 (DW_TAG_variable)
<21c> DW_AT_name : (indirect string, offset: 0x21a): static_var
<220> DW_AT_decl_file : 1
<221> DW_AT_decl_line : 48
<222> DW_AT_linkage_name: (indirect string, offset: 0x200): S::inline_method()::static_var
<226> DW_AT_type : <0x25>
<22a> DW_AT_external : 1
<22a> DW_AT_location : 9 byte block: 3 a0 10 60 0 0 0 0 0 (DW_OP_addr: 6010a0)
(The inline case makes the variable external so that the linker can
merge the different inlined copies. It seems like GCC never outputs
the linkage name for non-extern globals.)
When we read the DWARF, we record the static_var variable as a regular
variable of the containing function's block. This makes stopping in
the function and printing the variable as usual. The variable just so
happens to have a memory address as location.
So one way to make "p 'S::method()::static_var'" work would be to
record _two_ copies of the symbols for these variables. One in the
function's scope/block, with "static_var" as name, as we currently do,
and another in the static or global blocks (depending on whether the
symbol is external), with a fully-qualified name. I wrote a prototype
patch for that, and it works. For the non-inline case above, since
the debug info doesn't point to the linkage same, that patch built the
physname of the static local variable as the concat of the physname of
the containing function, plus "::", plus the variable's name. We
could make that approach work for C too, though it kind of feels
awkward to record fake symbol names like that in C.
The other approach I tried is to change the C++ symbol lookup routines
instead. This is the approach this commit takes. We can already
lookup up symbol in namespaces and classes, so this feels like a good
fit, and was easy enough. The advantage is that this doesn't require
recording extra symbols.
The test in gdb.cp/m-static.exp that exposed the need for this is
removed, since the same functionality is now covered by
gdb.cp/local-static.exp.
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* cp-namespace.c (cp_search_static_and_baseclasses): Handle
function/method scopes; lookup the nested name as a function local
static variable.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/local-static.exp: Also test with
class::method::variable wholly quoted.
* gdb.cp/m-static.exp (class::method::variable): Remove test.
This commit makes "print S::method()::static_var" actually find the
debug symbol for static_var. Currently, you get:
(gdb) print S::method()::static_var
A syntax error in expression, near `'.
Quoting the whole string would seemingly work before the previous
patch that made GDB stop assuming int for no-debug-info variables:
(gdb) p 'S::method()::static_var'
$1 = 1
... except that's incorrect output, because:
(gdb) ptype 'S::method()::static_var'
type = <data variable, no debug info>
The way to make it work correctly currently is by quoting the
function/method part, like this:
(gdb) print 'S::method()'::static_var
$1 = {i1 = 1, i2 = 2, i3 = 3}
(gdb) ptype 'S::method()'::static_var
type = struct aggregate {
int i1;
int i2;
int i3;
}
At least after the "stop assuming int" patch, this is what we
now get:
(gdb) p 'S::method()::static_var'
'S::method()::static_var' has unknown type; cast it to its declared type
(gdb) p (struct aggregate) 'S::method()::static_var'
$1 = {i1 = 1, i2 = 2, i3 = 3}
However, IMO, users shouldn't really have to care about any of this.
GDB should Just Work, without quoting, IMO.
So here's a patch that implements support for that in the C++ parser.
With this patch, you now get:
(gdb) p S::method()::S_M_s_var_aggregate
$1 = {i1 = 1, i2 = 2, i3 = 3}
(gdb) ptype S::method()::S_M_s_var_aggregate
type = struct aggregate {
int i1;
int i2;
int i3;
}
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
(%type <voidval>): Add function_method.
* c-exp.y (exp): New production for calls with no arguments.
(function_method, function_method_void_or_typelist): New
productions.
(exp): New production for "method()::static_var".
* eval.c (evaluate_subexp_standard): Handle OP_FUNC_STATIC_VAR.
* expprint.c (print_subexp_standard, dump_subexp_body_standard):
Handle OP_FUNC_STATIC_VAR.
* parse.c (operator_length_standard):
Handle OP_FUNC_STATIC_VAR.
* std-operator.def (OP_FUNC_STATIC_VAR): New.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/local-static.c: New.
* gdb.base/local-static.cc: New.
* gdb.base/local-static.exp: New.
An earlier commit made GDB no longer assume no-debug-info functions
return int. This commit gives the same treatment to variables.
Currently, you can end misled by GDB over output like this:
(gdb) p var
$1 = -1
(gdb) p /x var
$2 = 0xffffffff
until you realize that GDB is assuming that the variable is an "int",
because:
(gdb) ptype var
type = <data variable, no debug info>
You may try to fix it by casting, but that doesn't really help:
(gdb) p /x (unsigned long long) var
$3 = 0xffffffffffffffff # incorrect
^^
That's incorrect output, because the variable was defined like this:
uint64_t var = 0x7fffffffffffffff;
^^
What happened is that with the cast, GDB did an int -> 'unsigned long
long' conversion instead of reinterpreting the variable as the cast-to
type. To get at the variable properly you have to reinterpret the
variable's address manually instead, with either:
(gdb) p /x *(unsigned long long *) &var
$4 = 0x7fffffffffffffff
(gdb) p /x {unsigned long long} &var
$5 = 0x7fffffffffffffff
After this commit GDB does it for you. This is what you'll get
instead:
(gdb) p var
'var' has unknown type; cast it to its declared type
(gdb) p /x (unsigned long long) var
$1 = 0x7fffffffffffffff
As in the functions patch, the "compile" machinery doesn't currently
have the cast-to type handy, so it continues assuming no-debug
variables have int type, though now at least it warns.
The change to gdb.cp/m-static.exp deserves an explanation:
- gdb_test "print 'gnu_obj_1::method()::sintvar'" "\\$\[0-9\]+ = 4" \
+ gdb_test "print (int) 'gnu_obj_1::method()::sintvar'" "\\$\[0-9\]+ = 4" \
That's printing the "sintvar" function local static of the
"gnu_obj_1::method()" method.
The problem with that test is that that "'S::method()::static_var'"
syntax doesn't really work in C++ as you'd expect. The way to make it
work correctly currently is to quote the method part, not the whole
expression, like:
(gdb) print 'gnu_obj_1::method()'::sintvar
If you wrap the whole expression in quotes, like in m-static.exp, what
really happens is that the parser considers the whole string as a
symbol name, but there's no debug symbol with that name. However,
local statics have linkage and are given a mangled name that demangles
to the same string as the full expression, so that's what GDB prints.
After this commit, and without the cast, the print in m-static.exp
would error out saying that the variable has unknown type:
(gdb) p 'gnu_obj_1::method()::sintvar'
'gnu_obj_1::method()::sintvar' has unknown type; cast it to its declared type
TBC, if currently (even before this series) you try to print any
function local static variable of type other than int, you'll get
bogus results. You can see that with m-static.cc as is, even.
Printing the "svar" local, which is a boolean (1 byte) still prints as
"int" (4 bytes):
(gdb) p 'gnu_obj_1::method()::svar'
$1 = 1
(gdb) ptype 'gnu_obj_1::method()::svar'
type = <data variable, no debug info>
This probably prints some random bogus value on big endian machines.
If 'svar' was of some aggregate type (etc.) we'd still print it as
int, so the problem would have been more obvious... After this
commit, you'll get instead:
(gdb) p 'gnu_obj_1::method()::svar'
'gnu_obj_1::method()::svar' has unknown type; cast it to its declared type
... so at least GDB is no longer misleading. Making GDB find the real
local static debug symbol is the subject of the following patches. In
the end, it'll all "Just Work".
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* ax-gdb.c: Include "typeprint.h".
(gen_expr_for_cast): New function.
(gen_expr) <OP_CAST, OP_CAST_TYPE>: Use it.
<OP_VAR_VALUE, OP_MSYM_VAR_VALUE>: Error out if the variable's
type is unknown.
* dwarf2read.c (new_symbol_full): Fallback to int instead of
nodebug_data_symbol.
* eval.c: Include "typeprint.h".
(evaluate_subexp_standard) <OP_VAR_VALUE, OP_VAR_MSYM_VALUE>:
Error out if symbol has unknown type.
<UNOP_CAST, UNOP_CAST_TYPE>: Common bits factored out to
evaluate_subexp_for_cast.
(evaluate_subexp_for_address, evaluate_subexp_for_sizeof): Handle
OP_VAR_MSYM_VALUE.
(evaluate_subexp_for_cast): New function.
* gdbtypes.c (init_nodebug_var_type): New function.
(objfile_type): Use it to initialize types of variables with no
debug info.
* typeprint.c (error_unknown_type): New.
* typeprint.h (error_unknown_type): New declaration.
* compile/compile-c-types.c (convert_type_basic): Handle
TYPE_CODE_ERROR; warn and fallback to int for variables with
unknown type.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.asm/asm-source.exp: Add casts to int.
* gdb.base/nodebug.c (dataglobal8, dataglobal32_1, dataglobal32_2)
(dataglobal64_1, dataglobal64_2): New globals.
* gdb.base/nodebug.exp: Test different expressions involving the
new globals, with print, whatis and ptype. Add casts to int.
* gdb.base/solib-display.exp: Add casts to int.
* gdb.compile/compile-ifunc.exp: Expect warning. Add cast to int.
* gdb.cp/m-static.exp: Add cast to int.
* gdb.dwarf2/dw2-skip-prologue.exp: Add cast to int.
* gdb.threads/tls-nodebug.exp: Check that gdb errors out printing
tls variable with no debug info without a cast. Test with a cast
to int too.
* gdb.trace/entry-values.exp: Add casts.
The patch to make GDB stop assuming functions return int left GDB with
an inconsistency. While with normal expression evaluation the
"unknown return type" error shows the name of the function that misses
debug info:
(gdb) p getenv ("PATH")
'getenv' has unknown return type; cast the call to its declared return type
^^^^^^
which is handy in more complicated expressions, "ptype" does not:
(gdb) ptype getenv ("PATH")
function has unknown return type; cast the call to its declared return type
^^^^^^^^
This commit builds on the new OP_VAR_MSYM_VALUE to fix it, by making
OP_FUNCALL extract the function name from the symbol stored in
OP_VAR_VALUE/OP_VAR_MSYM_VALUE. We now get the same error in "print"
vs "ptype":
(gdb) ptype getenv()
'getenv' has unknown return type; cast the call to its declared return type
(gdb) p getenv()
'getenv' has unknown return type; cast the call to its declared return type
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* eval.c (evaluate_subexp_standard): <OP_FUNCALL>: Extract
function name from symbol/minsym and pass it to
error_call_unknown_return_type.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/nodebug.exp: Test that ptype's error about functions
with unknown return type includes the function name too.
The fact that GDB defaults to assuming that functions return int, when
it has no debug info for the function has been a recurring source of
user confusion. Recently this came up on the errno pretty printer
discussions. Shortly after, it came up again on IRC, with someone
wondering why does getenv() in GDB return a negative int:
(gdb) p getenv("PATH")
$1 = -6185
This question (with s/getenv/random-other-C-runtime-function) is a FAQ
on IRC.
The reason for the above is:
(gdb) p getenv
$2 = {<text variable, no debug info>} 0x7ffff7751d80 <getenv>
(gdb) ptype getenv
type = int ()
... which means that GDB truncated the 64-bit pointer that is actually
returned from getent to 32-bit, and then sign-extended it:
(gdb) p /x -6185
$6 = 0xffffe7d7
The workaround is to cast the function to the right type, like:
(gdb) p ((char *(*) (const char *)) getenv) ("PATH")
$3 = 0x7fffffffe7d7 "/usr/local/bin:/"...
IMO, we should do better than this.
I see the "assume-int" issue the same way I see printing bogus values
for optimized-out variables instead of "<optimized out>" -- I'd much
rather that the debugger tells me "I don't know" and tells me how to
fix it than showing me bogus misleading results, making me go around
tilting at windmills.
If GDB prints a signed integer when you're expecting a pointer or
aggregate, you at least have some sense that something is off, but
consider the case of the function actually returning a 64-bit integer.
For example, compile this without debug info:
unsigned long long
function ()
{
return 0x7fffffffffffffff;
}
Currently, with pristine GDB, you get:
(gdb) p function ()
$1 = -1 # incorrect
(gdb) p /x function ()
$2 = 0xffffffff # incorrect
maybe after spending a few hours debugging you suspect something is
wrong with that -1, and do:
(gdb) ptype function
type = int ()
and maybe, just maybe, you realize that the function actually returns
unsigned long long. And you try to fix it with:
(gdb) p /x (unsigned long long) function ()
$3 = 0xffffffffffffffff # incorrect
... which still produces the wrong result, because GDB simply applied
int to unsigned long long conversion. Meaning, it sign-extended the
integer that it extracted from the return of the function, to 64-bits.
and then maybe, after asking around on IRC, you realize you have to
cast the function to a pointer of the right type, and call that. It
won't be easy, but after a few missteps, you'll get to it:
..... (gdb) p /x ((unsigned long long(*) ()) function) ()
$666 = 0x7fffffffffffffff # finally! :-)
So to improve on the user experience, this patch does the following
(interrelated) things:
- makes no-debug-info functions no longer default to "int" as return
type. Instead, they're left with NULL/"<unknown return type>"
return type.
(gdb) ptype getenv
type = <unknown return type> ()
- makes calling a function with unknown return type an error.
(gdb) p getenv ("PATH")
'getenv' has unknown return type; cast the call to its declared return type
- and then to make it easier to call the function, makes it possible
to _only_ cast the return of the function to the right type,
instead of having to cast the function to a function pointer:
(gdb) p (char *) getenv ("PATH") # now Just Works
$3 = 0x7fffffffe7d7 "/usr/local/bin:/"...
(gdb) p ((char *(*) (const char *)) getenv) ("PATH") # continues working
$4 = 0x7fffffffe7d7 "/usr/local/bin:/"...
I.e., it makes GDB default the function's return type to the type
of the cast, and the function's parameters to the type of the
arguments passed down.
After this patch, here's what you'll get for the "unsigned long long"
example above:
(gdb) p function ()
'function' has unknown return type; cast the call to its declared return type
(gdb) p /x (unsigned long long) function ()
$4 = 0x7fffffffffffffff # correct!
Note that while with "print" GDB shows the name of the function that
has the problem:
(gdb) p getenv ("PATH")
'getenv' has unknown return type; cast the call to its declared return type
which can by handy in more complicated expressions, "ptype" does not:
(gdb) ptype getenv ("PATH")
function has unknown return type; cast the call to its declared return type
This will be fixed in the next patch.
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* ada-lang.c (ada_evaluate_subexp) <TYPE_CODE_FUNC>: Don't handle
TYPE_GNU_IFUNC specially here. Throw error if return type is
unknown.
* ada-typeprint.c (print_func_type): Handle functions with unknown
return type.
* c-typeprint.c (c_type_print_base): Handle functions and methods
with unknown return type.
* compile/compile-c-symbols.c (convert_symbol_bmsym)
<mst_text_gnu_ifunc>: Use nodebug_text_gnu_ifunc_symbol.
* compile/compile-c-types.c: Include "objfiles.h".
(convert_func): For functions with unknown return type, warn and
default to int.
* compile/compile-object-run.c (compile_object_run): Adjust call
to call_function_by_hand_dummy.
* elfread.c (elf_gnu_ifunc_resolve_addr): Adjust call to
call_function_by_hand.
* eval.c (evaluate_subexp_standard): Adjust calls to
call_function_by_hand. Handle functions and methods with unknown
return type. Pass expect_type to call_function_by_hand.
* f-typeprint.c (f_type_print_base): Handle functions with unknown
return type.
* gcore.c (call_target_sbrk): Adjust call to
call_function_by_hand.
* gdbtypes.c (objfile_type): Leave nodebug text symbol with NULL
return type instead of int. Make nodebug_text_gnu_ifunc_symbol be
an integer address type instead of nodebug.
* guile/scm-value.c (gdbscm_value_call): Adjust call to
call_function_by_hand.
* infcall.c (error_call_unknown_return_type): New function.
(call_function_by_hand): New "default_return_type" parameter.
Pass it down.
(call_function_by_hand_dummy): New "default_return_type"
parameter. Use it instead of defaulting to int. If there's no
default and the return type is unknown, throw an error. If
there's a default return type, and the called function has no
debug info, then assume the function is prototyped.
* infcall.h (call_function_by_hand, call_function_by_hand_dummy):
New "default_return_type" parameter.
(error_call_unknown_return_type): New declaration.
* linux-fork.c (call_lseek): Cast return type of lseek.
(inferior_call_waitpid, checkpoint_command): Adjust calls to
call_function_by_hand.
* linux-tdep.c (linux_infcall_mmap, linux_infcall_munmap): Adjust
calls to call_function_by_hand.
* m2-typeprint.c (m2_procedure): Handle functions with unknown
return type.
* objc-lang.c (lookup_objc_class, lookup_child_selector)
(value_nsstring, print_object_command): Adjust calls to
call_function_by_hand.
* p-typeprint.c (pascal_type_print_varspec_prefix): Handle
functions with unknown return type.
(pascal_type_print_func_varspec_suffix): New function.
(pascal_type_print_varspec_suffix) <TYPE_CODE_FUNC,
TYPE_CODE_METHOD>: Use it.
* python/py-value.c (valpy_call): Adjust call to
call_function_by_hand.
* rust-lang.c (rust_evaluate_funcall): Adjust call to
call_function_by_hand.
* valarith.c (value_x_binop, value_x_unop): Adjust calls to
call_function_by_hand.
* valops.c (value_allocate_space_in_inferior): Adjust call to
call_function_by_hand.
* typeprint.c (type_print_unknown_return_type): New function.
* typeprint.h (type_print_unknown_return_type): New declaration.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/break-main-file-remove-fail.exp (test_remove_bp): Cast
return type of munmap in infcall.
* gdb.base/break-probes.exp: Cast return type of foo in infcall.
* gdb.base/checkpoint.exp: Simplify using for loop. Cast return
type of ftell in infcall.
* gdb.base/dprintf-detach.exp (dprintf_detach_test): Cast return
type of getpid in infcall.
* gdb.base/infcall-exec.exp: Cast return type of execlp in
infcall.
* gdb.base/info-os.exp: Cast return type of getpid in infcall.
Bail on failure to extract the pid.
* gdb.base/nodebug.c: #include <stdint.h>.
(multf, multf_noproto, mult, mult_noproto, add8, add8_noproto):
New functions.
* gdb.base/nodebug.exp (test_call_promotion): New procedure.
Change expected output of print/whatis/ptype with functions with
no debug info. Test all supported languages. Call
test_call_promotion.
* gdb.compile/compile.exp: Adjust expected output to expect
warning.
* gdb.threads/siginfo-threads.exp: Likewise.
Calling a prototyped function via a function pointer with the right
prototype doesn't work correctly, if the called function requires
argument coercion... Like, e.g., with:
float mult (float f1, float f2) { return f1 * f2; }
(gdb) p mult (2, 3.5)
$1 = 7
(gdb) p ((float (*) (float, float)) mult) (2, 3.5)
$2 = 0
both calls should have returned the same, of course. The problem is
that GDB misses marking the type of the function pointer target as
prototyped...
Without the fix, the new test fails like this:
(gdb) p ((int (*) (float, float)) t_float_values2)(3.14159,float_val2)
$30 = 0
(gdb) FAIL: gdb.base/callfuncs.exp: p ((int (*) (float, float)) t_float_values2)(3.14159,float_val2)
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdbtypes.c (lookup_function_type_with_arguments): Mark function
types with more than one parameter as prototyped.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/callfuncs.exp (do_function_calls): New parameter
"prototypes". Test calling float functions via prototyped and
unprototyped function pointers.
(perform_all_tests): New parameter "prototypes". Pass it down.
(top level): Pass down "prototypes" parameter to
perform_all_tests.
This patch improves the loop_break and loop_continue tests to verify
that they work as expected when multiple loops are nested (they affect
the inner loop).
gdb/testsuite/ChangeLog:
* gdb.base/commands.exp (loop_break_test, loop_continue_test):
Test with nested loops.
I grepped the testsuite for loop_break and loop_continue and didn't find
anything, so I wrote some simple tests for those.
gdb/testsuite/ChangeLog:
* gdb.base/commands.exp: Call the new procedures.
(loop_break_test, loop_continue_test): New procedures.
When using "if" (or while) without args directly on gdb's command line,
you get this:
(gdb) if
if/while commands require arguments
When doing the same when entering a command list, you only get an error
when the command is executed, when parse_exp_in_context_1 fails to
evaluate the expression.
(gdb) define foo
Type commands for definition of "foo".
End with a line saying just "end".
>if
>end
>end
(gdb) foo
Argument required (expression to compute).
I think it would make more sense to error out when inputting the command
list directly:
(gdb) define foo
Type commands for definition of "foo".
End with a line saying just "end".
>if
if/while commands require arguments.
The only required change is to check whether args is an empty string in
build_command_line.
gdb/ChangeLog:
* cli/cli-script.c (build_command_line): For if/while commands,
check whether args is empty.
gdb/testsuite/ChangeLog:
* gdb.base/commands.exp: Call new procedure.
(define_if_without_arg_test): New procedure.
Currently, with "list LINESPEC1,LINESPEC2", if one of the linespecs is
ambiguous, i.e., if it expands to multiple locations, you get this
seemingly odd output:
(gdb) list foo,bar
file: "file0.c", line number: 26
file: "file1.c", line number: 29
Since "foo" above expands to multiple locations, the specified range
is indeterminate, and GDB is trying to be helpful by showing you what
was ambiguous. It looks confusing to me, though. I think it'd be
much more user friendly if GDB actually told you that, like this:
(gdb) list foo,bar
Specified first line 'foo' is ambiguous:
file: "file0.c", line number: 26
file: "file1.c", line number: 29
(gdb) list bar,foo
Specified last line 'foo' is ambiguous:
file: "file0.c", line number: 26
file: "file1.c", line number: 29
Note, I'm using "first" and "last" in the output because that's what
the manual uses:
~~~
list first,last
Print lines from first to last. [...]
~~~
Tested on x86-64 GNU/Linux.
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* cli/cli-cmds.c (edit_command): Pass message to
ambiguous_line_spec.
(list_command): Pass message to ambiguous_line_spec. Say
"first"/"last" instead of "start" and "end" to be consistent with
the manual.
(ambiguous_line_spec): Add 'format' and vararg parameters. Use
them to print formatted message.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/list-ambiguous.exp: New file.
* gdb.base/list-ambiguous0.c: New file.
* gdb.base/list-ambiguous1.c: New file.
* gdb.base/list.exp (test_list_range): Adjust expected output.
This patch implements the ability to set/unset environment variables
on the remote target, mimicking what GDB already offers to the user.
There are two features present here: user-set and user-unset
environment variables.
User-set environment variables are only the variables that are
explicitly set by the user, using the 'set environment' command. This
means that variables that were already present in the environment when
starting GDB/GDBserver are not transmitted/considered by this feature.
User-unset environment variables are variables that are explicitly
unset by the user, using the 'unset environment' command.
The idea behind this patch is to store user-set and user-unset
environment variables in two separate sets, both part of gdb_environ.
Then, when extended_remote_create_inferior is preparing to start the
inferior, it will iterate over the two sets and set/unset variables
accordingly. Three new packets are introduced:
- QEnvironmentHexEncoded, which is used to set environment variables,
and contains an hex-encoded string in the format "VAR=VALUE" (VALUE
can be empty if the user set a variable with a null value, by doing
'set environment VAR=').
- QEnvironmentUnset, which is used to unset environment variables, and
contains an hex-encoded string in the format "VAR".
- QEnvironmentReset, which is always the first packet to be
transmitted, and is used to reset the environment, i.e., discard any
changes made by the user on previous runs.
The QEnvironmentHexEncoded packet is inspired on LLDB's extensions to
the RSP. Details about it can be seen here:
<https://raw.githubusercontent.com/llvm-mirror/lldb/master/docs/lldb-gdb-remote.txt>
I decided not to implement the QEnvironment packet because it is
considered deprecated by LLDB. This packet, on LLDB, serves the same
purpose of QEnvironmentHexEncoded, but sends the information using a
plain text, non-hex-encoded string.
The other two packets are new.
This patch also includes updates to the documentation, testsuite, and
unit tests, without introducing regressions.
gdb/ChangeLog:
2017-08-31 Sergio Durigan Junior <sergiodj@redhat.com>
* NEWS (Changes since GDB 8.0): Add entry mentioning new support
for setting/unsetting environment variables on the remote target.
(New remote packets): Add entries for QEnvironmentHexEncoded,
QEnvironmentUnset and QEnvironmentReset.
* common/environ.c (gdb_environ::operator=): Extend method to
handle m_user_set_env_list and m_user_unset_env_list.
(gdb_environ::clear): Likewise.
(match_var_in_string): Change type of first parameter from 'char
*' to 'const char *'.
(gdb_environ::set): Extend method to handle
m_user_set_env_list and m_user_unset_env_list.
(gdb_environ::unset): Likewise.
(gdb_environ::clear_user_set_env): New method.
(gdb_environ::user_set_envp): Likewise.
(gdb_environ::user_unset_envp): Likewise.
* common/environ.h (gdb_environ): Handle m_user_set_env_list and
m_user_unset_env_list on move constructor/assignment.
(unset): Add new default parameter 'update_unset_list = true'.
(clear_user_set_env): New method.
(user_set_envp): Likewise.
(user_unset_envp): Likewise.
(m_user_set_env_list): New std::set.
(m_user_unset_env_list): Likewise.
* common/rsp-low.c (hex2str): New function.
(bin2hex): New overload for bin2hex function.
* common/rsp-low.c (hex2str): New prototype.
(str2hex): New overload prototype.
* remote.c: Include "environ.h". Add QEnvironmentHexEncoded,
QEnvironmentUnset and QEnvironmentReset.
(remote_protocol_features): Add QEnvironmentHexEncoded,
QEnvironmentUnset and QEnvironmentReset packets.
(send_environment_packet): New function.
(extended_remote_environment_support): Likewise.
(extended_remote_create_inferior): Call
extended_remote_environment_support.
(_initialize_remote): Add QEnvironmentHexEncoded,
QEnvironmentUnset and QEnvironmentReset packet configs.
* unittests/environ-selftests.c (gdb_selftest_env_var):
New variable.
(test_vector_initialization): New function.
(test_init_from_host_environ): Likewise.
(test_reinit_from_host_environ): Likewise.
(test_set_A_unset_B_unset_A_cannot_find_A_can_find_B):
Likewise.
(test_unset_set_empty_vector): Likewise.
(test_vector_clear): Likewise.
(test_std_move): Likewise.
(test_move_constructor):
(test_self_move): Likewise.
(test_set_unset_reset): Likewise.
(run_tests): Rewrite in terms of the functions above.
gdb/gdbserver/ChangeLog:
2017-08-31 Sergio Durigan Junior <sergiodj@redhat.com>
* server.c (handle_general_set): Handle QEnvironmentHexEncoded,
QEnvironmentUnset and QEnvironmentReset packets.
(handle_query): Inform remote that QEnvironmentHexEncoded,
QEnvironmentUnset and QEnvironmentReset are supported.
gdb/doc/ChangeLog:
2017-08-31 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.texinfo (set environment): Add @anchor. Explain that
environment variables set by the user are sent to GDBserver.
(unset environment): Likewise, but for unsetting variables.
(Connecting) <Remote Packet>: Add "environment-hex-encoded",
"QEnvironmentHexEncoded", "environment-unset", "QEnvironmentUnset",
"environment-reset" and "QEnvironmentReset" to the table.
(Remote Protocol) <QEnvironmentHexEncoded, QEnvironmentUnset,
QEnvironmentReset>: New item, explaining the packet.
gdb/testsuite/ChangeLog:
2017-08-31 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/share-env-with-gdbserver.c: New file.
* gdb.base/share-env-with-gdbserver.exp: Likewise.
Commit
Command names: make them case sensitive
3d7b173c29
made command name lookup case sensitive. However, define_command, used
when creating a user-defined command, converts the command name to
lowercase, assuming that the command name lookup works in a case
insensitive way. This causes user-defined commands with capital letters
in their name to only be callable with a lowercase version:
(gdb) define Foo
Type commands for definition of "Foo".
End with a line saying just "end".
>print 1
>end
(gdb) Foo
Undefined command: "Foo". Try "help".
(gdb) foo
$1 = 1
This patch removes that conversion to lowercase, so that the user can
call the command with the same name they provided.
gdb/ChangeLog:
* cli/cli-script.c (define_command): Don't convert command name
to lower case.
gdb/testsuite/ChangeLog:
* gdb.base/commands.exp (user_defined_command_case_sensitivity):
New proc, call it from toplevel.
There is an assertion that is triggering when we start GDB and
instruct it to debug a remote inferior, but don't provide a local
binary, like:
./gdb -nx -q --data-directory=data-directory -ex "tar ext :1234" \
-ex "set remote exec-file /bin/ls" -ex r
In this case, when calling exec_file_locate_attach to locate the
inferior, GDB is incorrectly resetting the breakpoints without a
thread/inferior even running, which causes an assertion to be
triggered:
binutils-gdb/gdb/thread.c:1609: internal-error: scoped_restore_current_thread::scoped_restore_current_thread(): Assertion `tp != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This happens because add_current_inferior_and_thread (on remote.c) is
breaking an invariant: making inferior_ptid point to a non-existing
thread and then calling common code, which in this case is
breakpoint_re_set. The fix is to make sure that inferior_ptid points
to null_ptid if there is no thread present.
A testcase is provided. Regtested on buildbot.
gdb/ChangeLog:
2017-08-23 Pedro Alves <palves@redhat.com>
PR remote/21852
* remote.c (add_current_inferior_and_thread): Set inferior_ptid
to null_ptid and switch to thread without reading the registers
after adding the inferior.
gdb/testsuite/ChangeLog:
2017-08-23 Sergio Durigan Junior <sergiodj@redhat.com>
PR remote/21852
* gdb.server/normal.c: New file, copied from gdb.base.
* gdb.server/run-without-local-binary.exp: New file.
The M7 processor supports an Application Data Integrity (ADI) feature
that detects invalid data accesses. When software allocates data, it
chooses a 4-bit version number, sets the version in the upper 4 bits
of the 64-bit pointer to that data, and stores the 4-bit version in
every cacheline of the object. Hardware saves the latter in spare
bits in the cache and memory hierarchy. On each load and store, the
processor compares the upper 4 VA (virtual address) bits to the
cacheline's version. If there is a mismatch, the processor generates a
version mismatch trap which can be either precise or disrupting. The
trap is an error condition which the kernel delivers to the process as
a SIGSEGV signal.
The upper 4 bits of the VA represent a version and are not part of the
true address. The processor clears these bits and sign extends bit 59
to generate the true address.
Note that 32-bit applications cannot use ADI.
This patch adds ADI support in gdb which allows the user to examine
current version tags and assign new version tags in the program. It
also catches and reports precise or disrupting memory corruption
traps.
gdb/ChangeLog:
2017-08-07 Weimin Pan <weimin.pan@oracle.com>
* sparc64-tdep.h: (adi_normalize_address): New export.
* sparc-nat.h: (open_adi_tag_fd): New export.
* sparc64-linux-nat.c: (open_adi_tag_fd): New function.
* sparc64-linux-tdep.c:
(SEGV_ACCADI, SEGV_ADIDERR, SEGV_ADIPERR) New defines.
(sparc64_linux_handle_segmentation_fault): New function.
(sparc64_linux_init_abi): Register
sparc64_linux_handle_segmentation_fault
* sparc64-tdep.c: Include cli-utils.h,gdbcmd.h,auxv.h.
(sparc64_addr_bits_remove): New function.
(sparc64_init_abi): Register sparc64_addr_bits_remove.
(MAX_PROC_NAME_SIZE): New macro.
(AT_ADI_BLKSZ, AT_ADI_NBITS, AT_ADI_UEONADI) New defines.
(sparc64adilist): New variable.
(adi_proc_list): New variable.
(find_adi_info): New function.
(add_adi_info): New function.
(get_adi_info_proc): New function.
(get_adi_info): New function.
(info_adi_command): New function.
(read_maps_entry): New function.
(adi_available): New function.
(adi_normalize_address): New function.
(adi_align_address): New function.
(adi_convert_byte_count): New function.
(adi_tag_fd): New function.
(adi_is_addr_mapped): New function.
(adi_read_versions): New function.
(adi_write_versions): New function.
(adi_print_versions): New function.
(do_examine): New function.
(do_assign): New function.
(adi_examine_command): New function.
(adi_assign_command): New function.
(_initialize_sparc64_adi_tdep): New function.
gdb/doc/ChangeLog:
2017-08-07 Weimin Pan <weimin.pan@oracle.com>
* gdb.texinfo (Architectures): Add new Sparc64 section to document
ADI support.
* NEWS: Add "adi examine" and "adi assign" commands.
gdb/testsuite/ChangeLog:
2017-08-07 Weimin Pan <weimin.pan@oracle.com>
* gdb.arch/sparc64-adi.exp: New file.
* gdb.arch/sparc64-adi.c: New file.
This adds a test for the "list" command change done in 0d999a6ef0
("List actual code around more than one location").
gdb/ChangeLog:
2017-08-22 Pedro Alves <palves@redhat.com>
* gdb.cp/overload.exp (line_range_pattern): New procedure.
(top level): Add "list all overloads" tests.
This changes gdb_realpath to return a unique_xmalloc_ptr and fixes up
the callers. This allows removing some cleanups. This change by
itself caused xfullpath.exp to fail; and attempting to fix that ran
into various problems (like .get() being optimized out); so this patch
also rewrites xfullpath.exp to be a C++ selftest instead.
ChangeLog
2017-08-22 Tom Tromey <tom@tromey.com>
* exec.c (exec_file_attach): Update.
* linux-thread-db.c (try_thread_db_load): Update.
* guile/scm-safe-call.c (gdbscm_safe_source_script): Update.
* utils.c (gdb_realpath): Change return type.
(gdb_realpath_keepfile): Update.
(gdb_realpath_check_trailer, gdb_realpath_tests): New functions.
(_initialize_utils): Register the new self test.
* source.c (openp): Update.
(find_and_open_source): Update.
* nto-tdep.c (nto_find_and_open_solib): Update.
* main.c (set_gdb_data_directory): Update.
(captured_main_1): Update.
* dwarf2read.c (dwarf2_get_dwz_file): Update
(dw2_map_symbol_filenames): Update.
* auto-load.c (auto_load_safe_path_vec_update): Update.
(filename_is_in_auto_load_safe_path_vec): Change type of
"filename_realp".
(auto_load_objfile_script): Update.
(file_is_auto_load_safe): Update. Use std::string.
* utils.h (gdb_realpath): Return a gdb::unique_xmalloc_ptr.
testsuite/ChangeLog
2017-08-22 Tom Tromey <tom@tromey.com>
* gdb.gdb/xfullpath.exp: Remove.
(Ref: https://sourceware.org/ml/gdb/2017-06/msg00048.html)
This patch improves GDB support for function aliases defined with
__attribute__ alias. For example, in the test added by this commit,
there is no reference to "func_alias" in the debug info at all, only
to "func"'s definition:
$ nm ./testsuite/outputs/gdb.base/symbol-alias/symbol-alias | grep " func"
00000000004005ae t func
00000000004005ae T func_alias
$ readelf -w ./testsuite/outputs/gdb.base/symbol-alias/symbol-alias | grep func -B 1 -A 8
<1><db>: Abbrev Number: 5 (DW_TAG_subprogram)
<dc> DW_AT_name : (indirect string, offset: 0x111): func
<e0> DW_AT_decl_file : 1
<e1> DW_AT_decl_line : 27
<e2> DW_AT_prototyped : 1
<e2> DW_AT_type : <0xf8>
<e6> DW_AT_low_pc : 0x4005ae
<ee> DW_AT_high_pc : 0xb
<f6> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<f8> DW_AT_GNU_all_call_sites: 1
So all GDB knows about "func_alias" is from the minsym (elf symbol):
(gdb) p func_alias
$1 = {<text variable, no debug info>} 0x4005ae <func>
(gdb) ptype func_alias
type = int ()
(gdb) p func
$2 = {struct S *(void)} 0x4005ae <func>
(gdb) ptype func
type = struct S {
int field1;
int field2;
} *(void)
The result is that calling func_alias from the command line produces
incorrect results.
This is similar (though not exactly the same) to the glibc
errno/__errno_location/__GI___errno_location situation. On glibc,
errno is defined like this:
extern int *__errno_location (void);
#define errno (*__errno_location ())
with __GI___errno_location being an internal alias for
__errno_location. On my system's libc (F23), I do see debug info for
__errno_location, in the form of name vs linkage name:
<1><95a5>: Abbrev Number: 18 (DW_TAG_subprogram)
<95a6> DW_AT_external : 1
<95a6> DW_AT_name : (indirect string, offset: 0x2c26): __errno_location
<95aa> DW_AT_decl_file : 1
<95ab> DW_AT_decl_line : 24
<95ac> DW_AT_linkage_name: (indirect string, offset: 0x2c21): __GI___errno_location
<95b0> DW_AT_prototyped : 1
<95b0> DW_AT_type : <0x9206>
<95b4> DW_AT_low_pc : 0x20f40
<95bc> DW_AT_high_pc : 0x11
<95c4> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<95c6> DW_AT_GNU_all_call_sites: 1
however that doesn't matter in practice, because GDB doesn't record
demangled names anyway, and so we end up with the exact same situation
covered by the testcase.
So the fix is to make the expression parser find a debug symbol for
the same address as the just-found minsym, when a lookup by name
didn't find a debug symbol by name. We now get:
(gdb) p func_alias
$1 = {struct S *(void)} 0x4005ae <func>
(gdb) p __errno_location
$2 = {int *(void)} 0x7ffff6e92830 <__errno_location>
I've made the test exercise variable aliases too, for completeness.
Those already work correctly, because unlike for function aliases, GCC
emits debug information for variable aliases.
Tested on GNU/Linux.
gdb/ChangeLog:
2017-08-21 Pedro Alves <palves@redhat.com>
PR gdb/19487
* c-exp.y (variable production): Handle function aliases.
* minsyms.c (msymbol_is_text): New function.
* minsyms.h (msymbol_is_text): Declare.
* symtab.c (find_function_alias_target): New function.
* symtab.h (find_function_alias_target): Declare.
gdb/testsuite/ChangeLog:
2017-08-21 Pedro Alves <palves@redhat.com>
PR gdb/19487
* gdb.base/symbol-alias.c: New.
* gdb.base/symbol-alias2.c: New.
* gdb.base/symbol-alias.exp: New.
(Ref: https://sourceware.org/ml/gdb/2017-06/msg00020.html)
Assuming int_t is a typedef to int:
typedef int int_t;
gdb currently loses this expression's typedef:
(gdb) p (int_t) 0
$1 = 0
(gdb) whatis $1
type = int
or:
(gdb) whatis (int_t) 0
type = int
or, to get "whatis" out of the way:
(gdb) maint print type (int_t) 0
...
name 'int'
code 0x8 (TYPE_CODE_INT)
...
This prevents a type printer for "int_t" kicking in, with e.g.:
(gdb) p (int_t) 0
From the manual, we can see that that "whatis (int_t) 0" command
invocation should have printed "type = int_t":
If @var{arg} is a variable or an expression, @code{whatis} prints its
literal type as it is used in the source code. If the type was
defined using a @code{typedef}, @code{whatis} will @emph{not} print
the data type underlying the @code{typedef}.
(...)
If @var{arg} is a type name that was defined using @code{typedef},
@code{whatis} @dfn{unrolls} only one level of that @code{typedef}.
That one-level stripping is currently done here, in
gdb/eval.c:evaluate_subexp_standard, handling OP_TYPE:
...
else if (noside == EVAL_AVOID_SIDE_EFFECTS)
{
struct type *type = exp->elts[pc + 1].type;
/* If this is a typedef, then find its immediate target. We
use check_typedef to resolve stubs, but we ignore its
result because we do not want to dig past all
typedefs. */
check_typedef (type);
if (TYPE_CODE (type) == TYPE_CODE_TYPEDEF)
type = TYPE_TARGET_TYPE (type);
return allocate_value (type);
}
However, this stripping is reachable in both:
#1 - (gdb) whatis (int_t)0 # ARG is an expression with a cast to
# typedef type.
#2 - (gdb) whatis int_t # ARG is a type name.
while only case #2 should strip the typedef. Removing that code from
evaluate_subexp_standard is part of the fix. Instead, we make the
"whatis" command implementation itself strip one level of typedefs
when the command argument is a type name.
We then run into another problem, also fixed by this commit:
value_cast always drops any typedefs of the destination type.
With all that fixed, "whatis (int_t) 0" now works as expected:
(gdb) whatis int_t
type = int
(gdb) whatis (int_t)0
type = int_t
value_cast has many different exit/convertion paths, for handling many
different kinds of casts/conversions, and most of them had to be
tweaked to construct the value of the right "to" type. The new tests
try to exercise most of it, by trying castin of many different
combinations of types. With:
$ make check TESTS="*/whatis-ptype*.exp */gnu_vector.exp */dfp-test.exp"
... due to combinatorial explosion, the testsuite results for the
tests above alone grow like:
- # of expected passes 246
+ # of expected passes 3811
You'll note that the tests exposed one GCC buglet, filed here:
Missing DW_AT_type in DW_TAG_typedef of "typedef of typedef of void"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81267
gdb/ChangeLog:
2017-08-21 Pedro Alves <palves@redhat.com>
* eval.c (evaluate_subexp_standard) <OP_TYPE>: Don't dig past
typedefs.
* typeprint.c (whatis_exp): If handling "whatis", and expression
is OP_TYPE, strip one typedef level. Otherwise don't strip
typedefs here.
* valops.c (value_cast): Save "to" type before resolving
stubs/typedefs. Use that type as resulting value's type.
gdb/testsuite/ChangeLog:
2017-08-21 Pedro Alves <palves@redhat.com>
* gdb.base/dfp-test.c
(d32_t, d64_t, d128_t, d32_t2, d64_t2, d128_t2, v_d32_t, v_d64_t)
(v_d128_t, v_d32_t2, v_d64_t2, v_d128_t2): New.
* gdb.base/dfp-test.exp: Add whatis/ptype/cast tests.
* gdb.base/gnu_vector.exp: Add whatis/ptype/cast tests.
* gdb.base/whatis-ptype-typedefs.c: New.
* gdb.base/whatis-ptype-typedefs.exp: New.
* gdb.python/py-prettyprint.c (int_type, int_type2): New typedefs.
(an_int, an_int_type, an_int_type2): New globals.
* gdb.python/py-prettyprint.exp (run_lang_tests): Add tests
involving typedefs and cast expressions.
* gdb.python/py-prettyprint.py (class pp_int_typedef): New.
(lookup_typedefs_function): New.
(typedefs_pretty_printers_dict): New.
(top level): Register lookup_typedefs_function in
gdb.pretty_printers.
This patch uses GDB self test in GDBserver. The self tests are run if
GDBserver is started with option --selftest.
gdb:
2017-08-18 Yao Qi <yao.qi@linaro.org>
* NEWS: Mention GDBserver's new option "--selftest".
* Makefile.in (SFILES): Remove selftest.c, add common/selftest.c.
* selftest.c: Move it to common/selftest.c.
* selftest.h: Move it to common/selftest.h.
* selftest-arch.c (reset): New function.
(tests_with_arch): Call reset.
gdb/gdbserver:
2017-08-18 Yao Qi <yao.qi@linaro.org>
* Makefile.in (OBS): Add selftest.o.
* configure.ac: AC_DEFINE GDB_SELF_TEST if $development.
* configure, config.in: Re-generated.
* server.c: Include common/sefltest.h.
(captured_main): Handle option --selftest.
gdb/testsuite:
2017-08-18 Yao Qi <yao.qi@linaro.org>
* gdb.server/unittest.exp: New.
gdb/doc:
2017-08-18 Yao Qi <yao.qi@linaro.org>
* gdb.texinfo (Server): Document "--selftest".
When I made commit 9a6c7d9c02, which
C++-fied gdb/common/environ.[ch], I mistakenly altered the behaviour
of the 'unset environment' command. This command, which should delete
all environment variables, is now resetting the list of variables to
the state they were when GDB was started.
This commit fixes this regression, and also adds a test on
gdb.base/environ.exp which really checks if 'unset environment'
worked.
gdb/ChangeLog:
2017-08-15 Sergio Durigan Junior <sergiodj@redhat.com>
PR gdb/21954
* infcmd.c (unset_environment_command): Use the 'clear' method on
the environment instead of resetting it.
gdb/testsuite/ChangeLog:
2017-08-15 Sergio Durigan Junior <sergiodj@redhat.com>
PR gdb/21954
* gdb.base/environ.exp: Add test to check if 'unset environment'
works.
Newer GCC versions yield colored diagnostic messages by default, which may
be useful when executing GDB interactively from a terminal. But when run
from a GDB test case, the compiler output is written into gdb.log, where
such escape sequences are usually more inhibiting than helpful to the
evaluation of test results. So this patch suppresses that.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (universal_compile_options): New caching proc.
(gdb_compile): Suppress GCC's coloring of messages.
PR gdb/21675 points out a few regressions in scalar printing.
One type of regression is due to not carrying over the old handling of
floating point printing -- where a format like "/d" causes a floating
point number to first be cast to a signed integer. This patch restores
this behavior.
The other regression is a longstanding bug in print_octal_chars: one of
the constants was wrong. This patch fixes the constant and adds static
asserts to help catch this sort of error.
ChangeLog
2017-08-14 Tom Tromey <tom@tromey.com>
PR gdb/21675
* valprint.c (LOW_ZERO): Change value to 034.
(print_octal_chars): Add static_asserts for octal constants.
* printcmd.c (print_scalar_formatted): Add 'd' case.
testsuite/ChangeLog
2017-08-14 Tom Tromey <tom@tromey.com>
PR gdb/21675:
* gdb.base/printcmds.exp (test_radices): New function.
* gdb.dwarf2/var-access.exp: Use p/u, not p/d.
* gdb.base/sizeof.exp (check_valueof): Use p/d.
* lib/gdb.exp (get_integer_valueof): Use p/d.
The get_valueof procedure allows tests to conveniently make gdb evaluate
an expression an return the value as a string. However, it includes an
end-of-line character in its result. I stumbled on this when trying to
use that result as part of a regex further in a test.
You can see this for example by adding a puts in
gdb.dwarf2/implref-struct.exp:get_members:
set members [get_valueof "" ${var} ""]
puts "<$members>"
The output is
<{a = 0, b = 1, c = 2}
>
This is because the regex in get_valueof is too greedy, the captured
portion matches anything up to the gdb_prompt, including the end of line
characters. This patch changes it to capture everything but end of line
characters.
The output of the puts becomes:
<{a = 0, b = 1, c = 2}>
I tested this by running gdb.dwarf2/implref-array.exp and
gdb.dwarf2/implref-struct.exp, the two only current users of that
procedure.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (get_valueof): Don't capture end-of-line
characters.
I ran the gdb.rust tests against Rust 1.20 (beta) and saw a few
failures. The failures all came because a particular item moved to a
different module. Since the particular choice of module name isn't
important here, I simply widened the allowable results.
Tested locally against rustc 1.19, 1.20, and 1.21.
testsuite/ChangeLog
2017-08-05 Tom Tromey <tom@tromey.com>
* gdb.rust/simple.exp: Allow String to appear in a different
namespace.
Now, GDB is able to dynamically create i386-linux target descriptions
from features, instead of using pre-generated target descriptions. These
pre-generated target descriptions are no longer used by GDB (note that
they are still used by GDBserver).
This patch add a new maint command "maint check xml-descriptions" to test
dynamically generated tdesc are identical to these generated from xml files.
gdb:
2017-07-26 Yao Qi <yao.qi@linaro.org>
* cli/cli-cmds.c (maintenancechecklist): New variable.
* gdbcmd.h (maintenancechecklist): Declare it.
* i386-linux-tdep.c (_initialize_i386_linux_tdep) [GDB_SELF_TEST]:
Call i386_linux_read_description with different masks.
* maint.c (maintenance_check_command): New function.
(_initialize_maint_cmds): Call add_prefix_cmd.
* target-descriptions.c (tdesc_reg): override operator != and ==.
(tdesc_type): Likewise.
(tdesc_feature): Likewise.
(target_desc): Likewise.
[GDB_SELF_TEST] (selftests::record_xml_tdesc): New function.
(maintenance_check_xml_descriptions): New function.
(_initialize_target_descriptions) Add command "xml-descriptions".
* target-descriptions.h (selftests::record_xml_tdesc): Declare.
gdb/testsuite:
2017-07-26 Yao Qi <yao.qi@linaro.org>
* gdb.gdb/unittest.exp: Invoke command
"maintenance check xml-descriptions".
gdb/doc:
2017-07-26 Yao Qi <yao.qi@linaro.org>
* gdb.texinfo (Maintenance Commands): Document command
"maint check xml-descriptions".
PR 21555 is caused by the exception during the prologue analysis when re-set
a breakpoint.
(gdb) bt
#0 memory_error_message (err=TARGET_XFER_E_IO, gdbarch=0x153db50, memaddr=93824992233232) at ../../binutils-gdb/gdb/corefile.c:192
#1 0x00000000005718ed in memory_error (err=TARGET_XFER_E_IO, memaddr=memaddr@entry=93824992233232) at ../../binutils-gdb/gdb/corefile.c:220
#2 0x00000000005719d6 in read_memory_object (object=object@entry=TARGET_OBJECT_CODE_MEMORY, memaddr=93824992233232, memaddr@entry=1, myaddr=myaddr@entry=0x7fffffffd0a0 "P\333S\001", len=len@entry=1) at ../../binutils-gdb/gdb/corefile.c:259
#3 0x0000000000571c6e in read_code (len=1, myaddr=0x7fffffffd0a0 "P\333S\001", memaddr=<optimized out>) at ../../binutils-gdb/gdb/corefile.c:287
#4 read_code_unsigned_integer (memaddr=memaddr@entry=93824992233232, len=len@entry=1, byte_order=byte_order@entry=BFD_ENDIAN_LITTLE) at ../../binutils-gdb/gdb/corefile.c:362
#5 0x000000000041d4a0 in amd64_analyze_prologue (gdbarch=gdbarch@entry=0x153db50, pc=pc@entry=93824992233232, current_pc=current_pc@entry=18446744073709551615, cache=cache@entry=0x7fffffffd1e0) at ../../binutils-gdb/gdb/amd64-tdep.c:2310
#6 0x000000000041e404 in amd64_skip_prologue (gdbarch=0x153db50, start_pc=93824992233232) at ../../binutils-gdb/gdb/amd64-tdep.c:2459
#7 0x000000000067bfb0 in skip_prologue_sal (sal=sal@entry=0x7fffffffd4e0) at ../../binutils-gdb/gdb/symtab.c:3628
#8 0x000000000067c4d8 in find_function_start_sal (sym=sym@entry=0x1549960, funfirstline=1) at ../../binutils-gdb/gdb/symtab.c:3501
#9 0x000000000060999d in symbol_to_sal (result=result@entry=0x7fffffffd5f0, funfirstline=<optimized out>, sym=sym@entry=0x1549960) at ../../binutils-gdb/gdb/linespec.c:3860
....
#16 0x000000000054b733 in location_to_sals (b=b@entry=0x15792d0, location=0x157c230, search_pspace=search_pspace@entry=0x1148120, found=found@entry=0x7fffffffdc64) at ../../binutils-gdb/gdb/breakpoint.c:14211
#17 0x000000000054c1f5 in breakpoint_re_set_default (b=0x15792d0) at ../../binutils-gdb/gdb/breakpoint.c:14301
#18 0x00000000005412a9 in breakpoint_re_set_one (bint=bint@entry=0x15792d0) at ../../binutils-gdb/gdb/breakpoint.c:14412
This problem can be fixed by
- either each prologue analyzer doesn't throw exception,
- or catch the exception thrown from gdbarch_skip_prologue,
I choose the latter because the former needs to fix *every* prologue
analyzer to not throw exception.
This error can be reproduced by changing reread.exp. The test reread.exp
has already test that breakpoint can be reset correctly after the
executable is re-read. This patch extends this test by compiling test c
file with and without -fPIE.
(gdb) run ^M
The program being debugged has been started already.^M
Start it from the beginning? (y or n) y^M
x86_64/gdb/testsuite/outputs/gdb.base/reread/reread' has changed; re-reading symbols.
Error in re-setting breakpoint 1: Cannot access memory at address 0x555555554790^M
Error in re-setting breakpoint 2: Cannot access memory at address 0x555555554790^M
Starting program: /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.base/reread/reread ^M
This is foo^M
[Inferior 1 (process 27720) exited normally]^M
(gdb) FAIL: gdb.base/reread.exp: opts= "-fPIE" "ldflags=-pie" : run to foo() second time (the program exited)
This patch doesn't re-indent the code, to keep the patch simple.
gdb:
2017-07-25 Yao Qi <yao.qi@linaro.org>
PR gdb/21555
* arch-utils.c (gdbarch_skip_prologue_noexcept): New function.
* arch-utils.h (gdbarch_skip_prologue_noexcept): Declare.
* infrun.c: Include arch-utils.h
(handle_step_into_function): Call gdbarch_skip_prologue_noexcept.
(handle_step_into_function_backward): Likewise.
* symtab.c (skip_prologue_sal): Likewise.
gdb/testsuite:
2017-07-25 Yao Qi <yao.qi@linaro.org>
PR gdb/21555
* gdb.base/reread.exp: Wrap the whole test with two kinds of
compilation flags, with -fPIE and without -fPIE.
s390-vregs.exp yields a Tcl error:
ERROR: can't read "i": no such variable
while executing
"expr $a_high * ($i + 1) * $a_high "
(procedure "hex128" line 2)
invoked from within
"hex128 $a_high $a_low $b_high $b_low"
...
This is a regression, caused by commit 30a254669b -- "Don't always
zero pad in print_*_chars". That patch introduced a new procedure
"hex128" for formatting a 128-bit value as hex, but it accidentally moved
the calculation of the 128-bit value into that new procedure as well
instead of leaving it in the original context. This is fixed.
gdb/testsuite/ChangeLog:
* gdb.arch/s390-vregs.exp: Calculate parameters to hex128 in the
calling context.
(hex128): Drop erroneous calculation of parameters.
[I made some typo fixes but forgot to amend my commit before sending the patch,
hence this v2.]
I see the following failure on Ubuntu 16.04's gcc 5.4.0:
Running /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.python/py-unwind.exp ...
FAIL: gdb.python/py-unwind.exp: continue to breakpoint: break backtrace-broken
FAIL: gdb.python/py-unwind.exp: Backtrace restored by unwinder (pattern 1)
The problem is that the test expects a very particular stack layout.
When stack protection is enabled, it adds a canary value which looks
like an additional local variable. This makes the test complain about
a bad stack layout and fail.
The simple solution is to disable stack protection for that test using
-fno-stack-protector. I checked older compilers (gcc 4.4, clang 3.5)
and they support that flag, so I don't think it's necessary to probe for
whether the compiler supports it.
Maybe a better solution would be to change the test to make it cope with
different stack layouts (perhaps it could save addresses of stuff in
some global variables which GDB/the unwinder would read). I'll go with
the simple solution for now though.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind.exp: Disable stack protection when
building test file.
Profiling GDB with the rest of series applied, I saw calls to
language_def showing up high in some runs. The problem is that
language_def is O(N) currently, since walk the languages vector each
time to find the matching language_defn.
IMO, the add_language mechanism is pointless, because "enum language"
implies the core of GDB needs to know about all languages anyway. So
simply make the languages vector array be an array where each
element's index is the corresponding enum language enumerator. Note
that "local_language_defn" is gone along the way. It's just a copy of
"auto", so the new code simply maps one to the other. One fewer place
to update when we need to change the language vector...
Also, a while ago the output of "set language" was made out of order
as side effect of some other change. While I was at it, I made them
sorted again.
gdb/ChangeLog:
2017-07-20 Pedro Alves <palves@redhat.com>
* ada-lang.c (ada_language_defn): Make extern.
(_initialize_ada_language): Remove add_language call.
* c-lang.c (c_language_defn, cplus_language_defn)
(asm_language_defn, minimal_language_defn): Make extern.
(_initialize_c_language): Delete.
* completer.c (compare_cstrings): Delete, moved to utils.h.
* d-lang.c (d_language_defn): Make extern.
(_initialize_d_language): Remove add_language calls.
* defs.h (enum language): Add comment.
* f-lang.c (f_language_defn): Make extern.
(_initialize_f_language): Remove add_language call.
* go-lang.c (go_language_defn): Make extern.
(_initialize_go_language): Remove add_language call.
* language.c: Include <algorithm>.
(languages): Redefine as const array.
(languages_size, languages_allocsize, DEFAULT_ALLOCSIZE): Delete.
(set_language_command): Handle "local". Use for-range loop.
(set_language): Remove loop.
(language_enum): Rewrite.
(language_def, language_str): Remove loops.
(add_language): Delete.
(add_set_language_command): New, based on add_languages.
(skip_language_trampoline): Adjust.
(local_language_defn): Delete.
(language_gdbarch_post_init): Adjust.
(_initialize_language): Remove add_language calls. Call
add_set_language_command.
* language.h (add_language): Delete.
(auto_language_defn)
(unknown_language_defn, minimal_language_defn, ada_language_defn)
(asm_language_defn, c_language_defn, cplus_language_defn)
(d_language_defn, f_language_defn, go_language_defn)
(m2_language_defn, objc_language_defn, opencl_language_defn)
(pascal_language_defn, rust_language_defn): Declare.
* m2-lang.c (m2_language_defn): Make extern.
(_initialize_m2_language): Remove add_language call.
* objc-lang.c (objc_language_defn): Make extern.
(_initialize_objc_language): Remove add_language call.
* opencl-lang.c (opencl_language_defn): Make extern.
(_initialize_opencl_language): Remove add_language call.
* p-lang.c (pascal_language_defn): Make extern.
(_initialize_pascal_language): Delete.
* rust-lang.c (rust_language_defn): Make extern.
(_initialize_rust_language): Delete.
* utils.h (compare_cstrings): New static inline function.
gdb/testsuite/ChangeLog:
2017-07-20 Pedro Alves <palves@redhat.com>
* gdb.base/default.exp (set language): Adjust expected output.
Tom Tromey
Thomas Preud'homme
Kevin Buettner
Pedro Alves
Walfred Tedeschi
John Baldwin
Christoph Weinmann
Bernhard Heckel
Frank Penczek
Jan Kratochvil
Simon Marchi
Sergio Durigan Junior
Weimin Pan
Yao Qi
Andreas Arnez