aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-11-18Fix deletion of FinishBreakpointsJohnson Sun4-1/+105
Currently, FinishBreakpoints are set at the return address of a frame based on the `finish' command, and are meant to be temporary breakpoints. However, they are not being cleaned up after use, as reported in PR python/18655. This was happening because the disposition of the breakpoint was not being set correctly. This commit fixes this issue by correctly setting the disposition in the post-stop hook of the breakpoint. It also adds a test to ensure this feature isn't regressed in the future. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18655
2022-11-18gdb: fix symtab.c build on 32 bit targetsSimon Marchi1-4/+4
When building on Ubuntu 22.04, gcc 12, x86-64 with -m32 and -O2, I get: CXX symtab.o /home/smarchi/src/binutils-gdb/gdb/symtab.c: In member function ‘std::vector<symbol_search> global_symbol_searcher::search() const’: /home/smarchi/src/binutils-gdb/gdb/symtab.c:4961:44: error: ‘__builtin___sprintf_chk’ may write a terminating nul past the end of the destination [-Werror=format-overflow=] 4961 | sprintf (tmp, "operator%.*s%s", fix, " ", opname); | ^ In file included from /usr/include/stdio.h:894, from ../gnulib/import/stdio.h:43, from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/common-defs.h:86, from /home/smarchi/src/binutils-gdb/gdb/defs.h:28, from /home/smarchi/src/binutils-gdb/gdb/symtab.c:20: In function ‘int sprintf(char*, const char*, ...)’, inlined from ‘std::vector<symbol_search> global_symbol_searcher::search() const’ at /home/smarchi/src/binutils-gdb/gdb/symtab.c:4961:16: /usr/include/i386-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 9 and 2147483648 bytes into a destination of size 2147483647 38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, | ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 39 | __glibc_objsize (__s), __fmt, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 40 | __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~ PR build/29798 shows a similar error message but on Solaris. Work around that by using string_printf. It is a good thing to get rid of the alloca anyway. Change-Id: Ifbac11fee3062ad7f134d596b4e2229dc5d166f9 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29798
2022-11-18gdb/testsuite: rewrite gdb.cp/call-method-register.exp with dwarf assemblerAndrew Burgess2-76/+80
Convert the gdb.cp/call-method-register.exp test to make use of the DWARF assembler. The existing gdb.cp/call-method-register.exp test relies on a GCC extension - forcing a local variable into a particular named register. This means that the test will only work with Clang, and, as we have to name the register into which the variable will be placed, will only work for those targets where we've selected a suitable register, currently this is x86-64, i386, and ppc64. By switching to the DWARF assembler, the test will work with gcc and clang, and should work on most, if not all, architectures. The test creates a small structure, something that can fit within a register, and then tries to call a method on the structure from within GDB. This should fail because GDB can't take the address of the in register structure (for the `this` pointer). As the test is for a failure case, then we don't really care _which_ register the structure is in, and I take advantage of this for the DWARF assembler test, I just declare that the variable is in DW_OP_reg0, whatever that might be. I've tested the new test on x86-64, ppc, aarch64, and risc-v, and the test runs, and passes on all these architectures, which is already more than we used to cover. Additionally, on x86-64, I've tested with Clang and gcc, and the test runs and passed with both compilers. Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
2022-11-18gdb/testsuite: fix gdb.debuginfod/fetch_src_and_symbols.exp with ClangAndrew Burgess2-2/+10
The gdb.debuginfod/fetch_src_and_symbols.exp test is showing a single failure when run with some older versions of Clang, e.g. 9.0.1. The problem appears to be with Clang's generated line table. The test source looks like this: int main() { asm ("main_label: .globl main_label"); return 0; } In GDB, when we 'start', we expect to stop at the 'return 0;' line. This is the behaviour when the compiler is gcc, or later versions of Clang. However, with Clang 9.0.2, I see GDB stop on the 'asm' line. In this commit I'll fix this issue by placing a breakpoint on the return line, and then using gdb_continue_to_breakpoint to ensure we have stopped in the correct place. Of course, using gdb_continue_to_breakpoint will only work if we are not already stopped at the breakpoint location, so I've added some filler work before the 'return 0;' line. With this done we can use gdb_continue_to_breakpoint in all cases. As a result of adding the new filler work, one of the later tests, that used the 'list' command, no longer see the correct expected output (the top line of the source file is no longer included in the output). I've fixed this by listing a known specific line, the test is checking that GDB managed to find the source file, it doesn't matter which source line we list, as long as we can list something.
2022-11-18gdb/testsuite: rename source file gdb.debuginfod/main.cAndrew Burgess2-1/+1
The test gdb.debuginfod/fetch_src_and_symbols.exp uses a source file named main.c. I can't see any particular reason why the file is named as such. Usually test source files are named after the test script. This commit just renames the source file inline with the test script, and updates the call to standard_testfile (removing the reference to main.c). There's no particular reason for this change other than seeing the file named main.c made me thing that the source file must be shared with some other test (it isn't). There should be no change in what is tested after this commit.
2022-11-18gdb/testsuite: add (and use) a new build-id compile optionAndrew Burgess2-2/+11
I noticed that the gdb.debuginfod/fetch_src_and_symbols.exp test was failing when run with Clang as the compiler. This test relies on the compiled binaries having a build-id within them. For GCC, really GNU ld, the default is to always include a build-id. When compiling with Clang though, the default is for no build-id. I did consider *always* turning on the build-id feature when the compiler is Clang, but that felt a little weird. Instead, I propose that we add a new 'build-id' compiler option to gdb_compile, this flag indicates that the test _requires_ a build-id. In gcc_compile we can then add the required flags if the compiler is Clang so that we do get a build-id. With this change the gdb.debuginfod/fetch_src_and_symbols.exp test now (mostly) passes with Clang 9.0.1 and 15.0.2, and still passes with gcc. The 'mostly' part is an unrelated issue, and will be addressed in a later commit in this series. Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
2022-11-18gdb/testsuite: fix gdb.compile/compile-ops.exp with clangAndrew Burgess2-11/+15
I noticed that the gdb.compile/compile-ops.exp test was failing when run with Clang as the compiler. This test makes use of the DWARF assembler, and, it turns out, uses a technique which is not portable to Clang. This problem is described in the comment on the function_range proc in lib/dwarf.exp, the explanation is: # If the compiler is gcc, we can do the following to get function start # and end address too: # # asm ("func_start: .globl func_start"); # static void func (void) {} # asm ("func_end: .globl func_end"); # # however, this isn't portable, because other compilers, such as clang, # may not guarantee the order of global asms and function. The code # becomes: # # asm ("func_start: .globl func_start"); # asm ("func_end: .globl func_end"); # static void func (void) {} These start/end labels are used for computing the function start, end, and length. The portable solution is to place a label within the function, like this: # int main (void) # { # asm ("main_label: .globl main_label"); # return 0; # } And make use of 'proc function_range' (from lib/dwarf.exp). So, that's what I do in this commit. One consequence of this change is that we need to compile the source file, and have it loaded into a GDB session, before calling function_range, so I've added an early call to prepare_for_testing. Additionally, this test script was generating the DWARF assembler into a file called gdbjit-ops.S, I suspect a copy and paste issue there, so I've switched this to use compile-ops-dbg.S instead, which is more inline with what other DWARF assembler tests do. The only other change, which might be a problem, is that I also deleted these two lines from the source file: asm (".section \".text\""); asm (".balign 8"); These lines were setting the alignment of the .text section. What I don't know is whether this was significant or not. If it is significant, then I can't see why. On x86-64, the test still passes fine without these lines, but that doesn't mean the test wont start failing on some other architecture. Still, I figure, lets remove them, then, if/when we find a test that starts failing, we can add the lines back, along with an explanation for why the extra alignment is required. But, if people would prefer to be more conservative, then I'm happy to just add the lines back. Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
2022-11-18gdb/testsuite: fix gdb.trace/unavailable-dwarf-piece.exp with ClangAndrew Burgess1-2/+2
I noticed that the test gdb.trace/unavailable-dwarf-piece.exp was failing when run with Clang. Or rather, the test was not running as the test executable failed to compile. The problem is that Clang was emitting this warning: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument] This warning is emitted when compiling the assembler file generated by the DWARF assembler. Most DWARF assembler tests generate the assembler file into a file with the '.S' extension. However, this particular test uses a '.s' extension. Now a .S file will be passed through the preprocessor, while a .s will be sent straight to the assembler. My guess is that Clang doesn't support the -fdiagnostics-color=never option for the assembler, but does for the preprocessor. That's a little annoying, but easily worked around. We don't care if our assembler file is passed through the preprocessor, so, in this commit, I just change the file extension from .s to .S, and the problem is fixed. Currently, the unavailable-dwarf-piece.exp script names the assembler file using standard_output_file, in this commit I've switched to make use of standard_testfile, as that seems to be the more common way of doing this sort of thing. With these changes the test now passes with Clang 9.0.1 and 15.0.2, and also still passes with gcc. Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
2022-11-18gdb/testsuite: don't avoid DWARF assembler tests with ClangAndrew Burgess2-11/+0
Two tests make the claim that the DWARF assembler requires gcc, however, this isn't true. I think at one point, when the DWARF assembler was first added, we did use some techniques that were not portable (see the comments in lib/dwarf.exp on function_range for details), however, I think most DWARF assembler tests will now work fine with Clang. The two tests that I modify in this commit both work fine with Clang, at least, I've tested with Clang 9.0.1 and 15.0.2, and don't see any problems, so I'm removing the early return logic that stops these tests from running with Clang. Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
2022-11-18GAS fix alignment for aarch64-peZac Walker1-0/+3
Fixes issue where various values of '.align' causes writing of COFF files to fail. Specific to the aarch64-pe target.
2022-11-18PR29799 heap buffer overflow in display_gdb_index dwarf.c:10548Alan Modra1-1/+1
PR 29799 * dwarf.c (display_gdb_index): Typo fix.
2022-11-18go32 sanity checkAlan Modra1-0/+4
* coff-stgo32 (go32exe_check_format): Sanity check stubsize against filesize before malloc.
2022-11-18Regen potfiles for sframeAlan Modra2-0/+4
2022-11-18Automatic date update in version.inGDB Administrator1-1/+1
2022-11-17[gas, aarch64]: fix build breakage for aarch64-peIndu Bhagat1-19/+22
SFrame is supported for ELF only. Keep the definitions and declarations guarded with OBJ_ELF consistently. ChangeLog: * gas/config/tc-aarch64.h: Guard SFrame related definitions with OBJ_ELF.
2022-11-17Fix static initialization order problem in windows-nat.cTom Tromey1-3/+6
This patch fixes a static initialization order problem in windows-nat.c that was pointed out by Jon Turney. The underlying problem is that the windows_nat_target constructor relies on serial_logfile already being constructed, but this is not enforced by C++ rules. This patch fixes the problem by initializing the global windows_nat_target later.
2022-11-17opcodes: Define NoSuf in i386-opc.tblH.J. Lu1-1847/+1848
Use NoSuf to replace No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf and add the explicit NoSuf to AddrPrefixOpReg in templates. * i386-opc.tbl (NoSuf): New macro. (AddrPrefixOpReg): Remove No_?Suf. Replace No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf with NoSuf in templates. Add NoSuf to AddrPrefixOpReg in templates.
2022-11-17i386: Move i386_seg_prefixes to gasH.J. Lu3-11/+10
gas/ * config/tc-i386.c (i386_seg_prefixes): New. Moved from opcodes. opcodes/ * i386-opc.c (i386_seg_prefixes): Removed. * i386-opc.h (i386_seg_prefixes): Likewise.
2022-11-17PowerPC, fix gdb.base/retval-large-struct.expCarl Love1-1/+7
Support for printining non-trivial return values was recently added in 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. The functionality can now be used to fix gdb.base/retval-large-struct.exp. The test just needs to be compiled with -fvar-tracking to enable GDB to determine the address off the return buffer when the function is called. The current output from the test: 34 return big_struct; (gdb) PASS: gdb.base/retval-large-struct.exp: continue to breakpoint: Break in print_large_struct finish warning: Cannot determine the function return value. Try compiling with -fvar-tracking. Run till exit from #0 return_large_struct () at binutils-gdb-current/gdb/testsuite/gdb.base/retval-large-struct.c:34 main (argc=1, argv=0x7fffffffcd58) at binutils-gdb-current/gdb/testsuite/gdb.base/retval-large-struct.c:44 44 return 0; Value returned has type: struct big_struct_t. Cannot determine contents (gdb) FAIL: gdb.base/retval-large-struct.exp: finish from return_large_struct testcase binutils-gdb-current/gdb/testsuite/gdb.base/retval-large-struct.exp completed in 1 seconds This patch adds the command line argument -fvar-tracking to enable gdb to determine the return vaule and thus fixing the test. Patch tested on Power 10 with no regressions.
2022-11-17Use boolean literals for pagination_enabledTom Tromey2-2/+2
I noticed a couple of spots that used '0' rather than 'false' when modifying pagination_enabled. This patch cleans these up.
2022-11-17Change NULL to nullptr in gdb/infcmd.c and gdb/infrun.cCarl Love2-142/+142
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.
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.