This patch adds a new function amd64_linux_read_description, which
creates amd64-linux target descriptions according to its two
arguments, xcr0 and is_x32.
gdb:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* amd64-linux-tdep.c (amd64_linux_read_description): New
function.
(amd64_linux_core_read_description): Call
amd64_linux_read_description.
(amd64_linux_init_abi): Likewise.
(amd64_x32_linux_init_abi): Likewise.
* amd64-linux-tdep.h (amd64_linux_read_description): Declare.
* x86-linux-nat.c (x86_linux_read_description): Call
amd64_linux_read_description.
GDBserver now is able to generate target descriptions from features, so
don't need to remember these target description files.
gdb/gdbserver:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* configure.srv (srv_i386_linux_xmlfiles): Remove
i386/i386-XXX-linux.xml from it.
Now, these *-generate.c files are only used in GDBserver for unit test.
If $development is false (in release), these *-generate.c files won't be
used at all.
gdb/gdbserver:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* configure.srv: Set srv_i386_linux_regobj empty if $development
is false.
* linux-i386-ipa.c (initialize_low_tracepoint): Don't call
initialize_low_tdesc.
* linux-x86-low.c (initialize_low_arch): Wrap initialize_low_tdesc
with #if initialize_low_tdesc.
* linux-x86-tdesc-selftest.c: New file.
* linux-x86-tdesc.c: Move code to linux-x86-tdesc-selftest.c.
The code on creating i386-linux target descriptions are quite similar
between GDB and GDBserver, so this patch moves them into a shared file
arch/i386.c. I didn't name it as i386-linux.c, because I want to reuse it
to create other i386 non-linux target descriptions later.
gdb:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* Makefile.in (ALL_TARGET_OBS): Add i386.o.
(SFILES): Add arch/i386.c.
(HFILES_NO_SRCDIR): Add arch/i386.h.
* arch/i386.c: New file.
* arch/i386.h: New file.
* arch/tdesc.h (allocate_target_description): Declare.
(set_tdesc_architecture): Declare.
(set_tdesc_osabi): Declare.
* configure.tgt (i[34567]86-*-linux*): Add i386.o.
* i386-linux-tdep.c: Don't include ../features/i386/32bit-XXX.c.
include arch/i386.h.
(i386_linux_read_description): Remove code and call
i386_create_target_description.
(set_tdesc_architecture): New function.
(set_tdesc_osabi): New function.
* target-descriptions.h (allocate_target_description): Remove.
gdb/gdbserver:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* Makefile.in (arch-i386.o): New rule.
* configure.srv (i[34567]86-*-linux*): Add arch-i386.o.
(x86_64-*-linux*): Likewise.
* linux-x86-tdesc.c: Don't include ../features/i386/32bit-XXX.c,
include arch/i386.h.
(i386_linux_read_description): Remove code and call
i386_create_target_description.
* tdesc.c (allocate_target_description): New function.
* tdesc.h (set_tdesc_architecture): Remove declaration.
(set_tdesc_osabi): Likewise.
GDBserver still uses pre-generated target descriptions in order to
reply to GDB's query on target description (see xml-builtin-generated.c
in GDBserver build directory). This patch teaches GDBserver to
create XML contents according to the target descriptions rather than
using pre-generated ones.
First, change target feature c files to pass the feature xml file
name to tdesc_create_feature, so that target description in GDBserver
can record them, and create XML contents from these features in
buffer, like
...
<xi:include href="$FEATURE1_XML_NAME"/>
<xi:include href="$FEATURE2_XML_NAME"/>
...
and send this buffer back to GDB.
Note that this patch reuses target_desc.xmltarget a little bit, which is
to hold the XML contents dynamically generated in tdesc_get_features_xml.
However, it is not xfree'ed in ~target_desc, because we can't tell it is
from xstrdup or a literal string. Since we don't delete target_desc,
there is no memory leak yet. After we change all target descriptions to
the new style, target_desc.xmltarget is from xstrdup, then, we can safely
xfree it in ~target_desc.
gdb:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* arch/tdesc.h (tdesc_create_feature): Add an argument xml.
* target-descriptions.c (tdesc_create_feature): Likewise, and
adjust code.
* features/i386/32bit-avx.c: Re-generated.
* features/i386/32bit-avx512.c: Re-generated.
* features/i386/32bit-core.c: Re-generated.
* features/i386/32bit-linux.c: Re-generated.
* features/i386/32bit-mpx.c: Re-generated.
* features/i386/32bit-pkeys.c: Re-generated.
* features/i386/32bit-sse.c: Re-generated.
gdb/gdbserver:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* linux-x86-tdesc.c: Don't include <inttypes.h>.
(i386_linux_read_description) [!IN_PROCESS_AGENT]: Call
set_tdesc_architecture and set_tdesc_osabi. Remove code setting
.xmltarget.
* server.c (get_features_xml): Call tdesc_get_features_xml.
* tdesc.c (set_tdesc_architecture): New function.
(set_tdesc_osabi): New function.
(tdesc_get_features_xml): New function.
(tdesc_create_feature): Add an argument.
* tdesc.h (struct target_desc) <features>: New field.
<arch, osabi>: New field.
(~target_desc): xfree features, arch, and osabi.
(target_desc::oerator==): Don't compare .xmltarget.
[!IN_PROCESS_AGENT] (set_tdesc_architecture): Declare.
(set_tdesc_osabi): Likewise.
(tdesc_get_features_xml): Likewise.
This patch adds a unit test in GDBserver to test dynamically created
target descriptions equal these pre-generated ones.
gdb/gdbserver:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* linux-x86-tdesc.c: Include selftest.h.
(i386_tdesc_test): New function.
(initialize_low_tdesc): Call selftests::register_test.
* tdesc.h: Include regdef.h.
(target_desc): Override operator == and !=.
gdb:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* regformats/regdef.h (struct reg): Override operator == and !=.
tdesc_i386_XXX_linux is used in many places in linux-x86-low.c and this
patch adds a new function i386_linux_read_description to return the right
tdesc according to xcr0. i386_linux_read_description is quite similar to
the counterpart in GDB, and the following patch will share the duplicated
code, so this patch adds arch/tdesc.h includes the declarations of various
tdesc apis which are used by the shared code. The generated c feature
files can include arch/tdesc.h only.
gdb/gdbserver:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* configure.srv (srv_tgtobj): Append linux-x86-tdesc.o.
(ipa_obj): Likewise.
* linux-i386-ipa.c: Include common/x86-xstate.h
(get_ipa_tdesc): Call i386_linux_read_description.
(initialize_low_tracepoint): Don't call init_registers_XXX
functions, call initialize_low_tdesc instead.
* linux-x86-low.c (x86_linux_read_description): Call
i386_linux_read_description.
(initialize_low_arch): Don't call init_registers_i386_XXX
functions, call initialize_low_tdesc.
* linux-x86-tdesc.c: New file.
* linux-x86-tdesc.h (x86_linux_tdesc): New X86_TDESC_LAST.
(i386_get_ipa_tdesc_idx): Declare.
(i386_get_ipa_tdesc): Declare.
(initialize_low_tdesc): Declare.
gdb:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* arch/tdesc.h: New file.
* regformats/regdat.sh: Generate code using tdesc_create_reg.
* target-descriptions.c: Update comments.
* target-descriptions.h: Include "arch/tdesc.h". Remove the
declarations.
* features/i386/32bit-avx.c: Re-generated.
* features/i386/32bit-avx512.c: Re-generated.
* features/i386/32bit-core.c: Re-generated.
* features/i386/32bit-linux.c: Re-generated.
* features/i386/32bit-mpx.c: Re-generated.
* features/i386/32bit-pkeys.c: Re-generated.
* features/i386/32bit-sse.c: Re-generated.
Nowadays, target_desc.reg_defs is a pointer points to a pre-generated
array, which is not flexible. This patch changes it from an array
to a VEC so that GDBserver can create target descriptions dynamically
later. Instead of using pre-generated array, the -generated.c calls
VEC_safe_push to add each register to vector.
Since target_desc.reg_defs is used in IPA, we need to build common/vec.c
for IPA too.
gdb/gdbserver:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* Makefile.in (IPA_OBJS): Add vec-ipa.o
* regcache.c (get_thread_regcache): Use VEC_length.
(init_register_cache): Likewise.
(regcache_cpy): Likewise.
(registers_to_string): Iterate reg_defs via VEC_iterate.
(find_regno): Likewise.
(find_register_by_number): Use VEC_index.
(register_size): Call find_register_by_number.
(register_data): Call find_register_by_number.
(supply_regblock): Use VEC_length.
(regcache_raw_read_unsigned): Likewise.
* tdesc.c (init_target_desc): Iterate reg_defs via
VEC_iterate.
(default_description): Update initializer.
(copy_target_description): Don't update field num_registers.
* tdesc.h (struct target_desc) <reg_defs>: Change it to VEC.
<num_registers>: Remove.
gdb:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* regformats/regdat.sh: Update generated code.
regformats/regdat.sh generate some *-generated.c files when GDBserver
is built. Each .c file has some static variables, which are only used
within function init_registers_XXX, like this,
static struct reg regs_i386_linux[] = {
{ "eax", 0, 32 },
{ "ecx", 32, 32 },
...
};
static const char *expedite_regs_i386_linux[] = { "ebp", "esp", "eip", 0 };
static const char *xmltarget_i386_linux = "i386-linux.xml";
void
init_registers_i386_linux (void)
{
...
}
This patch moves these static variables' definitions to function
init_registers_XXX, so the generated files look like this,
void
init_registers_i386_linux (void)
{
static struct target_desc tdesc_i386_linux_s;
struct target_desc *result = &tdesc_i386_linux_s;
static struct reg regs_i386_linux[] = {
...
};
static const char *expedite_regs_i386_linux[] = { "ebp", "esp", "eip", 0 };
static const char *xmltarget_i386_linux = "i386-linux.xml";
...
}
We want GDBserver create target descriptions dynamically in each
init_registers_XXXX functions, so this patch moves all the related code
into function init_registers_XXXX, so that the following patch can easily
change function init_registers_XXXX to create target description
dynamically, rather than using current pre-generated array.
gdb:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* regformats/regdat.sh: Adjust code order.
My compiler (gcc 5.4.0, clang 3.8) gives this warning:
/home/emaisin/src/binutils-gdb/gdb/expprint.c: In lambda function:
/home/emaisin/src/binutils-gdb/gdb/expprint.c:1055:35: error: format not a string literal and no format arguments [-Werror=format-security]
fprintf_filtered (stream, mod);
^
Fix it by not using the passed string as the format string.
gdb/ChangeLog:
* expprint.c (dump_subexp_body_standard): Use constant format
string in fprintf_filtered call.
Previously this used the error function from GDB directly when linked
against GDB instead of the error method in the host callbacks
structure. This was exposed via a link error when GDB was converted
to C++. The error function invokes the error callback similar to
sim_io_error.
Note that there are also error functions in sim/ppc/main.c and
sim/ppc/misc.c. The ppc libsim.a expects each consumer to provide
several symbols used by the library including "error". sim-calls.c
provides these symbols when the library is linked into gdb. The dgen,
igen, tmp-filter, tmp-ld-decode, tmp-ld-cache, and tmp-ld-insn programs
use the functions from misc.c. psim uses the functions from main.c.
sim/ppc/ChangeLog:
PR sim/20863
* sim_calls.c (error): New function.
NetBSD recently added PT_GETDBREGS and PT_SETDBREGS ptrace operations
that match the existing ones supported by x86-bsd-nat.c. NetBSD's
headers do not provide the DBREG_DRX helper macro, so define a local
version in x86-bsd-nat.c. In addition, add the x86-nat.o and x86-dregs.o
object files to the native NetBSD x86 build targets.
gdb/ChangeLog:
* configure.nat: Add "x86-nat.o x86-dregs.o" for NetBSD/amd64 and
NetBSD/i386.
* x86-bsd-nat.c [!DBREG_DRX && __NetBSD__]: Define DBREG_DRX.
Recent versions of NetBSD hide certain kernel structures needed by the
KVM target from userland unless this macro is defined.
gdb/ChangeLog:
* bsd-kvm.o: Define _KMEMUSER.
* configure.ac: Define _KMEMUSER when checking for "struct lwp".
* configure: Regenerate.
Here's the documentation bits for all the improvements done in
previous commits.
Note that the original "weak alias functions" paragraph ends up
disappearing, because this patch, which I'm considering kind of part
of this series, makes the alias case Just Work:
https://sourceware.org/ml/gdb-patches/2017-07/msg00018.html
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* NEWS (Safer support for debugging with no debug info): New.
gdb/doc/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Variables) <Program Variables>: Document inspecting
no-debug-info variables.
(Symbols) <Examining the Symbol Table>: Document inspecting
no-debug-info types.
(Calling) <Calling functions with no debug info>: New subsection,
documenting calling no-debug-info functions.
(Non-debug DLL Symbols) <Working with Minimal Symbols>: Update.
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.
Since minsym references now go via OP_VAR_MSYM_VALUE, UNOP_MEMVAL_TLS
is no longer used anywhere.
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* eval.c (evaluate_subexp_standard): Remove UNOP_MEMVAL_TLS
handling.
* expprint.c (print_subexp_standard, dump_subexp_body_standard):
Ditto.
* parse.c (operator_length_standard, operator_check_standard):
Ditto.
* std-operator.def (UNOP_MEMVAL_TLS): Delete.
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.
A following patch will want to call the new evaluate_var_value
function in another spot.
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* eval.c (evaluate_var_value): New function, factored out from ...
(evaluate_subexp_standard): ... here.
A following patch will want to factor out a bit of
evaluate_subexp_standard, and it'd be handy to reuse the code under the
"nosideret:" label there too. This commits moves it to a separate
function as preparation for that.
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* eval.c (eval_skip_value): New function.
(evaluate_subexp_standard): Use it.
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 previous patch 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 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 commit is a step toward fixing it.
The problem is that while evaluating the expression above, we have no
reference to the minimal symbol where we could extract the name from.
This is because the resulting expression tree has no reference to the
minsym at all. During parsing, the type and address of the minsym are
extracted and an UNOP_MEMVAL / UNOP_MEMVAL_TLS operator is generated
(see write_exp_elt_msym). With "set debug expression", here's what
you see:
0 OP_FUNCALL Number of args: 0
3 UNOP_MEMVAL Type @0x565334a51930 (<text variable, no debug info>)
6 OP_LONG Type @0x565334a51c60 (__CORE_ADDR), value 140737345035648 (0x7ffff7751d80)
The "print" case finds the function name, because
call_function_by_hand looks up the function by address again.
However, for "ptype", we don't reach that code, because obviously we
don't really call the function.
Unlike minsym references, references to variables with debug info have
a pointer to the variable's symbol in the expression tree, with
OP_VAR_VALUE:
(gdb) ptype main()
...
0 OP_FUNCALL Number of args: 0
3 OP_VAR_VALUE Block @0x0, symbol @0x559bbbd9b358 (main(int, char**))
...
so I don't see why do minsyms need to be different. So to prepare for
fixing the missing function name issue, this commit adds a new
OP_VAR_MSYM_VALUE operator that mimics OP_VAR_VALUE, except that it's
for minsyms instead of debug symbols. For infcalls, we now get
expressions like these:
0 OP_FUNCALL Number of args: 0
3 OP_VAR_MSYM_VALUE Objfile @0x1e41bf0, msymbol @0x7fffe599b000 (getenv)
In the following patch, we'll make OP_FUNCALL extract the function
name from the symbol stored in OP_VAR_VALUE/OP_VAR_MSYM_VALUE.
OP_VAR_MSYM_VALUE will be used more in a later patch in the series
too.
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* ada-lang.c (resolve_subexp): Handle OP_VAR_MSYM_VALUE.
* ax-gdb.c (gen_msym_var_ref): New function.
(gen_expr): Handle OP_VAR_MSYM_VALUE.
* eval.c (evaluate_var_msym_value): New function.
* eval.c (evaluate_subexp_standard): Handle OP_VAR_MSYM_VALUE.
<OP_FUNCALL>: Extract function name from symbol/minsym and pass it
to call_function_by_hand.
* expprint.c (print_subexp_standard, dump_subexp_body_standard):
Handle OP_VAR_MSYM_VALUE.
(union exp_element) <msymbol>: New field.
* minsyms.h (struct type): Forward declare.
(find_minsym_type_and_address): Declare.
* parse.c (write_exp_elt_msym): New function.
(write_exp_msymbol): Delete, refactored as ...
(find_minsym_type_and_address): ... this new function.
(write_exp_msymbol): Reimplement using OP_VAR_MSYM_VALUE.
(operator_length_standard, operator_check_standard): Handle
OP_VAR_MSYM_VALUE.
* std-operator.def (OP_VAR_MSYM_VALUE): New.
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.
For some reason I ended up staring at some of the "int flags" in
btrace-related code, and I got confused because I had no clue what the
flags where supposed to indicate.
Fix that by using enum_flags, so that:
#1 - it's clear from the type what the flags are about, and
#2 - the compiler can catch mismatching mistakes
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* cli/cli-cmds.c (print_disassembly, disassemble_current_function)
(disassemble_command): Use gdb_disassembly_flags instead of bare
int.
* disasm.c (gdb_pretty_print_disassembler::pretty_print_insn)
(dump_insns, do_mixed_source_and_assembly_deprecated)
(do_mixed_source_and_assembly, do_assembly_only, gdb_disassembly):
Use gdb_disassembly_flags instead of bare int.
* disasm.h (DISASSEMBLY_SOURCE_DEPRECATED, DISASSEMBLY_RAW_INSN)
(DISASSEMBLY_OMIT_FNAME, DISASSEMBLY_FILENAME)
(DISASSEMBLY_OMIT_PC, DISASSEMBLY_SOURCE)
(DISASSEMBLY_SPECULATIVE): No longer macros. Instead they're...
(enum gdb_disassembly_flag): ... values of this new enumeration.
(gdb_disassembly_flags): Define.
(gdb_disassembly)
(gdb_pretty_print_disassembler::pretty_print_insn): Use it.
* mi/mi-cmd-disas.c (mi_cmd_disassemble): Use
gdb_disassembly_flags instead of bare int.
* record-btrace.c (btrace_insn_history)
(record_btrace_insn_history, record_btrace_insn_history_range)
(record_btrace_insn_history_from): Use gdb_disassembly_flags
instead of bare int.
* record.c (get_insn_history_modifiers, cmd_record_insn_history):
Use gdb_disassembly_flags instead of bare int.
* target-debug.h (target_debug_print_gdb_disassembly_flags):
Define.
* target-delegates.c: Regenerate.
* target.c (target_insn_history, target_insn_history_from)
(target_insn_history_range): Use gdb_disassembly_flags instead of
bare int.
* target.h: Include "disasm.h".
(struct target_ops) <to_insn_history, to_insn_history_from,
to_insn_history_range>: Use gdb_disassembly_flags instead of bare
int.
(target_insn_history, target_insn_history_from)
(target_insn_history_range): Use gdb_disassembly_flags instead of
bare int.
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.
I think it would make more sense if the types and function declarations
related to command lines were in cli-script.h rather than defs.h, since
the related function definitions are in cli-script.c.
I had to add a few includes here and there. I also had to rename the
"lines" parameter of command_lines_deleter::operator(), because ncurses
has a "#define lines ..." that was interfering when cli-script.h is
included by some TUI source files that also include ncurses header files.
gdb/ChangeLog:
* cli/cli-script.h (enum misc_command_type): Move from defs.h.
(enum command_control_type): Likewise.
(struct command_line): Likewise.
(free_command_lines): Likewise.
(struct command_lines_deleter): Likewise.
(command_line_up): Likewise.
(read_command_lines): Likewise.
(read_command_lines_1): Likewise.
* defs.h (enum misc_command_type): Move to cli/cli-script.h.
(enum command_control_type): Likewise.
(struct command_line): Likewise.
(free_command_lines): Likewise.
(struct command_lines_deleter): Likewise.
(command_line_up): Likewise.
(read_command_lines): Likewise.
(read_command_lines_1): Likewise.
* breakpoint.h: Include cli/cli-script.h.
* extension-priv.h: Likewise.
* gdbcmd.h: Likewise.
If you "make" from scratch in gdbserver/, you'll notice that make
deletes the files it considers as intermediary at the end:
$ make clean && make
...
rm i386-mmx-linux-generated.c x32-avx-avx512-linux-generated.c ...
Then, if you type make again, make will rebuild these files and rebuild
gdbserver. To avoid this, we can add the .SECONDARY special target. If
it has no pre-requisites, all intermediary files will be kept.
gdb/gdbserver/ChangeLog:
* Makefile.in (.SECONDARY): Define target.
Instead, make symtab_and_line initialize its members itself. Many
symtab_and_line declarations are moved to where the object is
initialized at the same time both for clarity and to avoid double
initialization. A few functions, like e.g., find_frame_sal are
adjusted to return the sal using normal function return instead of an
output parameter likewise to avoid having to default-construct a sal
and then immediately have the object overwritten.
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* ada-lang.c (is_known_support_routine): Move sal declaration to
where it is initialized.
* breakpoint.c (create_internal_breakpoint, init_catchpoint)
(parse_breakpoint_sals, decode_static_tracepoint_spec)
(clear_command, update_static_tracepoint): Remove init_sal
references. Move declarations closer to initializations.
* cli/cli-cmds.c (list_command): Move sal declarations closer to
initializations.
* elfread.c (elf_gnu_ifunc_resolver_stop): Remove init_sal
references. Move sal declarations closer to initializations.
* frame.c (find_frame_sal): Return a symtab_and_line via function
return instead of output parameter. Remove init_sal references.
* frame.h (find_frame_sal): Return a symtab_and_line via function
return instead of output parameter.
* guile/scm-frame.c (gdbscm_frame_sal): Adjust.
* guile/scm-symtab.c (stscm_make_sal_smob): Use in-place new
instead of memset.
(gdbscm_find_pc_line): Remove init_sal reference.
* infcall.c (call_function_by_hand_dummy): Remove init_sal
references. Move declarations closer to initializations.
* infcmd.c (set_step_frame): Update. Move declarations closer to
initializations.
(finish_backward): Remove init_sal references. Move declarations
closer to initializations.
* infrun.c (process_event_stop_test, handle_step_into_function)
(insert_hp_step_resume_breakpoint_at_frame)
(insert_step_resume_breakpoint_at_caller): Likewise.
* linespec.c (create_sals_line_offset, decode_digits_ordinary)
(symbol_to_sal): Likewise.
* probe.c (parse_probes_in_pspace): Remove init_sal reference.
* python/py-frame.c (frapy_find_sal): Move sal declaration closer
to its initialization.
* reverse.c (save_bookmark_command): Use new/delete. Remove
init_sal references. Move declarations closer to initializations.
* source.c (get_current_source_symtab_and_line): Remove brace
initialization.
(set_current_source_symtab_and_line): Now takes the sal by const
reference. Remove brace initialization.
(line_info): Remove init_sal reference.
* source.h (set_current_source_symtab_and_line): Now takes a
symtab_and_line via const reference.
* stack.c (set_current_sal_from_frame): Adjust.
(print_frame_info): Adjust.
(get_last_displayed_sal): Return the sal via function return
instead of via output parameter. Simplify.
(frame_info): Adjust.
* stack.h (get_last_displayed_sal): Return the sal via function
return instead of via output parameter.
* symtab.c (init_sal): Delete.
(find_pc_sect_line): Remove init_sal references. Move
declarations closer to initializations.
(find_function_start_sal): Remove init_sal references. Move
declarations closer to initializations.
* symtab.h (struct symtab_and_line): In-class initialize all
fields.
* tracepoint.c (set_traceframe_context)
(print_one_static_tracepoint_marker): Remove init_sal references.
Move declarations closer to initializations.
* tui/tui-disasm.c (tui_show_disassem_and_update_source): Adjust.
* tui/tui-stack.c (tui_show_frame_info): Adjust. Move
declarations closer to initializations.
* tui/tui-winsource.c (tui_update_source_window_as_is): Remove
init_sal references. Adjust.
This replaces "struct symtabs_and_lines" with
std::vector<symtab_and_line> in most cases. This removes a number of
cleanups.
In some cases, the sals objects do not own the sals they point at.
Instead they point at some sal that lives on the stack. Typically
something like this:
struct symtab_and_line sal;
struct symtabs_and_lines sals;
// fill in sal
sals.nelts = 1;
sals.sals = &sal;
// use sals
Instead of switching those cases to std::vector too, such usages are
replaced by gdb::array_view<symtab_and_line> instead. This avoids
introducing heap allocations.
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* ax-gdb.c (agent_command_1): Use range-for.
* break-catch-throw.c (re_set_exception_catchpoint): Update.
* breakpoint.c: Include "common/array-view.h".
(init_breakpoint_sal, create_breakpoint_sal): Change sals
parameter from struct symtabs_and_lines to
array_view<symtab_and_line>. Adjust. Use range-for. Update.
(breakpoint_sals_to_pc): Change sals parameter from struct
symtabs_and_lines to std::vector reference.
(check_fast_tracepoint_sals): Change sals parameter from struct
symtabs_and_lines to std::array_view. Use range-for.
(decode_static_tracepoint_spec): Return a std::vector instead of
symtabs_and_lines. Update.
(create_breakpoint): Update.
(break_range_command, until_break_command, clear_command): Update.
(base_breakpoint_decode_location, bkpt_decode_location)
(bkpt_probe_create_sals_from_location)
(bkpt_probe_decode_location, tracepoint_decode_location)
(tracepoint_probe_decode_location)
(strace_marker_create_sals_from_location): Return a std::vector
instead of symtabs_and_lines.
(strace_marker_create_breakpoints_sal): Update.
(strace_marker_decode_location): Return a std::vector instead of
symtabs_and_lines. Update.
(update_breakpoint_locations): Change struct symtabs_and_lines
parameters to gdb::array_view. Adjust.
(location_to_sals): Return a std::vector instead of
symtabs_and_lines. Update.
(breakpoint_re_set_default): Use std::vector instead of struct
symtabs_and_lines.
(decode_location_default): Return a std::vector instead of
symtabs_and_lines. Update.
* breakpoint.h: Include "common/array-view.h".
(struct breakpoint_ops) <decode_location>: Now returns a
std::vector instead of returning a symtabs_and_lines via output
parameter.
(update_breakpoint_locations): Change sals parameters to use
gdb::array_view.
* cli/cli-cmds.c (edit_command, list_command): Update to use
std::vector and gdb::array_view.
(ambiguous_line_spec): Adjust to use gdb::array_view and
range-for.
(compare_symtabs): Rename to ...
(cmp_symtabs): ... this. Change parameters to symtab_and_line
const reference and adjust.
(filter_sals): Rewrite using std::vector and standard algorithms.
* elfread.c (elf_gnu_ifunc_resolver_return_stop): Simplify.
(jump_command): Update to use std::vector.
* linespec.c (struct linespec_state) <canonical_names>: Update
comment.
(add_sal_to_sals_basic): Delete.
(add_sal_to_sals, filter_results, convert_results_to_lsals)
(decode_line_2, create_sals_line_offset)
(convert_address_location_to_sals, convert_linespec_to_sals)
(convert_explicit_location_to_sals, parse_linespec)
(event_location_to_sals, decode_line_full, decode_line_1)
(decode_line_with_current_source)
(decode_line_with_last_displayed, decode_objc)
(decode_digits_list_mode, decode_digits_ordinary, minsym_found)
(linespec_result::~linespec_result): Adjust to use std::vector
instead of symtabs_and_lines.
* linespec.h (linespec_sals::sals): Now a std::vector.
(struct linespec_result): Use std::vector, bool, and in-class
initialization.
(decode_line_1, decode_line_with_current_source)
(decode_line_with_last_displayed): Return std::vector.
* macrocmd.c (info_macros_command): Use std::vector.
* mi/mi-main.c (mi_cmd_trace_find): Use std::vector.
* probe.c (parse_probes_in_pspace, parse_probes): Adjust to use
std::vector.
* probe.h (parse_probes): Return a std::vector.
* python/python.c (gdbpy_decode_line): Use std::vector and
gdb::array_view.
* source.c (select_source_symtab, line_info): Use std::vector.
* stack.c (func_command): Use std::vector.
* symtab.h (struct symtabs_and_lines): Delete.
* tracepoint.c (tfind_line_command, scope_info): Use std::vector.
An array_view is an abstraction that provides a non-owning view over a
sequence of contiguous objects.
A way to put it is that array_view is to std::vector (and std::array
and built-in arrays with rank==1) like std::string_view is to
std::string.
The main intent of array_view is to use it as function input parameter
type, making it possible to pass in any sequence of contiguous
objects, irrespective of whether the objects live on the stack or heap
and what actual container owns them. Implicit construction from the
element type is supported too, making it easy to call functions that
expect an array of elements when you only have one element (usually on
the stack). For example:
struct A { .... };
void function (gdb::array_view<A> as);
std::vector<A> std_vec = ...;
std::array<A, N> std_array = ...;
A array[] = {...};
A elem;
function (std_vec);
function (std_array);
function (array);
function (elem);
Views can be either mutable or const. A const view is simply created
by specifying a const T as array_view template parameter, in which
case operator[] of non-const array_view objects ends up returning
const references. (Making the array_view itself const is analogous to
making a pointer itself be const. I.e., disables re-seating the
view/pointer.) Normally functions will pass around array_views by
value.
Uses of gdb::array_view (other than the ones in the unit tests) will
be added in a follow up patch.
gdb/ChangeLog
2017-09-04 Pedro Alves <palves@redhat.com>
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Add
unittests/array-view-selftests.c.
(SUBDIR_UNITTESTS_OBS): Add array-view-selftests.o.
* common/array-view.h: New file.
* unittests/array-view-selftests.c: New file.
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.
Fix build regression introduced by 0860c437cb ("btrace: Store
btrace_insn in an std::vector"):
src/gdb/btrace.c: In function ‘void ftrace_add_pt(btrace_thread_info*, pt_insn_decoder*, int*, std::vector<unsigned int>&)’:
src/gdb/btrace.c:1329:38: error: invalid initialization of reference of type ‘const btrace_insn&’ from expression of type ‘btrace_insn*’
ftrace_update_insns (bfun, &btinsn);
^
src/gdb/btrace.c:648:1: note: in passing argument 2 of ‘void ftrace_update_insns(btrace_function*, const btrace_insn&)’
ftrace_update_insns (struct btrace_function *bfun, const btrace_insn &insn)
^
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* btrace.c (ftrace_add_pt): Pass btrace_insn to
ftrace_update_insns by reference instead of pointer.
This patch remove the usage of tdesc_i386_mmx in i386-go32-tdep.c, and use
i386_target_description to get it instead.
gdb:
2017-09-04 Yao Qi <yao.qi@linaro.org>
* i386-go32-tdep.c: Include x86-xstate.h.
(i386_go32_init_abi): Call i386_target_description.
* i386-tdep.c (i386_target_description): Return tdesc_i386_mmx
if xcr0 is X86_XSTATE_X87_MASK.
* i386-tdep.h (tdesc_i386): Remove the declaration.
(tdesc_i386_mmx): Likewise.
i386fbsd_core_read_xcr0 reads the value of xcr0 from the corefile. If
it fails, returns 0. This makes its caller {i386,amd64}_target_description
has to handle this special value. IMO, i386fbsd_core_read_xcr0 should
return the default xcr0 in case of error.
gdb:
2017-09-04 Yao Qi <yao.qi@linaro.org>
* i386-fbsd-tdep.c (i386fbsd_core_read_xcr0): Return
X86_XSTATE_SSE_MASK instead of 0.
Yao Qi