Use a combination of a single new Reg bit and Byte, Word, Dword, or
Qword instead.
Besides shrinking the number of operand type bits this has the benefit
of making register handling more similar to accumulator handling (a
generic flag is being accompanied by a "size qualifier"). It requires,
however, to split a few insn templates, as it is no longer correct to
have combinations like Reg32|Reg64|Byte. This slight growth in size will
hopefully be outweighed by this change paving the road for folding a
presumably much larger number of templates later on.
Consider the following Ada code defining a global variable whose
type is an array of static bounds (1 .. 2), but where its elements
are a variant record whose size is not statically known:
type Ints is array (Natural range <>) of Integer;
type Bounded_Ints (Max_Size : Natural) is record
Length : Natural := 0;
Objs : Ints (1 .. Max_Size);
end record;
type Ints_Doubled is array (1 .. 2) of Bounded_Ints (Idem (0));
Global : Ints_Doubled;
When compiling this program at -O2 using a GCC-6.4-based compiler
on x86_64-linux, trying to print the value of that global variable
yields:
(gdb) p global
$1 =
Let's look at the debugging info, which starts with the global
variable itself...
.uleb128 0x19 # (DIE (0x25e) DW_TAG_variable)
.long .LASF32 # DW_AT_name: "fd__global"
.long 0x273 # DW_AT_type
... its type is a reference to a typedef ...
.uleb128 0x14 # (DIE (0x273) DW_TAG_reference_type)
.byte 0x8 # DW_AT_byte_size
.long 0x202 # DW_AT_type
[...]
.uleb128 0x15 # (DIE (0x202) DW_TAG_typedef)
.long .LASF19 # DW_AT_name: "fd__ints_doubled"
.long 0x20d # DW_AT_type
... of an array (1..2) ...
.uleb128 0x2 # (DIE (0x20d) DW_TAG_array_type)
.long .LASF19 # DW_AT_name: "fd__ints_doubled"
.long 0x15b # DW_AT_type
.long 0x221 # DW_AT_sibling
.uleb128 0x16 # (DIE (0x21a) DW_TAG_subrange_type)
.long 0x40 # DW_AT_type
.sleb128 2 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x20d
... of a struct whose name is fd__Tints_doubledC:
.uleb128 0x10 # (DIE (0x15b) DW_TAG_structure_type)
.long .LASF11 # DW_AT_name: "fd__Tints_doubledC"
.long 0x1e4 # DW_AT_GNAT_descriptive_type
# DW_AT_artificial
.long 0x1e4 # DW_AT_sibling
.uleb128 0x7 # (DIE (0x16a) DW_TAG_member)
.long .LASF4 # DW_AT_name: "max_size"
[snip]
The error occurs while Ada evaluator is trying to "fix"
the element type inside the array, so as to determine its actual
size. For that, it searches for a parallel "XVZ" variable,
which, when found, contains the object's actual size.
Unfortunately in our case, the variable exists but has been
optimized out, as seen by the presence of a variable DIE in
the debugging info, but with no address attribute:
.uleb128 0x18 # (DIE (0x24e) DW_TAG_variable)
.long .LASF31 # DW_AT_name: "fd__Tints_doubledC___XVZ"
.long 0x257 # DW_AT_type
# DW_AT_artificial
Discussing this with some members of AdaCore's compiler team,
it is expected that the optimizer can get rid of this variable,
and we don't want to pessimize the code just to improve debuggability,
since -O2 is about performance. So, the idea of this patch is
not to make it work, but provide a bit more information to help
users understand what kind of error is preventing GDB from being
able to print the variable's value.
The first hurdle we had to clear was the fact that ada_val_print
traps all exceptions (including QUIT ones!), and does so completly
silently. So, the fix was to add a trace of the exception being
generated. While doing so, we fix an old XXX/FIXME by only catching
errors, letting QUIT exceptions go through.
Once this is done, we now get an error message, which gives a first
clue as to what was happening:
(gdb) p fd.global
$1 = <error reading variable: value has been optimized out>
However, it would be more useful to know which value it was
that was optimized out. For that purpose, we enhanced
ada-lang.c::ada_to_fixed_type_1 so as to re-throw the error
with a message which indicates which variable we failed to read.
With those changes, the new output is now:
(gdb) p fd.global
$1 = <error reading variable: unable to read value of fd__Tints_doubledC___XVZ (value has been optimized out)>
gdb/ChangeLog:
* ada-lang.c (ada_to_fixed_type_1): Rethrow errors with
a more detailed exception message when getting an exception
while trying to read the value of an XVZ variable.
* ada-valprint.c (ada_val_print): Only catch RETURN_MASK_ERROR
exceptions. Print an error message when an exception is caught.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/ada-valprint-error.c: New file.
* gdb.dwarf2/ada-valprint-error.exp: New file.
Tested on x86_64-linux
Consider the following code, which declares a variabled called "input"
of type "parameter", which is a record with one component called "u2",
where the type of that component is a simple 3-element array of
floating point values:
type Float_Array_3 is array (1 .. 3) of Float;
type parameters is record
u2 : Float_Array_3;
end record;
input : parameters;
Trying to assign a value to input.u2 causes GDB to crash:
(gdb) p input.u2 := (0.25,0.5,0.75)
[1] 20228 segmentation fault (core dumped) [...]/gdb
The crash occurs because input.u2 is described in the debugging
info as a typedef of an array. Indeed, input's type is:
<1><ae9>: Abbrev Number: 7 (DW_TAG_structure_type)
<aea> DW_AT_name : (indirect string, offset: 0x1045): target_wrapper__parameters
[...]
<2><af5>: Abbrev Number: 8 (DW_TAG_member)
<af6> DW_AT_name : u2
[...]
<afb> DW_AT_type : <0xaca>
and, looking at DIE 0xaca to get input.u2's type, we see:
<1><aca>: Abbrev Number: 4 (DW_TAG_typedef)
<acb> DW_AT_name : (indirect string, offset: 0x1060): target_wrapper__float_array_3
[...]
<ad1> DW_AT_type : <0xad5>
We can also confirm, following the DW_AT_type attribute (0xad5), that
it's a typedef of our array:
<1><ad5>: Abbrev Number: 5 (DW_TAG_array_type)
<ad6> DW_AT_name : (indirect string, offset: 0x1060): target_wrapper__float_array_3
[...]
In fact, this scenario uncovered 2 areas where typedef handling
is missing, thus causing a crash. The first happens inside
assign_aggregate:
if (ada_is_direct_array_type (lhs_type))
{
lhs = ada_coerce_to_simple_array (lhs);
lhs_type = value_type (lhs);
low_index = TYPE_ARRAY_LOWER_BOUND_VALUE (lhs_type);
high_index = TYPE_ARRAY_UPPER_BOUND_VALUE (lhs_type);
}
Here, lhs_type is a TYPE_CODE_TYPEDEF. ada_is_direct_array_type
knows how to handle it, but TYPE_ARRAY_LOWER_BOUND_VALUE assumes
that the given type is a TYPE_CODE_ARRAY. As such, it ends up
accessing some fields in lhs_type which it shouldn't, and kaboom.
We fixed this issue by making sure that the TYPE_CODE_TYPEDEF
layer gets stripped.
Once this is done, we hit a different kind of error, also leading to
a SEGV, this time in assign_component. The code looks like this:
if (TYPE_CODE (value_type (lhs)) == TYPE_CODE_ARRAY)
[...]
else
[...]
Because once again lhs is a TYPE_CODE_TYPEDEF, the check fail,
and we end up assuming that lhs is a struct, executing the "else"
block, which is:
else
{
elt = ada_index_struct_field (index, lhs, 0, value_type (lhs));
elt = ada_to_fixed_value (elt);
}
Since lhs is not a struct, ada_index_struct_field returns NULL,
which ada_to_fixed_value does not handle well, hence another crash.
This patch fixes this other issue the same way, by stripping
TYPE_CODE_TYPEDEF layers.
gdb/ChangeLog:
* ada-lang.c (assign_component): Strip any TYPE_CODE_TYPEDEF
layer from lhs' type.
(assign_aggregate): Likewise.
gdb/testsuite:
* gdb.ada/assign_arr: New testcase.
Tested on x86_64-linux.
Using this small example:
procedure Foo is
type Integer_Access is access all Integer;
procedure P (A : Integer_Access) is
begin
null;
end P;
begin
P (null);
end Foo;
and doing this debug session:
(gdb) b p
Breakpoint 1 at 0x402d67: file foo.adb, line 7.
(gdb) print p(null)
Breakpoint 1, foo.p (a=0x641010) at foo.adb:10
... ^^^^^^^^^^
shows that something goes wrong between the initial null value and the
received parameter value in the 'f' function.
The value for the parameter 'a' we get is the address of the value we
would expect instead of the value itself. This can be checked by doing:
(gdb) p *a
$1 = 0
Before this fix, in ada_convert_value, this function was looking to the
actual value (the null value here) to determine if the formal (parameter
'a' in the procedure 'P' in this exemple) requires a pointer or not which
is a wrong assumption and leads to push the address of the value to the
inferior instead of the value itself.
This is fixed by this patch.
gdb/ChangeLog:
* ada-lang.c (ada_convert_actual): Change the way actual value
are passed to the inferior when the inferior expects a pointer type.
gdb/testsuite/ChangeLog:
* gdb.ada/funcall_ptr: New testcase.
Tested on x86_64-linux.
Pseudo prefixes must be used on an instruction. Issue an error when
pseudo prefix is used without instruction.
PR gas/22623
* gas/config/tc-i386.c (output_insn): Check pseudo prefix
without instruction.
* testsuite/gas/i386/i386.exp: Run inval-pseudo.
* testsuite/gas/i386/inval-pseudo.l: New file.
* testsuite/gas/i386/inval-pseudo.s: Likewise.
As suggested by Joel Brobecker <brobecker@adacore.com> and as per fsf
coding standards. Also fix a few more issues with directly printing
pointers.
gdb/ChangeLog:
* gdb/or1k-tdep.c (show_or1k_debug): Fix function parameter alignment.
(or1k_analyse_inst): Likewise.
(or1k_single_step_through_delay): Likewise.
(or1k_frame_cache): Fix parameter alignment and use paddress()
instead of %x.
gdb/ChangeLog:
yyyy-mm-dd Stafford Horne <shorne@gmail.com>
* NEWS (Changes since GDB 8.0): Mention new or1k target and new
commands to set/show or1k debug.
I forgot to indent the "if" clause properly and put the "&&" at the
beginning of the line, so ARI complained. This commit fixed it.
gdb/ChangeLog:
2017-12-15 Sergio Durigan Junior <sergiodj@redhat.com>
* typeprint.c (whatis_exp): Fix ARI warning and reindent "if"
condition.
This commit implements the pahole-like '/o' option for 'ptype', which
prints the offsets and sizes of struct fields, reporting whenever
there is a hole found.
The output is heavily based on pahole(1), with a few modifications
here and there to adjust it to our reality. Here's an example:
/* offset | size */ type = struct wer : public tuv {
public:
/* 32 | 24 */ struct tyu {
/* 32:31 | 4 */ int a1 : 1;
/* 32:28 | 4 */ int a2 : 3;
/* 32: 5 | 4 */ int a3 : 23;
/* 35: 3 | 1 */ char a4 : 2;
/* XXX 3-bit hole */
/* XXX 4-byte hole */
/* 40 | 8 */ int64_t a5;
/* 48:27 | 4 */ int a6 : 5;
/* 48:56 | 8 */ int64_t a7 : 3;
/* total size (bytes): 24 */
} a1;
/* total size (bytes): 56 */
}
A big part of this patch handles the formatting logic of 'ptype',
which is a bit messy. The code to handle bitfield offsets, however,
took some time to craft. My thanks to Pedro Alves for figuring things
out and pointing me to the right direction, as well as coming up with
a way to inspect the layout of structs with bitfields (see testcase
for comments).
After many discussions both on IRC and at the mailing list, I tried to
implement printing vtables and inherited classes. Unfortunately the
code grew too complex and there were still a few corner cases failing
so I had to drop the attempt. This should be implemented in a future
patch.
This patch is the start of a long-term work I'll do to flush the local
patches we carry for Fedora GDB. In this specific case, I'm aiming at
upstreaming the feature implemented by the 'pahole.py' script that is
shipped with Fedora GDB:
<https://src.fedoraproject.org/rpms/gdb/blob/master/f/gdb-archer.patch#_311>
This has been regression-tested on the BuildBot. There's a new
testcase for it, along with an update to the documentation. I also
thought it was worth mentioning this feature in the NEWS file.
gdb/ChangeLog:
2017-12-15 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
PR cli/16224
* NEWS (Changes since GDB 8.0): Mention new '/o' flag.
* c-typeprint.c (OFFSET_SPC_LEN): New define.
(c_type_print_varspec_prefix): New argument 'struct
print_offset_data *'.
(c_type_print_base_1): New function and prototype.
(c_print_type_1): New function, with code from 'c_print_type'.
(c_print_type): Use 'c_print_type_1'.
(c_type_print_varspec_prefix): New argument 'struct
print_offset_data *'. Use it. Call 'c_type_print_base_1'
instead of 'c_print_type_base'.
(print_spaces_filtered_with_print_options): New function.
(output_access_specifier): Take new argument FLAGS. Modify
function to call 'print_spaces_filtered_with_print_options'.
(c_print_type_vtable_offset_marker): New function.
(c_print_type_union_field_offset): New function.
(c_print_type_struct_field_offset): New function.
(c_print_type_no_offsets): New function.
(c_type_print_base_struct_union): New argument 'struct
print_offset_data *'. Print offsets and sizes for
struct/union/class fields.
* typeprint.c (const struct type_print_options
type_print_raw_options): Initialize 'print_offsets'.
(static struct type_print_options default_ptype_flags):
Likewise.
(struct print_offset_data print_offset_default_data): New
variable.
(whatis_exp): Handle '/o' option.
(_initialize_typeprint): Add '/o' flag to ptype's help.
* typeprint.h (struct print_offset_data): New struct.
(struct type_print_options) <print_offsets>: New field.
gdb/testsuite/ChangeLog:
2017-12-15 Sergio Durigan Junior <sergiodj@redhat.com>
PR cli/16224
* gdb.base/ptype-offsets.cc: New file.
* gdb.base/ptype-offsets.exp: New file.
gdb/doc/ChangeLog:
2017-12-15 Sergio Durigan Junior <sergiodj@redhat.com>
PR cli/16224
* gdb.texinfo (ptype): Add documentation for new flag '/o'.
While doing the 'ptype /o' work, I noticed that 'c_type_print_base'
was very long, with a big amount of code just to handle the case of
TYPE_CODE_{STRUCT,UNION}. This made working with the function a bit
difficult, specially because of the level of indentation.
This commit moves this part of the code to their own functions. Now
we have a 'c_type_print_base_struct_union' with most of the code, and
also 'need_access_label_p', which is a subset of the code that was
also a good candidate for having its own function.
gdb/ChangeLog:
2017-12-15 Sergio Durigan Junior <sergiodj@redhat.com>
* c-typeprint.c (need_access_label_p): New function.
(c_type_print_base_struct_union): New function.
(c_type_print_base): Move code to handle
TYPE_CODE_{STRUCT,UNION} to the functions mentioned above.
PR 22571
* archive.c (bfd_openr_next_archived_file): Extend the
documentation to note that it is necessary to call
bfd_check_format on the rrturned bfd before using it.
This fixes PR19061, where gdb hangs/spins-on-cpu when debugging any
program on Alpha.
(This patch is Uros' forward port of the patch from comment #5
of the PR [1].)
Patch was tested on alphaev68-linux-gnu, also tested with gcc's
testsuite, where it fixed all hangs in guality.exp and
simulate-thread.exp testcases.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=19061#c5
gdb/ChangeLog:
2017-12-15 Richard Henderson <rth@redhat.com>
Uros Bizjak <ubizjak@gmail.com>
PR gdb/19061
* alpha-tdep.c (alpha_software_single_step): Call
alpha_deal_with_atomic_sequence here.
(set_gdbarch_software_single_step): Set to
alpha_software_single_step.
* nat/linux-ptrace.h [__alpha__]: Define GDB_ARCH_IS_TRAP_BRKPT
and GDB_ARCH_IS_TRAP_HWBKPT.
I see the following test failure when gdb is configured without XML
support,
maintenance check xml-descriptions binutils-gdb/gdb/testsuite/../features
warning: Can not parse XML target description; XML support was disabled at compile time^M
Tested 29 XML files, 29 failed
(gdb) FAIL: gdb.gdb/unittest.exp: maintenance check xml-descriptions ${srcdir}/../features
gdb/testsuite:
2017-12-15 Yao Qi <yao.qi@linaro.org>
* gdb.gdb/unittest.exp: Skip 'maintenance check xml-descriptions'
if XML is disabled.
I find a fail in gdb unit test when gdb is configured without XML
support.
warning: Can not parse XML memory map; XML support was disabled at compile time^M
Self test failed: self-test failed at ../../binutils-gdb/gdb/unittests/memory-map-selftests.c:65
...
Ran 31 unit tests, 1 failed^M
(gdb) FAIL: gdb.gdb/unittest.exp: maintenance selftest
gdb:
2017-12-15 Yao Qi <yao.qi@linaro.org>
* unittests/memory-map-selftests.c: Wrap test with HAVE_LIBEXPAT.
Again these look to be typos: No template currently allows for any two
(or all three) of RegXMM, RegYMM, and RegZMM in a single operand. Quite
clearly ! are missing, after the addition of which the checks for the
first and (if present) second operands also fully match up.
They are relevant only when multiple operands permit registers:
operand_type_register_match() returns true if either operand is not a
register one. IOW
grep -i CheckRegSize i386-opc.tbl | grep -Ev "(Reg[8136]|Acc).*,.*(Reg|Acc)"
should produce no output.
I'm rather certain the missing ! was just a typo, the more with the
similar check in mind that's in the same function a few hundred lines
down (in the body of "if (vex_reg != (unsigned int) ~0)"). Of course
this can't be demonstrated by a test case - internal data structure
consistency is being checked here, and neither form of the check
triggers with any current template.
It is also not really clear to me why operand_type_equal() is being used
in the {X,Y,Z}MM register check here, rather than just testing the
respective bits: Just like Reg32|Reg64 is legal in an operand template,
I don't see why e.g. RegXMM|RegYMM wouldn't be. For example it ought to
be possible to combine
vaddpd, 3, 0x6658, None, 1, CpuAVX, Modrm|Vex|VexOpcode=0|VexVVVV=1|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Xmmword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|RegXMM, RegXMM, RegXMM }
vaddpd, 3, 0x6658, None, 1, CpuAVX, Modrm|Vex=2|VexOpcode=0|VexVVVV=1|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Ymmword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|RegYMM, RegYMM, RegYMM }
into a single template (with setting of VEX.L suitably handled elsewhere
if that's not already happening anyway).
Additionally I don't understand why this uses abort() instead of
gas_assert().
Both of these latter considerations then also apply to the
aforementioned other check in the same function.
We never need to resolve_forwards() a symbol found by hash table lookup
such as target->tls_get_addr_opt() but we do potentially need to do so
for random symbols seen on relocs. So these calls were in the wrong
order, resulting in missing stubs and an assertion failure.
PR 22602
* powerpc.cc (Target_powerpc::Branch_info::mark_pltcall): Resolve
forwards before replacing __tls_get_addr.
(Target_powerpc::Branch_info::make_stub): Likewise.
Consider the following code:
type Top_T is tagged record
N : Integer := 1;
U : Integer := 974;
A : Integer := 48;
end record;
type Middle_T is new Top.Top_T with record
N : Character := 'a';
C : Integer := 3;
end record;
type Bottom_T is new Middle.Middle_T with record
N : Float := 4.0;
C : Character := '5';
X : Integer := 6;
A : Character := 'J';
end record;
Tagged records in Ada provide object-oriented features, and what
is interesting in the code above is that a child tagged record
introduce additional components (fields) which sometimes have
the same name as one of the components in the parent. For instance,
Bottom_T introduces a component named "C", while at the same time
inheriting from Middle_T which also has a component named "C";
so, in essence, type Bottom_T has two components with the same name!
And before people start wondering why the language can possibly
be allowing that, this can only happen if the parent type has
a private definition. In our case, this was brought to our attention
when the parent was a generic paramenter.
With that in mind... Let's say we now have a variable declared
and initialized as follow:
TC : Top_A := new Bottom_T;
And then we use this variable to call this function
procedure Assign (Obj: in out Top_T; TV : Integer);
as follow:
Assign (Top_T (B), 12);
Now, we're in the debugger, and we're inside that procedure
(Top.Assign in our gdb testcase), and we want to print
the value of obj.c:
Usually, the tagged record or one of the parent type owns the
component to print and there's no issue but in this particular
case, what does it mean to ask for Obj.C ? Since the actual
type for object is type Bottom_T, it could mean two things: type
component C from the Middle_T view, but also component C from
Bottom_T. So in that "undefined" case, when the component is
not found in the non-resolved type (which includes all the
components of the parent type), then resolve it and see if we
get better luck once expanded.
In the case of homonyms in the derived tagged type, we don't
guaranty anything, and pick the one that's easiest for us
to program.
This patch fixes the behavior like described above.
gdb/ChangeLog:
* ada-lang.c (ada_value_primitive_field): Handle field search
in case of homonyms.
(find_struct_field): Ditto.
(ada_search_struct_field): Ditto.
(ada_value_struct_elt): Ditto.
(ada_lookup_struct_elt_type): Ditto.
gdb/testsuite/ChangeLog:
* gdb.ada/same_component_name: New testcase.
Tested on x86_64-linux.
In Python 3, the 'p' format specifier can be passed to
PyArg_ParseTupleAndKeywords to test the argument for truth and convert
it to a boolean value (the p stands for predicate). However, it is not
available in Python 2, causing this error:
Traceback (most recent call last):
File "test.py", line 1, in <module>
b1 = gdb.Breakpoint("foo", qualified=False)
TypeError: argument 10 (impossible<bad format char>)
This patch changes it to the 'O' specifier, which returns the Python
object passed in without transformation, and uses PyObject_IsTrue on it.
This is what is done for the other boolean parameters of this function
(internal and temporary).
This fixes the test gdb.python/py-breakpoint.exp for Python 2.
gdb/ChangeLog:
* python/py-breakpoint.c (bppy_init): Use 'O' format specifier
for "qualified" and use PyObject_IsTrue.
We can run the gnu_unique_object symbol test on all ELF targets.
Those that don't support the symbol type and fail to assemble can just
be resolved as "unsupported". This means binutils_assemble can't
report an error on assembly failure, but it probably should never have
done that anyway.
* testsuite/lib/utils-lib.exp (default_binutils_assemble_flags):
Don't perror on assembler diagnostic output.
* testsuite/binutils-all/nm.exp: Run unique symbol test on all
ELF targets. Resolve as "unsupported" on assembly failure.
The .debug_names completely misses its support as it did not even produce
DW_IDX_type_unit.
gdb/ChangeLog
2017-12-14 Jan Kratochvil <jan.kratochvil@redhat.com>
* dwarf2read.c (dw2_debug_names_iterator::next): Support
DW_IDX_type_unit.
(debug_names::dwarf5_offset_size, unit_kind): New.
(debug_names::insert): Add parameter kind.
(debug_names::build): Support DW_IDX_type_unit.
(debug_names::recursively_write_psymbols): Update
(debug_names::write_psymbols caller.
(debug_names::write_one_signatured_type_data)
(debug_names::write_one_signatured_type): New.
(debug_names::index_key, debug_names::symbol_value)
(debug_names::write_psymbols): Add kind.
(debug_names::write_one_signatured_type): New.
(write_debug_names): Move dwarf5_offset_size to debug_names.
Use debug_names::write_one_signatured_type for type units.
Consider the following Ada Code:
type Str is new String (1 .. 4);
My_str : Str := "ABCD";
This simply declares a 4-character string type. Trying to perform
equality tests using it currently yield an error:
(gdb) p my_str = my_str
Attempt to compare array with non-array
(gdb) p my_str = "ABCD"
Attempt to compare array with non-array
The error occurs because my_str is defined as an object whose
type is a typdef to a TYPE_CODE_ARRAY, which ada_value_equal
is not expecting at all (yet). This patch fixes this oversight.
gdb/ChangeLog:
* ada-lang.c (ada_value_equal): Add handling of typedef types
when comparing array objects.
gdb/testsuite/ChangeLog:
* gdb.ada/str_binop_equal: New testcase.
Tested on x86_64-linux.
The reasons for not supporting task switching when debugging core files
appear to now mostly be OBE. In particular, on GNU/Linux, the thread
layer is now able to retrieve the same thread info as in the live
process. So, this patch is mostly about just removing the guard
that limited the use of task switching to live processes.
gdb/ChangeLog:
* ada-tasks.c (read_atcb): Properly set task_info->ptid
when !target_has_execution as well.
(task_command): Remove error when !target_has_execution.
gdb/testsuite/ChangeLog:
* gdb.ada/task_switch_in_core: New testcase.
This patch adds the possibility to pass a qualified=True|False parameter
when creating a breakpoint in Python. It is equivalent to using
-qualified in a linespec. The parameter actually accepts any Python
value, and converts it to boolean using Python's standard rules for
that (https://docs.python.org/3/library/stdtypes.html#truth).
Unlike the -source/-line/-function/-label parameters, it is possible to
use -qualified with a "normal" (non-explicit) linespec. Therefore, it
is possible (unlike these other parameters) to use this new parameter
along with the spec parameter.
I updated the py-breakpoint.exp test. To be able to test multiple
locations using a namespace, I had to switch the test case to compile as
C++. If we really wanted to, we could run it as both C and C++, but
omit the C++-specific parts when running it as C.
gdb/ChangeLog:
* location.h (string_to_event_location): Add match_type
parameter.
* location.c (string_to_event_location): Likewise.
* python/py-breakpoint.c (bppy_init): Handle qualified
parameter.
gdb/doc/ChangeLog:
* python.texi (Manipulating breakpoints using Python): Document
qualified parameter to gdb.Breakpoint.
gdb/testsuite/ChangeLog:
* gdb.python/py-breakpoint.c (foo_ns::multiply): New function.
* gdb.python/py-breakpoint.exp: Compile the test case as c++,
call test_bkpt_qualified.
(test_bkpt_qualified): New proc.
While writing the tests included in the previous commit, I noticed
that test_gdb_complete_tab_multiple would not FAIL if GDB happens to
show more completions than expected before the expected list.
E.g., with something like this, expecting "p foo" to complete to
"foo2" and "foo3":
test_gdb_complete_tab_multiple "p foo" "" {
"foo2"
"foo3"
}
and then if foo actually completes to:
(gdb) p foo[TAB]
foo1 foo2 foo3
^^^^
we'd still PASS. (Note the spurious "foo1" above.)
This tightens the regexp with a beginning anchor thus making the
completions above cause a FAIL. Other similar functions in
completion-support.exp already do something like this; I had just
missed this one originally. Thankfully, this did not expose any
problems in the gdb.linespec/ tests. Phew.
gdb/testsuite/ChangeLog:
2017-12-13 Pedro Alves <palves@redhat.com>
* lib/completion-support.exp (test_gdb_complete_tab_multiple):
Tighten regexp by matching with an anchor.
I noticed this regression in the expression completer:
"(gdb) p std::[TAB]" => "(gdb) p std::std::"
obviously we should have not completed to "std::std::".
The problem is that in the earlier big completer rework, I missed
taking into account the fact that with expressions, the completion
word point is not always at the start of the symbol name (it is with
linespecs).
The fix is to run the common prefix / LCD string (what readline uses
to expand the input line) through make_completion_match_str too.
New testcase included, exercising both TAB completion and the complete
command.
gdb/ChangeLog:
2017-12-13 Pedro Alves <palves@redhat.com>
* completer.c (completion_tracker::maybe_add_completion): New
'text' and 'word' parameters. Use make_completion_match_str.
(completion_tracker::add_completion): New 'text' and 'word'
parameters. Pass down.
(completion_tracker::recompute_lowest_common_denominator): Change
parameter type to gdb::unique_xmalloc_ptr rval ref. Adjust.
* completer.h (completion_tracker::add_completion): New 'text' and
'word' parameters.
(completion_tracker::recompute_lowest_common_denominator): Change
parameter type to gdb::unique_xmalloc_ptr rval ref.
(completion_tracker::recompute_lowest_common_denominator): Change
parameter type to gdb::unique_xmalloc_ptr rval ref.
* symtab.c (completion_list_add_name): Pass down 'text' and 'word'
as well.
gdb/testsuite/ChangeLog:
2017-12-13 Pedro Alves <palves@redhat.com>
* gdb.cp/cpcompletion.exp: Load completion-support.exp.
("expression with namespace"): New set of tests.
* gdb.cp/pr9594.cc (Test_NS::foo, Test_NS::bar)
(Nested::Test_NS::qux): New.
* lib/completion-support.exp (test_gdb_complete_cmd_multiple): Add
defaults to 'start_quote_char' and 'end_quote_char' parameters.
We have several places doing essentially the same thing; factor them
out to a central place. Some of the places overallocate for no good
reason, or use strcat unnecessarily. The centralized version is more
precise and to the point.
(I considered making the gdb::unique_xmalloc_ptr overload version of
make_completer_match_str try to realloc (not xrealloc) probably
avoiding an allocation in most cases, but that'd be probably overdoing
it, and also, now that I'm writing this I thought I'd try to see how
could we ever get to filename_completer with "text != word", but I
couldn't figure it out. Running the testsuite with 'gdb_assert (text
== word);' never tripped on the assertion either. So post gdb 8.1,
I'll probably propose a patch to simplify filename_completer a bit,
and the gdb::unique_xmalloc_str overload can be removed then.)
gdb/ChangeLog:
2017-12-13 Pedro Alves <palves@redhat.com>
* cli/cli-decode.c (complete_on_cmdlist, complete_on_enum): Use
make_completion_match_str.
* completer.c: Use gdb::unique_xmalloc_ptr and
make_completion_match_str.
(make_completion_match_str_1): New.
(make_completion_match_str(const char *, const char *,
const char *)): New.
(make_completion_match_str(gdb::unique_xmalloc_ptr<char> &&,
const char *, const char *)): New.
* completer.h (make_completion_match_str(const char *,
const char *, const char *)): New.
(make_completion_match_str(gdb::unique_xmalloc_ptr<char> &&,
const char *, const char *)): New.
* interps.c (interpreter_completer): Use make_completion_match_str.
* symtab.c (completion_list_add_name, add_filename_to_list): Use
make_completion_match_str.
I find the documentation of the gdb.Breakpoint constructor hard to read
and not very informative, especially since we have added the new
linespec parameters. There are multiple problems (some are subjective):
- It's not clear that you should use either the spec string or the
explicit arguments, not both.
- It's not clear what combination of parameters you can use.
- The big block of text describing the arguments is hard to read.
- Currently, it seems like the "spec" argument is mandatory, even though
it is not (if you use explicit linespec).
- The square bracket nesting
[arg1 [, arg2[, arg3]]]
makes it seems like if you specify arg3, you must specify arg1 and
arg2 (it's not the case here).
This patch tries to address these problems.
gdb/doc/ChangeLog:
* python.texi (Manipulating breakpoints using Python): Split doc
of Breakpoint.__init__ in two, split text in multiple
paragraphs, don't nest parameter square brackets.
R_AARCH64_ABS64, R_AARCH64_ABS32 and R_AARCH64_ABS16 are data relocations
supported in AArch64 elf ABI.
R_AARCH64_ABS64 under LP64 is allowed in shared object and a dynamic relocation entry
will be generated. This allows the dynamic linker to do further symbol resolution.
R_AARCH64_ABS32 likewise is allowed in shared object, however under ILP32 abi.
The original behavior for R_AARCH64_ABS32 under LP64 is that, it's allowed
in shared object and silently resolved at static linking time.
No dynamic relocation entry is generate for it.
R_AARCH64_ABS16 is allowed in shared object under both L64 and ILP32.
It's resolved at static linking time as well.
Under LP64, the address should be 64-bit. R_AARCH64_ABS32 relocation indicates
an address that is only sized 32 bits which is meaningless in LP64 shared object.
It's useful to error out.
I have checked glibc dynamic linker code, R_AARCH64_ABS16 is not supported at all. So
R_AARCH64_ABS16 should be reject in shared object completely.
In this patch, R_AARCH64_ABS32 is rejected under LP64 in constant section of shared object.
R_AARCH64_ABS16 is rejected in constant section of shared object in both ABI.
This will sometimes provide useful information for buggy code.
Fix a few issues not using the gettext _() wrapper and issues where
we are using %p directly instead of the dedicated host/target functions.
gdb/ChangeLog:
yyyy-mm-dd Stafford Horne <shorne@gmail.com>
* or1k-tdep.c (or1k_analyse_inst): Use _() wrapper for message
strings.
(or1k_unwind_pc): Use paddress() instead of %p.
(or1k_unwind_sp): Likewise.
(or1k_frame_cache): Use host_address_to_string()/paddress()
instead of %p and use _() wrapper for message strings.
opcodes * disassemble.c: Enable disassembler_needs_relocs for PRU.
gas * testsuite/gas/pru/extern.s: New test for print of U16_PMEMM
relocation.
* testsuite/gas/pru/extern.d: New test driver.
This fixes these failures on 64 bit which currently occur when running
the Binutils testsuite with a default PIE compiler.
< FAIL: Build rdynamic-1
< FAIL: Build dynamic-1
< FAIL: Build pr22269-1
bfd/ChangeLog:
2017-12-13 Andreas Krebbel <krebbel@linux.vnet.ibm.com>
* elf64-s390.c (elf_s390_adjust_dynamic_symbol): Use
UNDEFWEAK_NO_DYNAMIC_RELOC.
(allocate_dynrelocs): Likewise.
(elf_s390_relocate_section): Check resolved_to_zero.
(elf_s390_finish_dynamic_symbol): Don't generate runtime reloc if
UNDEFWEAK_NO_DYNAMIC_RELOC.
The "server" command prefix no longer turns confirmation queries off.
We can reproduce this with any program by tring to delete all breakpoints,
for instance:
(gdb) break main
Breakpoint 1 at 0x40049b: file /[...]/break-fun-addr1.c, line 21.
(gdb) server delete breakpoints
Delete all breakpoints? (y or n)
GDB should not be asking "Delete all breakpoints? (y or n)", but
instead just delete all breakpoints without asking for confirmation.
Looking at utils.c::defaulted_query gives a glimpse of how this feature
is expected to work:
/* Automatically answer the default value if the user did not want
prompts or the command was issued with the server prefix. */
if (!confirm || server_command)
return def_value;
So, it relies on the server_command global to be set when the "server "
command prefix is used, which is no longer the case since the following
commit:
commit b69d38afde
Date: Wed Mar 9 18:25:00 2016 +0000
Subject: Command line input handling TLC
The patch was simplifying the handling for the command line, and
I believe there was just a small oversight of removing the setting
of the server_command global.
This patch restores that, and adds a testcase to make sure we test
that feature.
gdb/ChangeLog:
* event-top.c (handle_line_of_input): Set server_command.
gdb/testsuite/ChangeLog:
* gdb.base/server-del-break.c: New file.
* gdb.base/server-del-break.exp: New file.
Tested on x86_64-linux, no regression.
This is the testsuite for the or1k sim, it tests running many of the
basic architecture instructions on the openrisc sim.
sim/testsuite/sim/or1k/ChangeLog:
2017-12-12 Peter Gavin <pgavin@gmail.com>
Stafford Horne <shorne@gmail.com>
* add.S: New file.
* alltests.exp: New file.
* and.S: New file.
* basic.S: New file.
* div.S: New file.
* ext.S: New file.
* find.S: New file.
* flag.S: New file.
* fpu.S: New file.
* jump.S: New file.
* load.S: New file.
* mac.S: New file.
* mfspr.S: New file.
* mul.S: New file.
* or.S: New file.
* or1k-asm-test-env.h: New file.
* or1k-asm-test-helpers.h: New file.
* or1k-asm-test.h: New file.
* or1k-asm.h: New file.
* or1k-test.ld: New file.
* ror.S: New file.
* shift.S: New file.
* spr-defs.h: New file.
* sub.S: New file.
* xor.S: New file.
sim/testsuite/ChangeLog:
2017-12-12 Stafford Horne <shorne@gmail.com>
Peter Gavin <pgavin@gmail.com>
* configure: Regenerated.
These are separted out to make the patch easier to read and smaller.
sim/ChangeLog:
2017-12-12 Stafford Horne <shorne@gmail.com>
Peter Gavin <pgavin@gmail.com>
* configure: Regenerated.
* or1k/aclocal.m4: Generated.
* or1k/config.in: Generated.
* or1k/configure: Generated.
These are the simulator files generated by cgen. These are split out
from the main sim patch to make the patch easier to review and smaller.
sim/ChangeLog:
2017-12-12 Stafford Horne <shorne@gmail.com>
Peter Gavin <pgavin@gmail.com>
* or1k/arch.c: Generated.
* or1k/arch.h: Generated.
* or1k/cpu.c: Generated.
* or1k/cpu.h: Generated.
* or1k/cpuall.h: Generated.
* or1k/decode.c: Generated.
* or1k/decode.h: Generated.
* or1k/model.c: Generated.
* or1k/sem-switch.c: Generated.
* or1k/sem.c: Generated.
This adds the OpenRISC 32-bit sim target. The OpenRISC sim is a CGEN
based sim so the bulk of the code is generated from the .cpu files by
CGEN. The engine decode and execute logic in mloop uses scache with
pseudo-basic-block extraction and supports both full and fast (switch)
modes.
The sim does not implement an mmu at the moment. The sim does implement
fpu instructions via the common sim-fpu implementation.
sim/ChangeLog:
2017-12-12 Stafford Horne <shorne@gmail.com>
Peter Gavin <pgavin@gmail.com>
* configure.tgt: Add or1k sim.
* or1k/README: New file.
* or1k/Makefile.in: New file.
* or1k/configure.ac: New file.
* or1k/mloop.in: New file.
* or1k/or1k-sim.h: New file.
* or1k/or1k.c: New file.
* or1k/sim-if.c: New file.
* or1k/sim-main.h: New file.
* or1k/traps.c: New file.
