aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-11-17ld: Always call elf_backend_output_arch_local_symsH.J. Lu5-2/+47
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.
2022-11-17gdb: new $_inferior_thread_count convenience variableAndrew Burgess6-2/+66
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.
2022-11-17Remove two obsolete declarationsTom Tromey1-4/+0
I happened to find a couple of obsolete declarations in cli-interp.h. This patch removes them. Tested by rebuilding.
2022-11-17gdb/testsuite: fix failure in gdb.python/py-send-packet.expAndrew Burgess1-3/+3
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.
2022-11-17Fix call functions command bug in 64 bits programs for AIXAditya Vidyadhar Kamath1-1/+9
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.
2022-11-17gdb/fortran/testsuite: print values and types of string variablesAndrew Burgess2-0/+107
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.
2022-11-17Fix various procfs.c compilation errorsRainer Orth1-15/+9
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: ‘int procfs_target::auxv_parse(gdb_byte**, gdb_byte*, CORE_ADDR*, CORE_ADDR*)’ marked ‘override’, 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 ‘void dead_procinfo(procinfo*, const char*, int)’: /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:563:11: warning: the address of ‘procinfo::pathname’ will never be NULL [-Waddress] 563 | if (pi->pathname) | ~~~~^~~~~~~~ /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:238:8: note: ‘procinfo::pathname’ 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 ‘virtual void procfs_target::create_inferior(const char*, const std::string&, char**, int)’: /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:2815:19: warning: ‘char* std::strncpy(char*, const char*, size_t)’ 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 ‘int find_memory_regions_callback(prmap*, find_memory_region_ftype, void*)’: /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>
2022-11-17RISC-V: Add T-Head Int vendor extensionChristoph Müllner8-1/+38
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>
2022-11-17RISC-V: Add T-Head Fmv vendor extensionChristoph Müllner8-3/+40
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>
2022-11-17[gdb/testsuite] Fix DUPLICATE in gdb.arch/ppc-fp.expTom de Vries1-2/+2
I noticed: ... DUPLICATE: gdb.arch/ppc-fp.exp: next ... Fix this by adding unique test names. Tested on powerpc64le-linux.
2022-11-17Automatic date update in version.inGDB Administrator1-1/+1
2022-11-17Add myself to the gdb/MAINTAINERS write-after-approval listKévin Le Gouguec1-0/+1
2022-11-17Guard against frame.c destructors running before frame-info.c'sKévin Le Gouguec1-1/+5
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>
2022-11-16PR29788, gprofng cannot display Java's generated assembly codeVladimir Mezentsev2-6/+7
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.
2022-11-16[gdb/testsuite] Use gdb_gcore_cmd in gdb.threads/gcore-thread.expTom de Vries1-1/+1
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.
2022-11-16Bug fix in commit for printing the function return value for non-trivial valuesCarl Love1-14/+16
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.
2022-11-16Update Ada tasks documentationTom Tromey1-1/+13
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.
2022-11-16gdb: add "set style tui-current-position on|off", default to offPedro Alves7-5/+83
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.
2022-11-16[gdb/testsuite] Modernize gdb.arch/i386-biarch-core.expTom de Vries2-26/+21
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.
2022-11-16[gdb/testsuite] Fix gdb.arch/ppc64-symtab-cordic.exp without bzip2Tom de Vries3-8/+32
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.
2022-11-16Automatic date update in version.inGDB Administrator1-1/+1
2022-11-15doc: add SFrame spec fileIndu Bhagat6-51/+1137
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.
2022-11-15gas/NEWS: add text about new command line option and SFrame supportIndu Bhagat1-0/+3
ChangeLog: * gas/NEWS: Add SFrame related news.
2022-11-15binutils/NEWS: add text for SFrame supportIndu Bhagat1-0/+3
ChangeLog: * binutils/NEWS: Add item for SFrame support.
2022-11-15src-release.sh: Add libsframeIndu Bhagat1-2/+2
Add libsframe to the list of top level directories that will be included in a release. ChangeLog: * src-release.sh: Add libsframe
2022-11-15readelf/objdump: support for SFrame sectionIndu Bhagat10-11/+355
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.
2022-11-15bfd: linker: merge .sframe sectionsIndu Bhagat43-24/+1595
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.
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.
generated by cgit v1.1 at 2024-10-14 23:42:18 +0000