Carl Love [Wed, 16 Nov 2022 17:04:51 +0000 (11:04 -0600)]
Change NULL to nullptr in gdb/infcmd.c and gdb/infrun.c
The GDB coding standard specifies that nullptr should be used instead of
NULL. There are numerous uses of NULL and nullptr in files infcmd.c and
infrun.c. This patch replaces the various uses of NULL with nullptr in
the source files. The use of NULL in the comments was not changed.
The patch does not introduce any functional changes.
The patch has been tested on PowerPC and Intel X86_64 with no new unexpected
test failures, unresolved tests, new core files etc.
H.J. Lu [Wed, 16 Nov 2022 23:06:37 +0000 (15:06 -0800)]
ld: Always call elf_backend_output_arch_local_syms
Always call elf_backend_output_arch_local_syms since only the backend
knows if elf_backend_output_arch_local_syms is needed when all symbols
are striped. elf_backend_output_arch_local_syms is defined only for
x86, ARM and AARCH64. On x86, elf_backend_output_arch_local_syms must
be called to handle local IFUNC symbols even if all symbols are striped.
Update ARM and AARCH64 to skip elf_backend_output_arch_local_syms when
symbols aren't needed.
bfd/
PR ld/29797
* elf32-arm.c (elf32_arm_output_arch_local_syms): Skip if symbols
aren't needed.
* elfnn-aarch64.c (elfNN_aarch64_output_arch_local_syms):
Likewise.
* elflink.c (bfd_elf_final_link): Always call
elf_backend_output_arch_local_syms if available.
ld/
PR ld/29797
* testsuite/ld-elf/linux-x86.exp: Run PR ld/29797 test.
* testsuite/ld-elf/pr29797.c: New file.
Andrew Burgess [Wed, 2 Nov 2022 13:48:42 +0000 (13:48 +0000)]
gdb: new $_inferior_thread_count convenience variable
Add a new convenience variable $_inferior_thread_count that contains
the number of live (non-exited) threads in the current inferior. This
can be used in command scripts, or breakpoint conditions, etc to
adjust the behaviour for multi-threaded inferiors.
This value is only stable in all-stop mode. In non-stop mode, where
new threads can be started, and existing threads exit, at any time,
this convenience variable can give a different value each time it is
evaluated.
Tom Tromey [Tue, 16 Aug 2022 15:22:21 +0000 (09:22 -0600)]
Remove two obsolete declarations
I happened to find a couple of obsolete declarations in cli-interp.h.
This patch removes them. Tested by rebuilding.
Andrew Burgess [Mon, 24 Oct 2022 14:05:40 +0000 (15:05 +0100)]
gdb/testsuite: fix failure in gdb.python/py-send-packet.exp
While working on another patch I noticed that, when run on an AArch64
target, the test gdb.python/py-send-packet.exp was failing:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/tmp/build/gdb/testsuite/outputs/gdb.python/py-send-packet/py-send-packet.py",
line 106, in run_auxv_send_packet_test
assert string == expected_result
AssertionError
Error while executing Python code.
(gdb) FAIL: gdb.python/py-send-packet.exp: call python run_auxv_send_packet_test function
The test uses 'maint packet ...' to send a packet to gdbserver, and
then captures the output in TCL. This output is then passed through
to a Python function, which performs some actions using the Python
API, and compares the results from the Python API to the results
captured in TCL from 'maint packet ...'.
The problem is that the output captured in TCL contains lots of things
like '\x000', when this is passed through to Python the '\x' causes
this to be treated as an escape code, which isn't what we want - we
want the actual string "\x000".
So, in the TCL part of the test we were expanding '\x' to '\\x', this
seemed to work fine for my testing on x86-64.
However, on AArch64 what I see is that the results from 'maint packet
...' contain a literal '\' character followed by a literal 'x'
character. When GDB prints this in the 'maint packet' output, GDB
escapes the '\' for us, thus we get '\\x' printed by 'maint packet'.
However, now our TCL test script kicks in and tries to "fix" the '\x',
this means we now have '\\\x', which isn't correct.
The problem is that in the TCL script we are too restrictive, we
expand '\x' to '\\x', but really, we should be expanding all '\'
characters, regardless of what follows them. This is what this patch
does.
After this the gdb.python/py-send-packet.exp test passes on AArch64
for me.
Aditya Vidyadhar Kamath [Thu, 17 Nov 2022 12:50:35 +0000 (13:50 +0100)]
Fix call functions command bug in 64 bits programs for AIX
In AIX for 64 bit programs we need to zero extend variables
of integer or enum or char data type.
Otherwise a zero will get dumped in the register as we memset
our word to 0 and we copy non zero extended contents to the cache.
Andrew Burgess [Fri, 4 Nov 2022 14:51:11 +0000 (14:51 +0000)]
gdb/fortran/testsuite: print values and types of string variables
While looking through the Fortran tests, I couldn't find a test of GDB
printing the value and type of a Fortran string defined using the
'character*SIZE' notation.
This works fine in GDB right now, but I thought it wouldn't hurt to
have a test for this, so this commit adds such a test.
The test also includes printing a string that includes some embedded
special characters: \n \r \t \000 - that's right, as Fortran strings
are stored as an address and length, it is fine to include an embedded
null, so this test includes an example of that.
Standard Fortran doesn't support backslash escape sequences within
strings, the special characters must be generated using the `achar`
function. However, when GDB prints the strings we currently print
using the standard C like backslash sequences.
I'm not currently proposing to change that behaviour, the backslash
sequences are more compact than the standard Fortran way of doing
things, and are so widely used that I suspect most Fortran programmers
will understand them.
Rainer Orth [Thu, 17 Nov 2022 09:55:25 +0000 (10:55 +0100)]
Fix various procfs.c compilation errors
procfs.c has accumulated several compilation errors lately (some of them
new with GCC 12), which are fixed by this patch:
* auxv_parse gets:
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:144:7: error:
\91int
procfs_target::auxv_parse(gdb_byte**, gdb_byte*, CORE_ADDR*, CORE_ADDR*)
\92
marked
\91override
\92, but does not override
144 | int auxv_parse (gdb_byte **readptr,
| ^~~~~~~~~~
Obviouly, procfs.c was missed in the auxv_parse constification.
* dead_procinfo has:
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In function
\91void
dead_procinfo(procinfo*, const char*, int)
\92:
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:563:11: warning: the address
of
\91procinfo::pathname
\92 will never be NULL [-Waddress]
563 | if (pi->pathname)
| ~~~~^~~~~~~~
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:238:8: note:
\91procinfo::pathname
\92 declared here
238 | char pathname[MAX_PROC_NAME_SIZE]; /* Pathname to /proc entry */
| ^~~~~~~~
The warning is correct, so the code can lose support for the NULL
pathname case.
* create_inferior has this ugly warning:
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function
\91virtual void procfs_target::create_inferior(const char*, const std::string&, char**, int)
\92:
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:2815:19: warning:
\91char* std::strncpy(char*, const char*, size_t)
\92 output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation]
2815 | strncpy (tryname, p, len);
| ~~~~~~~~^~~~~~~~~~~~~~~~~
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:2814:26: note: length computed here
2814 | len = strlen (p);
| ~~~~~~~^~~
It seems that this is another case of GCC PR middle-end/88059, which
Martin Sebor refuses to fix. So I'm using the hack suggested in the
PR to use memcpy instead of strncpy.
* find_memory_regions_callback fails with
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In function
\91int find_memory_regions_callback(prmap*, find_memory_region_ftype, void*)
\92:
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:3167:18: error: too few arguments to function
3167 | return (*func) ((CORE_ADDR) map->pr_vaddr,
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
3168 | map->pr_size,
| ~~~~~~~~~~~~~
3169 | (map->pr_mflags & MA_READ) != 0,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3170 | (map->pr_mflags & MA_WRITE) != 0,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3171 | (map->pr_mflags & MA_EXEC) != 0,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3172 | 1, /* MODIFIED is unknown, pass it as true. */
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3173 | data);
| ~~~~~
Again, procfs.c was overlooked when adding the new memory_tagged arg.
Unfortunately, it wasn't even documented in gdb/defs.h when it was
added in
commit
68cffbbd4406b4efe1aa6e18460b1d7ca02549f1
Author: Luis Machado <luis.machado@arm.com>
Date: Thu Mar 31 11:42:35 2022 +0100
[AArch64] MTE corefile support
With those changes, procfs.c compiles again. Together with the hack
from the Solaris gdbsupport breakage reported in PR build/29791, I was
able to build and test gdb on both amd64-pc-solaris2.11 and
sparcv9-sun-solaris2.11.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Christoph Müllner [Sun, 13 Nov 2022 15:59:21 +0000 (16:59 +0100)]
RISC-V: Add T-Head Int vendor extension
This patch adds the XTheadInt extension, which provides interrupt
stack management instructions.
The XTheadFmv extension is documented in the RISC-V toolchain
contentions:
https://github.com/riscv-non-isa/riscv-toolchain-conventions
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Christoph Müllner [Sun, 13 Nov 2022 15:59:20 +0000 (16:59 +0100)]
RISC-V: Add T-Head Fmv vendor extension
This patch adds the XTheadFmv extension, which allows to access the
upper 32 bits of a double-precision floating-point register in RV32.
The XTheadFmv extension is documented in the RISC-V toolchain
contentions:
https://github.com/riscv-non-isa/riscv-toolchain-conventions
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Tom de Vries [Thu, 17 Nov 2022 08:11:47 +0000 (09:11 +0100)]
[gdb/testsuite] Fix DUPLICATE in gdb.arch/ppc-fp.exp
I noticed:
...
DUPLICATE: gdb.arch/ppc-fp.exp: next
...
Fix this by adding unique test names.
Tested on powerpc64le-linux.
GDB Administrator [Thu, 17 Nov 2022 00:00:37 +0000 (00:00 +0000)]
Automatic date update in version.in
Kévin Le Gouguec [Wed, 16 Nov 2022 17:25:26 +0000 (18:25 +0100)]
Add myself to the gdb/MAINTAINERS write-after-approval list
Kévin Le Gouguec [Tue, 15 Nov 2022 15:08:04 +0000 (16:08 +0100)]
Guard against frame.c destructors running before frame-info.c's
On x86_64-windows, since
04e2ac7b2a7, we observe this internal error:
[...]/gdbsupport/intrusive_list.h:458: internal-error: erase_element:
Assertion `elem_node->prev != INTRUSIVE_LIST_UNLINKED_VALUE' failed.
Breaking in the destructors for intrusive_list and frame_info_ptr shows that
in this configuration, the destructors for frame.c's statically-stored
objects are run before frame-info.c's:
Thread 1 hit Breakpoint 7, intrusive_list<frame_info_ptr,
intrusive_base_node<frame_info_ptr> >::~intrusive_list (this=0x7ff69c418c90
<frame_info_ptr::frame_list>, __in_chrg=<optimized out>)
[...]/../gdbsupport/intrusive_list.h:250
250 clear ();
(gdb) bt
#0 intrusive_list<frame_info_ptr, intrusive_base_node<frame_info_ptr> >
::~intrusive_list (this=0x7ff69c418c90 <frame_info_ptr::frame_list>,
__in_chrg=<optimized out>) [...]/../gdbsupport/intrusive_list.h:250
#1 0x00007ff69b78edba in __tcf_1 () [...]/frame-info.c:27
#2 0x00007ff9c457aa9f in msvcrt!_initterm_e ()
from C:\Windows\System32\msvcrt.dll
#3 0x00007ff69b8246a6 in captured_main_1 (context=0x5ffe00)
[...]/main.c:1111
#4 0x00007ff69b825149 in captured_main (data=0x5ffe00) [...]/main.c:1320
#5 0x00007ff69b8251b1 in gdb_main (args=0x5ffe00) [...]/main.c:1345
#6 0x00007ff69b5d1730 in main (argc=2, argv=0x751730) [...]/gdb.c:32
(gdb) c
Continuing.
Thread 1 hit Breakpoint 8, frame_info_ptr::~frame_info_ptr
(this=0x7ff69c418e20 <selected_frame>, __in_chrg=<optimized out>)
[...]/frame-info.h:74
74 if (is_linked ())
(gdb) bt
#0 frame_info_ptr::~frame_info_ptr (this=0x7ff69c418e20 <selected_frame>,
__in_chrg=<optimized out>) [...]/frame-info.h:74
#1 0x00007ff69b79a643 in __tcf_1 () [...]/frame.c:1675
#2 0x00007ff9c457aa9f in msvcrt!_initterm_e () from
C:\Windows\System32\msvcrt.dll
#3 0x00007ff69b8246a6 in captured_main_1 (context=0x5ffe00)
[...]/main.c:1111
#4 0x00007ff69b825149 in captured_main (data=0x5ffe00) [...]/main.c:1320
#5 0x00007ff69b8251b1 in gdb_main (args=0x5ffe00) [...]/main.c:1345
#6 0x00007ff69b5d1730 in main (argc=2, argv=0x751730) [...]/gdb.c:32
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Vladimir Mezentsev [Wed, 16 Nov 2022 05:31:15 +0000 (21:31 -0800)]
PR29788, gprofng cannot display Java's generated assembly code
gprofng/ChangeLog
2022-11-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/29788
* src/Experiment.h: Declare dyntext_name.
* src/Experiment.cc: Use dyntext_name to initialize img_fname.
Tom de Vries [Wed, 16 Nov 2022 16:14:34 +0000 (17:14 +0100)]
[gdb/testsuite] Use gdb_gcore_cmd in gdb.threads/gcore-thread.exp
I noticed a plain gcore command in test-case gdb.threads/gcore-thread.exp:
...
gdb_test "gcore $core0file" "Saved corefile .*" \
"save a zeroed-threads corefile"
...
Use gdb_gcore_cmd instead.
Tested on x86_64-linux.
Carl Love [Tue, 15 Nov 2022 16:57:32 +0000 (10:57 -0600)]
Bug fix in commit for printing the function return value for non-trivial values
The recent commit:
commit
a0eda3df5b750ae32576a9be092b361281a41787
Author: Carl Love <cel@us.ibm.com>
Date: Mon Nov 14 16:22:37 2022 -0500
PowerPC, fix support for printing the function return value for non-trivial values.
Is generating a segmentation fault on x86_64-linux.
segfault:
...
PASS: gdb.asm/asm-source.exp: info source asmsrc1.s
ERROR: GDB process no longer exists
UNRESOLVED: gdb.asm/asm-source.exp: finish from foo3
...
Reproduced on command line:
...
$ gdb -q -batch -x outputs/gdb.asm/asm-source/gdb.in.1
...
The problem seems to be that:
...
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x000000000043de7a in symbol::type (this=0x0) at
.../gdb_versions/devel/src/gdb/symtab.h:1287
1287 return m_type;
...
because:
...
(gdb) up
#1 0x0000000000852d94 in finish_command (arg=0x0, from_tty=0)
at .../gdb_versions/devel/src/gdb/infcmd.c:1887
1887 = check_typedef (sm->function->type ()->target_type ());
(gdb) p sm->function
$1 = (symbol *) 0x0
The code is not checking if sm->function is NULL. If sm->function is NULL
the check for the return buffer should be skipped.
Tom Tromey [Tue, 15 Nov 2022 17:10:20 +0000 (10:10 -0700)]
Update Ada tasks documentation
My co-worker Kévin noticed that the Ada tasks documentation is
slightly out of date -- it does not document all the states that can
be reported by ada-tasks.c.
This patch adds the missing states to the appropriate node, and
updates one state to reflect a change made some time ago.
Pedro Alves [Tue, 1 Nov 2022 16:45:30 +0000 (16:45 +0000)]
gdb: add "set style tui-current-position on|off", default to off
As discussed at:
https://sourceware.org/pipermail/gdb-patches/2020-June/169519.html
this patch disables source and assembly code highlighting for the
text highlighted by the TUI's current position indicator, and adds a
command to enable it back.
Tom de Vries [Wed, 16 Nov 2022 10:19:48 +0000 (11:19 +0100)]
[gdb/testsuite] Modernize gdb.arch/i386-biarch-core.exp
I noticed in test-case gdb.arch/i386-biarch-core.exp that we run into the
completion limit for "complete set gnutarget":
...
set gnutarget vms-libtxt^M
set gnutarget *** List may be truncated, max-completions reached. ***^M
(gdb) PASS: gdb.arch/i386-biarch-core.exp: complete set gnutarget
...
Fix this by using get_set_option_choices.
Also use get_set_option_choices for "complete set architecture i386", which
required extending get_set_option_choices to accept a second argument, such
that we can do:
...
set archs [get_set_option_choices "set architecture" "i386"]
...
because this returns an empty list:
...
set archs [get_set_option_choices "set architecture i386"]
...
because it does "complete set architecture i386 ".
Also clean up the explicit gdb_exit/gdb_start and use clean_restart instead.
Tested on x86_64-linux.
Tom de Vries [Wed, 16 Nov 2022 10:19:48 +0000 (11:19 +0100)]
[gdb/testsuite] Fix gdb.arch/ppc64-symtab-cordic.exp without bzip2
After de-installing bzip2, I run into:
...
Running ppc64-symtab-cordic.exp ...
sh: bzip2: command not found
PATH: gdb.arch/ppc64-symtab-cordic.exp: failed bzip2 for \
src/gdb/testsuite/gdb.arch/cordic.ko.bz2
...
Fix these by:
- using remote_exec instead of catch system, and
- using file tail in the untested message.
I've tried making output redirection work with remote_exec, but that seems to
be broken, so we now:
- copy the file $f.bz2 into the desired location $dir/$f.bz2, and
- decompress the bz2 file using "bzip2 -df $dir/$f.bz2", resulting in a file
$dir/$f.
Factor out new function decompress_bz2 to make the test-case less verbose, and
also use it in gdb.arch/i386-biarch-core.exp.
Tested on x86_64-linux, without and with bzip2 installed.
GDB Administrator [Wed, 16 Nov 2022 00:00:29 +0000 (00:00 +0000)]
Automatic date update in version.in
Indu Bhagat [Tue, 15 Nov 2022 23:07:28 +0000 (15:07 -0800)]
doc: add SFrame spec file
ChangeLog:
* libsframe/Makefile.am: Add info-in-builddir to
AUTOMAKE_OPTIONS. Include doc/local.mk.
* libsframe/Makefile.in: Regenerated.
* libsframe/configure: Likewise.
* libsframe/configure.ac: Check for makeinfo and set BUILD_INFO.
* libsframe/doc/local.mk: New file.
* libsframe/doc/sframe-spec.texi: Likewise.
Indu Bhagat [Tue, 15 Nov 2022 23:07:24 +0000 (15:07 -0800)]
gas/NEWS: add text about new command line option and SFrame support
ChangeLog:
* gas/NEWS: Add SFrame related news.
Indu Bhagat [Tue, 15 Nov 2022 23:07:19 +0000 (15:07 -0800)]
binutils/NEWS: add text for SFrame support
ChangeLog:
* binutils/NEWS: Add item for SFrame support.
Indu Bhagat [Tue, 15 Nov 2022 23:07:13 +0000 (15:07 -0800)]
src-release.sh: Add libsframe
Add libsframe to the list of top level directories that will be included
in a release.
ChangeLog:
* src-release.sh: Add libsframe
Indu Bhagat [Tue, 15 Nov 2022 23:07:09 +0000 (15:07 -0800)]
readelf/objdump: support for SFrame section
This patch adds support for SFrame in readelf and objdump. The arguments
of --sframe are optional for both readelf and objdump.
include/ChangeLog:
* sframe-api.h (dump_sframe): New function declaration.
ChangeLog:
* binutils/Makefile.am: Add dependency on libsframe for
readelf and objdump.
* binutils/Makefile.in: Regenerate.
* binutils/doc/binutils.texi: Document --sframe=[section].
* binutils/doc/sframe.options.texi: New file.
* binutils/objdump.c: Add support for SFrame format.
* binutils/readelf.c: Likewise.
* include/sframe-api.h: Add new API for dumping .sframe
section.
* libsframe/Makefile.am: Add sframe-dump.c.
* libsframe/Makefile.in: Regenerate.
* libsframe/sframe-dump.c: New file.
Indu Bhagat [Tue, 15 Nov 2022 23:07:04 +0000 (15:07 -0800)]
bfd: linker: merge .sframe sections
The linker merges all the input .sframe sections. When merging, the
linker verifies that all the input .sframe sections have the same
abi/arch.
The linker uses libsframe library to perform key actions on the
.sframe sections - decode, read, and create output data. This
implies buildsystem changes to make and install libsframe before
libbfd.
The linker places the output .sframe section in a new segment of its
own: PT_GNU_SFRAME. A new segment is not added, however, if the
generated .sframe section is empty.
When a section is discarded from the final link, the corresponding
entries in the .sframe section for those functions are also deleted.
The linker sorts the SFrame FDEs on start address by default and sets
the SFRAME_F_FDE_SORTED flag in the .sframe section.
This patch also adds support for generation of SFrame unwind
information for the .plt* sections on x86_64. SFrame unwind info is
generated for IBT enabled PLT, lazy/non-lazy PLT.
The existing linker option --no-ld-generated-unwind-info has been
adapted to include the control of whether .sframe unwind information
will be generated for the linker generated sections like PLT.
Changes to the linker script have been made as necessary.
ChangeLog:
* Makefile.def: Add install dependency on libsframe for libbfd.
* Makefile.in: Regenerated.
* bfd/Makefile.am: Add elf-sframe.c
* bfd/Makefile.in: Regenerated.
* bfd/bfd-in2.h (SEC_INFO_TYPE_SFRAME): Regenerated.
* bfd/configure: Regenerate.
* bfd/configure.ac: Add elf-sframe.lo.
* bfd/elf-bfd.h (struct sframe_func_bfdinfo): New struct.
(struct sframe_dec_info): Likewise.
(struct sframe_enc_info): Likewise.
(struct elf_link_hash_table): New member for encoded .sframe
object.
(struct output_elf_obj_tdata): New member.
(elf_sframe): New access macro.
(_bfd_elf_set_section_sframe): New declaration.
* bfd/elf.c (get_segment_type): Handle new segment
PT_GNU_SFRAME.
(bfd_section_from_phdr): Likewise.
(get_program_header_size): Likewise.
(_bfd_elf_map_sections_to_segments): Likewise.
* bfd/elf64-x86-64.c (elf_x86_64_link_setup_gnu_properties): Add
contents to the .sframe sections or .plt* entries.
* bfd/elflink.c (elf_section_ignore_discarded_relocs): Handle
SEC_INFO_TYPE_SFRAME.
(_bfd_elf_default_action_discarded): Handle .sframe section.
(elf_link_input_bfd): Merge .sframe section.
(bfd_elf_final_link): Write the output .sframe section.
(bfd_elf_discard_info): Handle discarding .sframe section.
* bfd/elfxx-x86.c (_bfd_x86_elf_size_dynamic_sections): Create
.sframe section for .plt and .plt.sec.
(_bfd_x86_elf_finish_dynamic_sections): Handle .sframe from
.plt* sections.
* bfd/elfxx-x86.h (PLT_SFRAME_FDE_START_OFFSET): New
definition.
(SFRAME_PLT0_MAX_NUM_FRES): Likewise.
(SFRAME_PLTN_MAX_NUM_FRES): Likewise.
(struct elf_x86_sframe_plt): New structure.
(struct elf_x86_link_hash_table): New member.
(struct elf_x86_init_table): New members for .sframe
creation.
* bfd/section.c: Add new definition SEC_INFO_TYPE_SFRAME.
* binutils/readelf.c (get_segment_type): Handle new segment
PT_GNU_SFRAME.
* ld/ld.texi: Update documentation for
--no-ld-generated-unwind-info.
* ld/scripttempl/elf.sc: Support .sframe sections.
* ld/Makefile.am (TESTSFRAMELIB): Use it.
(check-DEJAGNU): Likewise.
* ld/Makefile.in: Regenerated.
* ld/configure.ac (TESTSFRAMELIB): Set to the .so or .a like TESTBFDLIB.
* ld/configure: Regenerated.
* bfd/elf-sframe.c: New file.
include/ChangeLog:
* elf/common.h (PT_GNU_SFRAME): New definition.
* elf/internal.h (struct elf_segment_map): Handle new segment
type PT_GNU_SFRAME.
ld/testsuite/ChangeLog:
* ld/testsuite/ld-bootstrap/bootstrap.exp: Add SFRAMELIB.
* ld/testsuite/ld-aarch64/aarch64-elf.exp: Add new test
sframe-simple-1.
* ld/testsuite/ld-aarch64/sframe-bar.s: New file.
* ld/testsuite/ld-aarch64/sframe-foo.s: Likewise.
* ld/testsuite/ld-aarch64/sframe-simple-1.d: Likewise.
* ld/testsuite/ld-sframe/sframe-empty.d: New test.
* ld/testsuite/ld-sframe/sframe-empty.s: New file.
* ld/testsuite/ld-sframe/sframe.exp: New testsuite.
* ld/testsuite/ld-x86-64/sframe-bar.s: New file.
* ld/testsuite/ld-x86-64/sframe-foo.s: Likewise.
* ld/testsuite/ld-x86-64/sframe-simple-1.d: Likewise.
* ld/testsuite/ld-x86-64/sframe-plt-1.d: Likewise.
* ld/testsuite/ld-x86-64/sframe-simple-1.d: Likewise.
* ld/testsuite/ld-x86-64/x86-64.exp: Add new tests -
sframe-simple-1, sframe-plt-1.
* ld/testsuite/lib/ld-lib.exp: Add new proc to check if
assembler supports SFrame section.
* ld/testsuite/ld-sframe/discard.d: New file.
* ld/testsuite/ld-sframe/discard.ld: Likewise.
* ld/testsuite/ld-sframe/discard.s: Likewise.
Weimin Pan [Tue, 15 Nov 2022 23:06:59 +0000 (15:06 -0800)]
libsframe: add the SFrame library
libsframe is a library that allows you to:
- decode a .sframe section
- probe and inspect a .sframe section
- encode (and eventually write) a .sframe section.
This library is currently being used by the linker, readelf, objdump.
This library will also be used by the SFrame unwinder which is still
to be upstream'd.
The file include/sframe-api.h defines the user-facing APIs for decoding,
encoding and probing .sframe sections. A set of error codes together
with their error message strings are also defined.
Endian flipping is performed automatically at read and write time, if
cross-endianness is detected.
ChangeLog:
* Makefile.def: Add libsframe as new module with its
dependencies.
* Makefile.in: Regenerated.
* binutils/Makefile.am: Add libsframe.
* binutils/Makefile.in: Regenerated.
* configure: Regenerated
* configure.ac: Add libsframe to host_libs.
* libsframe/Makefile.am: New file.
* libsframe/Makefile.in: New file.
* libsframe/aclocal.m4: New file.
* libsframe/config.h.in: New file.
* libsframe/configure: New file.
* libsframe/configure.ac: New file.
* libsframe/sframe-error.c: New file.
* libsframe/sframe-impl.h: New file.
* libsframe/sframe.c: New file.
include/ChangeLog:
* sframe-api.h: New file.
testsuite/ChangeLog:
* libsframe/testsuite/Makefile.am: New file.
* libsframe/testsuite/Makefile.in: Regenerated.
* libsframe/testsuite/libsframe.decode/Makefile.am: New
file.
* libsframe/testsuite/libsframe.decode/Makefile.in:
Regenerated.
* libsframe/testsuite/libsframe.decode/decode.exp: New file.
* libsframe/testsuite/libsframe.encode/Makefile.am:
Likewise.
* libsframe/testsuite/libsframe.encode/Makefile.in:
Regenerated.
* libsframe/testsuite/libsframe.encode/encode.exp: New file.
* libsframe/testsuite/libsframe.encode/encode-1.c: Likewise.
* libsframe/testsuite/libsframe.decode/be-flipping.c: Likewise.
* libsframe/testsuite/libsframe.decode/frecnt-1.c: Likewise.
* libsframe/testsuite/libsframe.decode/frecnt-2.c: Likewise.
* libsframe/testsuite/libsframe.decode/DATA-BE: New file.
* libsframe/testsuite/libsframe.decode/DATA1: Likewise.
* libsframe/testsuite/libsframe.decode/DATA2: Likewise.
Indu Bhagat [Tue, 15 Nov 2022 23:06:53 +0000 (15:06 -0800)]
gas: testsuite: add new tests for SFrame unwind info
Earlier these tests were in the same commit as previous which adds the
support in GNU assembler to generate .sframe section from CFI
directives. Splitting this out here for ease of applying and testing.
ChangeLog:
* gas/testsuite/gas/cfi-sframe/cfi-sframe-aarch64-1.d: New file.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-aarch64-1.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-1.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-1.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-2.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-2.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-3.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-3.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-4.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-4.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-5.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-5.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-6.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-6.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-7.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-7.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-8.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-8.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-x86_64-1.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-x86_64-1.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe.exp: Likewise.
* gas/testsuite/gas/cfi-sframe/common-empty-1.d: Likewise.
* gas/testsuite/gas/cfi-sframe/common-empty-1.s: Likewise.
* gas/testsuite/gas/cfi-sframe/common-empty-2.d: Likewise.
* gas/testsuite/gas/cfi-sframe/common-empty-2.s: Likewise.
* gas/testsuite/gas/cfi-sframe/common-empty-3.d: Likewise.
* gas/testsuite/gas/cfi-sframe/common-empty-3.s: Likewise.
* gas/testsuite/gas/cfi-sframe/common-empty-4.d: Likewise.
* gas/testsuite/gas/cfi-sframe/common-empty-4.s: Likewise.
Indu Bhagat [Tue, 15 Nov 2022 23:06:46 +0000 (15:06 -0800)]
gas: generate .sframe from CFI directives
Currently supported for x86_64 and aarch64 only.
[PS: Currently, the compiler has not been adapted to generate
".cfi_sections" with ".sframe" in it. The newly added command line
option of --gsframe provides an easy way to try out .sframe support
in the toolchain.]
gas interprets the CFI directives to generate DWARF-based .eh_frame
info. These internal DWARF structures are now consumed by
gen-sframe.[ch] sub-system to, in turn, create the SFrame unwind
information. These internal DWARF structures are read-only for the
purpose of SFrame unwind info generation.
SFrame unwind info generation does not impact .eh_frame unwind info
generation. Both .eh_frame and .sframe can co-exist in an ELF file,
if so desired by the user.
Recall that SFrame unwind information only contains the minimal
necessary information to generate backtraces and does not provide
information to recover all callee-saved registers. The reason being
that callee-saved registers other than FP are not needed for stack
unwinding, and hence are not included in the .sframe section.
Consequently, gen-sframe.[ch] only needs to interpret a subset of
DWARF opcodes in gas. More details follow.
[Set 1, Interpreted] The following opcodes are interpreted:
- DW_CFA_advance_loc
- DW_CFA_def_cfa
- DW_CFA_def_cfa_register
- DW_CFA_def_cfa_offset
- DW_CFA_offset
- DW_CFA_remember_state
- DW_CFA_restore_state
- DW_CFA_restore
[Set 2, Bypassed] The following opcodes are acknowledged but are not
necessary for generating SFrame unwind info:
- DW_CFA_undefined
- DW_CFA_same_value
Anything else apart from the two above-mentioned sets is skipped
altogether. This means that any function containing a CFI directive not
in Set 1 or Set 2 above, will not have any SFrame unwind information
generated for them. Holes in instructions covered by FREs of a single
FDE are not representable in the SFrame unwind format.
As few examples, following opcodes are not processed for .sframe
generation, and are skipped:
- .cfi_personality*
- .cfi_*lsda
- .cfi_escape
- .cfi_negate_ra_state
- ...
Not processing .cfi_escape, .cfi_negate_ra_state will cause SFrame
unwind information to be absent for SFrame FDEs that contain these CFI
directives, hence affecting the asynchronicity.
x86-64 and aarch64 backends need to have a few new definitions and
functions for .sframe generation. These provide gas with architecture
specific information like the SP/FP/RA register numbers and an
SFrame-specific ABI marker.
Lastly, the patch also implements an optimization for size, where
specific fragments containing SFrame FRE start address and SFrame FDE
function are fixed up. This is similar to other similar optimizations
in gas, where fragments are sized and fixed up when the associated
symbols can be resolved. This optimization is controlled by a #define
SFRAME_FRE_TYPE_SELECTION_OPT and should be easy to turn off if needed.
The optimization is on by default for both x86_64 and aarch64.
ChangeLog:
* gas/Makefile.am: Include gen-sframe.c and sframe-opt.c.
* gas/Makefile.in: Regenerated.
* gas/as.h (enum _relax_state): Add new state rs_sframe.
(sframe_estimate_size_before_relax): New function.
(sframe_relax_frag): Likewise.
(sframe_convert_frag): Likewise.
* gas/config/tc-aarch64.c (aarch64_support_sframe_p): New
definition.
(aarch64_sframe_ra_tracking_p): Likewise.
(aarch64_sframe_cfa_ra_offset): Likewise.
(aarch64_sframe_get_abi_arch): Likewise.
(md_begin): Set values of sp/fp/ra registers.
* gas/config/tc-aarch64.h (aarch64_support_sframe_p): New
declaration.
(support_sframe_p): Likewise.
(SFRAME_CFA_SP_REG): Likewise.
(SFRAME_CFA_FP_REG): Likewise.
(SFRAME_CFA_RA_REG): Likewise.
(aarch64_sframe_ra_tracking_p): Likewise.
(sframe_ra_tracking_p): Likewise.
(aarch64_sframe_cfa_ra_offset): Likewise.
(sframe_cfa_ra_offset): Likewise.
(aarch64_sframe_get_abi_arch): Likewise.
(sframe_get_abi_arch): Likewise.
* gas/config/tc-i386.c (x86_support_sframe_p): New definition.
(x86_sframe_ra_tracking_p): Likewise.
(x86_sframe_cfa_ra_offset): Likewise.
(x86_sframe_get_abi_arch): Likewise.
* gas/config/tc-i386.h (x86_support_sframe_p): New declaration.
(support_sframe_p): Likewise.
(SFRAME_CFA_SP_REG): Likewise.
(SFRAME_CFA_FP_REG): Likewise.
(x86_sframe_ra_tracking_p): Likewise.
(sframe_ra_tracking_p): Likewise.
(x86_sframe_cfa_ra_offset): Likewise.
(sframe_cfa_ra_offset): Likewise.
(x86_sframe_get_abi_arch): Likewise.
(sframe_get_abi_arch): Likewise.
* gas/config/tc-xtensa.c (unrelaxed_frag_max_size): Add case for
rs_sframe.
* gas/doc/as.texi: Add .sframe to the documentation for
.cfi_sections.
* gas/dw2gencfi.c (cfi_finish): Create a .sframe section.
* gas/dw2gencfi.h (CFI_EMIT_sframe): New definition.
* gas/write.c (cvt_frag_to_fill): Handle rs_sframe.
(relax_segment): Likewise.
* gas/gen-sframe.c: New file.
* gas/gen-sframe.h: New file.
* gas/sframe-opt.c: New file.
Indu Bhagat [Tue, 15 Nov 2022 23:06:39 +0000 (15:06 -0800)]
gas: add new command line option --gsframe
When --gsframe is specified, the assembler will generate a .sframe
section from the CFI directives in the assembly.
ChangeLog:
* gas/as.c (parse_args): Parse args and set flag_gen_sframe.
* gas/as.h: Introduce skeleton for --gsframe.
* gas/doc/as.texi: document --gsframe.
Indu Bhagat [Tue, 15 Nov 2022 23:06:23 +0000 (15:06 -0800)]
sframe.h: Add SFrame format definition
The header sframe.h defines the SFrame format.
The SFrame format is the Simple Frame format. It can be used to
represent the minimal necessary unwind information required for
backtracing. The current version supports AMD64 and AARCH64.
More details of the SFrame format are included in the documentation
of the header file in this patch.
include/ChangeLog:
* sframe.h: New file.
Alan Modra [Tue, 15 Nov 2022 21:29:27 +0000 (07:59 +1030)]
Re: [gas] arm: Add support for new unwinder directive ".pacspval".
* testsuite/gas/arm/ehabi-pacbti-m.d: Limit test to ELF.
Alan Modra [Tue, 15 Nov 2022 08:13:43 +0000 (18:43 +1030)]
aarch64-pe can't fill 16 bytes in section .text
Without commit
b66e671854, this:
.p2align 4
nop
.p2align 3
nop
results in an error when coff_frob_section attempts to pad out the
section to a 16-byte boundary. Due to miscalculating the pad pattern
repeat count, write.c:write_contents attempts to shove 16 bytes of
padding into the remaining 4 bytes of the .text section.
* config/obj-coff.c (coff_frob_section): Correct fill count.
Don't pad after errors.
Jose E. Marchesi [Tue, 15 Nov 2022 19:26:30 +0000 (20:26 +0100)]
gdb/configure: regenerate
The commit
bbaabc767a4293492817a0840819aef2768cce90 introduced an
incorrect thunk for the `configure' script. This patch regenerates
configure by calling autoreconf.
Jose E. Marchesi [Mon, 7 Nov 2022 19:35:43 +0000 (20:35 +0100)]
gdb: use libtool in GDB_AC_CHECK_BFD
The GDB_AC_CHECK_BFD macro defined in gdb/acinclude.m4 uses the
AC_LINK_IFELSE autoconf macro in order to link a simple program to
check features of libbfd.
If libbfd's link dependencies change, it was necessary to reflect them
either in the definition of the macro, or as a consequence of checking
for them with an autoconf macro resulting in an addition to LIBS.
This patch modifies the definition of the GDB_CHECK_BFD macro in order
to use libtool to perform the test link. This makes it possible to
not have to list dependencies of libbfd (which are indirect to GDB) at
all.
After this patch:
configure:28553: checking for ELF support in BFD
configure:28573: ./libtool --quiet --mode=link gcc -o conftest \
-I../../gdb/../include -I../bfd \
-I../../gdb/../bfd -g -O2 \
-L../bfd -L../libiberty conftest.c -lbfd -liberty \
-lncursesw -lm -ldl >&5
configure:28573: $? = 0
configure:28583: result: yes
Tests performed:
- Configure --with-system-zlib and --without-system-zlib.
- Check link dependencies of installed GDB with both --enable-shared
and --disable-shared.
- Run installed GDB in both cases.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Thu, 20 Oct 2022 16:55:35 +0000 (10:55 -0600)]
Fix crash in ada_print_type
The "varstring" paramter to ada_print_type can be null, but one spot
failed to check this. This could cause a crash in some situations.
As this is Ada-specific, and we've been using it internally at AdaCore
for a while, I am going to push it.
Tejas Joshi [Tue, 15 Nov 2022 16:26:37 +0000 (21:56 +0530)]
Add AMD znver4 processor support
2022-09-28 Tejas Joshi <TejasSanjay.Joshi@amd.com>
gas/
* config/tc-i386.c (cpu_arch): Add znver4 ARCH and rmpquery SUBARCH.
(md_assemble): Expand comment before swap_operands() with rmpquery.
* doc/c-i386.texi: Add znver4.
* testsuite/gas/i386/arch-14-1.d: New.
* testsuite/gas/i386/arch-14-1.s: New.
* testsuite/gas/i386/arch-14-znver4.d: New.
* testsuite/gas/i386/i386.exp: Add new znver4 test cases.
* testsuite/gas/i386/rmpquery.d: New.
* testsuite/gas/i386/rmpquery.s: New.
* testsuite/gas/i386/x86-64-arch-4-1.d: New.
* testsuite/gas/i386/x86-64-arch-4-1.s: New.
* testsuite/gas/i386/x86-64-arch-4-znver4.d: New.
opcodes/
* i386-dis.c (x86_64_table): Add rmpquery.
* i386-gen.c (cpu_flag_init): Add CPU_ZNVER4_FLAGS and
CPU_RMPQUERY_FLAGS.
(cpu_flags): Add CpuRMPQUERY.
* i386-opc.h (enum): Add CpuRMPQUERY.
(i386_cpu_flags): Add cpurmpquery.
* i386-opc.tbl: Add rmpquery insn.
* i386-init.h: Re-generated.
* i386-tbl.h: Re-generated.
Simon Marchi [Mon, 14 Nov 2022 15:10:04 +0000 (10:10 -0500)]
gdb/testsuite: get_set_option_choices: expect \r\n after each item
I get some random failures since commit
8d45c3a82a0e ("[gdb/testsuite]
Set completions to unlimited in get_set_option_choices"), which can be
reproduced with:
$ make check-read1 TESTS="gdb.base/parse_number.exp"
For instance:
set architecture A^M
Ambiguous item "A".^M
(gdb) FAIL: gdb.base/parse_number.exp: arch=A: set architecture A
The problem is the regexp in get_set_option_choices, it is possible that
is only matches part of a completion result. With check-read1, that is
always one letter.
Fix this by expecting the \r\n at the end of the line, so we only match
entire results. Use ^ in match patterns to ensure we don't miss any
output.
Approved-By: Tom de Vries <tdevries@suse.de>
Change-Id: Ib1733737feab7dde0f7095866e089081a891054e
Andre Vieira [Tue, 15 Nov 2022 14:36:49 +0000 (14:36 +0000)]
aarch64, testsuite: Fixed recently added cssc.d
Fixed wrong paste in cssc.d.
gas/ChangeLog:
* testsuite/gas/aarch64/cssc.d: Removed duplicate head.
Tom de Vries [Tue, 15 Nov 2022 14:24:54 +0000 (15:24 +0100)]
[gdb/testsuite] Normalize gdbserver path name
Currently for the target board remote-gdbserver-on-localhost we use the
gdbserver file on build, using a file name which includes "/../".
Fix this by using a normalized file name instead.
This allows us to be more restrictive about which files REMOTE_TARGET_USERNAME
can access:
...
- remote_exec build "chmod go-rx $objdir/outputs"
+ remote_exec build "chmod go-rx $objdir"
...
Tested on x86_64-linux.
Tom de Vries [Tue, 15 Nov 2022 14:24:54 +0000 (15:24 +0100)]
[gdb/testsuite] Fix gdb.base/jit-elf-so.exp for remote target
With test-case gdb.base/jit-elf-so.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.
Fix these by:
- setting jit_libname with the name as returned by gdb_load_shlib
- allowing the libraries to be prefixed with the remote target directory.
Tested on x86_64-linux.
Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
Tom de Vries [Tue, 15 Nov 2022 14:24:54 +0000 (15:24 +0100)]
[gdb/testsuite] Fix gdb.base/jit-reader-exec.exp for remote target
With test-case gdb.base/jit-reader-exec.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.
Fix this by adding the missing gdb_remote_download.
Tested on x86_64-linux.
Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
Tom de Vries [Tue, 15 Nov 2022 14:24:54 +0000 (15:24 +0100)]
[gdb/testsuite] Fix gdb.base/info-shared.exp for remote target
With test-case gdb.base/info-shared.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.
Fix these by adding the missing gdb_load_shlib.
Tested on x86_64-linux.
Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
Tom de Vries [Tue, 15 Nov 2022 14:24:54 +0000 (15:24 +0100)]
[gdb/testsuite] Fix gdb.base/solib-vanish.exp for remote target
When running test-case gdb.base/solib-vanish.exp with target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.
Fix these by adding the missing gdb_load_shlib.
Tested on x86_64-linux.
Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
Tom de Vries [Tue, 15 Nov 2022 14:24:54 +0000 (15:24 +0100)]
[gdb/testsuite] Fix gdb.base/infcall-exec.exp for remote target
When running test-case gdb.base/infcall-exec.exp with target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into:
...
(gdb) call (int) execlp ("$outputs/gdb.base/infcall-exec/infcall-exec2", \
"$outputs/gdb.base/infcall-exec/infcall-exec2", (char *)0)^M
$1 = -1^M
(gdb) FAIL: gdb.base/infcall-exec.exp: call execlp
...
Fix this by using just:
...
(gdb) call (int) execlp ("infcall-exec2", "infcall-exec2", (char *)0)^M
...
and using putenv ("PATH=...") to allow infcall-exec to exec infcall-exec2
if it's available alongside.
Also fix the exec name in the test-case, such that we can successfully
run the test-case:
...
$ ./outputs/gdb.base/infcall-exec/infcall-exec
PATH SETTING: 'PATH=./outputs/gdb.base/infcall-exec'
$
...
Tested on x86_64-linux.
Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
Tom de Vries [Tue, 15 Nov 2022 14:24:54 +0000 (15:24 +0100)]
[gdb/testsuite] Fix gdb.base/print-file-var.exp for remote target
When running test-case gdb.base/print-file-var.exp with target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.
Fix these by using the name of a shared lib as returned by gdb_load_shlib.
This required splitting up the gdb_load_shlib functionality, which is now
defined as:
...
proc gdb_load_shlib { file } {
set dest [gdb_download_shlib $file]
gdb_locate_shlib $file
return $dest
}
...
such that we can do gdb_download_shlib before gdb is started.
Tested on x86_64-linux.
Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
Tom de Vries [Tue, 15 Nov 2022 14:24:54 +0000 (15:24 +0100)]
[gdb/testsuite] Add REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.exp
As reported here
( https://sourceware.org/pipermail/gdb-patches/2022-October/193147.html ) a
number of test-cases fails with a remote target setup, for instance test-case
gdb.base/print-file-var.exp.
So, why don't we see these fails with our remote target boards in
gdb/testsuite/boards, say remote-gdbserver-on-localhost.exp?
The problem is that the target board uses the same machine and user for
both (by-definition-local) build and remote target, and when using absolute
pathnames to refer to files on build, we can access those files on target,
which in a real remote target setup wouldn't be the case: we'd have to
download them to target first, and then the filename would also be different.
For aforementioned test-case, this happens when the name of a shared library is
passed as absolute file name to gcc:
...
gcc ... -DSHLIB_NAME="$outputs/gdb.base/print-file-var/\
print-file-var-lib2-hidden0-dlopen1-version_id_main0_c.so"
...
Make these problems visible with remote-gdbserver-on-localhost.exp by
adding an option to specify a test account (still on the same machine)
using REMOTE_TARGET_USERNAME.
We make sure by restricting file permissions, that the test account cannot see
the build files on the $USER account, and that the $USER account cannot see
the target files on the test account.
And so we can reproduce the reported fails:
...
$ cd build/gdb
$ tc="gdb.base/print-file-var.exp"
$ tb="--target_board remote-gdbserver-on-localhost"
$ tbu="REMOTE_TARGET_USERNAME=remote-target"
$ make check RUNTESTFLAGS="$tb $tbu $tc"
...
FAIL: gdb.base/print-file-var.exp: lang=c: hidden=0: dlopen=1: \
version_id_main=0: continue to STOP marker
...
Tested on x86_64-linux.
Reported-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
Tom de Vries [Tue, 15 Nov 2022 14:24:54 +0000 (15:24 +0100)]
[gdb/testsuite] Fix gdb.base/info_sources_2.exp for remote target
With test-case gdb.base/info_sources_2.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.
Fix these by adding the missing gdb_load_shlib.
Tested on x86_64-linux.
Tom de Vries [Tue, 15 Nov 2022 14:24:54 +0000 (15:24 +0100)]
[gdb/testsuite] Fix gdb.base/foll-exec.exp for remote target
When running test-case gdb.base/foll-exec.exp with target board
remote-gdbserver-on-localhost.exp, I run into:
...
(gdb) PASS: gdb.base/foll-exec.exp: insert first exec catchpoint
continue^M
Continuing.^M
[Inferior 1 (process 4476) exited normally]^M
(gdb) FAIL: gdb.base/foll-exec.exp: continue to first exec catchpoint (the program e\
xited)
...
The problem is that the foll-exec executable expects the exec-ed executable
execd-prog alongside it, but it's missing.
Fix this by adding the missing gdb_remote_download.
Likewise in a few other test-cases.
Tested on x86_64-linux.
Tom de Vries [Tue, 15 Nov 2022 13:00:41 +0000 (14:00 +0100)]
[gdb/testssuite] Skip aarch64 in skip_gdbserver_test if no xml support
On aarch64-linux, with a gdb build without libexpat, so without xml support, I
run into:
...
(gdb) builtin_spawn attach-no-multi-process^M
attach 26808^M
Attaching to Remote target^M
warning: Can not parse XML target description; XML support was disabled at \
compile time^M
Reading symbols from attach-no-multi-process...^M
Remote 'g' packet reply is too long (expected 788 bytes, got 796 bytes): ... ^M
...
The test-case checks for skip_gdbserver_tests and that one contains a check
for xml support:
...
# If GDB is lack of XML support, and targets, like arm, have
# multiple target descriptions, GDB doesn't know which target
# description GDBserver uses, and may fail to parse 'g' packet
# after connection.
if { [gdb_skip_xml_test]
&& ([istarget "arm*-*-linux*"]
|| [istarget "mips*-*-linux*"]
|| [istarget "powerpc*-*-linux*"]
|| [istarget "s390*-*-linux*"]
|| [istarget "x86_64-*-linux*"]
|| [istarget "i\[34567\]86-*-linux*"]) } {
return 1
}
...
but it doesn't trigger because aarch64 is missing.
Fix this by adding istarget "aarch64*-*-linux*".
Tested on aarch64-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
Aditya Vidyadhar Kamath [Tue, 15 Nov 2022 12:36:18 +0000 (13:36 +0100)]
Enable multi-process debugging for AIX
This patch adds multi-process debugging feature in AIX.
Till now AIX supported debugging only one inferior at a time,
now we can be able to debug multi process. Users can use set
follow fork mode in child or parent and set detach on fork on
or off to enable/disable simultaneous debugging of parent/child.
GDB Administrator [Tue, 15 Nov 2022 00:00:31 +0000 (00:00 +0000)]
Automatic date update in version.in
Carl Love [Mon, 14 Nov 2022 21:22:37 +0000 (16:22 -0500)]
PowerPC, fix support for printing the function return value for non-trivial values.
Currently, a non-trivial return value from a function cannot currently be
reliably determined on PowerPC. This is due to the fact that the PowerPC
ABI uses register r3 to store the address of the buffer containing the
non-trivial return value when the function is called. The PowerPC ABI
does not guarantee the value in register r3 is not modified in the
function. Thus the value in r3 cannot be reliably used to obtain the
return addreses on exit from the function.
This patch adds a new gdbarch method to allow PowerPC to access the value
of r3 on entry to a function. On PowerPC, the new gdbarch method attempts
to use the DW_OP_entry_value for the DWARF entries, when exiting the
function, to determine the value of r3 on entry to the function. This
requires the use of the -fvar-tracking compiler option to compile the
user application thus generating the DW_OP_entry_value in the binary. The
DW_OP_entry_value entries in the binary file allows GDB to resolve the
DW_TAG_call_site entries. This new gdbarch method is used to get the
return buffer address, in the case of a function returning a nontrivial
data type, on exit from the function. The GDB function should_stop checks
to see if RETURN_BUF is non-zero. By default, RETURN_BUF will be set to
zero by the new gdbarch method call for all architectures except PowerPC.
The get_return_value function will be used to obtain the return value on
all other architectures as is currently being done if RETURN_BUF is zero.
On PowerPC, the new gdbarch method will return a nonzero address in
RETURN_BUF if the value can be determined. The value_at function uses the
return buffer address to get the return value.
This patch fixes five testcase failures in gdb.cp/non-trivial-retval.exp.
The correct function return values are now reported.
Note this patch is dependent on patch: "PowerPC, function
ppc64_sysv_abi_return_value add missing return value convention".
This patch has been tested on Power 10 and x86-64 with no regressions.
Carl Love [Mon, 14 Nov 2022 21:22:11 +0000 (16:22 -0500)]
PowerPC, function ppc64_sysv_abi_return_value add missing return value convention
This patch address five testcase failures in gdb.cp/non-trivial-retval.exp.
The following commit resulted in the five testcases failures on PowerPC.
The value returned by the function is being reported incorrectly.
commit
b1718fcdd1d2a5c514f8ee504ba07fb3f42b8608
Author: Andrew Burgess <aburgess@redhat.com>
Date: Mon Dec 13 16:56:16 2021 +0000
gdb: on x86-64 non-trivial C++ objects are returned in memory
Fixes PR gdb/28681. It was observed that after using the `finish`
command an incorrect value was displayed in some cases. Specifically,
this behaviour was observed on an x86-64 target.
The function:
enum return_value_convention
ppc64_sysv_abi_return_value (struct gdbarch *gdbarch, struct value *function,
struct type *valtype, struct regcache *regcache,
gdb_byte *readbuf, const gdb_byte *writebuf)
should return RETURN_VALUE_STRUCT_CONVENTION if the valtype->code() is
TYPE_CODE_STRUCT and if the language_pass_by_reference is not
trivially_copyable.
This patch adds the needed code to return the value
RETURN_VALUE_STRUCT_CONVENTION in this case.
With this patch, the five test cases still fail but with the message "Value
returned has type: A. Cannot determine contents". The PowerPC ABI stores
the address of the buffer containing the function return value in register
r3 on entry to the function. However, the PowerPC ABI does not guarentee
that r3 will not be modified in the function. So when the function returns,
the return buffer address cannot be reliably obtained from register r3.
Thus the message "Cannot determine contents" is appropriate in this case.
Tom Tromey [Tue, 1 Nov 2022 19:24:32 +0000 (13:24 -0600)]
Remove dump_prefix_expression
Since the expression rewrite, dump_prefix_expression has been
misnamed. This patch cleans this up by removing the function, turning
it into a method on struct expression.
Andre Vieira [Mon, 14 Nov 2022 16:47:22 +0000 (16:47 +0000)]
aarch64: Add support for Common Short Sequence Compression extension
This patch adds support for the CSSC extension and its corresponding
instructions: ABS, CNT, CTZ, SMAX, UMAX, SMIN, UMIN.
gas/ChangeLog:
* config/tc-aarch64.c (parse_operands): Handle new operand types.
* doc/c-aarch64.texi: Document new extension.
* testsuite/gas/aarch64/cssc.d: New test.
* testsuite/gas/aarch64/cssc.s: New test.
include/ChangeLog:
* opcode/aarch64.h (AARCH64_FEATURE_CSSC): New feature Macro.
(enum aarch64_opnd): New operand types.
(enum aarch64_insn_class): New instruction class.
opcodes/ChangeLog:
* aarch64-asm-2.c: Regenerate.
* aarch64-dis-2.c: Regenerate.
* aarch64-opc-2.c: Regenerate.
* aarch64-opc.c (operand_general_constraint_met_p): Update for new
operand types.
(aarch64_print_operand): Likewise.
* aarch64-opc.h (enum aarch64_field_kind): Declare FLD_CSSC_imm8 field.
* aarch64-tbl.h (aarch64_feature_cssc): Define new feature set.
(CSSC): Define new feature set Macro.
(CSSC_INSN): Define new instruction type.
(aarch64_opcode_table): Add new instructions.
Jan Beulich [Mon, 14 Nov 2022 16:10:14 +0000 (17:10 +0100)]
x86: fold special-operand insn attributes into a single enum
Attributes which aren't used together in any single insn template can be
converted from individual booleans to a single enum, as was done for a few
other attributes before. This is more space efficient. Collect together
all attributes which express special operand constraints (and which fit
the criteria for folding).
Dimitar Dimitrov [Fri, 27 May 2022 20:09:24 +0000 (23:09 +0300)]
pru: bfd: Correct default to no execstack
Data and instruction memories are strictly separated, so it is not
possible to execute instructions from the stack memory on PRU.
I don't see any difference in testsuite results with or without this
change.
bfd/ChangeLog:
* elf32-pru.c (elf_backend_default_execstack): Define as 0.
ld/ChangeLog:
* testsuite/ld-elf/elf.exp (target_defaults_to_execstack):
Return 0 for pru.
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
Srinath Parvathaneni [Mon, 14 Nov 2022 15:13:17 +0000 (15:13 +0000)]
[gas] arm: Add support for new unwinder directive ".pacspval".
This patch adds the assembler support for the new unwinder
directive ".pacspval" and encodes this directives with opcode
"0xb5". This opcode indicates the unwinder to use effective
vsp as modifier for PAC validation.
gas/ChangeLog:
2022-11-07 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
* doc/c-arm.texi: Document directive.
* config/tc-arm.c (s_arm_unwind_pacspval): Define function.
(md_pseudo_table): Add entry for pacspval directive.
* testsuite/gas/arm/ehabi-pacbti-m.d: New test.
* testsuite/gas/arm/ehabi-pacbti-m.s: Likewise.
Srinath Parvathaneni [Mon, 14 Nov 2022 15:11:49 +0000 (15:11 +0000)]
[readelf] arm: Support for new pacbti unwind opcode 0xb5.
This patch adds readelf support for decoding the exception
table opcode "0xb5", which indicates to use effective vsp
as modifier for PAC validation as defined by EHABI
(https://github.com/ARM-software/abi-aa/releases/download/2022Q3/ehabi32.pdf
Section 10.3).
binutils/ChangeLog:
2022-11-07 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
* readelf.c (decode_arm_unwind_bytecode): Add entry to decode opcode 0xb5.
Tsukasa OI [Thu, 20 Oct 2022 09:32:06 +0000 (09:32 +0000)]
gdb/unittests: PR28413, suppress warnings generated by Gnulib
Gnulib generates a warning if the system version of certain functions
are used (to redirect the developer to use Gnulib version). It caused a
compiler error when...
- Compiled with Clang
- -Werror is specified (by default)
- C++ standard used by Clang is before C++17 (by default as of 15.0.0)
when this unit test is activated.
This issue is raised as PR28413.
However, previous proposal to fix this issue (a "fix" to Gnulib):
<https://lists.gnu.org/archive/html/bug-gnulib/2021-10/msg00003.html>
was rejected because it ruins the intent of Gnulib warnings.
So, we need a Binutils/GDB-side solution.
This commit tries to address this issue on the GDB side. We have
"include/diagnostics.h" to disable certain warnings only when necessary.
This commit suppresses the Gnulib warnings by surrounding entire #include
block with DIAGNOSTIC_IGNORE_USER_DEFINED_WARNINGS to disable Gnulib-
generated warnings on all standard C++ header files.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28413
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ieeb5a31a6902808d4c7263a2868ae19a35e0ccaa
Srinath Parvathaneni [Mon, 14 Nov 2022 13:55:51 +0000 (13:55 +0000)]
arm: Add support for Cortex-X1C CPU.
This patch adds support for Cortex-X1C CPU in Arm.
bfd/ChangeLog:
2022-11-09 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
* cpu-arm.c (processors): Add Cortex-X1C CPU entry.
gas/ChangeLog:
2022-11-09 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
* NEWS: Update docs.
* config/tc-arm.c (arm_cpus): Add cortex-x1c to -mcpu.
* doc/c-arm.texi: Update docs.
* testsuite/gas/arm/cpu-cortex-x1c.d: New test.
Tom de Vries [Mon, 14 Nov 2022 11:12:19 +0000 (12:12 +0100)]
[gdb/testsuite] Run gdb.arch/ppc64-symtab-cordic.exp for --enable-targets=all
While looking at test-case gdb.arch/ppc64-symtab-cordic.exp I realized that
the test-case is too restrictive here:
...
if {![istarget "powerpc*"] || ![is_lp64_target]} {
verbose "Skipping powerpc64 separate debug file symtab test."
return
}
...
and can also be run on x86_64-linux, if "set arch powerpc:common64" is
supported, which is the case if we've build gdb with --enable-targets=all.
Fix this by instead checking if powerpc:common64 is in the completion list for
"set arch".
This allows us to remove the 'untested "powerpc:common64 is not supported"'.
While we're at it, clean up the test-case by using clean_restart.
Tested on x86_64-linux.
Tom de Vries [Mon, 14 Nov 2022 11:12:19 +0000 (12:12 +0100)]
[gdb/testsuite] Handle with_set arch
I realized that the more irregular output of show arch:
...
(gdb) show arch^M
The target architecture is set to "auto" (currently "i386").^M
...
would be a problem for something like:
...
with_set arch powerpc:common64 {}
...
and indeed:
...
(gdb) set arch powerpc:common64^M
The target architecture is set to "powerpc:common64".^M
(gdb) FAIL: gdb.base/foo.exp: set arch powerpc:common64
...
and:
...
(gdb) set arch set to "auto" (currently "i386")^M
Undefined item: "set".^M
...
Fix this in with_set by handling this type of output.
Tested on x86_64-linux.
Tom de Vries [Mon, 14 Nov 2022 11:12:19 +0000 (12:12 +0100)]
[gdb/testsuite] Set completions to unlimited in get_set_option_choices
In some test-case I tried to use get_set_option_choices "set architecture" and
ran into max-completions:
...
set architecture simple^M
set architecture tomcat^M
set architecture xscale^M
set architecture *** List may be truncated, max-completions reached. ***^M
(gdb) PASS: gdb.base/foo.exp: complete set architecture
...
There's only one test-case using this currently: gdb.base/parse_number.exp,
and it locally sets max-completions to unlimited.
Fix this by:
- factoring out a new proc with_set out of proc with_complaints, and
- using it to temporarily set max-completions to unlimited in
get_set_option_choice.
Tested on x86_64-linux, by running test-cases that excercise
get_set_option_choice and with_complaints.
Alan Modra [Mon, 14 Nov 2022 03:07:21 +0000 (13:37 +1030)]
Re: objcopy renaming section with explicit flags
For now, xfail the new test. Some header/aux-header rewriting is
required at the very least.
* testsuite/binutils-all/rename-section-01.d: xfail xcoff.
Alan Modra [Sun, 13 Nov 2022 21:55:16 +0000 (08:25 +1030)]
objcopy renaming section with explicit flags
This tidies SEC_RELOC handling in bfd, in the process fixing a bug
with objcopy when renaming sections.
bfd/
* reloc.c (_bfd_generic_set_reloc): Set/clear SEC_RELOC depending
on reloc count.
* elf64-sparc.c (elf64_sparc_set_reloc): Likewise.
binutils/
* objcopy.c (copy_relocations_in_section): Remove now unnecessary
clearing of SEC_RELOC.
* testsuite/binutils-all/rename-section-01.d: New test.
* testsuite/binutils-all/objcopy.exp: Run it.
gas/
* write.c (size_seg): Remove unneccesary twiddle of SEC_RELOC.
(write_relocs): Likewise. Always call bfd_set_reloc.
GDB Administrator [Mon, 14 Nov 2022 00:00:31 +0000 (00:00 +0000)]
Automatic date update in version.in
Jon Turney [Wed, 2 Nov 2022 13:16:16 +0000 (13:16 +0000)]
Fix Cygwin build after
02d04eac
Commit
02d04eac "Use strwinerror in gdb/windows-nat.c" also moves
strwinerror() under the USE_WIN32API conditional, which is not defined
for Cygwin (and looks like it shouldn't be, as appears to imply
non-POSIX and MiNGW and WinSock...)
Also enable the declaration and definition of strwinerror() when
__CYGWIN__ is defined.
Jon Turney [Wed, 2 Nov 2022 14:32:55 +0000 (14:32 +0000)]
Drop apparently unneeded include of winsock2.h
Commit
d08bae3d ("Implement target async for Windows") unconditionally
includes winsock2.h. We don't want to do that on Cygwin, since
including both winsock2.h and sys/select.h causes incompatible
redefinition problems.
Since that include is apparently unneeded, just drop it.
Fixes: d08bae3d
GDB Administrator [Sun, 13 Nov 2022 00:00:30 +0000 (00:00 +0000)]
Automatic date update in version.in
Dimitar Dimitrov [Fri, 11 Nov 2022 18:14:13 +0000 (20:14 +0200)]
sim: pru: Fix behaviour when loop count is zero
If the counter for LOOP instruction is provided by a register with
value zero, then the instruction must cause a PC jump directly to the
loop end. But in that particular case simulator must not initialize
its internal loop variables, because loop body will not be executed.
Instead, simulator must obtain the loop's end address directly from
the LOOP instruction.
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
Alan Modra [Sat, 12 Nov 2022 00:10:13 +0000 (10:40 +1030)]
PowerPC64 paddi -Mraw
On a testcase like
pla 8,foo@pcrel
disassembled with -Mpower10 results in
0: 00 00 10 06 pla r8,0 # 0
4: 00 00 00 39
0: R_PPC64_PCREL34 foo
but with -Mpower10 -Mraw
0: 00 00 10 06 .long 0x6100000
0: R_PPC64_PCREL34 foo
4: 00 00 00 39 addi r8,0,0
The instruction is unrecognised due to the hack we have in
extract_pcrel0 in order to disassemble paddi with RA0=0 and R=1 as
pla. I could have just added "&& !(dialect & PPC_OPCODE_RAW)" to the
condition in extract_pcrel0 under which *invalid is set, but went for
this larger patch that reorders the extended insn pla to the more
usual place before its underlying machine insn. (la is after addi
because we never disassemble to la.)
gas/
* testsuite/gas/ppc/raw.d,
* testsuite/gas/ppc/raw.s: Add pla.
opcodes/
* ppc-opc.c (extract_pcrel1): Rename from extract_pcrel0 and
invert *invalid logic.
(PCREL1): Rename from PCREL0.
(prefix_opcodes): Sort pla before paddi, adjusting R operand
for pla, paddi and psubi.
Indu Bhagat [Sat, 12 Nov 2022 06:01:25 +0000 (22:01 -0800)]
libctf: use libtool for link test in configure
The configure check for ELF support in BFD uses the AC_TRY_LINK. If
libbfd's dependencies change, this macro will need to be updated
manually with explicit additions to LDFLAGS and LIBS.
This patch updates the check to use libtool instead.
ChangeLog:
* libctf/configure.ac: Use libtool instead.
* libctf/configure: Regenerated.
GDB Administrator [Sat, 12 Nov 2022 00:00:21 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Fri, 11 Nov 2022 12:58:35 +0000 (07:58 -0500)]
gdb: fix start breakpoint expression not working in some languages
Commit
0be837be9fb4 ("gdb: make "start" breakpoint inferior-specific")
regresses gdb.ada/start.exp:
(gdb) start
Error in expression, near `1'.
(gdb) UNTESTED: gdb.ada/start.exp: start failed to land inside the right procedure
This is because in Ada, the equality operator is =, not ==.
I checked the other languages supported by GDB, these other languages
use = for equality:
- Pascal: tests like gdb.pascal/hello.exp are affected too
- Modula-2: I tried building a Modula-2 hello world using gm2, but it
seems like the generated DWARF doesn't specify the Modula-2 language
in the CUs, it's C++ and C, so the selected language isn't
"modula-2". But if I manually do "set language modula-2" on a dummy
program and then "start", I get the same error.
Other languages all use ==.
So, a short term fix would be to use = or == in the expression, based on
the current language. If this was meant to be permanent, I would
suggest adding something like an "equality_operator" method to
language_defn, that returns the right equality operator for the
language. But the goal is to replace all this with proper
inferior-specific breakpoints, so I hope all this is temporary.
Approved-By: Tom de Vries <tdevries@suse.de>
Change-Id: Id4d38e14a80e6bbbb1ad2b2277f974dd55192969
Mike Frysinger [Fri, 11 Nov 2022 15:02:39 +0000 (22:02 +0700)]
sim: igen: cleanup archaic pointer-to-long printf casts
Use proper %p to printf a pointer instead of casting it to long and
using 0x%lx. It's cleaner, more correct, and doesn't break on LLP64.
Tom de Vries [Fri, 11 Nov 2022 14:52:10 +0000 (15:52 +0100)]
[gdb/testsuite] Don't timeout on prompt in gdb_start_cmd
We're currently running into a timeout at:
...
(gdb) start ^M
Error in expression, near `1'.^M
(gdb) UNTESTED: gdb.ada/start.exp: start failed to land inside the right \
procedure
...
due to the fact that gdb_start_cmd doesn't handle a prompt as reaction to
the start command.
Fix this by handling the prompt. Reduces execution time of the test-case from
1m1s to 1s.
Tested on x86_64-linux.
Tom de Vries [Fri, 11 Nov 2022 14:30:44 +0000 (15:30 +0100)]
[gdb/testsuite] Better error checking in has_hw_wp_support
With gdb 12.1, on powerpc64le I ran into ERRORs related to has_hw_wp_support
usage, which was already fixed on trunk by commits:
-
13f72372413 ("gdb/testsuite: fix gdb.base/break-idempotent.exp on ppc"), and
-
01a32ee0b8c ("PowerPC, fix gdb.base/watchpoint.exp on Power 9")
While looking into these ERRORs and the commits that fix them, it occurred to
me that while the commits fix the root cause, the failure mode is not great.
The test-cases expect a running instance of gdb upon return, which is not
there, so there's an long stream of ERRORs generated as a result.
Fix this at the start of has_hw_wp_support, by (instead of accomodating a
running gdb instance by calling gdb_exit), checking whether it's called
without a running gdb instance, and erroring out otherwise. This way, there's
just one error.
I also noticed that in case we do an early exit due to !runto_main, we don't
clean up, so copy the missing cleanups (gdb_exit and $obj file deletion) from
the regular exit.
Tested on x86_64-linux, using has_hw_wp_support for x86_64 in
skip_hw_watchpoint_tests.
Lancelot SIX [Mon, 7 Nov 2022 14:10:58 +0000 (14:10 +0000)]
gdb/py-inferior: Keep inferior threads in a map
The python code maintains a list of threads for each inferior. This
list is implemented as a linked list. When the number of threads grows
high, this implementation can begin to be a performance bottleneck as
finding a particular thread_object in the list has a complexity of O(N).
We see this in ROCgdb[1], a downstream port of GDB for AMDGUP. On
AMDGPU devices, the number of threads can get significantly higher than
on usual GDB workloads.
In some situations, we can reach the end of the inferior process with
GDB still having a substantial list of known threads. While running
target_mourn_inferior, we end up in inferior::clear_thread_list which
iterates over all remaining threads and marks each thread exited. This
fires the gdb::observers::thread_exit observer and eventually
py-inferior.c:set_thread_exited gets called. This function searches in
the linked list with poor performances.
This patch proposes to change the linked list that keeps the per
inferior_object list of thread_objects into a std::unordered_map. This
allows to have the search operation complexity be O(1) on average
instead of O(N).
With this patch, we can complete clear_thread_list in about 2.5 seconds
compared to 10 minutes without it.
Except for the performance change, no user visible change is expected.
Regression tested on Ubuntu-22.04 x86_64.
[1] https://github.com/ROCm-Developer-Tools/ROCgdb
Luis Machado [Tue, 25 Oct 2022 10:01:32 +0000 (11:01 +0100)]
Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr
PR gdb/29272
Investigating PR29272, it was mentioned a particular test used to work on
GDB 10, but it started failing with GDB 11 onwards. I tracked it down to
some displaced stepping improvements on commit
187b041e2514827b9d86190ed2471c4c7a352874.
In particular, one of the corner cases using copy_insn_closure_by_addr got
silently broken. It is hard to spot because it doesn't have any good tests
for it, and the situation is quite specific to the Arm target.
Essentially, the change from the displaced stepping improvements made it so
we could still invoke copy_insn_closure_by_addr correctly to return the
pointer to a copy_insn_closure, but it always returned nullptr due to
the order of the statements in displaced_step_buffer::prepare.
The way it is now, we first write the address of the displaced step buffer
to PC and then save the copy_insn_closure pointer.
The problem is that writing to PC for the Arm target requires figuring
out if the new PC is thumb mode or not.
With no copy_insn_closure data, the logic to determine the thumb mode
during displaced stepping doesn't work, and gives random results that
are difficult to track (SIGILL, SIGSEGV etc).
Fix this by reordering the PC write in displaced_step_buffer::prepare
and, for safety, add an assertion to
displaced_step_buffer::copy_insn_closure_by_addr so GDB stops right
when it sees this invalid situation. If this gets broken again in the
future, it will be easier to spot.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29272
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Felix Willgerodt [Thu, 10 Nov 2022 15:22:46 +0000 (16:22 +0100)]
gdb, btrace: Fix rn-dl-bind.exp for new icx remark.
When running the test with the latest Intel compiler:
Running gdb/gdb/testsuite/gdb.btrace/rn-dl-bind.exp ...
gdb compile failed, icpx: warning: treating 'c' input as 'c++' when
in C++ mode, this behavior is deprecated [-Wdeprecated]
The test doesn't seem to test something specifically for C++,
so I removed the C++ compilation option. Alternatively we could rename
rn-dl-bind.exp.c to rn-dl-bind.exp.cc.
Signed-off-by: Felix Willgerodt <felix.willgerodt@intel.com>
Bruno Larsen [Tue, 4 Oct 2022 17:02:31 +0000 (19:02 +0200)]
gdb/testsuite: disable gdb.cp/call-method-register.exp when not using gcc
The test gdb.cp/call-method-register.exp assumes that the class will be
placed on a register. However, this keyword has been deprecated since
C++11, and Clang, for instance, does not feel the need to follow it.
Since this test is not usable without this working, this commit marks
this test as untested.
Approved-by: Tom Tromey <tom@tromey.com>
Bruno Larsen [Tue, 4 Oct 2022 17:07:46 +0000 (19:07 +0200)]
gdb/testsuite: remove XFAIL on gdb.cp/temargs.exp
gdb.cp/temargs.exp last 2 tests always setup an XFAILs, despite checking
for old gcc versions. However, Clang does not fail in this test,
turning into XPASSes and slighty annoying when comparing between
compilers. To change this, make the xfails only happen if we using gcc.
Approved-by: Tom Tromey <tom@tromey.com>
Bruno Larsen [Thu, 29 Sep 2022 12:51:34 +0000 (14:51 +0200)]
gdb/testsuite: disable some tests of gdb.cp/typeid.exp when using Clang
Since Clang chooses to not add any debug information for base types,
expecting it to be included with libraries' informations, gdb.cp/typeid.exp
will always fail if the program hasn't started. This commit fixes that by
making it so when using Clang, the base type variables aren't tested.
Approved-by: Tom Tromey <tom@tromey.com>
Bruno Larsen [Thu, 29 Sep 2022 11:05:42 +0000 (13:05 +0200)]
gdb/testsuite: skip gdb.cp/anon-struct.exp when using Clang
When Clang compiles anonymous structures, it does not add linkage names in
their dwarf representations. This is compounded by Clang not adding linkage
names to subprograms of those anonymous structs (for instance, the
constructor). With these 2 things together, GDB is unable to refer to
any of them, so there is no way to pass any of the tests of
gdb.cp/anon-struct.exp
Since this isn't a bug on Clang or GDB according to the DWARF
specifications as DW_AT_name is optional for all DIEs, the test was marked
as untested.
Since I was already touching the file, I also added a comment at the top
of the file explaining what it is testing for.
Approved-by: Tom Tromey <tom@tromey.com>
Bruno Larsen [Fri, 9 Sep 2022 13:56:25 +0000 (15:56 +0200)]
gdb/testsuite: allow for Clang style destructors on gdb.cp/m-static.exp
when running gdb.cp/m-static.exp using Clang, we get the following
failures:
print test1.~gnu_obj_1^M
$6 = {void (gnu_obj_1 * const)} 0x555555555470 <gnu_obj_1::~gnu_obj_1()>^M
(gdb) FAIL: gdb.cp/m-static.exp: simple object instance, print destructor
ptype test1.~gnu_obj_1^M
type = void (gnu_obj_1 * const)^M
(gdb) FAIL: gdb.cp/m-static.exp: simple object instance, ptype destructor
print test1.'~gnu_obj_1'^M
$7 = {void (gnu_obj_1 * const)} 0x555555555470 <gnu_obj_1::~gnu_obj_1()>^M
(gdb) FAIL: gdb.cp/m-static.exp: simple object instance, print quoted destructor
This is because the test is expecting an extra integer parameter on the
destructor. Looking at the debuginfo, it seems that there is nothing
actually wrong with this output, so these tests were changed to test
multiple possible regexps.
Approved-by: Tom Tromey <tom@tromey.com>
Bruno Larsen [Thu, 8 Sep 2022 08:43:14 +0000 (10:43 +0200)]
gdb/testsuite: add XFAIL to gdb.cp/derivation.exp when using Clang
When running gdb.cp/derivation.exp using Clang, we get an unexpected
failure when printing the type of a class with an internal typedef. This
happens because Clang doesn't add accessibility information for typedefs
inside classes (see https://github.com/llvm/llvm-project/issues/57608
for more info). To help with Clang testing, an XFAIL was added to this
test.
Approved-by: Tom Tromey <tom@tromey.com>
Bruno Larsen [Wed, 7 Sep 2022 15:45:09 +0000 (17:45 +0200)]
gdb/testsuite: account for clang's nested destructor calls on gdb.cp/mb-ctor.exp
When compiling virtual classes's destructors, two versions are compiled,
one with a single parameter (this) and the other with 2 parameters (this
and vtt).
GCC's compilation makes it so either the version with 1
parameter or the one with 2 parameters is called, depending on whether
the destructor is being called by the class itself or by an inherited
class. On the test gdb.cp/mb-ctor.exp, this means that the breakpoint
set at the destructor will be hit 4 times.
Clang, on the other hand, makes the single-parameter version call the 2
parameter version, probably in an attempt to reduce the size of the
resulting executable. This means that the gdb.cp/mb-ctor.exp will hit 6
breakpoints before finishing, and is the reason why this test was
failing. To make this test stop failing, a compiler check is added and
another "continue" instruction is issued to account for this difference.
Approved-by: Tom Tromey <tom@tromey.com>
Bruno Larsen [Wed, 7 Sep 2022 13:48:08 +0000 (15:48 +0200)]
gdb/testsuite: enable running gdb.cp/classes.exp with clang
When attempting to run the gdb.cp/classes.exp test using Clang++, the
test fails to prepare with -Wnon-c-typedef-for-linkage like the
previously fixed gdb.cp/class2.exp. Upon fixing this, the test shows 5
unexpected failures. One such failures is:
ptype/r class class_with_public_typedef
type = class class_with_public_typedef {
private:
int a;
public:
class_with_public_typedef::INT b;
private:
typedef int INT;
}
(gdb) FAIL: gdb.cp/classes.exp: ptype class class_with_public_typedef // wrong access specifier for typedef: private
While g++ provided the following output:
ptype/r class class_with_public_typedef
type = class class_with_public_typedef {
private:
int a;
public:
class_with_public_typedef::INT b;
typedef int INT;
}
(gdb) PASS: gdb.cp/classes.exp: ptype class class_with_public_typedef
This error happens because Clang does not add DW_AT_accessibility to
typedefs inside classes, and without this information GDB defaults to
assuming the typedef is private. Since there is nothing that GDB can do
about this, these tests have been set as xfails, and Clang bug 57608 has
been filed.
Bug: https://github.com/llvm/llvm-project/issues/57608
Approved-by: Tom Tromey <tom@tromey.com>
Bruno Larsen [Wed, 7 Sep 2022 07:50:21 +0000 (09:50 +0200)]
gdb/testsuite: ignore Non-C-typedefs for gdb.cp/class2.exp
When attempting to test gdb.cp/class2.exp using Clang, it fails to
prepare with the following error:
Executing on host: clang++ -fdiagnostics-color=never -Wno-unknown-warning-option -c -g -o /home/blarsen/Documents/fsf_build/gdb/testsuite/outputs/gdb.cp/class2/class20.o /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc (timeout = 300)
builtin_spawn -ignore SIGHUP clang++ -fdiagnostics-color=never -Wno-unknown-warning-option -c -g -o /home/blarsen/Documents/fsf_build/gdb/testsuite/outputs/gdb.cp/class2/class20.o /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:53:14: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage]
typedef class {
^
Dbase
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:54:2: note: type is not C-compatible due to this member declaration
public:
^~~~~~~
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:58:3: note: type is given name 'Dbase' for linkage purposes by this typedef declaration
} Dbase;
^
1 warning generated.
gdb compile failed, /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:53:14: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage]
typedef class {
^
Dbase
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:54:2: note: type is not C-compatible due to this member declaration
public:
^~~~~~~
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:58:3: note: type is given name 'Dbase' for linkage purposes by this typedef declaration
} Dbase;
^
1 warning generated.
UNTESTED: gdb.cp/class2.exp: failed to prepare
This can be silenced by adding -Wno-non-c-typedef-for-linkage for Clang
11 or later. The test shows no failures with this change.
Approved-by: Tom Tromey <tom@tromey.com>
Jan Beulich [Fri, 11 Nov 2022 08:27:41 +0000 (09:27 +0100)]
gas: accept custom ".linefile <n> ."
While .linefile is generally intended for gas internal use only, its use
in a source file would better not result in an internal error. Give use
of it outside of any macro(-like) construct the meaning of restoring the
original (physical) input file name.
Jan Beulich [Fri, 11 Nov 2022 08:27:23 +0000 (09:27 +0100)]
x86: drop stray IsString from PadLock insns
The need for IsString on the PadLock insns went away with the
introduction of RepPrefixOk. Drop these leftovers.
Jan Beulich [Fri, 11 Nov 2022 08:26:25 +0000 (09:26 +0100)]
x86: drop duplicate sse4a entry from cpu_arch[]
Of the two instances the first is correct in using ANY_SSE4A as 3rd
argument to SUBARCH(), so drop the wrong/redundant/dead 2nd one.
Alan Modra [Fri, 11 Nov 2022 03:13:42 +0000 (13:43 +1030)]
PR28834, PR26946 sanity checking section size
This patch provides a new function to sanity check section sizes.
It's mostly extracted from what we had in bfd_get_full_section_contents
but also handles compressed debug sections.
Improvements are:
- section file offset is taken into account,
- added checks that a compressed section can be read from file.
The function is then used when handling multiple .debug_* sections
that need to be read into a single buffer, to sanity check sizes
before allocating the buffer.
PR 26946, PR 28834
* Makefile.am (LIBBFD_H_FILES): Add section.c.
* compress.c (bfd_get_full_section_contents): Move section size
sanity checks..
* section.c (_bfd_section_size_insane): ..to here. New function.
* dwarf2.c (read_section): Use _bfd_section_size_insane.
(_bfd_dwarf2_slurp_debug_info): Likewise.
* Makefile.in: Regenerate.
* libbfd.h: Regenerate.
Alan Modra [Thu, 10 Nov 2022 23:22:43 +0000 (09:52 +1030)]
Sanity check SHT_MIPS_OPTIONS size
* elfxx-mips.c (_bfd_mips_elf_section_from_shdr): Use
bfd_malloc_and_get_section to read contents of .MIPS.options.
Alan Modra [Fri, 11 Nov 2022 07:31:58 +0000 (18:01 +1030)]
Re: gold: add --compress-debug-sections=zstd [PR 29641]
Fix the following:
compressed_output.cc:86:8: error: assignment of read-only variable ‘size’
86 | size = ZSTD_compress(*compressed_data + header_size, size, uncompressed_data,
Fangrui Song [Fri, 11 Nov 2022 06:09:09 +0000 (22:09 -0800)]
gold: add --compress-debug-sections=zstd [PR 29641]
This option compresses output debug sections with zstd and sets ch_type
to ELFCOMPRESS_ZSTD. Latest gdb and lldb support ELFCOMPRESS_ZSTD.
There will be an error if zstd is not enabled at configure time.
error: --compress-debug-sections=zstd: gold is not built with zstd support