aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-06-28RISC-V: Add 'Smstateen' extension and its CSRsTsukasa OI14-0/+568
This commit adds State Enable Extension (Smstateen) and its CSRs. bfd/ChangeLog: * elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Smstateen' extension to valid 'S' extension list. gas/ChangeLog: * config/tc-riscv.c (enum riscv_csr_class): Add CSR classes for 'Smstateen' extension. (riscv_csr_address): Add handling for new CSR classes. * testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs. * testsuite/gas/riscv/csr-dw-regnums.d: Likewise. * testsuite/gas/riscv/csr.s: Add new CSRs. * testsuite/gas/riscv/csr-version-1p9p1.d: Likewise. * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise. * testsuite/gas/riscv/csr-version-1p10.d: Likewise. * testsuite/gas/riscv/csr-version-1p10.l: Likewise. * testsuite/gas/riscv/csr-version-1p11.d: Likewise. * testsuite/gas/riscv/csr-version-1p11.l: Likewise. * testsuite/gas/riscv/csr-version-1p12.d: Likewise. * testsuite/gas/riscv/csr-version-1p12.l: Likewise. include/ChangeLog: * opcode/riscv-opc.h (CSR_MSTATEEN0, CSR_MSTATEEN1, CSR_MSTATEEN2, CSR_MSTATEEN3, CSR_SSTATEEN0, CSR_SSTATEEN1, CSR_SSTATEEN2, CSR_SSTATEEN3, CSR_HSTATEEN0, CSR_HSTATEEN1, CSR_HSTATEEN2, CSR_HSTATEEN3, CSR_MSTATEEN0H, CSR_MSTATEEN1H, CSR_MSTATEEN2H, CSR_MSTATEEN3H, CSR_HSTATEEN0H, CSR_HSTATEEN1H, CSR_HSTATEEN2H, CSR_HSTATEEN3H): New CSR macros.
2022-06-28RISC-V: Add new CSR feature gate handling (RV32,H)Tsukasa OI1-4/+7
To support feature gate like Smstateen && H, this commit adds certain CSR feature gate handling. It also changes how RV32-only CSRs are handled for cleanliness. gas/ChangeLog: * config/tc-riscv.c (riscv_csr_address): Add CSR feature gate handling for H. Change handling on RV32.
2022-06-28Re: Disable execstack and rwx segments warnings for MIPS targets.Alan Modra2-3/+3
PR 29263 * configure.ac: Fix typo. * testsuite/ld-elf/elf.exp: Add mips to targets that need --warn-execstack to pass first pr29072 test.
2022-06-28Automatic date update in version.inGDB Administrator1-1/+1
2022-06-27gdb/testsuite: update bug numbers from Gnats to bugzillaBruno Larsen2-11/+11
Some tests link to outdated bug numbers when an XFAIL or a KFAIL happen. gdb.base/macscp.exp was referencing bug number 555, and the bug 7660 mentions that it used to be 555 on the Gnats system and seems to relate to the issue at hand. gdb.base/annota1.exp was referencing bug number 1270, and bug 8375 mentions being number 1270 on Gnats, and mentions annota1 specifically, so it seemed pretty obvious.
2022-06-27[gdb/build] Fix build breaker with --enable-sharedTom de Vries2-4/+12
When building gdb with --enable-shared, I run into: ... ld: build/zlib/libz.a(libz_a-inffast.o): relocation R_X86_64_32S against \ `.rodata' can not be used when making a shared object; recompile with -fPIC ld: build/zlib/libz.a(libz_a-inflate.o): warning: relocation against \ `inflateResetKeep' in read-only section `.text' collect2: error: ld returned 1 exit status make[3]: *** [libbfd.la] Error 1 ... This is a regression since commit a08bdb159bb ("[gdb/build] Fix gdbserver build with -fsanitize=thread"). The problem is that a single case statement in configure is shared to handle special requirements for both the host libiberty and host zlib, which has the effect that only one is handled. Fix this by handling libiberty and zlib each in its own case statement. Build on x86_64-linux, with and without --enable-shared. ChangeLog: 2022-06-27 Tom de Vries <tdevries@suse.de> * configure.ac: Set extra_host_libiberty_configure_flags and extra_host_zlib_configure_flags in separate case statements. * configure: Regenerate.
2022-06-27Make GDBserver abort on internal error in development modePedro Alves4-3/+43
Currently, if GDBserver hits some internal assertion, it exits with error status, instead of aborting. This makes it harder to debug GDBserver, as you can't just debug a core file if GDBserver fails an assertion. I've had to hack the code to make GDBserver abort to debug something several times before. I believe the reason it exits instead of aborting, is to prevent potentially littering the filesystem of smaller embedded targets with core files. I think I recall Daniel Jacobowitz once saying that many years ago, but I can't be sure. Anyhow, that seems reasonable to me. Since we nowadays have a distinction between development and release modes, I propose to make GDBserver abort on internal error if in development mode, while keeping the status quo when in release mode. Thus, after this patch, in development mode, you get: $ ../gdbserver/gdbserver ../../src/gdbserver/server.cc:3711: A problem internal to GDBserver has been detected. captured_main: Assertion `0' failed. Aborted (core dumped) $ while in release mode, you'll continue to get: $ ../gdbserver/gdbserver ../../src/gdbserver/server.cc:3711: A problem internal to GDBserver has been detected. captured_main: Assertion `0' failed. $ echo $? 1 I do not think that this requires a separate configure switch. A "--target_board=native-extended-gdbserver" run on Ubuntu 20.04 ends up with: === gdb Summary === # of unexpected core files 29 ... for me, of which 8 are GDBserver core dumps, 7 more than without this patch. Change-Id: I6861e08ad71f65a0332c91ec95ca001d130b0e9d
2022-06-27Replace a run-time assertion failure with a warning message when parsing ↵Nick Clifton2-1/+12
corrupt DWARF data. PR 29289 * dwarf.c (display_debug_names): Replace assert with a warning message.
2022-06-27Fix NULL pointer indirection when parsing corrupt DWARF data.Nick Clifton2-6/+12
PR 29290 * dwarf.c (read_and_display_attr_value): Check that debug_info_p is set before dereferencing it.
2022-06-27Have gold's File_read::do_read() function check the start parameterNick Clifton2-0/+12
PR 23765 * fileread.cc (File_read::do_read): Check start parameter before computing number of bytes to read.
2022-06-27gdb/arm: Unwind Non-Secure callbacks from SecureYvan Roux1-30/+84
Without this changeset, the unwinding doesn't take into account Non-Secure to Secure stack unwinding enablement status and doesn't choose the proper SP to do the unwinding. This patch only unwinds the stack when Non-Secure to Secure unwinding is enabled, previous SP is set w/r to the current mode (Handler -> msp_s, Thread -> psp_s) and then the Secure stack is unwound. Ensure thumb bit is set in PSR when needed. Also, drop thumb bit from PC if set. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> Signed-off-by: Yvan ROUX <yvan.roux@foss.st.com>
2022-06-27Stop bogus warnings about DWARF indexed string offsets being too big.Nick Clifton3-75/+26
* dwarf.c (fetch_indexed_string): Do not use length of first table in string section as the length of every table in the section. * testsuite/binutils-all/pr26112.r: Update expected output.
2022-06-27[gdb/testsuite] Handle older python in gdb.python/py-send-packet.pyTom de Vries1-2/+6
With python 3.4, I run into: ... Traceback (most recent call last):^M File "<string>", line 1, in <module>^M File "outputs/gdb.python/py-send-packet/py-send-packet.py", line 128, in \ run_set_global_var_test^M res = conn.send_packet(b"X%x,4:\x02\x02\x02\x02" % addr)^M TypeError: Could not convert Python object: b'X%x,4:\x02\x02\x02\x02'.^M Error while executing Python code.^M ... while with python 3.6 this works fine. The type of addr is <class 'gdb.Value'>, so the first thing to try is whether changing it into a string works: ... addr_str = "%x" % addr res = conn.send_packet(b"X%s,4:\x02\x02\x02\x02" % addr_str) ... which gets us the more detailed: ... TypeError: unsupported operand type(s) for %: 'bytes' and 'str' ... Fix this by avoiding the '%' operator in the byte literal, and use instead: ... def xpacket_header (addr): return ("X%x,4:" % addr).encode('ascii') ... res = conn.send_packet(xpacket_header(addr) + b"\x02\x02\x02\x02") ... Tested on x86_64-linux, with python 3.4 and 3.6, and a backported version was tested on the gdb-12-branch in combination with python 2.7.
2022-06-27[gdb/testsuite] Fix gdb.reverse/i387-env-reverse.exp for -pieTom de Vries1-1/+1
When running test-case gdb.reverse/i387-env-reverse.exp for x86_64-linux with target board unix/-m32/-fPIE/-pie, we run into: ... (gdb) PASS: gdb.reverse/i387-env-reverse.exp: push st0 info register eax^M eax 0x56550000 1448411136^M (gdb) FAIL: gdb.reverse/i387-env-reverse.exp: verify eax == 0x8040000 ... The problem is that the tested instruction (fstsw) only sets $ax, not $eax. Fix this by verifying $ax instead of $eax. Tested on x86_64-linux with target boards unix/-m32 and unix/-m32/-fPIE/-pie.
2022-06-27[gdb/testsuite] Enable some test-cases for x86_64 -m32Tom de Vries4-173/+166
When trying to run test-case gdb.reverse/i387-env-reverse.exp for x86_64-linux with target board unix/-m32, it's skipped. Fix this by using is_x86_like_target instead of istarget "i?86-*linux*". This exposes a number of duplicates, fix those by making the test names unique. Likewise in a couple of other test-cases. Tested on x86_64-linux with target boards unix/-m32.
2022-06-27[gdb/testsuite] Workaround unnecessary .s file with gfortran 4.8Tom de Vries1-0/+6
After running test-case gdb.fortran/namelist.exp with gfortran 4.8.5, I'm left with: ... $ git sti On branch master Your branch is up to date with 'origin/master'. Untracked files: (use "git add <file>..." to include in what will be committed) gdb/testsuite/lib/compiler.s nothing added to commit but untracked files present (use "git add" to track) ... We're running into PR gcc/60447, which was fixed in gcc 4.9.0. Workaround this by first copying the source file to the temp dir, such that the .s file is left there instead: ... $ ls build/gdb/testsuite/temp/<runtest pid>/ compiler.c compiler.F90 compiler.s ... Tested on x86_64-linux.
2022-06-27[gdb/testsuite] Skip gdb.fortran/namelist.exp for gfortran 4.8Tom de Vries2-4/+12
The test-case gdb.fortran/namelist.exp uses a gfortran feature (emitting DW_TAG_namelist in the debug info) that has been supported since gfortran 4.9, see PR gcc/37132. Skip the test for gfortran 4.8 and earlier. Do this using gcc_major_version, and update it to be able to handle "gcc_major_version {gfortran-*} f90". Tested on x86_64-linux, with gfortran 4.8.5, 7.5.0, and 12.1.1.
2022-06-27[gdb/symtab] Fix parsing of .debug_str_offsets headerTom de Vries1-7/+57
When running test-case gdb.dwarf2/fission-mix.exp with target board dwarf64 and gcc-12 (defaulting to DWARF5), I run into: ... (gdb) break func2^M Offset from DW_FORM_GNU_str_index or DW_FORM_strx pointing outside of \ .debug_str.dwo section in CU at offset 0x0 [in module fission-mix]^M (gdb) FAIL: gdb.dwarf2/fission-mix.exp: break func2 ... The .debug_str_offsets section has version 5, so as per the standard it has it's own header, with initial length and version: ... Contents of the .debug_str_offsets.dwo section (loaded from fission-mix2.dwo): Length: 0x1c Version: 0x5 Index Offset [String] 0 0 build/gdb/testsuite 1 33 GNU C17 2 8f src/gdb/testsuite/gdb.dwarf2/fission-mix-2.c ... But when trying to read the string offset at index 0 in the table (which is 0), we start reading at offset 8, which points in the header, at the last 4 bytes of the initial length (it's 12 bytes because of 64-bit dwarf), as well at the 2-byte version field and 2 bytes of padding, so we get: ... (gdb) p /x str_offset $1 = 0x500000000 ... which indeed is an offset that doesn't fit in the .debug_str section. The offset 8 is based on reader->cu->header.addr_size: ... static const char * read_dwo_str_index (const struct die_reader_specs *reader, ULONGEST str_index) { ULONGEST str_offsets_base = reader->cu->header.version >= 5 ? reader->cu->header.addr_size : 0; ... which doesn't in look in agreement with the standard. Note that this happens to give the right answer for 32-bit dwarf and addr_size == 8, because then we have header size == (initial length (4) + version (2) + padding (2)) == 8. Conversely, for 32-bit dwarf and addr_size == 4 (target board unix/-m32) we run into a similar problem. It just happens to not trigger the warning, instead we get the wrong strings, like "func2" for DW_AT_producer and "build/gdb/testsuite" for DW_AT_name of the DW_TAG_compile_unit DIE. Fix this by parsing the .debug_str_offsets header in read_dwo_str_index. Add a FIXME that we should not parse this for every call. Tested on x86_64-linux.
2022-06-27[gdb/build] Fix gdbserver build with -fsanitize=threadTom de Vries2-2/+2
[ Copied from gcc commit 153689603fd ("[gdb/build] Fix gdbserver build with -fsanitize=thread"). ] When building gdbserver with -fsanitize=thread (added to CFLAGS/CXXFLAGS) we run into: ... ld: ../libiberty/libiberty.a(safe-ctype.o): warning: relocation against \ `__tsan_init' in read-only section `.text' ld: ../libiberty/libiberty.a(safe-ctype.o): relocation R_X86_64_PC32 \ against symbol `__tsan_init' can not be used when making a shared object; \ recompile with -fPIC ld: final link failed: bad value collect2: error: ld returned 1 exit status make[1]: *** [libinproctrace.so] Error 1 ... which looks similar to what is described in commit 78e49486944 ("[gdb/build] Fix gdbserver build with -fsanitize=address"). The gdbserver component builds a shared library libinproctrace.so, which uses libiberty and therefore requires the pic variant. The gdbserver Makefile is setup to use this variant, if available, but it's not there. Fix this by listing gdbserver in the toplevel configure alongside libcc1, as a component that needs the libiberty pic variant, setting: ... extra_host_libiberty_configure_flags=--enable-shared ... Tested on x86_64-linux. ChangeLog: 2022-06-27 Tom de Vries <tdevries@suse.de> * configure.ac: Build libiberty pic variant for gdbserver. * configure: Regenerate.
2022-06-27Disable execstack and rwx segments warnings for MIPS targets.Nick Clifton4-29/+48
PR 29263 * configure.ac: Move HPPA specific code from here... * configure.tgt: ... to here. Add similar code for MIPS. Move code for CRIS, MIPS and HPPA to block at start of file. * configure: Regenerate.
2022-06-27bfd: prune config.bfd's setting of targ_archsJan Beulich1-5/+1
The final "match all" case can take care of a few explicit entries: Purge those. Also move s12z* into proper position (the table is otherwise sorted, after all).
2022-06-27drop XC16x bitsJan Beulich107-18085/+7
Commit 04f096fb9e25 ("Move the xc16x target to the obsolete list") moved the architecture from the "obsolete but still available" to the "obsolete / support removed" list in config.bfd, making the architecture impossible to enable (except maybe via "enable everything" options"). Note that I didn't touch */po/*.po{,t} on the assumption that these would be updated by some (half)automatic means.
2022-06-27Fix location list offset address dump under DW_AT_location (dwarf-5)Bhuvanendra Kumar N1-12/+26
For clang compiled objects with dwarf-5, location list offset address dump under DW_AT_location is corrected, where DW_FORM_loclistx is used. While dumping the location list offset, the address dumped is wrong where it was refering to .debug_addr instead of .debug_loclists * dwarf.c (fetch_indexed_value): Add base_address as parameter and use it to access the section offset. (read_and_display_attr_value): Handle DW_FORM_loclistx form separately. Pass loclists_base to fetch_indexed_value().
2022-06-27PowerPC64 .branch_lt addressAlan Modra2-3/+3
.branch_lt is really an extension of .plt, as is .iplt. We'd like all of the PLT sections to be fixed relative to .TOC. after stub sizing, because changes in offset to PLT entries might mean a change in stub sizes. When -z relro, the relro layout does this by laying out sections from the end of the relro segment. So for example, a change in .eh_frame (which happens after stub sizing) will keep the same GOT to PLT offset when -z relro. Not so when -z norelro, because then the usual forward layout of section is done and .got is more aligned than .branch_lt. * emulparams/elf64ppc.sh: Set .branch_lt address fixed relative to .got. * testsuite/ld-powerpc/elfv2exe.d: Adjust to suit.
2022-06-27-z relro relaxation and ld script SIZEOFAlan Modra8-26/+33
A number of targets use assignments like: . = DATA_SEGMENT_RELRO_END (SIZEOF (.got.plt) >= 12 ? 12 : 0, .); (from i386) in linker scripts to put the end of the relro segment past the header in .got.plt. Examination of testcases like those edited by this patch instead sees the end of the relro segment being placed at the start of .got.plt. For the i386 pie1 test: [ 9] .got.plt PROGBITS 00002000 001000 00000c 04 WA 0 0 4 GNU_RELRO 0x000f90 0x00001f90 0x00001f90 0x00070 0x00070 R 0x1 A map file shows: .dynamic 0x0000000000001f90 0x70 *(.dynamic) .dynamic 0x0000000000001f90 0x70 tmpdir/pie1.o 0x0000000000001f90 _DYNAMIC .got 0x0000000000002000 0x0 *(.got) .got 0x0000000000002000 0x0 tmpdir/pie1.o *(.igot) 0x0000000000002ff4 . = DATA_SEGMENT_RELRO_END (., (SIZEOF (.got.plt) >= 0xc)?0xc:0x0) .got.plt 0x0000000000002000 0xc *(.got.plt) .got.plt 0x0000000000002000 0xc tmpdir/pie1.o 0x0000000000002000 _GLOBAL_OFFSET_TABLE_ The DATA_SEGMENT_RELRO_END value in the map file is weird too. All of this is triggered by SIZEOF (.got.plt) being evaluated wrongly as zero. Fix it by taking into account the action of lang_reset_memory_regions during relaxation. * ldexp.c (fold_name <SIZEOF>): Use rawsize if size has been reset. * ldlang.c (lang_size_sections_1): Don't reset processed_vma here. * testsuite/ld-i386/pie1.d: Adjust to suit. * testsuite/ld-x86-64/pr20830a.d: Likewise. * testsuite/ld-x86-64/pr20830b.d: Likewise. * testsuite/ld-x86-64/pr21038a.d: Likewise. * testsuite/ld-x86-64/pr21038b.d: Likewise. * testsuite/ld-x86-64/pr21038c.d: Likewise.
2022-06-27Automatic date update in version.inGDB Administrator1-1/+1
2022-06-26Automatic date update in version.inGDB Administrator1-1/+1
2022-06-25arm: Define elf_backend_extern_protected_data to 0 [PR 18705]Fangrui Song2-2/+2
Similar to commit 4fb55bf6a9606eb7b626c30a9f4e71d6c2d4fbb2 for aarch64. Commit b68a20d6675f1360ea4db50a9835c073675b9889 changed ld to produce R_ARM_GLOB_DAT but that defeated the purpose of protected visibility as an optimization. Restore the previous behavior (which matches ld.lld) by defining elf_backend_extern_protected_data to 0.
2022-06-25Fix corrupt DWARF in dw2-double-set-die-typeTom Tromey1-31/+0
The dw2-double-set-die-type.exp test case caused an AddressSanitizer failure in the new DWARF scanner. The immediate cause was bad DWARF in the test -- in particular, the the sibling attribute here: <2><181>: Abbrev Number: 33 (DW_TAG_subprogram) <182> DW_AT_external : 1 <183> DW_AT_name : address <18b> DW_AT_type : <0x171> <18f> DW_AT_declaration : 1 <190> DW_AT_sibling : <0x1a1> ... <1><1a1>: Abbrev Number: 23 (DW_TAG_pointer_type) <1a2> DW_AT_byte_size : 4 <1a3> DW_AT_type : <0x1a7> ...points to a "sibling" DIE that is at a different child depth. Because this test case doesn't really require sibling attributes, this patch fixes the problem by removing them from the test. Note that gdb is not generally robust against malformed DWARF. Detecting and compensating for this problem would probably be expensive and, IMO, is better left to some (still hypothetical) DWARF linter.
2022-06-25Fix end of CU calculation in cooked_indexer::index_diesTom Tromey1-1/+3
cooked_indexer::index_dies incorrect computes the end of the current CU in the .debug_info. This isn't readily testable without writing intentionally corrupt DWARF, but it's apparent through observation: it is currently based on 'info_ptr', which does not always point to the start of the CU. This patch fixes the expression. Tested on x86-64 Fedora 34.
2022-06-25gdb: LoongArch: Implement loongarch_linux_syscall_next_pc()Tiezhu Yang3-0/+36
When FRAME is at a syscall instruction, return the PC of the next instruction to be executed. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-06-25gdb: LoongArch: Define register numbers and clean up codeTiezhu Yang4-133/+89
This commit defines register numbers of various important registers, we can use them directly in the related code, and also clean up some code to make them more clear and readable. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-06-25Automatic date update in version.inGDB Administrator1-1/+1
2022-06-24Eliminate TUI/CLI observers duplicationPedro Alves2-253/+64
For historical reasons, the CLI and the TUI observers are basically exact duplicates, except for the downcast: cli: struct cli_interp *cli = as_cli_interp (interp); tui: struct interp *tui = as_tui_interp (interp); and how they get at the interpreter's ui_out: cli: cli->cli_uiout tui: tui->interp_ui_out () Since interp_ui_out() is a virtual method that also works for the CLI interpreter, and, both the CLI and the TUI interpreters inherit from the same base class (cli_interp_base), we can convert the CLI observers to cast to cli_interp_base instead and use interp_ui_out() too. With that, the CLI observers will work for the TUI interpreter as well. This lets us completely eliminate the TUI observers. That's what this commit does. Change-Id: Iaf6cf12dfa200ed3ab203a895a72b69dfedbd6e0
2022-06-24Revert "Delete delete_thread_silent"Pedro Alves2-5/+27
Turns out we'll be gaining a new use of this function very soon, the incoming AMDGPU port needs it. Let's add it back, as it isn't really hurting anything. This reverts commit 39b8a8090ed7e8967ceca3655aa5f3a2ae91219d.
2022-06-24gdb/arm: Update the value of active sp when base sp changesYvan Roux1-5/+11
For Arm Cortex-M33 with security extensions, there are 4 different stacks pointers (msp_s, msp_ns, psp_s, psp_ns). When plain "sp" is updated during unwinding of the stack, the active stack pointer of the 4 stack pointers needs to be kept in sync. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
2022-06-24gdb/testsuite: remove unneeded calls to get_compiler_infoAndrew Burgess174-714/+10
It is not necessary to call get_compiler_info before calling test_compiler_info, and, after recent commits that removed setting up the gcc_compiled, true, and false globals from get_compiler_info, there is now no longer any need for any test script to call get_compiler_info directly. As a result every call to get_compiler_info outside of lib/gdb.exp is redundant, and this commit removes them all. There should be no change in what is tested after this commit.
2022-06-24gdb/testsuite: remove global gcc_compiled from gdb.expAndrew Burgess37-177/+54
After this commit the gcc_compiled global is no longer exported from lib/gdb.exp. In theory we could switch over all uses of gcc_compiled to instead call test_compiler_info directly, however, I have instead added a new proc to gdb.exp: 'is_c_compiler_gcc'. I've then updated the testsuite to call this proc instead of using the global. Having a new proc specifically for this task means that we have a single consistent pattern for detecting gcc. By wrapping this logic within a proc that calls test_compiler_info, rather than using the global, means that test scripts don't need to call get_compiler_info before they read the global, simply calling the new proc does everything in one go. As a result I've been able to remove the get_compiler_info calls from all the test scripts that I've touched in this commit. In some of the tests e.g. gdb.dwarf2/*.exp, the $gcc_compiled flag was being checked at the top of the script to decide if the whole script should be skipped or not. In these cases I've called the new proc directly and removed all uses of gcc_compiled. In other cases, e.g. most of the gdb.base scripts, there were many uses of gcc_compiled. In these cases I set a new global gcc_compiled near the top of the script, and leave the rest of the script unchanged. There should be no changes in what is tested after this commit.
2022-06-24Include count of unexpected core files in gdb.sum summaryPedro Alves2-1/+49
If GDB, GDBserver, a testcase program, Valgrind, etc. unexpectedly crash while running the GDB testsuite, and you've setup your machine such that core files are dumped in the current directory instead of being shoved somewhere by abrt, apport, or similar (as you should for proper GDB testing), you'll end up with an unexpected core file in the $build/gdb/testsuite/ directory. It can happen that GDB, GDBserver, etc. even crashes _after_ gdb_exit, during teardown, and thus such a crash won't be noticed by looking at the gdb.sum file at all. This commit aims at improving that, by including a new "unexpected core files" line in the testrun summary. For example, here's what I get on x86-64 Ubuntu 20.04, with this patch: === gdb Summary === # of unexpected core files 12 << new info # of expected passes 107557 # of unexpected failures 35 # of expected failures 77 # of unknown successes 2 # of known failures 114 # of untested testcases 31 # of unsupported tests 139 I have my core pattern setup like this: $ cat /proc/sys/kernel/core_pattern core.%e.%p.%h.%t That's: %e: executable filename %p: pid %h: hostname %t: UNIX time of dump and so I get these core files: $ ls -1 testsuite/core.* testsuite/core.connect-with-no.216191.nelson.1656002431 testsuite/core.connect-with-no.217729.nelson.1656002431 testsuite/core.gdb.194247.nelson.1656002423 testsuite/core.gdb.226014.nelson.1656002435 testsuite/core.gdb.232078.nelson.1656002438 testsuite/core.gdb.352268.nelson.1656002441 testsuite/core.gdb.4152093.nelson.1656002337 testsuite/core.gdb.4154515.nelson.1656002338 testsuite/core.gdb.4156668.nelson.1656002339 testsuite/core.gdb.4158871.nelson.1656002341 testsuite/core.gdb.468495.nelson.1656002444 testsuite/core.vgdb.4192247.nelson.1656002366 where we can see that GDB crashed a number of times, but also Valgrind's vgdb, and a couple testcase programs. Neither of which is good. If your core_pattern is just "core" (but why??), then I guess that you may end up with just a single core file in testsuite/. Still, that is one core file too many. Above, we see a couple cores for "connect-with-no", which are the result of gdb.server/connect-with-no-symbol-file.exp. This is a case mentioned above -- while the program crashed, that happens during testcase teardown, and it goes unnoticed (without this commit) by gdb.sum results. Vis: $ make check TESTS="gdb.server/connect-with-no-symbol-file.exp" ... === gdb Summary === # of unexpected core files 2 # of expected passes 8 ... $ The tests fully passed, but still the testcase program crashed somehow: $ ls -1 testsuite/core.* testsuite/core.connect-with-no.941561.nelson.1656003317 testsuite/core.connect-with-no.941682.nelson.1656003317 Against --target_board=native-extended-gdbserver it's even worse. I get: # of unexpected core files 26 and note that when GDBserver hits an assertion failure, it exits with error, instead of crashing with SIGABRT. I think that should be changed, at least on development builds, but that would be for another patch. After such patch, I suspect the number of unexpected cores will be higher, as there are likely teardown GDBserver assertions that we're not noticing. I decided to put this new info in the "gdb Summary" section, as that's a place people already are used to looking at, either when looking at the tail of gdb.sum, or when diffing gdb.sum files, and we've already extended this section before, to include the count of DUPLICATE and PATH problems, so there's precedent. Implementation-wise, the new line is appended after DejaGnu is finished, with a shell script that is invoked by the Makefile. It is done this way so that serial and parallel testing work the same way. My initial cut at an implementation was in TCL, straight in testsuite/lib/check-test-names.exp, where DUPLICATES and PATH are handled, like so: @@ -148,6 +159,10 @@ namespace eval ::CheckTestNames { $counts(paths,$which) maybe_show_count "# of duplicate test names\t" \ $counts(duplicates,$which) + + set cores [glob -nocomplain -directory $::objdir core*] + maybe_show_count "# of unexpected core files\t" \ + [llength $cores] } But that would only work for serial testing, as in parallel testing, the final gdb.sum is generated by aggregating the results of all the individual gdb.sum files, and dg-extract-results.sh doesn't know about our new summary line. And I don't think that dg-extract-results.sh should be taught about it, since the count of core files is not something that we want to count many times, once per testcase, and then add up the subcounts at the end. Every time we count the core files, we're already counting the final count. I considered using the Tcl implementation in serial mode, and the script approach for parallel testing, but that has the obvious downside of implementing and maintaining the same thing twice. In the end, I settled on the script approach for serial mode too, which requires making the "check-single" rule print the tail end of the gdb.sum file, with a side effect being that if you look at the terminal after a run (instead of at the gdb.sum file), you'll see the "gdb Summary" section twice, once without the unexpected core lines printed, and then another with. IMO, this isn't an issue; when testing in parallel mode, if you look at the terminal after "make -jN check", you'll also see multiple "gdb Summary" sections printed. Change-Id: I190b8d41856d49ad143854b6e3e6ccd7caa04491
2022-06-24Improve core file path detection & put cores in output dirPedro Alves5-54/+117
After a testrun, I noticed that I have some kernel-produced cores for testcase programs, under build/gdb/testsuite/, which shouldn't be there: $ ls -1 testsuite/core.* testsuite/core.annota1.1274351.nelson.1656004407 testsuite/core.annota3.1288474.nelson.1656004414 testsuite/core.exitsignal.1240674.nelson.1656004391 I have my core pattern setup like this: $ cat /proc/sys/kernel/core_pattern core.%e.%p.%h.%t That's: %e: executable filename %p: pid %h: hostname %t: UNIX time of dump so it's easy to tell which program produced the core from the core file name. From above, we can tell that the corresponding testcases are gdb.base/annota1.exp, gdb.base/annota3.exp and gdb.base/exitsignal.exp. At least gdb.base/annota1.exp and gdb.base/annota3.exp have code in them to delete the core file. However, that isn't working for me, because said code only looks for cores named exactly either "core" or "core.PID", and my core_pattern doesn't match that. Another issue I noticed, is that I have not been running gdb.base/bigcore.exp, for a similar reason. I get: Program terminated with signal SIGABRT, Aborted. The program no longer exists. (gdb) PASS: gdb.base/bigcore.exp: signal SIGABRT UNTESTED: gdb.base/bigcore.exp: can't generate a core file But I actually have a core file under the testcase's output dir: $ find . -name "core.*" ./testsuite/outputs/gdb.base/bigcore/core.bigcore.2306705.nelson.1656005213 $ This commit fixes these things, by adding a find_core_file routine that searches core files in a way that works with my core pattern as well. This then also adds a convenience remove_core routine as a wrapper around find_core_file that removes the found core file. In addition, it changes some testcases that expect to have their program dump core, to switch the inferior's cwd to the testcase's output dir, so that the core is dumped there instead of in build/gdb/testsuite/. Some testcases were already doing that, but not all. The idea is that any core file dumped in build/gdb/testsuite/ is an unexpected core file. The next patch will add a count of such unexpected core files to gdb.sum. Another change is that the directory changing is now done with "set cwd" instead of with "cd". "set cwd" only affects the inferior cwd, while "cd" affects GDB's cwd too. By using "set cwd" instead of "cd", if GDB dumps core in these testcases, the GDB core dump will still end up in build/gdb/testsuite/, and can thus be detected as an unexpected core. Change-Id: I45068f21ffd4814350aaa8a3cc65cad5e3107607
2022-06-24gdb: make use of RAII in run_inferior_callAndrew Burgess1-14/+11
In passing I noticed that there are three local variables in run_inferior_call that are used to save, and then restore some state, I think these could all be replaced with a RAII style scoped_restore instead. Of the three locals that I've changed, the only one that I believe is now restored in a different location is ui::async, before this commit the async field was restored after a call to either delete_file_handle or ui_register_input_event_handler, and after this commit, the field is restored before these calls. However, I don't believe that either of these functions depend on the value of the async field, so I believe the commit is fine. Tested on x86-64/Linux passes with no regressions.
2022-06-24Delete delete_thread_silentPedro Alves2-27/+5
delete_thread_silent is no longer used anywhere. Delete it. Change-Id: Iafcec12339861d5ab2e29c14d7b1f884c9e11c0f
2022-06-24Automatic date update in version.inGDB Administrator1-1/+1
2022-06-23Don't declare cli_set_loggingTom Tromey1-5/+0
cli_set_logging is declared but not defined. It's probably a leftover from whenever interpreters were changed to use inheritance. This patch removes the declaration. Tested by grep and rebuilding.
2022-06-23Use PyBool_FromLongTom Tromey3-8/+4
I noticed a few spots that were explicitly creating new references to Py_True or Py_False. It's simpler here to use PyBool_FromLong, so this patch changes all the places I found.
2022-06-23PowerPC64: fix assertion in ppc_build_one_stub with -Os codeAlan Modra1-1/+2
save_res stubs aren't written in ppc_build_one_stub, their offsets (which are zero) should not be checked. * elf64-ppc.c (ppc_build_one_stub): Don't check save_res offsets.
2022-06-23Re: PowerPC64: stub debug dumpAlan Modra1-41/+61
Let's show the current stub as well as the previous one. Of interest is the current offset and a new field, id. Check that the build hash table traversal is in the same order as sizing traversal too. * elf64-ppc.c (struct ppc_stub_hash_entry): Add id. (struct ppc_link_hash_table): Add stub_id. (stub_hash_newfunc): Init id and symtype. (dump_stub): New function, extracted from.. (dump_previous_stub): ..here. Deleted. (ppc_build_one_stub): Sanity check stub id as well as offset. Show current stub as well as previous. (ppc_size_one_stub): Set stub id. (ppc64_elf_size_stubs): Init stub_id before traversal. (ppc64_elf_build_stubs): Likewise.
2022-06-23aarch64: Allow PC-relative relocations against protected STT_FUNC for -sharedFangrui Song4-1/+20
__attribute__((visibility("protected"))) void *foo() { return (void *)foo; } gcc -fpic -shared -fuse-ld=bfd fails with the confusing diagnostic: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `foo' which may bind externally can not be used when making a shared object; recompile with -fPIC Call _bfd_elf_symbol_refs_local_p with local_protected==true to suppress the error. The new behavior matches gold and ld.lld. Note: if some code tries to use direct access relocations to take the address of foo (likely due to -fno-pic), the pointer equality will break, but the error should be reported on the executable link, not on the innocent shared object link. glibc 2.36 will give a warning at relocation resolving time.
2022-06-23aarch64: Define elf_backend_extern_protected_data to 0 [PR 18705]Fangrui Song2-2/+2
Follow-up to commit 90b7a5df152a64d2bea20beb438e8b81049a5c30 ("aarch64: Disallow copy relocations on protected data"). Commit 32f573bcb3aaa1c9defcad79dbb5851fcc02ae2d changed ld to produce R_AARCH64_GLOB_DAT but that defeated the purpose of protected visibility as an optimization. Restore the previous behavior (which matches ld.lld) by defining elf_backend_extern_protected_data to 0.
2022-06-23Automatic date update in version.inGDB Administrator1-1/+1
generated by cgit v1.1 at 2024-11-26 17:56:22 +0000