This commit applies all changes made after running the gdb/copyright.py
script.
Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.
gdb/ChangeLog:
Update copyright year range in all GDB files.
After the previous patch, on Fedora 27 (glibc 2.26), if you try
calling strlen in the inferior, you now get:
(top-gdb) p strlen ("hello")
'__strlen_avx2' has unknown return type; cast the call to its declared return type
This is correct, because __strlen_avx2 is written in assembly.
We can improve on this though -- if the final ifunc resolved/target
function has no debug info, but the ifunc _resolver_ does have debug
info, we can try extracting the final function's type from the type
that the resolver returns. E.g.,:
typedef size_t (*strlen_t) (const char*);
size_t my_strlen (const char *) { /* some implementation */ }
strlen_t strlen_resolver (unsigned long hwcap) { return my_strlen; }
extern size_t strlen (const char *s);
__typeof (strlen) strlen __attribute__ ((ifunc ("strlen_resolver")));
In the strlen example above, the resolver returns strlen_t, which is a
typedef for pointer to a function that returns size_t. "strlen_t" is
the type of both the user-visible "strlen", and of the the target
function that implements it.
This patch teaches GDB to extract that type.
This is done for actual inferior function calls (in infcall.c), and
for ptype (in eval_call). By the time we get to either of these
places, we've already lost the original symbol/minsym, and only have
values and types to work with. Hence the changes to c-exp.y and
evaluate_var_msym_value, to ensure that we propagate the ifunc
minsymbol's info.
The change to make ifunc symbols have no/unknown return type exposes a
latent problem -- gdb.compile/compile-ifunc.exp calls a no-debug-info
function, but we did not warn about it. The test is fixed by this
commit too.
gdb/ChangeLog:
2018-04-26 Pedro Alves <palves@redhat.com>
* blockframe.c (find_gnu_ifunc_target_type): New function.
(find_function_type): New.
* eval.c (evaluate_var_msym_value): For GNU ifunc types, always
return a value with a memory address.
(eval_call): For calls to GNU ifunc functions, try to find the
type of the target function from the type that the resolver
returns.
* gdbtypes.c (objfile_type): Don't install a return type for ifunc
symbols.
* infcall.c (find_function_return_type): Delete.
(find_function_addr): Add 'function_type' parameter. For calls to
GNU ifunc functions, try to find the type of the target function
from the type that the resolver returns, and return it via
FUNCTION_TYPE.
(call_function_by_hand_dummy): Adjust to use the function type
returned by find_function_addr.
(find_function_addr): Add 'function_type' parameter and move
description here.
* symtab.h (find_function_type, find_gnu_ifunc_target_type): New
declarations.
gdb/testsuite/ChangeLog:
2018-04-26 Pedro Alves <palves@redhat.com>
* gdb.compile/compile-ifunc.exp: Also expect "function has unknown
return type" warnings.
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.
This applies the second part of GDB's End of Year Procedure, which
updates the copyright year range in all of GDB's files.
gdb/ChangeLog:
Update copyright year range in all GDB files.
Due to the lack of debug information in the binary, GDB is unable to figure
out what language is being used. This may be a problem when doing remote
debugging and the binary stops at the entry point containing asm code.
In this case GDB will switch to asm as current language and will not switch
back to C when it reaches main, which in turn causes the compile feature check
to malfunction.
This is solved by forcing the language to C after reaching main.
gdb/testsuite/ChangeLog:
2015-08-26 Luis Machado <lgustavo@codesourcery.com>
* gdb.compile/compile-ifunc.exp (with_test_prefix): Force language
to C.
One could not call IFUNCs (=indirect functions) from the compiled injected
code. Either it errored with:
gdb command line:1:1: error: function return type cannot be function
or it just called the IFUNC dispatcher in normal way, returning real function
implementation address instead of the function return value (and thus no
function was called).
gdb/ChangeLog
2015-02-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* compile/compile-c-symbols.c (convert_one_symbol, convert_symbol_bmsym)
(gcc_symbol_address): Call gnu_ifunc_resolve_addr.
gdb/testsuite/ChangeLog
2015-02-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile-ifunc.c: New file.
* gdb.compile/compile-ifunc.exp: New file.
Joel Brobecker
Sandra Loosemore
Pedro Alves
Luis Machado
Jan Kratochvil