aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-04-28s390: Avoid dynamic TLS relocs in PIEStefan Liebler1-13/+13
No dynamic relocs are needed for TLS defined in an executable, the TP relative offset is known at link time. Fixes FAIL: Build pr22263-1 bfd/ PR ld/22263 * elf64-s390.c (elf_s390_tls_transition): Use bfd_link_dll instead of bfd_link_pic for TLS. (elf_s390_check_relocs): Likewise. (allocate_dynrelocs): Likewise. (elf_s390_relocate_section): Likewise.
2022-04-28libctf: impose an ordering on conflicting typesNick Alcock7-2/+98
When two types conflict and they are not types which can have forwards (say, two arrays of different sizes with the same name in two different TUs) the CTF deduplicator uses a popularity contest to decide what to do: the type cited by the most other types ends up put into the shared dict, while the others are relegated to per-CU child dicts. This works well as long as one type *is* most popular -- but what if there is a tie? If several types have the same popularity count, we end up picking the first we run across and promoting it, and unfortunately since we are working over a dynhash in essentially arbitrary order, this means we promote a random one. So multiple runs of ld with the same inputs can produce different outputs! All the outputs are valid, but this is still undesirable. Adjust things to use the same strategy used to sort types on the output: when there is a tie, always put the type that appears in a CU that appeared earlier on the link line (and if there is somehow still a tie, which should be impossible, pick the type with the lowest type ID). Add a testcase -- and since this emerged when trying out extern arrays, check that those work as well (this requires a newer GCC, but since all GCCs that can emit CTF at all are unreleased this is probably OK as well). Fix up one testcase that has slight type ordering changes as a result of this change. libctf/ChangeLog: * ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Use cd_output_first_gid to break ties. ld/ChangeLog: * testsuite/ld-ctf/array-conflicted-ordering.d: New test, using... * testsuite/ld-ctf/array-char-conflicting-1.c: ... this... * testsuite/ld-ctf/array-char-conflicting-2.c: ... and this. * testsuite/ld-ctf/array-extern.d: New test, using... * testsuite/ld-ctf/array-extern.c: ... this. * testsuite/ld-ctf/conflicting-typedefs.d: Adjust for ordering changes.
2022-04-28libctf: add a comment explaining how to use ctf_*openNick Alcock1-1/+7
Specifically, tell users what to pass to those functions that accept raw section content, since it's fairly involved and easy to get wrong. (.dynsym / .dynstr when CTF_F_DYNSTR is set, otherwise .symtab / .strtab). include/ChangeLog: * ctf-api.h (ctf_*open): Improve comment.
2022-04-27gprofng: test suite problemsVladimir Mezentsev1-2/+2
gprofng/ChangeLog 2022-04-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> PR gprofng/29065 * testsuite/lib/Makefile.skel: Search parent dir for libs too.
2022-04-27gdb: remove BLOCKVECTOR_MAP macroSimon Marchi7-17/+26
Replace with equivalent methods. Change-Id: I4e56c76dfc363c1447686fb29c4212ea18b4dba0
2022-04-27gdb: constify addrmap_findSimon Marchi2-9/+9
addrmap_find shouldn't need to modify the addrmap, so constify the addrmap parameter. This helps for the following patch, where getting the map of a const blockvector will return a const addrmap. Change-Id: If670e425ed013724a3a77aab7961db50366dccb2
2022-04-27gdb: remove BLOCKVECTOR_BLOCK and BLOCKVECTOR_NBLOCKS macrosSimon Marchi25-161/+194
Replace with calls to blockvector::blocks, and the appropriate method call on the returned array_view. Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
2022-04-27gdb: remove BLOCK_ENTRY_PC macroSimon Marchi17-51/+56
Replace with equivalent method. Change-Id: I0e033095e7358799930775e61028b48246971a7d
2022-04-27gdb: remove BLOCK_CONTIGUOUS_P macroSimon Marchi3-9/+8
Replace with an equivalent method. Change-Id: I60fd3be7b4c2601c2a74328f635fa48ed80eb7f5
2022-04-27gdb: remove BLOCK_RANGE macroSimon Marchi1-5/+1
Replace with access through the block::ranges method. Change-Id: I50f3ed433b997c9f354e49bc6583f540ae4b6121
2022-04-27gdb: remove BLOCK_NRANGES macroSimon Marchi3-19/+15
Replace with range for loops. Change-Id: Icbe04f9b6f9e6ddae2e15b2409c61f7a336bc3e3
2022-04-27gdb: remove BLOCK_RANGES macroSimon Marchi3-17/+24
Replace with an equivalent method on struct block. Change-Id: I6dcf13e9464ba8a08ade85c89e7329c300fd6c2a
2022-04-27gdb: remove BLOCK_RANGE_{START,END} macrosSimon Marchi4-26/+35
Replace with equivalent methods on blockrange. Change-Id: I20fd8f624e0129782c36768291891e7582d77c74
2022-04-27gdb: remove BLOCK_NAMESPACE macroSimon Marchi2-13/+19
Replace with equivalent methods. Change-Id: If86b8cbdfb0f52e22c929614cd53e73358bab76a
2022-04-27gdb: remove BLOCK_MULTIDICT macroSimon Marchi7-30/+37
Replace with equivalent methods. Change-Id: If9a239c511a664f2a59fecb6d1cd579881b23dc2
2022-04-27gdb: remove BLOCK_SUPERBLOCK macroSimon Marchi26-84/+92
Replace with equivalent methods. Change-Id: I334a319909a50b5cc5570a45c38c70e10dc00630
2022-04-27gdb: remove BLOCK_FUNCTION macroSimon Marchi24-69/+74
Replace with equivalent methods. Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101
2022-04-27gdb: remove BLOCK_{START,END} macrosSimon Marchi20-99/+117
Replace with equivalent methods. Change-Id: I10a6c8a2a86462d9d4a6a6409a3f07a6bea66310
2022-04-28Automatic date update in version.inGDB Administrator1-1/+1
2022-04-27x86: Disable 2 tests with large memory requirementH.J. Lu2-3/+4
gas/ * testsuite/gas/i386/i386.exp: Disable rept. ld/ * testsuite/ld-x86-64/x86-64.exp: Disable pr17618.
2022-04-27Make gdb.base/parse_number.exp test all architecturesPedro Alves1-11/+63
There are some subtle differences between architectures, like the size of a "long" type, and this isn't currently accounted for in gdb.base/parse_number.exp. For example, on aarch64 a long type is 8 bytes, whereas a long type is 4 bytes for x86_64. This causes the following FAIL's: FAIL: gdb.base/parse_number.exp: lang=asm: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=auto: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=c: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=c++: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=fortran: p/x 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=fortran: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=go: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=local: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=minimal: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=objective-c: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=opencl: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=pascal: ptype 0xffffffffffffffff There are some fortran-specific divergences as well, where 32-bit architectures show "unsigned int" for both 32-bit and 64-bit integers and 64-bit architectures show "unsigned int" and "unsigned long" for 32-bit and 64-bit integers. There might be a bug that 32-bit fortran truncates 64-bit values to 32-bit, given "p/x 0xffffffffffffffff" returns "0xffffffff". Here's what we get for aarch64: (gdb) ptype 0xffffffff type = unsigned int (gdb) ptype 0xffffffffffffffff type = unsigned long (gdb) p sizeof (0xffffffff) $1 = 4 (gdb) p sizeof (0xffffffffffffffff) quit $2 = 8 (gdb) ptype 0xffffffff type = unsigned int (gdb) ptype 0xffffffffffffffff type = unsigned long And for arm: (gdb) ptype 0xffffffff type = unsigned int (gdb) ptype 0xffffffffffffffff quit type = unsigned long long (gdb) p sizeof (0xffffffff) quit $1 = 4 (gdb) p sizeof (0xffffffffffffffff) quit $2 = 8 (gdb) ptype 0xffffffff type = unsigned int (gdb) ptype 0xffffffffffffffff type = unsigned long This patch... * Makes the testcase iterate over all architectures, thus covering all the different combinations of types/sizes every time. * Adjusts the expected values and types based on the sizes of long long, long and int. A particularly curious architecture is s12z, which has 32-bit long long, and thus no way to represent 64-bit integers in C-like languages. Co-Authored-By: Luis Machado <luis.machado@arm.com> Change-Id: Ifc0ccd33e7fd3c7585112ff6bebe7d266136768b
2022-04-27Fix gdbserver build for x86-64 WindowsTom Tromey3-28/+36
I broke the gdbserver build on x86-64 Windows a little while back. Previously, I could not build this configuration, but today I found out that if I configure with: --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 using the Fedora 34 tools, it will in fact build. I'm not certain, but maybe the gnulib update helped with this. This patch fixes the build. I'm checking it in.
2022-04-27Create pseudo sections for NT_ARM_TLS notes on FreeBSD.John Baldwin2-0/+7
bfd/ChangeLog: * elf.c (elfcore_grok_freebsd_note): Handle NT_ARM_TLS notes.
2022-04-27gdb/arm: Extend arm_m_addr_is_magic to support FNC_RETURN, add ↵Christophe Lyon3-62/+267
unwind-secure-frames command This patch makes use of the support for several stack pointers introduced by the previous patch to switch between them as needed during unwinding. It introduces a new 'unwind-secure-frames' arm command to enable/disable mode switching during unwinding. It is enabled by default. It has been tested using an STM32L5 board (with cortex-m33) and the sample applications shipped with the STM32Cube development environment: GTZC_TZSC_MPCBB_TrustZone in STM32CubeL5/Projects/NUCLEO-L552ZE-Q/Examples/GTZC. The test consisted in setting breakpoints in various places and check that the backtrace is correct: SecureFault_Callback (Non-secure mode), __gnu_cmse_nonsecure_call (before and after the vpush instruction), SecureFault_Handler (Secure mode). This implies that we tested only some parts of this patch (only MSP* were used), but remaining parts seem reasonable. Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com> Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-04-27gdb/arm: Add support for multiple stack pointers on Cortex-MChristophe Lyon4-20/+284
Armv8-M architecture with Security extension features four stack pointers to handle Secure and Non-secure modes. This patch adds support to switch between them as needed during unwinding, and replaces all updates of cache->prev_sp with calls to arm_cache_set_prev_sp. Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com> Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-04-27gdb/arm: Introduce arm_cache_initChristophe Lyon1-6/+27
This patch is a preparation for the rest of the series and adds two arm_cache_init helper functions. It updates every place that updates cache->saved_regs to call the helper instead. Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com> Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-04-27gdb/arm: Define MSP and PSP registers for M-ProfileChristophe Lyon7-29/+89
This patch removes the hardcoded access to PSP in arm_m_exception_cache() and relies on the definition with the XML descriptions. Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-04-27gdb/arm: Fix prologue analysis to support vpushChristophe Lyon1-0/+29
While working on adding support for Non-secure/Secure modes unwinding, I noticed that the prologue analysis lacked support for vpush, which is used for instance in the CMSE stub routine. This patch updates thumb_analyze_prologue accordingly, adding support for vpush of D-registers. Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-04-27gdb/testsuite: fix FAIL in gdb.base/clear_non_user_bp.expEnze Li1-18/+48
Tom and Simon feedback that there is a test failing in this commit: commit a5c69b1e49bae4d0dcb20f324cebb310c63495c6 Date: Sun Apr 17 15:09:46 2022 +0800 gdb: fix using clear command to delete non-user breakpoints(PR cli/7161) Then, I reproduced the same fail with Ubuntu 20.04 as Simon said, and I fixed the nit in this patch. The root of the problem is not correctly matching the presentation of internal breakpoints. In addition, as Pedro pointed out, the original testcase is not portable in some methods, so this patch fixes this issue and some other improvements. Tested on x86_64 ubuntu 20.04.4 and openSUSE Tumbleweed(VERSION_ID="20220425").
2022-04-27x86: VFPCLASSSH is Evex.LLIGJan Beulich7-3/+54
This also was mistakenly flagged as Evex.128.
2022-04-27Fix potential buffer overruns when creating DLLs.Nick Clifton2-15/+53
PR 29006 * pe-dll.c (make_head): Use asprintf to allocate and populate a buffer containing the temporary name. (make_tail, make_one, make_singleton_name_thunk): Likewise. (make_import_fixup_mark, make_import_fixup_entry): Likewise. (make_runtime_pseudo_reloc): Likewise. (pe_create_runtime_relocator_reference): Likewise.
2022-04-27Revert pr29072 lto test changesAlan Modra3-4/+4
Revert commit 65daf5bed6 testsuite changes in ld-plugin/. -z isn't supported for non-ELF targets, and isn't needed since we now prune the exec stack warning (commit 333cd559ba). PR 29072
2022-04-26gdb/testsuite: use with_cwd where possibleSimon Marchi8-67/+59
I learned about with_cwd today. I spotted a few spots that could use it, to make the code more robust. Change-Id: Ia23664cb827f25e79d31948e0c006a8dc61c33e1
2022-04-27Automatic date update in version.inGDB Administrator1-1/+1
2022-04-26GDB PowerPC record test cases for ISA 2.06 and ISA 3.1Carl Love4-0/+580
This patch adds PowerPC specific tests to verify recording of various instructions. The first test case checks the ISA 2.06 lxvd2x instruction. The second test case tests several of the ISA 3.01 instructions. Specifically, it checks the word and prefixed instructions and some of the Matrix Multiply Assist (MMA) instructions. The patch has been run on both Power 10 and Power 9 to verify the ISA 2.06 test case runs on both platforms without errors. The ISA 3.1 test runs without errors on Power 10 and is skipped as expected on Power 9.
2022-04-26Add recording support for the ISA 3.1 PowerPC instructions.Carl Love1-26/+1169
This patch adds support for the PowerPC ISA 3.1 instructions to the PowerPC gdb instruction recording routines. Case statement entries are added to a number of the existing routines for recording the 32-bit word instructions. A few new functions were added to handle the new word instructions. The 64-bit prefix instructions are all handled by a set of new routines. The function ppc_process_prefix_instruction() is the primary function to handle the prefixed instructions. It calls additional functions to handle specific sets of prefixed instructions. These new functions are: ppc_process_record_prefix_vsx_d_form(), ppc_process_record_prefix_store_vsx_ds_form(), ppc_process_record_prefix_op34(), ppc_process_record_prefix_op33(), ppc_process_record_prefix_op32(), ppc_process_record_prefix_store(), ppc_process_record_prefix_op59_XX3(), ppc_process_record_prefix_op42().
2022-04-26Handle encoding failures in Windows thread namesTom Tromey1-5/+16
Internally at AdaCore, we noticed that the new Windows thread name code could fail. First, it might return a zero-length string, but in gdb conventions it should return nullptr instead. Second, an encoding failure could wind up showing replacement characters to the user; this is confusing and not useful; it's better to recognize such errors and simply discard the name. This patch makes both of these changes.
2022-04-26i386: Pass -z noexecstack to linker testsH.J. Lu1-2/+4
PR ld/29072 * testsuite/ld-i386/i386.exp: Pass -z noexecstack to gotpc1 and property-6.
2022-04-26bsd-kvm: Fix build after recent changes to path handling functions.John Baldwin1-13/+11
Convert bsd_kvm_corefile and the local filename in bsd_kvm_open to std::string rather than simple char * pointers freed by xfree.
2022-04-26gdb: make some random Python files Python 3-compatibleSimon Marchi3-18/+18
I noticed that these files failed to format with Black, because they use print without parenthesis (which isn't Python 3 compatible). I don't know if these files are still relevant, but the change is trivial, so here it is. Change-Id: I116445c2b463486016f824d32effffc915b60766
2022-04-26PowerPC: Update expected floating point output for gdb.arch/altivec-regs.exp ↵Carl Love2-19/+20
and gdb.arch/vsx-regs.exp The format for printing the floating point values was changed by commit: commit 56262a931b7ca8ee3ec9104bc7e9e0b40cf3d64e Author: Tom Tromey <tromey@adacore.com> Date: Thu Feb 17 13:43:59 2022 -0700 Change how "print/x" displays floating-point value Currently, "print/x" will display a floating-point value by first casting it to an integer type. This yields weird results like: (gdb) print/x 1.5 $1 = 0x1 ... Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16242 The above change results in 417 regression test failures since the expected Power vector register output no longer match. This patch updates the expected Altivec floating point register prints to the hexadecimal format for both big endian and little endian systems. The patch also fixes a formatting isue with the decimal_vector expected value assign statements. The expected VSX vector_register1, vector_register1_vr, vector_register2, vector_register2_vr variables are updated to include the new float128 entry. Additionally, the comment in the vsx expect file about the initialization of the vs registers is updated. The patch has been tested on Power 10, Power 8 LE and Power 8 BE.
2022-04-25gdbsupport/pathstuff.h: #include <array> explicitly for std::array<>John Baldwin1-0/+1
This fixes build breakage using clang with libc++ on FreeBSD where std::array<> is not yet declared when used by the path_join variadic function template.
2022-04-26Automatic date update in version.inGDB Administrator1-1/+1
2022-04-25Do not put linkage names into .gdb_indexTom Tromey1-0/+8
This changes the .gdb_index writer to skip linkage names. This was always done historically (though somewhat implicitly).
2022-04-25Emit a note warning the user that creating an executable stack because of a ↵Nick Clifton6-2/+28
missing .note.GNU-stack section is deprecated. PR 29072 bfd * elflink.c (bfd_elf_size_dynamic_sections): Display a note to the user that the current ehaviour of creating an executable stack because of a missing .note.GNU-stack section is deprecated and will be changed in a future release. binutils* testsuite/lib/binutils-common.exp (prune_warnings_extra): Filter out notes about the executable stacjk behaviour beign deprecated. ld * testsuite/ld-elf/pr29072.b.warn: Update to include the note about the linker's behaviour being depreccated.
2022-04-25gdb/fortran: Support for assumed rank zerorupothar4-5/+27
If a variable is passed to function in FORTRAN as an argument the variable is treated as an array with rank zero. GDB currently does not support the case for assumed rank 0. This patch provides support for assumed rank 0 and updates the testcase as well. Without patch: Breakpoint 1, arank::sub1 (a=<error reading variable: failed to resolve dynamic array rank>) at assumedrank.f90:11 11 PRINT *, RANK(a) (gdb) p a failed to resolve dynamic array rank (gdb) p rank(a) failed to resolve dynamic array rank With patch: Breakpoint 1, arank::sub1 (a=0) at assumedrank.f90:11 11 PRINT *, RANK(a) (gdb) p a $1 = 0 (gdb) p rank(a) $2 = 0
2022-04-25gdb/infrun: assert !step_over_info_valid_p in restart_threadsLancelot SIX1-1/+7
While working in gdb/infrun.c:restart_threads, I was wondering what are the preconditions to call the function. It seems to me that !step_over_info_valid_p should be a precondition (i.e. if we are doing an inline step over breakpoint, we do not want to resume non stepping threads as one of them might miss the breakpoint which is temporally disabled). To convince myself that this is true, I have added an assertion to enforce this, and got one regression in the testsuite: FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: single step over vfork (GDB internal error) This call to restart_threads originates from handle_vfork_done which does not check if a step over is active when restarting other threads: if (target_is_non_stop_p ()) { scoped_restore_current_thread restore_thread; insert_breakpoints (); restart_threads (event_thread, event_thread->inf); start_step_over (); } In this patch, I propose to: - Call start_step_over before restart_threads. If a step over is already in progress (as it is the case in the failing testcase), start_step_over return immediately, and there is no point in restarting all threads just to stop them right away for a step over breakpoint. - Only call restart_threads if no step over is in progress at this point. In this patch, I also propose to keep the assertion in restart_threads to help enforce this precondition, and state it explicitly. I have also checked all other places which call restart_threads, and they all seem to check that there is no step over currently active before doing the call. As for infrun-related things, I am never completely sure I did not miss something. So as usual, all feedback and thoughts are very welcome. Tested on x86_64-linux-gnu. Change-Id: If5f5f98ec4cf9aaeaabb5e3aa88ae6ffd70d4f37
2022-04-25Automatic date update in version.inGDB Administrator1-1/+1
2022-04-24gdb: move setbuf calls out of gdb_readline_no_editing_callbackAndrew Burgess2-13/+39
After this commit: commit d08cbc5d3203118da5583296e49273cf82378042 Date: Wed Dec 22 12:57:44 2021 +0000 gdb: unbuffer all input streams when not using readline Issues were reported with some MS-Windows hosts, see the thread starting here: https://sourceware.org/pipermail/gdb-patches/2022-March/187004.html Filed in bugzilla as: PR mi/29002 The problem seems to be that calling setbuf on terminal file handles is not always acceptable, see this mail for more details: https://sourceware.org/pipermail/gdb-patches/2022-April/187310.html This commit does two things, first moving the setbuf calls out of gdb_readline_no_editing_callback so that we don't end up calling setbuf so often. Then, for MS-Windows hosts, we don't call setbuf for terminals, this appears to resolve the issues that have been reported. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29002
2022-04-24Automatic date update in version.inGDB Administrator1-1/+1
generated by cgit v1.1 at 2025-03-01 11:13:20 +0000