If the cris sim hasn't been built yet, trying to run its testsuite
will hang indefinitely. The common sim APIs already have this, so
copy it over to the cris forks of the test+run functions.
The tests assume that the cwd is the objdir directory and write its
intermediates to there all the time. When using runtest's --objdir
setting though, this puts the files in the wrong place. This isn't
a big problem currently as we never change --objdir, but in order to
support parallel test execution, we're going to start setting that
option, so clean up the code ahead of time.
We also have to tweak some of the cris tests which were making
assumptions about the argv[0] value.
Now that all the other toolchain settings have been renamed to match
the dejagnu settings of XXX_FOR_TARGET, rename global_sim_options to
SIMFLAGS_FOR_TARGET too.
Only a few tests actually use global_ld_options, but we can replace the
sim-specific settings with the dejagnu common LDFLAGS_FOR_TARGET and get
the same result.
2021-11-26 John David Anglin <danglin@gcc.gnu.org>
PR ld/27442
ld/ChangeLog:
* ld/testsuite/ld-ifunc/ifunc.exp (contains_irelative_reloc): Adjust
regexp.
Skip static ifunc-using executable test on hppa*-*-*.
Update
commit 4780e5e493
Author: Tom de Vries <tdevries@suse.de>
Date: Fri Nov 26 09:59:45 2021 +0100
[gas] Fix file 0 dir with -gdwarf-5
1. Replace i with j in
for (j = 0; i < NUM_MD5_BYTES; ++j)
2. Pass -W to readelf to force CU: in output due to:
if (do_wide || strlen (directory) < 76)
printf (_("CU: %s/%s:\n"), directory, file_table[0].name);
else
printf ("%s:\n", file_table[0].name);
PR gas/28629
* dwarf2dbg.c (out_dir_and_file_list): Fix a typo in commit
4780e5e493.
* testsuite/gas/elf/dwarf-5-nop-for-line-table.d: Pass -W to
readelf.
Only a few tests actually use global_as_options, but we can replace the
sim-specific settings with the dejagnu common ASFLAGS_FOR_TARGET and get
the same result.
The test-case gdb.ada/dgopt.exp uses the -gnatD switch, in combination with
-gnatG.
This causes the source file $src/gdb/testsuite/gdb.ada/dgopt/x.adb to be
expanded into $build/gdb/testsuite/outputs/gdb.ada/dgopt/x.adb.dg, and the
debug information should refer to the x.adb.dg file.
That is the case for the .debug_line part:
...
The Directory Table is empty.
The File Name Table (offset 0x1c):
Entry Dir Time Size Name
1 0 0 0 x.adb.dg
...
but not for the .debug_info part:
...
<11> DW_AT_name : $src/gdb/testsuite/gdb.ada/dgopt/x.adb
<15> DW_AT_comp_dir : $build/gdb/testsuite/outputs/gdb.ada/dgopt
...
Filed as PR gcc/103436.
In C we can generate similar debug information, using a source file that does
not contain any code, but includes another one that does:
...
$ cat gdb/testsuite/gdb.base/include-main.c
#include "main.c"
...
such that in the .debug_line part we have:
...
The Directory Table (offset 0x1c):
1 /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base
The File Name Table (offset 0x57):
Entry Dir Time Size Name
1 1 0 0 main.c
...
and in the .debug_info part:
...
<11> DW_AT_name : $src/gdb/testsuite/gdb.base/include-main.c
<15> DW_AT_comp_dir : $build/gdb/testsuite
...
Add a C test-case that mimics gdb.ada/dgopt.exp, that is:
- generate debug info as described above,
- issue a list of a line in include-main.c, while the corresponding
CU is not expanded yet.
Tested on x86_64-linux.
Nothing in the testsuite is using this setting, so let's drop it.
Any code that wants to set compiler flags can use CFLAGS_FOR_TARGET
instead to get the same effect.
These haven't been used in over 20 years. The sim testsuite used to
run these tools itself directly, but back in ~1999 it switched to the
dejagnu helpers (e.g. target_assemble & target_link), and the dejagnu
logic only utilizes XXX_FOR_TARGET variables. Punt them here to avoid
confusion with dead code.
This commit adds support for RISC-V disassembler options to GDB. This
commit is based on this patch which was never committed:
https://sourceware.org/pipermail/binutils/2021-January/114944.html
All of the binutils refactoring has been moved to a separate, earlier,
commit, so this commit is pretty straight forward, just registering
the required gdbarch hooks.
Co-authored-by: Simon Cook <simon.cook@embecosm.com>
In preparation for the next commit, which will add GDB support for
RISC-V disassembler options, this commit restructures how the
disassembler options are managed within libopcodes.
The implementation provided here is based on this mailing list patch
which was never committed:
https://sourceware.org/pipermail/binutils/2021-January/114944.html
which in turn took inspiration from the MIPS implementation of the
same feature.
The biggest changes from the original mailing list post are:
1. The GDB changes have been split into a separate patch, and
2. The `riscv_option_args_privspec` variable, which held the valid
priv-spec values is now gone, instead we use the `riscv_priv_specs`
array from bfd/cpu-riscv.c instead.
Co-authored-by: Simon Cook <simon.cook@embecosm.com>
include/ChangeLog:
* dis-asm.h (disassembler_options_riscv): Declare.
opcodes/ChangeLog:
* riscv-dis.c (enum riscv_option_arg_t): New enum typedef.
(riscv_options): New static global.
(disassembler_options_riscv): New function.
(print_riscv_disassembler_options): Rewrite to use
disassembler_options_riscv.
In out_dir_and_file_list, if file 0 is copied from file 1, only the filename
is copied, and the dir and md5 fields are left to their default values.
Fix this by adding the copy of the dir and md5 fields.
gas/ChangeLog:
2021-11-26 Tom de Vries <tdevries@suse.de>
PR 28629
* dwarf2dbg.c (out_dir_and_file_list): When copying file 1 to file 0,
also copy dir and md5 fields.
* testsuite/gas/i386/dwarf5-line-4.d: Adjust expected output.
In this commit:
commit c6a6aad52d
Date: Mon Oct 25 17:25:45 2021 +0100
gdb/python: make some global variables static
building without Python was broken. The extension_language_python
global was moved from being always defined, to only being defined when
the HAVE_PYTHON macro was defined. As a consequence, building without
Python support would result in errors like:
/usr/bin/ld: extension.o:(.rodata+0x120): undefined reference to `extension_language_python'
This commit fixes the problem by moving the definition of
extension_language_python outside of the HAVE_PYTHON macro protection.
This commit introduced a test failure in gdb.server/attach-flag.exp.
I didn't spot this failure originally as the problem is fixed by this,
as yet unpushed patch:
https://sourceware.org/pipermail/gdb-patches/2021-November/183768.html
I unfortunately didn't test each patch in the original series
independently. I'll repost this patch after the above patch has been
merged.
This reverts commit 32b1f5e8d6.
Basic ambiguity detection assumes that when 2 fields with the same name
have the same byte offset, it must be an unambiguous request. This is not
always correct. Consider the following code:
class empty { };
class A {
public:
[[no_unique_address]] empty e;
};
class B {
public:
int e;
};
class C: public A, public B { };
if we tried to use c.e in code, the compiler would warn of an ambiguity,
however, since A::e does not demand an unique address, it gets the same
address (and thus byte offset) of the members, making A::e and B::e have the
same address. however, "print c.e" would fail to report the ambiguity,
and would instead print it as an empty class (first path found).
The new code solves this by checking for other found_fields that have
different m_struct_path.back() (final class that the member was found
in), despite having the same byte offset.
The testcase gdb.cp/ambiguous.exp was also changed to test for this
behavior.
Section alignment for coff-go32 is inconsistent - The '.text' and
'.data' sections are 16-byte aligned, but named sections '.text.*' and
'.data.*' are only 4-byte aligned. '.gnu.linkonce.r.*' is aligned to
16 bytes, yet '.rodata' and '.rodata.*' are aligned to 4 bytes. For
'.bss' all input sections are only aligned to 4 bytes.
This primarily can cause trouble when using SSE instructions, which
require their memory operands to be aligned to 16-byte boundaries.
This patch solves the issue simply by setting the section alignment
to 16 bytes, for all code and data sections referenced in the default
linker script.
* coff-go32.c (COFF_SECTION_ALIGNMENT_ENTRIES): Use partial
name match for .text, .data. Add entries for .const, .rodata,
.bss, .gnu.linkonce.b.
Commit b69c9d41e8 edited bfd/Makefile.in rather than using automake,
which meant a typo in Makefile.am was not discovered and other
differences in Makefile.in are seen with a proper regeneration. One
difference was lack of an empty line between the pe-aarch64igen.c rule
and the following $(BFD32_LIBS) etc. dependency rule, in the
regenerated file. Not that it matters for proper "make" behaviour,
but it's nicer with a line between those rules. Moving the rule
earlier seems to cure the missing empty line.
* Makefile.am (BFD64_BACKENDS): Correct typo.
(BFD_H_DEPS, LOCAL_H_DEPS): Move earlier. Move rule using these
deps earlier too.
* Makefile.in: Regenerate.
* po/BLD-POTFILES.in: Regenerate.
* po/SRC-POTFILES.in: Regenerate.
In a later commit I plan to add disassembler styling. In the same way
that we have a source_styling_changed observer I would need to add a
disassembler_styling_changed observer.
However, currently, these observers would only be notified from
cli-style.c:set_style_enabled, and observed in tui-winsource.c,
tui_source_window::style_changed, as a result, having two observers
seems unnecessary right now, so, in this commit, I plan to rename
source_styling_changed to just styling_changed, then, in the later
commit, when disassembler styling is added, I can use the same
observer for both source styling, and disassembler styling.
There should be no user visible changes after this commit.
Make a couple of global variables static in python/python.c. To do
this I had to move the definition of extension_language_python to
later in the file.
There should be no user visible changes after this commit.
While working on another patch I ended up in a situation where I had
async mode disabled (with 'maint set target-async off'), but the async
event token got marked anyway.
In this situation GDB was continually calling into
remote_target::wait, however, the async token would never become
unmarked as the unmarking is guarded by target_is_async_p.
We could just unconditionally unmark the token, but that would feel
like just ignoring a bug, so, instead, lets assert that if
!target_is_async_p, then the async token should not be marked.
This assertion would have caught my earlier mistake.
There should be no user visible changes with this commit.
This commit simplifies remote_target::is_async_p by removing the
target_async_permitted check.
In previous commits I have added additional assertions around the
target_async_permitted flag into target.c, as a result we should now
be confident that if target_can_async_p returns false, a target will
never have async mode enabled. Given this, it should not be necessary
to check target_async_permitted in remote_target::is_async_p, if this
flag is false ::is_async_p should return false anyway. There is an
assert to this effect in target_is_async_p.
There should be no user visible change after this commit.
The target_async_permitted flag allows a user to override whether a
target can act in async mode or not. In previous commits I have moved
the checking of this flag out of the various ::can_async_p methods and
into the common target.c code.
In this commit I will add some additional assertions into
target_is_async_p and target_async. The rules these assertions are
checking are:
1. A target that returns false for target_can_async_p should never
become "async enabled", and so ::is_async_p should always return
false. This is being checked in target_is_async_p.
2. GDB should never try to enable async mode for a target that
returns false for target_can_async_p, this is checked in
target_async.
There are a few places where we call the ::is_async_p method directly,
in these cases we will obviously not pass through the assert in
target_is_async_p, however, there are also plenty of places where we
do call target_is_async_p so if GDB starts to misbehave we should
catch it quickly enough.
There should be no user visible changes after this commit.
This commit moves the target_async_permitted check out of each targets
::can_async_p method and into the target_can_async_p wrapper function.
I've left some asserts in the two ::can_async_p methods that I
changed, which will hopefully catch any direct calls to these methods
that might be added in the future.
There should be no user visible changes after this commit.
There are a few places where we call the target_ops::can_async_p
member function directly, instead of using the target_can_async_p
wrapper.
In some of these places this is because we need to ask before the
target has been pushed, and in another location (in target.c) it seems
unnecessary to go through the wrapper when we are already in target.c
code.
However, in the next commit I'd like to hoist some common checks out
of target specific code into target.c. To achieve this, in this
commit, I introduce a new overload of target_can_async_p which takes a
target_ops pointer, and calls the ::can_async_p method directly. I
then make use of the new overload where appropriate.
There should be no user visible changes after this commit.
The test must be done with the shared object and not with the object
file which is already being tested above.
ld/
* testsuite/ld-elfvsb/elfvsb.exp: use .so file in "weak hidden
symbol DSO last"
Before commit 3b6acaee89 "Update more calls to add_prefix_cmd" we had the
following output for "show logging file":
...
$ gdb -q -batch -ex "set trace-commands on" \
-ex "set logging off" \
-ex "show logging file" \
-ex "set logging on" \
-ex "show logging file"
+set logging off
+show logging file
Future logs will be written to gdb.txt.
+set logging on
+show logging file
Currently logging to "gdb.txt".
...
After that commit we have instead:
...
+set logging off
+show logging file
The current logfile is "gdb.txt".
+set logging on
+show logging file
The current logfile is "gdb.txt".
...
Before the commit, whether logging is enabled or not can be deduced from the
output of the command. After the commit, the message is unified and it's no
longer clear whether logging is enabled or not.
Fix this by:
- adding a new command "show logging enabled"
- adding a corresponding new command "set logging enabled on/off"
- making the commands "set logging on/off" deprecated aliases of the
"set logging enabled on/off" command.
Update the docs and testsuite to use "set logging enabled". Mention the new
and deprecated commands in NEWS.
Tested on x86_64-linux.
Currently we have:
...
$ gdb -q -batch -ex "help set logging overwrite"
Set whether logging overwrites or appends to the log file.
If set, logging overrides the log file.
...
Fix overrides -> overwrites typo.
When implementing this command, I put "help doc" as a placeholder for
the help string, and forgot to update it. Change it for a real help
string.
Change-Id: Id23c2142c5073dc570bd8a706e9ec6fa8c40eb09
This reverts (par of) commit ab19827912.
This commit changed what the test expects when catching the execve
syscall based on the behavior seen on a Linux PowerPC machine. That is,
we get an "entry" event, but no "return" event. This is not what we get
on Linux with other architectures, though, and it seems like a
PowerPC-specific bug.
Revert the part of the patch related to this, but not the other hunk.
Change-Id: I4248776e4299f10999487be96d4acd1b33639996
In commit:
commit 633cf2548b
Date: Wed May 9 15:42:28 2018 -0600
Remove cleanups from mdebugread.c
the following change was made in the function parse_partial_symbols in
mdebugread.c:
- fdr_to_pst = XCNEWVEC (struct pst_map, hdr->ifdMax + 1);
- old_chain = make_cleanup (xfree, fdr_to_pst);
+ gdb::def_vector<struct pst_map> fdr_to_pst_holder (hdr->ifdMax + 1);
+ fdr_to_pst = fdr_to_pst_holder.data ();
The problem with this change is that XCNEWVEC calls xcalloc, which in
turn calls calloc, and calloc zero initializes the allocated memory.
In contrast, the new line gdb::def_vector<struct pst_map> specifically
does not initialize the underlying memory.
This is a problem because, later on in this same function, we
increment the n_globals field within 'struct pst_map' objects stored
in the vector. The incrementing is now being done from an
uninitialized starting point.
In this commit we switch from using gdb::def_vector to using
std::vector, this alone should be enough to ensure that the fields are
initialized to zero.
However, for extra clarity, I have also added initial values in the
'struct pst_map' to make it crystal clear how the struct will start
up.
This issue was reported on the mailing list here:
https://sourceware.org/pipermail/gdb-patches/2021-November/183693.html
Co-Authored-By: Lightning <lightningth@gmail.com>
When readline development package is missing make fails with
"configure: error: system readline is not new enough" which
might be confusing. This patch checks for the readline.h explicitly
and makes make to warn about the missing package.
This adds support for efi-*-aarch64 by virtue of adding a new PEI target
pei-aarch64-little. This is not a full target and only exists to support EFI
at this time.
This means that this target does not support relocation processing and is mostly
a container format. This format has been added to elf based aarch64 targets
such that efi images can be made natively on Linux.
However this target is not valid for use with gas but only with objcopy.
With these changes the resulting file is recognized as an efi image by
third party tools:
> pecli info hello.efi
Metadata
================================================================================
MD5: 598c32a778b0f0deebe977fef8578c4e
SHA1: 4580121edd5cb4dc40f51b28f171fd15250df84c
SHA256: 3154bd7cf42433d1c957f6bf55a17ad8c57ed41b29df2d485703349fd6ff1d5c
Imphash:
Size: 47561 bytes
Type: PE32+ executable (EFI application) (stripped to external PDB), for MS Windows
Compile Time: 1970-01-01 00:00:00 (UTC - 0x0 )
Entry point: 0x2000 (section .text)
Sections
================================================================================
Name RWX VirtSize VirtAddr RawAddr RawSize Entropy md5
.text R-X 0x5bb0 0x2000 0x400 0x5c00 6.39 551fbc264256a3f387de8a891500ae0d
.reloc R-- 0xc 0x8000 0x6000 0x200 0.02 0c45f6d812d079821c1d54c09ab89e1d
.data RW- 0x1d88 0x9000 0x6200 0x1e00 4.18 5d1137c09f01289dc62bf754f7290db3
.dynamic RW- 0xf0 0xb000 0x8000 0x200 0.34 5c94ed3206f05a277e6f04fbf131f131
.rela R-- 0xe58 0xc000 0x8200 0x1000 1.87 8b5c6bc30f3acb7ca7bf2e6789d68519
.dynsym R-- 0x138 0xd000 0x9200 0x200 0.96 bdcf5101da51aadc663ca8859f88138c
Imports
================================================================================
Any magic number is based on the Microsoft PE specification [1].
[1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
bfd/ChangeLog:
2021-10-21 Tamar Christina <tamar.christina@arm.com>
PR binutils/26206
* .gitignore (pe-aarch64igen.c): New.
* Makefile.am (pei-aarch64.lo, pe-aarch64igen.lo, pei-aarch64.c,
pe-aarch64igen.c): Add support.
* Makefile.in: Likewise.
* bfd.c (bfd_get_sign_extend_vma): Add pei-aarch64-little.
* coff-aarch64.c: New file.
* coffcode.h (coff_set_arch_mach_hook, coff_set_flags,
coff_write_object_contents) Add aarch64 (aarch64_pei_vec) support.
* config.bfd: Likewise.
* configure: Likewise.
* configure.ac: Likewise.
* libpei.h (GET_OPTHDR_IMAGE_BASE, PUT_OPTHDR_IMAGE_BASE,
GET_OPTHDR_SIZE_OF_STACK_RESERVE, PUT_OPTHDR_SIZE_OF_STACK_RESERVE,
GET_OPTHDR_SIZE_OF_STACK_COMMIT, PUT_OPTHDR_SIZE_OF_STACK_COMMIT,
GET_OPTHDR_SIZE_OF_HEAP_RESERVE, PUT_OPTHDR_SIZE_OF_HEAP_RESERVE,
GET_OPTHDR_SIZE_OF_HEAP_COMMIT, PUT_OPTHDR_SIZE_OF_HEAP_COMMIT,
GET_PDATA_ENTRY, _bfd_peAArch64_bfd_copy_private_bfd_data_common,
_bfd_peAArch64_bfd_copy_private_section_data,
_bfd_peAArch64_get_symbol_info, _bfd_peAArch64_only_swap_filehdr_out,
_bfd_peAArch64_print_private_bfd_data_common,
_bfd_peAArch64i_final_link_postscript,
_bfd_peAArch64i_only_swap_filehdr_out, _bfd_peAArch64i_swap_aouthdr_in,
_bfd_peAArch64i_swap_aouthdr_out, _bfd_peAArch64i_swap_aux_in,
_bfd_peAArch64i_swap_aux_out, _bfd_peAArch64i_swap_lineno_in,
_bfd_peAArch64i_swap_lineno_out, _bfd_peAArch64i_swap_scnhdr_out,
_bfd_peAArch64i_swap_sym_in, _bfd_peAArch64i_swap_sym_out,
_bfd_peAArch64i_swap_debugdir_in, _bfd_peAArch64i_swap_debugdir_out,
_bfd_peAArch64i_write_codeview_record,
_bfd_peAArch64i_slurp_codeview_record,
_bfd_peAArch64_print_ce_compressed_pdata): New.
* peXXigen.c (_bfd_XXi_swap_aouthdr_in, _bfd_XXi_swap_aouthdr_out,
pe_print_pdata, _bfd_XX_print_private_bfd_data_common,
_bfd_XX_bfd_copy_private_section_data, _bfd_XXi_final_link_postscript):
Support COFF_WITH_peAArch64,
* pei-aarch64.c: New file.
* peicode.h (coff_swap_scnhdr_in, pe_ILF_build_a_bfd, pe_ILF_object_p):
Support COFF_WITH_peAArch64.
(jtab): Add dummy entry that traps.
* targets.c (aarch64_pei_vec): New.
binutils/ChangeLog:
2021-10-21 Tamar Christina <tamar.christina@arm.com>
PR binutils/26206
* NEWS: Add new support.
* objcopy.c (convert_efi_target): Add efi-*-aarch64 support.
* testsuite/binutils-all/aarch64/pei-aarch64-little.d: New test.
* testsuite/binutils-all/aarch64/pei-aarch64-little.s: New test.
include/ChangeLog:
2021-10-21 Tamar Christina <tamar.christina@arm.com>
PR binutils/26206
* coff/aarch64.h: New file.
* coff/pe.h (IMAGE_FILE_MACHINE_ARM64): New.
A missing "return" resulted in this non-ELF fail:
x86_64-w64-mingw32 +FAIL: debuginfod (create separate debug info file)
Also, the debuginfod I have installed does not appear to handle
non-native ELF objects, so only run the test when native.
* testsuite/binutils-all/debuginfod.exp: Don't run test unless
native ELF.
Some time ago add_info_alias was changed (commit
e0f25bd971). These calls were not updated
and caused errors on compilation.
Change-Id: I354ae4e8b8926d785abc94ec7142471ffd76d2de
While working on target_waitstatus changes, I noticed a few places where
const target_waitstatus objects could be passed by reference instead of
by pointers. And in some cases, places where a target_waitstatus could
be passed as const, but was not. Convert them as much as possible.
Change-Id: Ied552d464be5d5b87489913b95f9720a5ad50c5a
