aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-11-15libsframe: add the SFrame libraryWeimin Pan30-7/+21577
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.
2022-11-15gas: testsuite: add new tests for SFrame unwind infoIndu Bhagat29-0/+533
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.
2022-11-15gas: generate .sframe from CFI directivesIndu Bhagat15-10/+1844
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.
2022-11-15gas: add new command line option --gsframeIndu Bhagat3-1/+18
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.
2022-11-15sframe.h: Add SFrame format definitionIndu Bhagat1-0/+303
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.
2022-11-16Re: [gas] arm: Add support for new unwinder directive ".pacspval".Alan Modra1-4/+5
* testsuite/gas/arm/ehabi-pacbti-m.d: Limit test to ELF.
2022-11-16aarch64-pe can't fill 16 bytes in section .textAlan Modra1-2/+6
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.
2022-11-15gdb/configure: regenerateJose E. Marchesi1-2/+4
The commit bbaabc767a4293492817a0840819aef2768cce90 introduced an incorrect thunk for the `configure' script. This patch regenerates configure by calling autoreconf.
2022-11-15gdb: use libtool in GDB_AC_CHECK_BFDJose E. Marchesi3-11/+1652
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>
2022-11-15Fix crash in ada_print_typeTom Tromey5-3/+114
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.
2022-11-15Add AMD znver4 processor supportTejas Joshi17-4057/+4265
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.
2022-11-15gdb/testsuite: get_set_option_choices: expect \r\n after each itemSimon Marchi1-2/+7
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
2022-11-15aarch64, testsuite: Fixed recently added cssc.dAndre Vieira1-7/+0
Fixed wrong paste in cssc.d. gas/ChangeLog: * testsuite/gas/aarch64/cssc.d: Removed duplicate head.
2022-11-15[gdb/testsuite] Normalize gdbserver path nameTom de Vries2-5/+4
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.
2022-11-15[gdb/testsuite] Fix gdb.base/jit-elf-so.exp for remote targetTom de Vries1-4/+7
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>
2022-11-15[gdb/testsuite] Fix gdb.base/jit-reader-exec.exp for remote targetTom de Vries1-5/+9
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>
2022-11-15[gdb/testsuite] Fix gdb.base/info-shared.exp for remote targetTom de Vries1-2/+9
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>
2022-11-15[gdb/testsuite] Fix gdb.base/solib-vanish.exp for remote targetTom de Vries1-4/+17
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>
2022-11-15[gdb/testsuite] Fix gdb.base/infcall-exec.exp for remote targetTom de Vries2-3/+55
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>
2022-11-15[gdb/testsuite] Fix gdb.base/print-file-var.exp for remote targetTom de Vries2-17/+29
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>
2022-11-15[gdb/testsuite] Add REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.expTom de Vries1-2/+27
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>
2022-11-15[gdb/testsuite] Fix gdb.base/info_sources_2.exp for remote targetTom de Vries1-0/+12
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.
2022-11-15[gdb/testsuite] Fix gdb.base/foll-exec.exp for remote targetTom de Vries3-0/+12
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.
2022-11-15[gdb/testssuite] Skip aarch64 in skip_gdbserver_test if no xml supportTom de Vries1-0/+1
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>
2022-11-15Enable multi-process debugging for AIXAditya Vidyadhar Kamath1-7/+174
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.
2022-11-15Automatic date update in version.inGDB Administrator1-1/+1
2022-11-14PowerPC, fix support for printing the function return value for non-trivial ↵Carl Love13-14/+172
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.
2022-11-14PowerPC, function ppc64_sysv_abi_return_value add missing return value ↵Carl Love1-0/+4
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.
2022-11-14Remove dump_prefix_expressionTom Tromey4-10/+8
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.
2022-11-14aarch64: Add support for Common Short Sequence Compression extensionAndre Vieira11-50/+511
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.
2022-11-14x86: fold special-operand insn attributes into a single enumJan Beulich5-11231/+11222
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).
2022-11-14pru: bfd: Correct default to no execstackDimitar Dimitrov2-0/+3
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>
2022-11-14[gas] arm: Add support for new unwinder directive ".pacspval".Srinath Parvathaneni4-0/+76
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.
2022-11-14[readelf] arm: Support for new pacbti unwind opcode 0xb5.Srinath Parvathaneni1-0/+2
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.
2022-11-14gdb/unittests: PR28413, suppress warnings generated by GnulibTsukasa OI1-0/+11
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
2022-11-14arm: Add support for Cortex-X1C CPU.Srinath Parvathaneni5-0/+13
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.
2022-11-14[gdb/testsuite] Run gdb.arch/ppc64-symtab-cordic.exp for --enable-targets=allTom de Vries1-8/+4
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.
2022-11-14[gdb/testsuite] Handle with_set archTom de Vries1-2/+20
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.
2022-11-14[gdb/testsuite] Set completions to unlimited in get_set_option_choicesTom de Vries2-29/+35
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.
2022-11-14Re: objcopy renaming section with explicit flagsAlan Modra1-0/+1
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.
2022-11-14objcopy renaming section with explicit flagsAlan Modra6-14/+26
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.
2022-11-14Automatic date update in version.inGDB Administrator1-1/+1
2022-11-13Fix Cygwin build after 02d04eacJon Turney2-3/+3
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.
2022-11-13Drop apparently unneeded include of winsock2.hJon Turney1-1/+0
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
2022-11-13Automatic date update in version.inGDB Administrator1-1/+1
2022-11-12sim: pru: Fix behaviour when loop count is zeroDimitar Dimitrov2-2/+43
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>
2022-11-12PowerPC64 paddi -MrawAlan Modra3-10/+13
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.
2022-11-11libctf: use libtool for link test in configureIndu Bhagat2-0/+1368
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.
2022-11-12Automatic date update in version.inGDB Administrator1-1/+1
2022-11-11gdb: fix start breakpoint expression not working in some languagesSimon Marchi1-2/+7
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