Alan Hayward [Wed, 1 Aug 2018 09:57:13 +0000 (10:57 +0100)]
Aarch64 SVE: Support changing vector lengths in gdbserver
There are two parts to this patch - gdbserver and GDB.
In gdbserver, there needs to be an equivalent of the thread_architecture
method used in GDB. In regcache, validate the tdesc with the
use target_validate_tdesc target function. If this fails then re-obtain
the target descriptor via general setup.
The aarch64 validation step simply checks the value of the VG register to
see if it matches the current kernel value.
In GDB, we have a similar check when receiving a stop reply. Validate the
tdesc using gdbarch_target_description_changed_p. If this fails re-obtain
the target descriptor via general setup - which is done by setting up an
tdep info structure containing the vector length.
The aarch64 validation step checks the value of VG (which is marked as
an expediated register, so is in the stop reply).
Alan Hayward [Thu, 13 Sep 2018 15:48:51 +0000 (16:48 +0100)]
Add gdbserver target methods target_validate_tdesc and arch_setup
target_validate_tdesc () is added as a new target function.
This function checks current target description is still valid for the
current inferior, returning false if not. On SVE, we need to check if the
vector length has changed - if it has then the current target descriptor
will need to be switched to a valid one.
The existing arch_setup () is extended to be a target function.
This will later allow it to be called from get_thread_regcache () in
gdbserver/regcache.c. This call is required to generate a new target
descriptor if we have decided the current one is no longer valid.
2018-09-13 Alan Hayward <alan.hayward@arm.com>
gdbserver/
* linux-aarch64-low.c (int aarch64_validate_tdesc): New function.
(struct linux_target_ops): Add aarch64_validate_tdesc.
* linux-low.c (linux_validate_tdesc): New function.
(linux_target_ops): Add linux_arch_setup and linux_validate_tdesc.
* linux-low.h (linux_target_ops): Add validate_tdesc.
* target.h (struct target_ops): Likewise.
(target_arch_setup) New macro.
(target_validate_tdesc) New macro.
Alan Hayward [Thu, 13 Sep 2018 15:48:27 +0000 (16:48 +0100)]
Add target_description_changed_p and target_get_tdep_info methods
target_description_changed_p () is added as a new gdbarch function.
Given a list of register values received from the inferior, it will check if
the current target descriptor is no longer valid for the inferior. This is
required because on SVE the register sizes can change whilst the inferior is
running.
target_get_tdep_info () is added as a new gdbarch function.
Given a list of registers, it will return a tdep info which then can be used
when creating/finding a valid target descriptor for that inferior.
Include stubbed aarch64 versions.
2018-09-13 Alan Hayward <alan.hayward@arm.com>
gdb/
* aarch64-tdep.c (aarch64_target_description_changed_p): New function.
(aarch64_target_get_tdep_info): New function.
(aarch64_gdbarch_init): Add in the new functions
* arch-utils.c (default_target_description_changed_p): New function.
(default_target_get_tdep_info): New function.
* arch-utils.h: (default_target_description_changed_p): New
declaration.
(default_target_get_tdep_info): New declaration.
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh: (target_description_changed_p): New function.
(target_get_tdep_info): New function.
Alan Hayward [Thu, 13 Sep 2018 15:44:29 +0000 (16:44 +0100)]
Aarch64 SVE: Support changing vector lengths in GDB
Override the thread_architecture method to place the vector length in the
tdep_info and then find using info. Do not set this as a pointer as
this will cause issues in later patches.
2018-09-13 Alan Hayward <alan.hayward@arm.com>
gdb/
* aarch64-linux-nat.c
(aarch64_linux_nat_target::thread_architecture): Add override.
* aarch64-tdep.c (aarch64_get_tdesc_vq): Check for nullptr.
(aarch64_gdbarch_init): Ensure differemt tdesc for each VQ.
Alan Hayward [Thu, 13 Sep 2018 15:44:10 +0000 (16:44 +0100)]
Aarch64 SVE: Support changing vector lengths for ptrace
When writing registers to the kernel, check if regcache VG has been changed. If
so then update the thread's vector length. If required, resize the registers
in the kernel dump before writing it back.
When reading registers from the kernel, ensure regcache VG register is updated.
The regcache registers should already be of the correct length.
Jan Beulich [Thu, 13 Sep 2018 09:07:07 +0000 (11:07 +0200)]
x86: use D attribute also for SIMD templates
Various moves come in load and store forms, and just like on the GPR
and FPU sides there would better be only one pattern. In some cases this
is not feasible because the opcodes are too different, but quite a few
cases follow a similar standard scheme. Introduce Opcode_SIMD_FloatD and
Opcode_SIMD_IntD, generalize handling in operand_size_match() (reverse
operand handling there simply needs to match "straight" operand one),
and fix a long standing, but so far only latent bug with when to zap
found_reverse_match.
Also once again drop IgnoreSize where pointlessly applied to templates
touched anyway as well as *word when redundant with Reg*.
Jan Beulich [Thu, 13 Sep 2018 09:05:27 +0000 (11:05 +0200)]
x86: improve operand reversal
In quite a few cases the .s suffix or {load} / {store} prefixes did not
work as intended, or produced errors when they're supposed to be ignored
when it is not possible to carry out the request.
The change here re-purposes(?) the .s suffix to no longer mean "store"
(if that's what 's' did stand for), since the forms used in the base
templates are not consistently loads (and we unlikely want to change
that). The pseudo prefixes will now fulfill what their names say, i.e.
{load} now only ever produces a load form encoding (if available) while
{store} only ever produces a store form one (again if available). This
requires minimal test suite adjustments, while the majority of the
changes there are simply additions.
Simon Marchi [Wed, 12 Sep 2018 22:27:57 +0000 (18:27 -0400)]
python: Add tests for trying to use an invalid Inferior object
This patch adds tests for trying to use property or methods on a
gdb.Inferior object that represents an inferior that does not exist
anymore. We expect an exception to be thrown.
gdb/testsuite/ChangeLog:
* gdb.python/py-inferior.exp: Test using an invalid gdb.Inferior
object.
Move 'is_regular_file' from common-utils.c to filestuff.c
There is no reason for 'is_regular_file' to be in common-utils.c; it
belongs to 'filestuff.c'. This commit moves the function definition
and its prototype to the appropriate files.
The motivation behind this move is a failure that happens on certain
cross-compilation environments when compiling the IPA library, due to
the way gnulib probes the need for a 'stat' call replacement. Because
configure checks when cross-compiling are more limited, gnulib decides
that it needs to substitute the 'stat' calls its own 'rpl_stat';
however, the IPA library doesn't link with gnulib, which leads to an
error when compiling 'common-utils.c':
The most simple fix for this problem is to move 'is_regular_file' to
'filestuff.c', which is not used by IPA. This ends up making the
files more logically organized as well, since 'is_regular_file' is a
file operation.
Simon Marchi [Wed, 12 Sep 2018 16:24:41 +0000 (12:24 -0400)]
Add debug output about skipping files and functions
While trying to create skips for libstdc++, I found myself debugging GDB
quite a bit, mostly to find out what the exact function name to match
is. I thought it would make sense to have this information as debug
output.
Darwin: set startup-with-shell to off on Sierra and later.
On Mac OS X Sierra and later, the shell is not allowed to be
debug so add a check and disable startup with shell in that
case. This disabling is done temporary before forking
inferior and restored after the fork.
gdb/ChangeLog:
* darwin-nat.c (should_disable_startup_with_shell):
New function.
(darwin_nat_target::create_inferior): Add call.
(gdb) start
Temporary breakpoint 1 at 0x100000fb4: file /tmp/helloworld.c, line 1.
Starting program: /private/tmp/helloworld
[New Thread 0x2903 of process 60326]
During startup program terminated with signal SIGTRAP, Trace/breakpoint
trap.
Field signaled from darwin_thread_info is not initialized thus signal
sent to the debuggee is considered as not sent by GDB whereas it should.
This patch fixes this problem and also updates (change type and/or
initialize) other fields in the same structure at the same time.
gdb/ChangeLog:
* darwin-nat.h (struct darwin_thread_info) <gdb_port,
inf_port, msg_state>: Initialize.
(struct darwin_thread_info) <signaled, single_step>: Change
type and initialize.
(struct darwin_thread_info) <event>: Initialize.
Jan Kratochvil [Tue, 11 Sep 2018 10:59:52 +0000 (12:59 +0200)]
[testsuite] Fix dg-extract-results.sh path
There was a typo in patch:
commit 5a6996172e6294ea37054b1a9caa3a923a8fe399
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date: Mon Aug 6 16:05:16 2018 +0200
Update dg-extract-results.* from gcc
gdb/testsuite/ChangeLog
2018-09-11 Jan Kratochvil <jan.kratochvil@redhat.com>
The problem reported there is about the replacement of 'getcwd' when
cross-compiling GDB. With our current gnulib copy, the mechanism for
deciding whether to use the system's 'getcwd' or gnulib's version is
too simplistic and pessimistic, so when cross-compiling we always end
up using gnulib's version, which has a limitation: it cannot handle
the situation when the parent directory doesn't have read permissions.
The solution is to backport the following gnulib commit:
This reverts commit 7a6dbc2fdb2323c35e981f93236f323e9d7c0b24 ("Update
gnulib to current upstream master"). It is needed because the gnulib
update caused problems with people using old GCC compilers (version
4.8, for example), which support C99 but don't default to using it.
Unfortunately this broke GDB for these users. A more detailed report
of what happened can be found at:
The reason for updating our gnulib copy was to fix PR gdb/23558.
Reverting this patch reintroduces the bug, so in order to fix it I
will submit a subsequent patch which cherry-picks the fix from gnulib.
(Ada) Fix resolving of homonym components in tagged types
ada_value_struct_elt is used when displaying a component (say, 'N') of
a record object (say, 'Obj') of type, say, 't1'. Now if Obj is tagged
(Ada parlance: "tagged types" are what other object-oriented languages
call "classes"), then 'N' may not be visible in the current view and
we need to look for it in its actual type. We do that at the same time
as resolving variable-length fields. This would typically be done by
the following call to ada_value_struct_elt, with the last parameter
check_tag set to 1:
This is the general logic, but recently we introduced a special case
to handle homonyms. Different components may have the same name in a
tagged type. For instance:
type Top_T is tagged record
N : Integer := 1;
end record;
type Middle_T is new Top.Top_T with record
N : Character := 'a';
end record;
Middle_T extends Top_T and both define a (different) component with
the same name ('N'). In such a case, using the actual type of a
Middle_T object would create a confusion, since we would have two
component 'N' in this actual type.
So, to handle homonyms, we convert t1 to the actual type *if
and only if* N cannot be found in the current view. For example, if Obj
has been created as a Middle_T but is seen as a Top_T'Class at our
point of execution, then "print Obj.N" will display the integer field
defined in Top_T's declaration.
Now, even if we find N in the current view, we still have to get a
fixed type: for instance, the record can be unconstrained and we still
need a fixed type to get the proper offset to each field. That is
to say, in this case:
type Dyn_Top_T (Disc : Natural) is tagged record
S : Integer_Array (1 .. Disc) := (others => Disc);
N : Integer := 1;
end record;
type Dyn_Middle_T is new Dyn_Top.Dyn_Top_T with record
N : Character := 'a';
U : Integer := 42;
end record;
If we have an object Obj of type Dyn_Middle_T and we want to display
U, we don't need to build, from its tag, a real type with all its real
fields. In other words, we don't need to add the parent components:
Disc, S, and the integer N. We only need to access U and it is
directly visible in Dyn_Middle_T. So no tag handling. However, we do
need to build a fixed-size type to have the proper offset to U (since
this offset to U depends on the size of Obj.S, which itself is dynamic
and depends on the value of Obj.Disc).
We accidentally lost some of this treatment when we introduced the
resolution of homonyms. This patch re-install this part by uncoupling
the tag resolution from the "fixing" of variable-length components.
This change also slightly simplifies the non-tagged case: in the
non-tagged case, no need to set check_tag to 1, since we already know
that there is no tag.
gdb/ChangeLog:
* ada-lang.c (ada_value_struct_elt): Call ada_to_fixed_type
with check_tag to 1 if and only if the type is tagged and the
component being searched cannot been found in the current
view. Otherwise, always call ada_to_fixed_type with
check_tag to 0.
gdb/testsuite/ChangeLog:
* gdb.ada/same_component_name: Add test for case of tagged record
with variable-length fields.
(Ada) Fix printing of access to unconstrained arrays
Using this Ada code:
type String_Access is access String;
type Array_Of_String is array (1 .. 2) of String_Access;
Aos : Array_Of_String := (new String'("ab"), new String'("cd"));
When debugging with GDB, printing each Aos element displays:
The problem was located in ada_value_print function and due to the fact
that the value_type used in this function was based on
value_enclosing_type rather than value_type itself.
In our example, the difference between the value_type and the
value_enclosing_type of the value is that the value_type contains an
additional typedef layer which is not present in the value_enclosing_type.
This typedef layer is GNAT's way to specify that the element is, at the
source level, an access to the unconstrained array, rather than the
unconstrained array.
Moreover, the value_enclosing_type is not really needed in that case and
the value_type can be used instead in this function, and this patch fixes
this.
gdb/ChangeLog:
* ada-valprint.c (ada_value_print): Use type instead of
enclosing type.
testsuite/ChangeLog:
* gdb.ada/access_to_unbounded_array.exp: New testcase.
* gdb.ada/access_to_unbounded_array/foo.adb: New file.
* gdb.ada/access_to_unbounded_array/pack.adb: New file.
* gdb.ada/access_to_unbounded_array/pack.ads: New file.
(Ada/MI) Fix -var-evaluate-expression for access to unconstrained arrays
Using this Ada code:
type String_Access is access String;
type Array_Of_String is array (1 .. 2) of String_Access;
Aos : Array_Of_String := (new String'("ab"), new String'("cd"));
In GDB/MI mode, create a variable which type is Aos, evaluate it:
(gdb) -var-create var1 * Aos
^done,name="var1",numchild="2",value="[2]",type="bar.array_of_string",thread-id="1",has_more="0"
* ada-lang.c (ada_value_subscript): Handle case when parameter is
an array of access to unconstrained array.
testsuite/ChangeLog
* gdb.ada/mi_string_access.exp: New testcase.
* gdb.ada/mi_string_access/bar.adb: New file.
* gdb.ada/mi_string_access/pck.adb: New file.
* gdb.ada/mi_string_access/pck.asd: New file.
(Ada) New function ada_is_access_to_unconstrained_array
Add a new function to check if a given type is an access to an
unconstrained array. This function contains code that is present only
once in the current sources but will be used in a future patch.
gdb/ChangeLog:
* ada-lang.c (ada_is_access_to_unconstrained_array): New function.
(ada_check_typedef): Use it.
(Ada) Fix -var-list-children MI command for union type
Using this Ada code:
type Union_Type (A : Boolean := False) is record
case A is
when True => B : Integer;
when False => C : Float;
end case;
end record;
pragma Unchecked_Union (Union_Type);
Ut : Union_Type := (A => True, B => 3);
In GDB/MI mode, once creating a varobj from variable "Ut" as follow:
(gdb) -var-create var1 * ut
^done,name="var1",numchild="2",value="{...}",type="foo.union_type",thread-id="1",has_more="0"
The problem occurs because ada_varobj_describe_struct_child wasn't
handling unions. This patch fixes this.
gdb/ChangeLog:
* ada-varobj.c (ada_varobj_describe_struct_child)
(ada_varobj_describe_child): Handle union case like struct one.
testsuite/ChangeLog
* gdb.ada/mi_var_union.exp: New testcase.
* gdb.ada/mi_var_union/bar.adb: New file.
* gdb.ada/mi_var_union/pck.adb: New file.
* gdb.ada/mi_var_union/pck.asd: New file.
Tom Tromey [Sat, 8 Sep 2018 20:00:48 +0000 (14:00 -0600)]
Remove periods from Python section titles
This removes the remaining trailing periods from the Python section
titles. I thought these looked weird and I don't this is generally
done in the gdb documentation.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
* python.texi (Frames In Python, Blocks In Python)
(Symbols In Python, Symbol Tables In Python)
(Lazy Strings In Python): Remove periods from section titles.
Tom Tromey [Sat, 8 Sep 2018 19:37:26 +0000 (13:37 -0600)]
Mention Python versions in the documentation
This updates python.texi to note that gdb can be compiled against
either major version of Python. It also removes the "execfile"
example, because that is specific to Python 2.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
Tom Tromey [Sat, 8 Sep 2018 19:25:34 +0000 (13:25 -0600)]
Update Python unwinder documentation
PR python/19808 points out a few issues in the Python unwinder
documentation. This patch update the documentation for
create_unwind_info and read_register to address the issues noted, and
adds a cautionary note about writing an unwinder.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
PR python/19808:
* python.texi (Unwinding Frames in Python): Rewrite
create_unwind_info documentation. Update read_register
documentation and add a note about unwinder caution.
Tom Tromey [Sat, 8 Sep 2018 16:16:46 +0000 (10:16 -0600)]
Update Python frame filter documentation
This fixes a few frame filter documentation omissions noted in
PR python/17752.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
PR python/17752:
* python.texi (Frame Filter API): Remove period from subsection
title. Mention 100 as good default priority.
(Frame Decorator API): Remove period from subsection title.
Mention FrameDecorator module.
Tom Tromey [Sat, 8 Sep 2018 15:39:41 +0000 (09:39 -0600)]
Reword gdb.GdbError text
PR python/23108 points out that the gdb.GdbError documentation is
somewhat difficult to find. The exception is apparently just
mentioned in passing. This patch introduces a new table and adds a
bit more text to try to make it more obvious.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
PR python/23108:
* python.texi (Exception Handling): Rearrange gdb.GdbError text
and add a table.
Tom Tromey [Sat, 8 Sep 2018 15:29:18 +0000 (09:29 -0600)]
Avoid warnings from makeinfo
"make info" gives a number of warnings about the use of a "." in
@ref-like commands. These come from the ".info" suffix. I think this
suffix is redundant, and removing the suffix also removes the warning.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Compilation): Use "gcc", not "gcc.info", in @xref.
(Machine Code): Use "binutils", not "binutils.info", in @pxref.
(Separate Debug Files): Use "ld", not "ld.info", in @ref.
* python.texi (Objfiles In Python): Use "ld", not "ld.info", in @ref.
Tom Tromey [Sat, 8 Sep 2018 15:13:37 +0000 (09:13 -0600)]
Fix help text for "python" command
PR python/18380 points out that the example in the "help python" text
will only work in Python 2. This changes the example to be valid
syntax for both Python 2 and Python 3.
gdb/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
PR python/18380:
* python/python.c (_initialize_python): Make example in "python"
help work in Python 3.
Eli Zaretskii [Mon, 10 Sep 2018 07:14:04 +0000 (10:14 +0300)]
Fix "make install-strip" failure to install gdb-add-index.sh
gdb/ChangeLog:
2018-09-10 Eli Zaretskii <eliz@gnu.org>
* Makefile.in (transformed_name): Use INSTALL_SCRIPT instead of
INSTALL_PROGRAM to install gdb-add-index.sh. Don't append
$(EXEEXT) to the script, as it is not a program.
Alan Modra [Mon, 10 Sep 2018 02:27:08 +0000 (11:57 +0930)]
PR23611, objcopy is not removing executable relocatable sections
BFD handles ELF relocation sections in an executable differently to
relocation sections in a relocatable object. For a relocatable
object, BFD carries the relocations as data associated with the
section to which they apply; The relocation section doesn't appear as
a separate section. For an executable, dynamic relocation sections do
appear as separate sections. This means that objcopy needs to use
different strategies when dealing with relocations.
When --remove-relocations was added to objcopy with commit d3e5f6c8f1e, objcopy lost the ability to remove dynamic relocation
sections such as .rela.plt from executables using the option
"--remove-section=.rela.plt". This patch reinstates that
functionality.
I thought it best to keep --remove-relocations as is, rather than
extending to handle dynamic relocations as per the patch in the PR,
because executables linked with --emit-relocs may have both dynamic
and non-dynamic relocations. In that case --remove-relocataions=* is
useful to remove all the non-dynamic relocations.
PR binutils/23611
* objcopy.c (handle_remove_section_option): Consider .rela and
.rel sections for stripping directly as well as attached to the
associated section they relocate.
* doc/binutils.texi (remove-relocations): Specify that this
option removes non-dynamic relocation sections.
* testsuite/binutils-all/objcopy.exp
(objcopy_remove_relocations_from_executable): New test.
Simon Marchi [Sun, 9 Sep 2018 07:13:17 +0000 (08:13 +0100)]
python: Make two functions return gdbpy_ref<>
I noticed that we release a gdbpy_ref in pretty_print_one_value only to
create it again later. This patch fills the gap by returning a
gdbpy_ref all the way.
Tom Tromey [Sat, 8 Sep 2018 20:40:38 +0000 (14:40 -0600)]
Allow a pretty-printer without a to_string method
PR python/16047 points out that, while the documentation says that the
to_string method is optional for a pretty-printer, the code disagrees
and throws an exception. This patch fixes the problem. varobj is
already ok here.
Tested on x86-64 Fedora 26.
gdb/ChangeLog
2018-09-08 Tom Tromey <tom@tromey.com>
PR python/16047:
* python/py-prettyprint.c (pretty_print_one_value): Check for
to_string method.
gdb/testsuite/ChangeLog
2018-09-08 Tom Tromey <tom@tromey.com>
PR python/16047:
* gdb.python/py-prettyprint.py (pp_int_typedef3): New class.
(register_pretty_printers): Register new printer.
* gdb.python/py-prettyprint.exp (run_lang_tests): Add int_type3
test.
* gdb.python/py-prettyprint.c (int_type3): New typedef.
(an_int_type3): New global.
Joel Brobecker [Sat, 8 Sep 2018 21:51:36 +0000 (16:51 -0500)]
(Ada) fix handling of expression with parameterless function call
Consider the following function, which takes no parameter and returns
an integer:
function Something return Integer;
For the purpose of this discussion, our function has been implemented
to always return 124:
function Something return Integer is
begin
return 124;
end Something;
In Ada, such function can been called without using the parentheses.
For instance, in the statement below, variable My_Value is assigned
the returned value from the call to Something:
My_Value := Something;
The Ada expression interpeter in GDB supports this case, as we can
see below:
(gdb) print something
$1 = 124
However, we get fairly strange results when trying to use this feature
as part of a larger expression. For instance:
(gdb) print something + 1
$2 = 248
The problem occurs while doing the resolution pass of the expression.
After prefixying the expression, we obtain the following expression:
0 BINOP_ADD
1 OP_VAR_VALUE Block @0x2021550, symbol @0x20213a0 (pck.something)
5 OP_LONG Type @0x1e3c170 (int), value 1 (0x1)
The resolution pass is then expected to remove the OP_VAR_VALUE
entry, and replace it with an OP_FUNCALL. This is what the call
to replace_operator_with_call in ada-lang.c::resolve_subexp is
expected to do:
The problem is that we're passing OPLEN (zero -- 4th parameter in
the call), and so replace_operator_with_call ends up removing zero
element from our expression, and inserting the corresponding OP_FUNCALL
instead. As a result, instead of having the OP_LONG (1) as the second
argument of the BINOP_ADD, it is now the OP_VAR_VALUE that we were
meant to replace. That OP_VAR_VALUE then itself gets transformed into
an OP_FUNCALL, with the same issue, and eventually, the resolved
expression now looks like this:
0 BINOP_ADD
1 OP_FUNCALL Number of args: 0
4 OP_VAR_VALUE Block @0x2021550, symbol @0x20213a0 (pck.something)
8 OP_FUNCALL Number of args: 0
11 OP_VAR_VALUE Block @0x2021550, symbol @0x20213a0 (pck.something)
15 OP_VAR_VALUE Block @0x2021550, symbol @0x20213a0 (pck.something)
19 OP_LONG Type @0x1e3c170 (int), value 1 (0x1)
This explains why we get twice the result of the function call
instead of its value plus one. The extra entries in the expression
at the end are just ignored.
This patch fixes the issue by calling replace_operator_with_call
with the correct OPLEN equal to the size of an OP_VAR_VALUE (4).
gdb/ChangeLog:
* ada-lang.c (resolve_subexp): Pass correct OPLEN in call to
replace_operator_with_call.
Joel Brobecker [Sat, 8 Sep 2018 21:49:10 +0000 (16:49 -0500)]
(Ada) slightly incorrect bounds for type of array indexed by enum
Consider the following code:
type Enumerated is (Enum_A, Enum_B, Enum_C, Enum_Last);
type Table is array (Enumerated) of Integer;
-- Declare a variable of type Table to make sure the compiler
-- does emit the debugging information for that type.
V : Table := (others => 1);
Trying to print the type description of type Table, or of variable V
yields:
(gdb) ptype v
type = array (0 .. 3) of integer
(gdb) ptype example.table
type = array (0 .. 3) of integer
The compiler generates an XA type for the bounds...
Normally, for arrays, we expect a range type, rather than an enumerated
type. However, for a situation like this, where the range of the array
index is the full enumeration type, it seems like a waste to require
an extra range layer.
Instead, looking at print_range, we see that we print the bounds
of our range using the target type:
In this case, this causes us to use the enumerated type's subtype,
which is a plain integer type, hence the output we get. However,
there is no reason for using the target type, even in the TYPE_CODE_RANGE
situation. So this patch fixes the issue by simply printing the bounds
using the type being given, instead of its target type.
gdb/ChangeLog:
* ada-typeprint.c (print_range): Print the bounds using TYPE
rather than its TYPE_TARGET_TYPE.
A new test for this isn't necessary, as existing tests will demonstrate
this issue once a change in the compiler triggering the generation of
this type of debugging info gets pushed.
Joel Brobecker [Sat, 8 Sep 2018 21:48:04 +0000 (16:48 -0500)]
minor reformatting in ada-lang.c::ada_to_fixed_value
The arguments in the call to ada_to_fixed_value_create where
improperly aligned. But I also noticed that all the arguments
do fit on a single-line (up to 79 characters). So this patch
just fixes the code by putting everything on that same line.
gdb/ChangeLog:
* ada-lang.c (ada_to_fixed_value): Minor reformatting in
call to ada_to_fixed_value_create.
On PPC64, the entry point of the function "FN" is ".FN" when a function
descriptor is used. One of the consequences of this is that GDB then
presents the name of the function to the user (eg: in backtraces) with
the leading dot, which is a low-level internal detail that the user
should not be seeing. The Ada decoding should strip it.
gdb/ChangeLog:
* ada-lang.c (ada_decode): strip dot prefix in symbol name.
No testcase added, as a number of existing testcases should already
demonstrate that problem.
Joel Brobecker [Sat, 8 Sep 2018 21:46:08 +0000 (16:46 -0500)]
(Ada) "catch assert" spurious internal error
We noticed while debugging a program compiled without assertions
enabled and using an older compiler that inserting a catchpoint
on failed assertions would cause an internal error:
(gdb) catch assert
../../src/gdb/ada-lang.c:13321: internal-error: ada_exception_sal:
Assertion`sym != NULL' failed.
A problem internal to GDB has been detected,
This is due to a combination of factors:
1. With older versions of the compiler, the function used as a hook
was provided by a unit that's different from the unit which
provides the hooks for the other exception catchpoints.
2. The program either does not use any assertion, or is compiled
without the assertions enabled.
With newer versions of the compiler, all such functions are provided
by the same unit, so should normally always be available. However,
there can still be reasons why this is not the case. Consider, for
instance, the case of a runtime compiled with -ffunction-sections,
in which case the hook might be eliminated unless assertions are
used and enabled.
So this patch transforms the internal error into a simple error.
gdb/ChangeLog:
* ada-lang.c (ada_exception_sal): Replace gdb_assert calls
by calls to error.
No testcase added, as the existing testcase gdb.ada/catch_ex.exp
should trigger it when using an older version of GNAT as the Ada
compiler.
Joel Brobecker [Sat, 8 Sep 2018 21:45:25 +0000 (16:45 -0500)]
(Ada) infinite loop when hitting unhandled exception catchpoint
When debugging a program compiled with an older version of GNAT,
hitting a catchpoint on unhandled exceptions can caused GDB to
got into an infinite loop. This happens while trying to find
the name of the exception that was raised. For that, it searches
for a frame corresponding to a specific function we know gets
called during the exeption handling.
In our particular case, the compiler was too old, and so GDB never
found that frame, and eventually got past the "main" subprogram,
all the way to system frames, where no symbol was available.
As a result, the code addresses could not be resolved into
a function name, leading to the infinite loop because of
a misplaced update of our loop variable "fi":
while (fi != NULL)
{
char *func_name;
enum language func_lang;
if (strcmp (func_name,
data->exception_info->catch_exception_sym) == 0)
break; /* We found the frame we were looking for... */
fi = get_prev_frame (fi);
}
}
If FUNC_NAME is NULL, then FI never gets updated ever after!
gdb/ChangeLog:
* ada-lang.c (ada_unhandled_exception_name_addr_from_raise):
Move update of loop variable "fi".
No testcase added, as the existing testcase gdb.ada/catch_ex.exp
should trigger it when using an older version of GNAT as the Ada
compiler.
Joel Brobecker [Sat, 8 Sep 2018 21:44:36 +0000 (16:44 -0500)]
(Ada) assigning packed array aggregate with variable as component
Consider a variable "PRA" defined as a packed array of packed
records as follow:
subtype Int is Integer range 0 .. 7;
type Packed_Rec is record
X, Y : Int;
W : Integer;
end record;
pragma Pack (Packed_Rec);
type Packed_RecArr is array (Integer range <>) of Packed_Rec;
pragma Pack (Packed_RecArr);
PRA : Packed_RecArr (1 .. 3);
Consider also a variable "PR", which is a Packed_Rec record,
declared as follow:
PR : Packed_Rec := (2, 2, 2);
Trying to assign a new value to PRA using an aggregate expression
where one of the components is our variable PR yields the wrong
result on big-endian machines (e.g. on ppc-linux):
(gdb) p pra := (pr, (2,2,2), (2,2,2))
$6 = ((x => 1, y => 0, w => 8), [...]
On the other hand, replacing "pr" by "(2,2,2)" does work.
I tracked the issue down to the bit offset we use to extract
the value of "PR" and copy it inside PRA. in value_assign_to_component,
we have:
if (gdbarch_bits_big_endian (get_type_arch (value_type (container))))
move_bits ([target buffer], [bit offset in target buffer],
[source buffer where PR is stored],
TYPE_LENGTH (value_type (component)) * TARGET_CHAR_BIT - bits,
bits, 1);
The issue is with the third-to-last argument, which provides the bit
offset where the value of PR is stored relative to its start address,
and therefore the bit offset relative to the start of the source
buffer passed as the previous argument.
In our case, component is a 38bit packed record whose TYPE_LENGTH
is 5 bytes, so the bit-offset that gets calculated is 2 (bits).
However, that formula only really applies to scalars, whereas
in our case, we have a record (struct). The offset in the non-scalar
case should be zero.
gdb/ChangeLog:
* ada-lang.c (value_assign_to_component): In the case of
big-endian targets, extract the bits of the given VAL
using an src_offset of zero if container is not a scalar.
Simon Ser [Thu, 6 Sep 2018 22:03:19 +0000 (15:03 -0700)]
Generate NT_PROCSTAT_{AUXV,VMMAP,PS_STRINGS} in FreeBSD coredumps
gcore generates NT_AUXV and NT_FILE notes for Linux targets. On
FreeBSD auxv is stored in a NT_PROCSTAT_AUXV section, virtual memory
mappings are stored in a NT_PROCSTAT_VMMAP, and both are prefixed with
the struct size. In addition, store a NT_PROCSTAT_PS_STRINGS note
saving the initial location of the argv[] and environment[] arrays.
gdb/ChangeLog:
PR gdb/23105
* fbsd-nat.c (fbsd_nat_target::xfer_partial): Add support for
TARGET_OBJECT_FREEBSD_VMMAP and TARGET_OBJECT_FREEBSD_PS_STRINGS.
* fbsd-tdep.c (fbsd_make_note_desc): New.
(fbsd_make_corefile_notes): Write NT_PROCSTAT_AUXV,
NT_PROCSTAT_VMMAP and NT_PROCSTAT_PS_STRINGS notes.
* target.h (enum target_object) Add FreeBSD-specific
TARGET_OBJECT_FREEBSD_VMMAP and TARGET_OBJECT_FREEBSD_PS_STRINGS.
we prefer to avoid non-const references. This patch changes the
non-const references I could find in the compile/ directory, either by
making them rvalue-reference (&&) or changing them to pointers.
I'd say all the changes are pretty obvious, except the one in
compile_cplus_instance::enter_scope which might require more attention.
Tom Tromey [Wed, 5 Sep 2018 19:46:47 +0000 (13:46 -0600)]
Make -Wformat-nonliteral work with gcc
After looking into why the build failed for Simon but not for me, we
found that the underlying cause was due to how gcc treats
-Wformat-nonliteral. gcc requires -Wformat to be given first; but
warning.m4 was not doing this, so -Wformat-nonliteral was not being
used.
This patch changes warning.m4 to account gcc's requirement.
This then showed that the target-float.c build change in the earlier
Makefile patch was also incorrect. Simon didn't see this in his
build, but gcc now points it out. So, this patch fixes this problem
as well.
2018-09-05 Tom Tromey <tom@tromey.com>
* warning.m4 (AM_GDB_WARNINGS): Add -Wformat when testing
-Wformat-nonliteral.
* target-float.c (host_float_ops<T>::to_string)
(host_float_ops<T>::from_string): Use
DIAGNOSTIC_IGNORE_FORMAT_NONLITERAL.
* configure: Rebuild.
gdb/gdbserver/ChangeLog
2018-09-05 Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 6 Sep 2018 03:21:51 +0000 (21:21 -0600)]
Disable -Wformat-nonliteral in parts of printcmd.c
commit 3322c5d9a1 ("Remove unneeded explicit .o targets") broke the
build with clang, because -Wno-format-nonliteral was in fact needed.
This patch fixes the problem by introducing
DIAGNOSTIC_IGNORE_FORMAT_NONLITERAL and using it in printcmd.c. This
seems preferable to reverting the patch because now the warning
suppression is more targeted.
gdb/ChangeLog
2018-09-05 Simon Marchi <simon.marchi@ericsson.com>
* printcmd.c (printf_c_string): Use
DIAGNOSTIC_IGNORE_FORMAT_NONLITERAL.
(printf_wide_c_string, printf_pointer, ui_printf): Likewise.
include/ChangeLog
2018-09-05 Simon Marchi <simon.marchi@ericsson.com>
* diagnostics.h (DIAGNOSTIC_IGNORE_FORMAT_NONLITERAL): New macro.
projects / thirdparty / binutils-gdb.git / log
