class Plugin_manager has
// A pointer to the current plugin. Used while loading plugins.
Plugin_list::iterator current_;
The same iterator is shared by all threads. It is OK to use it to load
plugins since only one thread loads plugins. Avoid sharing Plugin_list
iterator in all other cases.
PR gold/26200
* plugin.cc (Plugin_manager::claim_file): Don't share Plugin_list
iterator.
(Plugin_manager::all_symbols_read): Likewise.
(Plugin_manager::cleanup): Likewise.
In commit:
commit 6d81691950
CommitDate: Sat Sep 19 09:44:58 2020 +0100
gdb/fortran: Move Fortran expression handling into f-lang.c
A bug was introduced that broke GDB's ability to perform debug dumps
of expressions containing function calls. For example this would no
longer work:
(gdb) set debug expression 1
(gdb) print call_me (&val)
Dump of expression @ 0x4eced60, before conversion to prefix form:
Language c, 12 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 OP_M2_STRING 79862864 P...............
2 unknown opcode: 224 79862240 ................
3 OP_VAR_VALUE 40 (...............
4 OP_VAR_VALUE 40 (...............
5 OP_RUST_ARRAY 79861600 `...............
6 UNOP_PREDECREMENT 79861312 @...............
7 OP_VAR_VALUE 40 (...............
8 UNOP_ADDR 61 =...............
9 OP_FUNCALL 46 ................
10 BINOP_ADD 1 ................
11 OP_FUNCALL 46 ................
Dump of expression @ 0x4eced60, after conversion to prefix form:
Expression: `call_me (&main::val, VAL(Aborted (core dumped)
The situation was even worse for Fortran function calls, or array
indexes, which both make use of the same expression opcode.
The problem was that in a couple of places the index into the
expression array was handled incorrectly causing GDB to interpret
elements incorrectly. These issues are fixed in this commit.
There are already some tests to check GDB when 'set debug expression
1' is set, these can be found in gdb.*/debug-expr.exp. Unfortunately
the cases above were not covered.
In this commit I have cleaned up all of the debug-expr.exp files a
little, there was a helper function that had clearly been copied into
each file, this is now moved into lib/gdb.exp.
I've added a gdb.fortran/debug-expr.exp test file, and extended
gdb.base/debug-expr.exp to cover the function call case.
gdb/ChangeLog:
* expprint.c (print_subexp_funcall): Increment expression position
after reading argument count.
* f-lang.c (print_subexp_f): Skip over opcode before calling
common function.
(dump_subexp_body_f): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/debug-expr.c: Add extra function to allow for an
additional test.
* gdb.base/debug-expr.exp (test_debug_expr): Delete, replace calls
to this proc with gdb_test_debug_expr. Add an extra test.
* gdb.cp/debug-expr.exp (test_debug_expr): Delete, replace calls
to this proc with gdb_test_debug_expr, give the tests names
* gdb.dlang/debug-expr.exp (test_debug_expr): Delete, replace
calls to this proc with gdb_test_debug_expr, give the tests names
* gdb.fortran/debug-expr.exp: New file.
* gdb.fortran/debug-expr.f90: New file.
* lib/gdb.exp (gdb_test_debug_expr): New proc.
When creating a .debug_ranges section using the testsuite's DWARF
assembler, it currently looks like this:
ranges {
sequence {
{base ...}
{range ...}
{range ...}
}
}
The sub-tree of sequence is manually traversed as a list of lists. I
think it would be nicer if `base` and `range` where procedure, just like
the other levels:
ranges {
sequence {
base ...
range ...
range ...
}
}
That makes the implementation more robust, and the usage a bit nicer
(less special characters). It also allows having comments in between
the range list entries:
ranges {
sequence {
base ...
range ...
# Hello world.
range ...
}
}
... which doesn't work with the current approach.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (ranges): Handle "base" and "range" as
proceduresu.
* gdb.dwarf/dw2-bad-elf.exp: Adjust.
* gdb.dwarf2/dw2-inline-many-frames.exp: Adjust.
* gdb.dwarf2/dw2-inline-stepping.exp: Adjust.
* gdb.dwarf2/dw2-ranges-base.exp: Adjust.
* gdb.dwarf2/dw2-ranges-func.exp: Adjust.
* gdb.dwarf2/dw2-ranges-overlap.exp: Adjust.
* gdb.dwarf2/dw2-ranges-psym.exp: Adjust.
* gdb.dwarf2/enqueued-cu-base-addr.exp: Adjust.
Change-Id: I0b2af480faff54d0fd4214e0cc8d042d9583a865
In python 3, itertools is a builtin module, so whether or not the
python you link against is a shared or a static one, importing it
works.
Change the import test to use ctypes which is a dynamic module in both
python 2 and 3.
gdb/ChangeLog:
PR python/26832
* configure: Regenerate.
* configure.ac: Check for python modules ctypes instead of
itertools.
GDB currently fails to build with (at least) Clang 10 and 11, due to:
$ make
CXX macroexp.o
../../src/gdb/macroexp.c:125:3: error: definition of implicit copy constructor for 'macro_buffer' is deprecated because it has a user-declared destructor [-Werror,-Wdeprecated-copy-dtor]
~macro_buffer ()
^
Now, we could just add the copy constructor, like we already have a
copy assignment operator. And like that assignment operator, we would
assert that only shared buffers can be copied from.
However, it is hard to see why only shared buffers need to be copied.
I mean, it must be true, otherwise macro support would be broken,
since currently GDB is relying on the default implementation of the
copy constructor, which just copies the fields, which can't work
correctly for the non-shared version. Still, it's not easy to tell
from the code that that is indeed correct, that there isn't some
corner case that would require copying a non-shared buffer.
Or to put it simply - the tangling of shared and non-shared buffers in
the same macro_buffer struct makes this structure hard to understand.
My reaction was -- try splitting the macro_buffer class into two
classes, one for non-shared buffers, and another for shared buffers.
Comments and asserts like these:
...
SRC must be a shared buffer; DEST must not be one. */
static void
scan (struct macro_buffer *dest,
struct macro_buffer *src,
struct macro_name_list *no_loop,
const macro_scope &scope)
{
gdb_assert (src->shared);
gdb_assert (! dest->shared);
... made me suspect it should be possible. Then after the split it
should be easier to reimplement either of the classes if we want.
So I decided to try splitting the struct in two distinct types, and
see where that leads. It turns out that there is really no good
reason for a single struct, no code that wants to work with either
shared or non-shared buffers. It's always shared for input being
parsed, and non-shared for output.
This commit is the result. I named the new classes
shared_macro_buffer and growable_macro_buffer.
A future direction could be for example to make shared_macro_buffer
wrap a string_view and growable_macro_buffer a std::string. With that
in mind, other than text/len, only the 'last_token' field is common to
both classes. I didn't feel like creating a base class just for that
single field.
I constified shared_macro_buffer's 'text' field, which of course had
some knock-on effects, fixed in the patch.
On the original warning issued by Clang -- now it is clear that only
the shared version needs to be copied. Since this class doesn't need
a user-declared destructor, the default implementations of the copy
assign/ctor can be used, and Clang no longer warns.
The growable version doesn't need to be copied, so I disabled
copy/assign for it.
gdb/ChangeLog:
* macroexp.c (struct macro_buffer): Split in two classes. Add
uses adjusted.
(struct shared_macro_buffer): New, factored out from struct
macro_buffer.
(struct growable_macro_buffer): New, factored out from struct
macro_buffer.
(set_token, get_comment, get_identifier, get_pp_number)
(get_character_constant, get_string_literal, get_punctuator)
(get_next_token_for_substitution): Constify parameters.
(substitute_args): Constify locals.
Change-Id: I5712e30e826d949715703b2e9172adf04e63b152
* lexsup.c (parse_args): Add more checks of the mapfile. If it is
a directory use the basename of the output file as the file
component. If the % character is present, replace it with the
full output filepath.
* testsuite/ld-scripts/map-address.exp: Add test of %
functionality.
* ld.texi: Document the new behaviour.
Update elfedit message to
$ elfedit --help
Usage: elfedit <option(s)> elffile(s)
Update the ELF header of ELF files
The options are:
--input-mach [none|i386|iamcu|l1om|k1om|x86_64]
Set input machine type
--output-mach [none|i386|iamcu|l1om|k1om|x86_64]
Set output machine type
--input-type [none|rel|exec|dyn]
Set input file type
--output-type [none|rel|exec|dyn]
Set output file type
--input-osabi [none|HPUX|NetBSD|GNU|Linux|Solaris|AIX|Irix|FreeBSD|TRU64|Modesto|OpenBSD|OpenVMS|NSK|AROS|FenixOS]
Set input OSABI
--output-osabi [none|HPUX|NetBSD|GNU|Linux|Solaris|AIX|Irix|FreeBSD|TRU64|Modesto|OpenBSD|OpenVMS|NSK|AROS|FenixOS]
Set output OSABI
--enable-x86-feature [ibt|shstk]
Enable x86 feature
--disable-x86-feature [ibt|shstk]
Disable x86 feature
-h --help Display this information
-v --version Display the version number of elfedit
Report bugs to <http://www.sourceware.org/bugzilla/>
* elfedit.c: Include "libiberty.h".
(usage): Update help message.
Extract PAC (Pointer Authentication) feature from Armv8.3-A.
Please note that PAC stays a Armv8.3-A feature but now can be
assigned to other architectures or CPUs.
In a longer series that I am working on, I needed to remove the
objfile parameter from abbrev_table::read. It seemed to me that this
was a simple and relatively harmless patch, so I'm sending it now.
gdb/ChangeLog
2020-11-05 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_cutu_die_from_dwo)
(cutu_reader::cutu_reader, cutu_reader::cutu_reader)
(build_type_psymtabs_1): Update.
* dwarf2/abbrev.h (struct abbrev_table): Remove objfile
parameter.
* dwarf2/abbrev.c (abbrev_table::read): Remove objfile parameter.
Don't read section. Add assert.
This patch:
+ updates RAS feature system registers with new RAS 1.1 regs.
+ extends RAS/RAS 1.1 support for all architecture levels of Armv8-A.
Please note that early Armv8-A architectures do not officially support RAS
extension.
Rationale of the patch:
To ease development so that user-friendly RAS system registers operands can be
used. Certain use cases require developers to enable only more generic
architecture (e.g. -march=armv8-a) during system development. Users must use
RAS extension registers bearing in mind that system they use must support it.
The RAS (Reliability, Availability, Serviceability) extension is a
system-level extension that defines a number of system registers.
RAS 1.1 (FEAT_RASv1p1) introduces five new system registers:
ERXPFGCTL_EL1, ERXPFGCDN_EL1, ERXMISC2_EL1, ERXMISC3_EL1 and
ERXPFGF_EL1.
For details see [0].
[0] https://developer.arm.com/docs/ddi0595/i/
Sometimes the Ada compiler will emit an "__XVL" name for a field. The
Ada compiler describes:
-- Second, the variable-length fields themselves are represented by
-- replacing the type by a special access type. The designated type of
-- this access type is the original variable-length type, and the fact
-- that this field has been transformed in this way is signalled by
-- encoding the field name as:
-- field___XVL
Currently gdb describes such fields as having "access" type, but this
is inaccurate. This patch changes gdb to avoid printing "access" in
this case.
gdb/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* ada-typeprint.c (ada_print_type): Handle __XVL fields.
gdb/testsuite/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* gdb.ada/funcall_ref.exp: Update.
* gdb.ada/var_rec_arr.exp: Update.
In some cases the name of an Ada type cannot be decoded by
decoded_type_name. For example, the name
"p__complex_variable_record_type__T9s" in the included test case is
rejected due to the "T". This causes ptype to display the full
contents of a record type -- when in fact the name is available and
ought to be printed.
Fixing this in decoded_type_name isn't possible because the "__T" name
is not the real name of the type -- it is just a compiler-assigned
name of convenience.
This patch fixes the problem by using the resolved type's name when
the original type's name isn't suitable.
gdb/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* ada-typeprint.c (ada_print_type): Handle __T types.
gdb/testsuite/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* gdb.ada/rec_ptype.exp: New file.
* gdb.ada/rec_ptype/main.adb: New file.
* gdb.ada/rec_ptype/p.ads: New file.
With -fgnat-encodings=minimal, Gnat will emit DW_TAG_array_type that
has a name -- and this is the only time the name is emitted for the
type. (For comparison, in C a typedef would be emitted in this
situation.)
This patch changes gdb to recognize the name of an array type. This
is limited to Ada, to avoid any potential problems if some rogue DWARF
happens to name an array type in some other language, and to avoid
loading unnecessary partial DIEs.
gdb/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (add_partial_symbol, process_die):
Handle DW_TAG_array_type.
(is_type_tag_for_partial): Add "lang" parameter.
(load_partial_dies, new_symbol): Handle DW_TAG_array_type.
gdb/testsuite/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* gdb.ada/tick_length_array_enum_idx.exp: Add ptype test.
* gdb.ada/tick_length_array_enum_idx/foo_n207_004.adb
(PT_Full): New variable.
* gdb.ada/tick_length_array_enum_idx/pck.adb
(Full_PT): New type.
Testing with -fgnat-encodings=minimal showed that the Ada code failed
to use the bit stride of an array when taking a slice. This patch
fixes the oversight.
gdb/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_value_slice_from_ptr): Use bit size.
gdb/testsuite/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* gdb.ada/array_of_variant.exp: New file.
* gdb.ada/array_of_variant/p.adb: New file.
* gdb.ada/array_of_variant/pck.ads: New file.
* gdb.ada/array_of_variant/pck.adb: New file.
A DWARF array type may specify a stride. Currently, the DWARF reader
applies this stride to every dimension of an array. However, this
seems incorrect to me -- only the innermost array ought to use the
stride, while outer arrays should compute a stride based on the size
of the inner arrays. This patch arranges to apply the stride only to
the innermost array type. This fixes a bug noticed when running some
Ada tests with -fgnat-encodings=minimal.
gdb/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (read_array_type): Only apply stride to innermost
array.
gdb/testsuite/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* gdb.ada/enum_idx_packed.exp: Add test.
* gdb.ada/enum_idx_packed/foo.adb (Multi_Access):
New variable.
* gdb.ada/enum_idx_packed/pck.ads (Short)
(Multi_Dimension, Multi_Dimension_Access): New types.
With -fgnat-encodings=minimal, the enum_idx_packed.exp test will fail.
In this test case, we have an array (with dynamic length) of arrays,
and the inner array has a bit stride. In this situation, the outer
array's bit stride must be updated to account for the entire bit
length of the inner array.
Here, again, some tests must be kfail'd when an older version of GNAT
is in use.
gdb/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* gdbtypes.c (update_static_array_size): Handle bit stride.
gdb/testsuite/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* gdb.ada/enum_idx_packed.exp: Test two forms of -fgnat-encodings.
An internal AdaCore test case showed that gdb mishandled a case of
assigning to an array element in a packed array inside a variant
record. This problem can only be seen with -fgnat-encodings=minimal,
which isn't yet widely used. This patch fixes the bug, and also
updates an existing test to check this case.
gdb/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_value_struct_elt): Resolve dynamic type.
gdb/testsuite/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* gdb.ada/set_pckd_arr_elt.exp: Also test
-fgnat-encodings=minimal. Add tests.
* gdb.ada/set_pckd_arr_elt/foo.adb (Foo): Add VA variable.
Call Update_Small a second time.
* gdb.ada/set_pckd_arr_elt/pck.adb (New_Variant): New function.
* gdb.ada/set_pckd_arr_elt/pck.ads (Buffer, Variant)
(Variant_Access): New types.
(New_Variant): Declare.
In Ada mode, gdb rejects slicing a packed array. However, with
-fgnat-encodings=minimal, gdb will instead print incorrect results.
This patch changes gdb to also reject slicing a packed array in this
mode.
FWIW I believe that this rejection is a gdb limitation. Removing it
looked complicated, though, and meanwhile my main goal for the time
being is to bring the DWARF encodings up to par with Gnat encodings.
gdb/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_is_any_packed_array_type): New function.
(ada_evaluate_subexp) <case TERNOP_SLICE>: Use it.
gdb/testsuite/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* gdb.ada/mod_from_name.exp: Test printing slice.
When -fgnat-encodings=minimal, the compiler will avoid the special
GNAT-specific "encodings" format, and instead emit ordinary DWARF as
much as possible.
When emitting DWARF for thick pointers to arrays, the compiler emits
something like:
<1><11db>: Abbrev Number: 7 (DW_TAG_array_type)
<11dc> DW_AT_name : (indirect string, offset: 0x1bb8): string
<11e0> DW_AT_data_location: 2 byte block: 97 6
(DW_OP_push_object_address; DW_OP_deref)
<11e3> DW_AT_type : <0x1173>
<11e7> DW_AT_sibling : <0x1201>
<2><11eb>: Abbrev Number: 8 (DW_TAG_subrange_type)
<11ec> DW_AT_type : <0x1206>
<11f0> DW_AT_lower_bound : 6 byte block: 97 23 8 6 94 4
(DW_OP_push_object_address; DW_OP_plus_uconst: 8; DW_OP_deref;
DW_OP_deref_size: 4)
<11f7> DW_AT_upper_bound : 8 byte block: 97 23 8 6 23 4 94 4
(DW_OP_push_object_address; DW_OP_plus_uconst: 8; DW_OP_deref;
DW_OP_plus_uconst: 4; DW_OP_deref_size: 4)
If you read between the lines, the "array" is actually a structure
with two elements. One element is a pointer to the array data, and
the other structure describes the bounds of the array. However, the
compiler doesn't emit this explicitly, but instead hides it behind
these location expressions.
gdb can print such objects, but currently there is no way to construct
one. So, this patch adds some code to the DWARF reader to recognize
this construct, and then synthesize an array descriptor. This
descriptor is then handled by the existing Ada code.
Internally, we've modified GCC to emit the structure type explicitly
(we will of course be sending this upstream). In this case, the array
still has the DW_AT_data_location, though. This patch also modifies
gdb to ignore the data location in this case -- this is preferred
because the location only serves to confuse the Ada code that already
knows where to find the data. In the future I hope to move some of
this handling to the gdb core, so that Ada-specific hacks are not
needed; however I have not yet done this.
Because parallel types are not emitted with -fgnat-encodings=minimal,
some changes to the Ada code were also required.
The change ina ada-valprint.c was needed to avoid infinite recursion
when trying to print a constrained packed array. And, there didn't
seem to be any need for a recursive call here -- the value could
simply be returned instead.
Finally, gdb.ada/frame_arg_lang.exp no longer works in C mode, because
we drop back to the structure approach now. As mentioned earlier,
future work should probably fix this again; meanwhile, this doesn't
seem to be a big problem, because it is what is currently done (users
as a rule don't use -fgnat-encodings=minimal -- which is what I am
ultimately trying to fix).
Note that a couple of tests have an added KFAIL. Some
-fgnat-encodings=minimal changes have landed in GNAT, and you need
something very recent to pass all the tests. I'm using git gcc to
accomplish this.
gdb/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (recognize_bound_expression)
(quirk_ada_thick_pointer): New functions.
(read_array_type): Call quirk_ada_thick_pointer.
(set_die_type): Add "skip_data_location" parameter.
(quirk_ada_thick_pointer): New function.
(process_structure_scope): Call quirk_ada_thick_pointer.
* ada-lang.c (ada_is_unconstrained_packed_array_type)
(decode_packed_array_bitsize): Handle thick pointers without
parallel types.
(ada_is_gnat_encoded_packed_array_type): Rename from
ada_is_packed_array_type.
(ada_is_constrained_packed_array_type): Update.
* ada-valprint.c (ada_val_print_gnat_array): Remove.
(ada_value_print_1): Use ada_get_decoded_value.
gdb/testsuite/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* gdb.ada/O2_float_param.exp: Test different -fgnat-encodings
values.
* gdb.ada/access_to_unbounded_array.exp: Test different
-fgnat-encodings values.
* gdb.ada/big_packed_array.exp: Test different -fgnat-encodings
values.
* gdb.ada/arr_enum_idx_w_gap.exp: Test different -fgnat-encodings
values.
* gdb.ada/array_ptr_renaming.exp: Test different -fgnat-encodings
values.
* gdb.ada/array_of_variable_length.exp: Test different
-fgnat-encodings values.
* gdb.ada/arrayparam.exp: Test different -fgnat-encodings values.
* gdb.ada/arrayptr.exp: Test different -fgnat-encodings values.
* gdb.ada/frame_arg_lang.exp: Revert -fgnat-encodings=minimal
change.
* gdb.ada/mi_string_access.exp: Test different -fgnat-encodings
values.
* gdb.ada/mod_from_name.exp: Test different -fgnat-encodings values.
* gdb.ada/out_of_line_in_inlined.exp: Test different
-fgnat-encodings values.
* gdb.ada/packed_array.exp: Test different -fgnat-encodings
values.
* gdb.ada/pckd_arr_ren.exp: Test different -fgnat-encodings
values.
* gdb.ada/unc_arr_ptr_in_var_rec.exp: Test different
-fgnat-encodings values.
* gdb.ada/variant_record_packed_array.exp: Test different
-fgnat-encodings values.
Printing a multi-dimensional constrained packed array in Ada would not
show the correct values. The bug here is that, when decoding the type
of such an array, only the innermost dimension's element bitsize would
be correct. For outer dimensions, the bitsize must account for the
size of each sub-array, but this was not done.
This patch fixes the problem by arranging to compute these sizes after
decoding the array type. I've included a bit more test case than is
strictly necessary -- the current test here was derived from an
internal test, and this patch brings the two into sync.
gdb/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* ada-lang.c (recursively_update_array_bitsize): New function.
(decode_constrained_packed_array_type): Call it.
gdb/testsuite/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* gdb.ada/enum_idx_packed.exp: Add tests.
* gdb.ada/enum_idx_packed/foo.adb: Add variables.
* gdb.ada/enum_idx_packed/pck.adb: Add functions.
* gdb.ada/enum_idx_packed/pck.ads: Add types, function
declarations.
When debugging Ada programs compiled by certain versions of GNAT with
-fgnat-encodings=minimal, gdb can crash. These crashes occur when
running the gdb test suite, once some of the later patches in this
series have been applied.
This patch works around the bug by throwing an exception in the
failing case. I did not implement a full fix because GNAT has been
changed to emit better DWARF, and so in the near future this will stop
being a problem. (Currently, users don't generally use
-fgnat-encodings=minimal, and the GNAT default will only be changed in
a fully-patched compiler.)
gdb/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* ada-lang.c (to_fixed_array_type): Error if
decode_constrained_packed_array_type returns NULL.
read_3_bytes assumes little-endian data, but in fact it depends on the
BFD. This patch rewrites this function to use bfd_get_24 instead.
2020-11-04 Tom Tromey <tromey@adacore.com>
* dwarf2/leb.h (read_3_bytes): Use bfd_get_24.
The abbreviations table for a single compilation unit has two types of
terminators:
- a ".byte 0" pair denoting the end of an attribute list
- a single ".byte 0" denoting the end of the table
However, at the end of the .debug_abbrev section in dw2-line-number-zero-dw.S,
we have four ".byte 0" entries:
...
.uleb128 0x12 /* DW_AT_high_pc */
.uleb128 0x01 /* DW_FORM_addr */
.byte 0x0 /* Terminator */
.byte 0x0 /* Terminator */
.byte 0x0 /* Terminator */
.byte 0x0 /* Terminator */
...
The first two are the attribute list terminator, the third is the end-of-table
terminator, and the last is superfluous/incorrect.
Fix this by emitting instead:
...
.uleb128 0x12 /* DW_AT_high_pc */
.uleb128 0x01 /* DW_FORM_addr */
.byte 0x0 /* DW_AT - Terminator */
.byte 0x0 /* DW_FORM - Terminator */
.byte 0x0 /* Abbrev end - Terminator */
...
where the last comment resembles the comment for other abbreviation codes:
...
.section .debug_abbrev
.Labbrev1_begin:
.uleb128 2 /* Abbrev start */
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-11-03 Tom de Vries <tdevries@suse.de>
* lib/dwarf.exp (Dwarf::_handle_DW_TAG): Improve attribute list
terminator comments.
(Dwarf::cu, Dwarf::tu): Remove superfluous abbreviation table
terminator.
* ar.c (long_options): Add --record-libdeps.
(usage): Mention the new option.
(decode_options): Handle the new option.
(replace_members): If necessary, create a bfd to hold the libdeps
description.
* binemul.c (ar_emul_append_bfd): New function.
(ar_emul_replace_bfd): New function.
(ar_emul_default_append): Replace file_name and target arguments
with new_bfd argument.
(ar_emul_default_replace): Likewise.
* binemul.h: Update prototypes.
(struct bin_emulation_xfer_struct): Update fields.
* doc/binutils.texi: Document the new option.
* NEWS: Mention the new feature.
* emul_aix.c (ar_emul_aix_append): Update.
(ar_emul_aix_replace): Likewise.
* testsuite/binutils-all/ar.exp: Add test of new feature.
Armv8.7 architecture introduces the "accelerator extension", aka
load/store of 64 bytes. New atomic load/store instructions are: LD64B,
ST64B, ST64BV and ST64BV0.
This patch adds:
+ New feature +ls64 to -march command line.
+ New atomic load/store instructions associated with above feature.
For more details regarding atomic 64-byte load/store instruction for
Armv8.7 please refer to Arm A64 Instruction set documentation for
Armv8-A architecture profile, see document page 157 for load
instruction, and pages 414-418 for store instructions of [0].
[0]: https://developer.arm.com/docs/ddi0596/i
Symbol value is in bytes while fragS::fr_address is in octets. Fixes GAS
symver12 and symver13 tests on ELF targets with with OCTETS_PER_BYTE>1.
* config/obj-elf (elf_frob_symbol): Fix symbol value calculation
for versioned symbol aliases.
Signed-off-by: Christian Eggers <ceggers@gmx.de>
Since upgrading to binutils 2.35 I've been experiencing random memory
corruption related crashes with ld.gold --threads. It's caused by
multiple threads concurrently pushing elements onto the shared
std::vector in File_read::record_file_read(). This vector is supposed to
be protected by file_counts_lock, but that is initialized lazily and
might be NULL when File_read::open() is called, in which case
Hold_optional_lock silently skips locking it.
Fix by calling the initialize() method before attempting to acquire the
lock, the same as other places that use file_counts_lock.
PR 26827
* fileread.cc (File_read::open): Ensure file_counts_lock is
initialized.
* testsuite/Makefile.am (check_PROGRAMS): Add a test that passes
-Wl,--threads.
* testsuite/Makefile.in: Regenerate.
This test fails on my machine:
p /x $pc^M
$2 = 0x55555555514e^M
(gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=off: get after PC
FAIL: gdb.base/step-over-no-symbols.exp: displaced=off: advanced
This is due to the check added in 5f0e2eb79e ("GDB/testsuite: Fix a
catastrophic step-over-no-symbols.exp failure"), that makes sure the PC
values are integer. As documented in the TCL doc [1], "string is
integer" returns 1 if the string is a valid 32-bit integer format. The
PC values are greater than 32 bits, so are not recognized as integers by
that test.
% string is integer -strict 0x55555555
1
% string is integer -strict 0x555555555
0
Replace the "string is integer" test with a regexp one, that verifies
the PC is a hex value.
[1] https://www.tcl.tk/man/tcl/TclCmd/string.htm#M21
gdb/testsuite/ChangeLog:
* gdb.base/step-over-no-symbols.exp (test_step_over): Replace
integer format test with regexp.
Change-Id: I71f8197e7b52e97b4901980544a8d1072aabd362
Support for x86_64 ravenscar was recently added to the Ada runtime.
This patch updates gdb to follow.
As this is Ada-specific, and was reviewed internally by Joel, I am
checking it in.
2020-11-02 Tom Tromey <tromey@adacore.com>
* Makefile.in (ALL_64_TARGET_OBS): Add amd64-ravenscar-thread.o.
(ALLDEPFILES): Add amd64-ravenscar-thread.c.
(HFILES_NO_SRCDIR): Add amd64-ravenscar-thread.h.
* amd64-ravenscar-thread.c: New file.
* amd64-ravenscar-thread.h: New file.
* amd64-tdep.c (amd64_init_abi): Register ravenscar ops.
* configure.tgt (amd64_tobjs): Add ravenscar objects.
Small refactor to wrap up executing the scripts and commands passed
using the -x, -ex, -ix, -iex command line flags.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* main.c (execute_cmdargs): New function.
(captured_main_1): Make use of execute_cmdargs.
This commit effectively changes the default location of the .gdbinit
file, while maintaining backward compatibility.
For non Apple hosts the .gdbinit file will now be looked for in the
following locations:
$XDG_CONFIG_HOME/gdb/gdbinit
$HOME/.config/gdb/gdbinit
$HOME/.gdbinit
On Apple hosts the search order is instead:
$HOME/Library/Preferences/gdb/gdbinit
$HOME/.gdbinit
I've performed an extensive rewrite of the documentation, moving all
information about initialization files and where to find them into a
new @node, text from other areas has been moved into this one
location, and other areas cross-reference to this new @node as much as
possible.
gdb/ChangeLog:
* NEWS: Mention changes to config file search path.
* main.c
gdb/doc/ChangeLog:
* gdb.texinfo (Mode Options): Descriptions of initialization files
has been moved to 'Initialization Files'.
(Startup): Likewise.
(Initialization Files): New node.
(gdb man): Update to mention alternative file paths.
(gdbinit man): Likewise.
This adds a new get_standard_config_dir, which returns the name of the
configuration directory. In XDG, this is ~/.config/gdb/. Future
patches will make use of this.
2020-07-05 Tom Tromey <tom@tromey.com>
* pathstuff.h (get_standard_config_dir): Declare.
* pathstuff.cc (get_standard_config_dir): New function.
I noticed that a few "#if"s could be removed from the Python code.
This patch is the result.
gdb/ChangeLog
2020-11-02 Tom Tromey <tromey@adacore.com>
* python/python.c: Consolidate two HAVE_PYTHON blocks.
(python_GdbModuleDef): Move earlier. Now static.
(do_start_initialization): Consolidate some IS_PY3K blocks.
The C++ parts of gdb.base/print-file-var.exp failed to build with
Clang because the "-x c++" option added by gdb_compile caused the
compiler to attempt to parse .so files as C++. This commit splits
the compiler and linker options into separate lists, and switches
to building via build_executable_from_specs which can accommodate
this separation.
gdb/testsuite/ChangeLog:
* gdb.base/print-file-var.exp (test): Separate compiler and
linker options, and build using build_executable_from_specs
to accommodate this.
In commits 221db974e6 and
68d654afdf, these patches:
2020-06-24 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_compile): Pass "-x c++" explicitly when
compiling C++ programs.
2020-09-25 Gary Benson <gbenson@redhat.com>
* lib/gdb.exp (gdb_compile): Pass "-x c++" earlier, and only
for .c files.
attempted to fix problems with testcases that compile .c files
using the C++ compiler. These patches cause gdb_compile to add
"-x c++" to the compiler options when using Clang. This fix does
not work for gdb.base/print-file-var.exp, however, which attempts
to compile a .c input file to an executable linked with shared
libraries: the resulting command caused the compiler to attempt
to parse the .so files as C++. This commit causes gdb_compile
to reject this combination of options.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_compile): Inhibit passing "-x c++"
for .c files compiled as C++ with Clang if any shared
libraries are specified.
Clang fails to compile a number of files with the following warning:
unknown attribute 'noclone' ignored [-Wunknown-attributes]. This
commit adds a new header, lib/noclone.h, which defines the macro
ATTRIBUTE_NOCLONE accordingly, and updates the relevant testcases
to use it.
gdb/testsuite/ChangeLog:
* lib/attributes.h: New header.
* gdb.base/backtrace.c: Include the above. Replace
__attribute__(noclone)) with ATTRIBUTE_NOCLONE.
* gdb.base/infcall-nested-structs.c: Likewise.
* gdb.base/vla-optimized-out.c: Likewise.
Consider test-case gdb.dwarf2/fission-multi-cu.exp. It produces an executable
fission-multi-cu and a dwo file fission-multi-cu.dwo.
The file fission-multi-cu.dwo contains a .debug_line.dwo section, which
according to the DWARF v5 standard is a "specialized line number table" for
type units in the .debug_info.dwo section, and contains only the directory and
filename lists.
When reading the actual .debug_line.dwo section using readelf -w, we get:
...
The Directory Table is empty.
The File Name Table is empty.
No Line Number Statements.
...
So, the section does not contain any actual information. Furthermore, no
information is required because the .debug_line.dwo section does not contain
any type units.
This is confirmed by:
- re-doing the commands listed at the start of fission-multi-cu.S, which were
used as starting point for fission-multi-cu.S, and
- compiling the fission-multi-cu{1,2}.c files with clang -flto -g -gsplit-dwarf
In both cases, no .debug_line.dwo section is generated.
Remove the .debug_line.dwo section, to make it fit how split dwarf is actually
generated by clang.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-11-02 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/fission-multi-cu.S: Remove .debug_line.dwo section.
I noticed an issue with the RISC-V prologue scanning stack unwinder.
We currently read the frame base register (either $sp or $fp) as a
signed value. This means that the frame_id's stack_addr field will be
a signed value.
In other contexts though these registers are data pointers, and so are
unsigned.
There's not many places where this mismatch actually shows though, but
I did find one place. Consider this GDB session:
(gdb) maintenance set dwarf unwinders off
(gdb) set backtrace past-main on
...
(gdb) b main
Breakpoint 1 at 0x20400344: file main.c, line 86.
(gdb) run
...
(gdb) bt
#0 main () at main.c:86
#1 0x2040005c in _start () at start.S:59
Backtrace stopped: frame did not save the PC
(gdb) info frame 1
Stack frame at 0x80000a1c:
pc = 0x2040005c in _start (start.S:59); saved pc = <not saved>
Outermost frame: frame did not save the PC
caller of frame at 0x80000a1c
source language asm.
Arglist at 0x80000a1c, args:
Locals at 0x80000a1c, Previous frame's sp is 0x80000a1c
(gdb) frame address 0x80000a1c
No frame at address 0x80000a1c.
(gdb) frame address 0xffffffff80000a1c
#1 0x2040005c in _start () at start.S:59
59 call main
Notice that the 'info frame 1' reports that the frame is at
'0x80000a1c', this is the unsigned frame base value, but when I try
to select a frame using this address I can't.
The reason is that the frame_id for frame #1 actually has the
unsigned (and hence sign-extended) stack_addr value. When I use the
sign extended address I can correctly select the frame.
I propose changing the prologue scanning unwinder to read the frame
base as unsigned. After this in the above case I can now do this:
(gdb) frame address 0x80000a1c
#1 0x2040005c in _start () at start.S:59
59 call main
(gdb) frame address 0xffffffff80000a1c
No frame at address 0xffffffff80000a1c.
Which I think makes more sense.
This issue causes failures in gdb.base/frame-selection.exp if you
compile for RV32 with a linker script that places the stack in the
correct location, which are resolved by this patch.
gdb/ChangeLog:
* riscv-tdep.c (riscv_frame_cache): Read the frame base register
as an unsigned value.
