aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-08-12configure: Implement --enable-host-pieMarek Polacek4-7/+97
This patch implements the --enable-host-pie configure option which makes the compiler executables PIE. This can be used to enhance protection against ROP attacks, and can be viewed as part of a wider trend to harden binaries. Co-Authored by: Iain Sandoe <iain@sandoe.co.uk> * configure.ac (--enable-host-pie): New check. Set PICFLAG after this check. intl/ * configure.ac (--enable-host-shared): Don't set PICFLAG here. (--enable-host-pie): New check. Set PICFLAG after this check. libdecnumber/ * configure.ac (--enable-host-shared): Don't set PICFLAG here. (--enable-host-pie): New check. Set PICFLAG after this check. zlib/ * configure.ac (--enable-host-shared): Don't set PICFLAG here. (--enable-host-pie): New check. Set PICFLAG after this check.
2023-08-12configure: When host-shared, pass --with-pic to in-tree lib configs.Iain Sandoe2-6/+17
If we are building PIC/PIE host executables, and we are building dependent libs (e.g. GMP) in-tree those libs need to be configured to generate PIC code. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> * Makefile.def: Pass host_libs_picflag to host dependent library configures. * configure.ac (host_libs_picflag): New configure variable set to '--with-pic' when building 'host_shared'.
2023-08-12configure: Do not build the ununsed libffi shared library.Iain Sandoe1-1/+2
We do not use the shared libffi libraray, nor do we install it. However, on at least Darwin, the shared version will be picked up for testing, so it is preferrable not to build it. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> * Makefile.def: Do not build shared libffi.
2023-08-12Darwin : Update libtool and dependencies for Darwin20 [PR97865]Iain Sandoe1-15/+17
The change in major version (and the increment from Darwin19 to 20) caused libtool tests to fail which resulted in incorrect build settings for shared libraries. PR target/97865 * libtool.m4: Update handling of Darwin platform link flags for Darwin20.
2023-08-12LoongArch: implement count_{leading,trailing}_zerosXi Ruoyao1-0/+12
LoongArch always support clz and ctz instructions, so we can always use __builtin_{clz,ctz} for count_{leading,trailing}_zeros. This improves the code of libgcc, and also benefits Glibc once we merge longlong.h there. Bootstrapped and regtested on loongarch64-linux-gnu. include/ * longlong.h [__loongarch__] (count_leading_zeros): Define. [__loongarch__] (count_trailing_zeros): Likewise. [__loongarch__] (COUNT_LEADING_ZEROS_0): Likewise.
2023-08-12Updated constants from <https://dwarfstd.org/Languages.php>Meghan Denny1-0/+10
include/ * dwarf2.h: Update with additional languages from dwarf standard.
2023-08-12c++: source position of lambda captures [PR84471]Jason Merrill1-1/+1
include/ * ansidecl.h (ATTRIBUTE_WARN_UNUSED_RESULT): Add __.
2023-08-12Libvtv: Add loongarch support.Lulu Cheng1-0/+4
The loongarch64 specification permits page sizes of 4KiB, 16KiB and 64KiB, but only 16KiB pages are supported for now. Co-Authored-By: qijingwen <qijingwen@loongson.cn> include/ * vtv-change-permission.h (defined): Determines whether the macro __loongarch_lp64 is defined (VTV_PAGE_SIZE): Set VTV_PAGE_SIZE to 16KiB for loongarch64.
2023-08-12Automatic date update in version.inGDB Administrator1-1/+1
2023-08-11gdb.ada/mi_var_access.expCarl Love1-2/+9
The NUMCHILD value for the "A_String_Access" test differs for X86 and PowerPC. The patch substitutes $decimal instead of "1" to match the value of NUMCHILD. The test "-var-update A_String_Access" generates different output depending on the value of VAROBJ_UPDATE_RESULT.TYPE_CHANGED. If the value is true, the strings "new_type" and "new_num_children" are printed along with their values. The VAROBJ_UPDATE_RESULT.TYPE_CHANGED value is true on PowerPC which produces the output: Expecting: ^(-var-update A_String_Access[ ]+)?(\^done,changelist=\[\{name="A_String_Access",in_scope="true",type_changed="false",has_more="0"\}\][ ]+[(]gdb[)] [ ]*) -var-update A_String_Access ^done,changelist=[{name="A_String_Access",in_scope="true",type_changed="true",new_type="pck.string_access",new_num_children="1",has_more="0"}] (gdb) FAIL: gdb.ada/mi_var_access.exp: update at stop 2 (unexpected output) The patch adds a second possible result string for the test $re_varobj_update_result_type to match the case when type_changed is true. Currently for the mi_var_access.exp test VAROBJ_UPDATE_RESULT.TYPE_CHANGED is true on PowerPC and false on X86-64. Fixes 2 failures on PowerPC. Approved-By: Tom Tromey <tom@tromey.com>
2023-08-11Fix Python documentation for range type fieldsTom Tromey1-3/+0
GDB's Python documentation claims that range types have two fields, but this is not true, and attempts to access them hit this error: "Type is not a structure, union, enum, or function type." This patch fixes the documentation.
2023-08-11Test GNAT encodings in arr_acc_idx_w_gap.expTom Tromey1-37/+43
While working on a GNAT bug, I wanted to also test arr_acc_idx_w_gap.exp using GNAT encodings. When the GNAT change is ready, I plan to add a new case here. Tested on x86-64 Fedora 36. I am checking this in.
2023-08-11RISC-V: Reflect actual range of vlen for hashingTsukasa OI1-1/+1
Before actual vlen handling, fix the riscv_gdbarch_features hashing function based on the actual valid range of vlen. In bytes, vlen is 0, or 4 <= xlen <= 8192.
2023-08-11RISC-V: Add reference to Zve32*Tsukasa OI1-3/+4
Before actual vlen handling, this commit fixes its description to allow vlen less than 16 (but 4 or greater), to support vector subset extensions for embedded environment ('Zve32*').
2023-08-11gdb: warn unused result for bfd IO functionsAlan Modra4-68/+85
This fixes the compilation warnings introduced by my bfdio.c patch. The removed bfd_seeks in coff_symfile_read date back to 1994, commit 7f4c859520, prior to which the file used stdio rather than bfd to read symbols. Since it now uses bfd to read the file there should be no need to synchronise to bfd's idea of the file position. I also fixed a potential uninitialised memory access. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-08-11Fix AIX build break.Aditya Vidyadhar Kamath1-4/+2
In a recent commit the signature of the scoped_restore_current_inferior_for_memory function was changed and in AIX we did not update the same. This patch updates it in aix-thread.c file fixed the break and the thread debugging works alright as a result.
2023-08-11gas: purge md_elf_section_word()Jan Beulich3-19/+0
It's not documented anyway, and having it makes no sense anymore with obj_elf_section_word() now being TC_SPARC-only. In any event the x86 backing function was dead code.
2023-08-11x86: pack CPU flags in opcode tableJan Beulich5-31505/+4684
The table constantly growing in two dimensions (number of table entries times number of ISA extension flags) doesn't scale very well. Use a more compact representation: Only identifiers which need to combine with other identifiers retain individual flag bits. All others are combined into an enum, with a new helper added to transform the table entries into the original i386_cpu_flags layout. This way the table in the final binary shrinks by almost a third (the generated source code shrinks by about half), and isn't likely to grow again in that dimension any time soon. While moving the 3DNow! fields, drop the stray inner 'a' from their names.
2023-08-11warn unused result for bfd IO functionsAlan Modra16-161/+252
This patch fixes all the warnings I found in bfd, binutils and ld, plus some bitrotted COFF_GO32 code that tried to allocate -168ul bytes. When the malloc fail was reported these testsuite fails resulted: i386-go32 +FAIL: go32 stub i386-go32 +ERROR: tcl error sourcing /home/alan/src/binutils-gdb/ld/testsuite/ld-i386/i386.exp. i386-go32 +ERROR: couldn't open "tmpdir/go32stub": no such file or directory i386-go32 +FAIL: ld-scripts/sane1 i386-go32 +FAIL: ld-scripts/assign-loc i386-go32 +FAIL: ld-scripts/pr18963 This does result in some warnings in gdb which are fixed in a followup patch. bfd/ * bfdio.c (bfd_read, bfd_write): Add ATTRIBUTE_WARN_UNUSED_RESULT. (bfd_tell, bfd_stat, bfd_seek, bfd_mmap): Likewise. * bfd-in2.h: Regenerate. * coff-rs6000.c (xcoff_write_armap_big) Don't ignore bfd_write return value. (xcoff_generate_rtinit): Likewise. Also free data_buffer and string_table before returning. * coff64-rs6000.c (xcoff64_generate_rtinit): Likewise. * coff-stgo32.c (go32exe_check_format): Don't ignore bfd_seek return value. * coffcode.h (coff_apply_checksum): Don't ignore bfd_write return. (coff_write_object_contents <COFF_GO32>): Likewise, and bfd_malloc. Fix bitrotted code to look for first section with non-zero filepos. * elf64-ia64-vms.c (elf64_vms_write_shdrs_and_ehdr): Don't ignore bfd_seek or bfd_write return values. * pef.c (bfd_pef_scan_section): Likewise. (bfd_pef_read_header, bfd_pef_xlib_read_header): Likewise. * vms-misc.c (_bfd_vms_output_end): Likewise. Return status. * vms.h (_bfd_vms_output_end): Update prototype. * vms-alpha.c: Pass _bfd_vms_output_end status up call chains. * wasm-module.c (wasm_compute_custom_section_file_position): Don't ignore bfd_seek or bfd_write return values. (wasm_compute_section_file_positions): Likewise. * xsym.c (bfd_sym_scan): Don't ignore bfd_seek return value. (bfd_sym_read_name_table): Likewise. binutils/ * ar.c (print_contents, extract_file): Don't ignore bfd_seek return value. ld/ * pdb.c (create_section_contrib_substream): Don't ignore bfd_seek return value. (create_section_header_stream): Likewise. * pe-dll.c (pe_get16, pe_get32): Add fail param to return results from bfd_seek and bfd_read. (pe_implied_import_dll): Handle these fails, and other bfd_seek and bfd_read return values.
2023-08-11RISC-V: Fix opcode entries of "vmsge{,u}.vx"Tsukasa OI1-4/+4
Their check_func should be "match_never", not "match_opcode". The reasons this error did not cause any disassembler errors are: 1. The problem will not reproduce if "no-aliases" is specified (because macro instructions are handled as aliases). 2. If not, all affected compressed instructions or their aliases precede before "vmsge{,u}.vx" macro instructions. However, it'll easily break if we reorder opcode entries. This commit fixes this issue before the *accident* occurs. opcodes/ChangeLog: * riscv-opc.c (riscv_opcodes): Make sure that we never match to vmsge{,u}.vx instructions unless specified in the assembler.
2023-08-11RISC-V: Remove support for non-existing 'Zve32d'Tsukasa OI1-1/+0
Since this "extension" does not exist (on the other hand, 'Zve64d' exists) and it's not useful if we keep it (as other code portions just ignore "zve32d"), this commit just removes it. bfd/ChangeLog: * elfxx-riscv.c (riscv_supported_std_z_ext): Remove 'Zve32d' extension from the list.
2023-08-11Automatic date update in version.inGDB Administrator1-1/+1
2023-08-10[gdb/symtab] Fix off-by-one error in cooked_indexer::recurseTom de Vries2-1/+13
Test-case gdb.dwarf2/pr13961.exp contains: ... <1><25>: Abbrev Number: 8 (DW_TAG_class_type) <26> DW_AT_specification: <0x2a> <1><2a>: Abbrev Number: 2 (DW_TAG_class_type) <2b> DW_AT_name : foo <2f> DW_AT_byte_size : 4 <30> DW_AT_decl_file : 1 <31> DW_AT_decl_line : 1 <32> DW_AT_sibling : <0x44> ... The DIE at 0x25 contains an intra-CU forward reference, and is deferred during DIE indexing in the cooked_index, by adding it to m_deferred_entries. The resulting cooked index entries are: ... [25] ((cooked_index_entry *) 0x333b5d0) name: foo canonical: foo qualified: foo DWARF tag: DW_TAG_class_type flags: 0x0 [] DIE offset: 0x2a parent: ((cooked_index_entry *) 0) [26] ((cooked_index_entry *) 0x333b630) name: foo canonical: foo qualified: foo::foo DWARF tag: DW_TAG_class_type flags: 0x0 [] DIE offset: 0x25 parent: ((cooked_index_entry *) 0x333b5d0) [foo] ... Notice that 0x2a is the parent of 0x25, and that this is why the qualified name of 0x25 is "foo::foo", which is incorrect, it's supposed to be "foo". The parent is set here in cooked_indexer::make_index: ... for (const auto &entry : m_deferred_entries) { void *obj = m_die_range_map.find (entry.spec_offset); cooked_index_entry *parent = static_cast<cooked_index_entry *> (obj); m_index_storage->add (entry.die_offset, entry.tag, entry.flags, entry.name, parent, m_per_cu); } ... and AFAICT, we store in m_die_range_map the parent of the respective spec_offset DIE (though that's not clear from the comment describing it). So, the root cause of this is that when we lookup the parent for DIE 0x25, we get m_die_range_map.find (0x2a) == 0x2a. This is an off-by-one error, fixed in cooked_indexer::recurse by: ... - CORE_ADDR start = form_addr (parent_entry->die_offset, + CORE_ADDR start = form_addr (parent_entry->die_offset + 1, ... which gives us: ... [12] ((cooked_index_entry *) 0x41e21f0) name: foo canonical: foo qualified: foo DWARF tag: DW_TAG_class_type flags: 0x0 [] DIE offset: 0x25 parent: ((cooked_index_entry *) 0) [13] ((cooked_index_entry *) 0x41e2190) name: foo canonical: foo qualified: foo DWARF tag: DW_TAG_class_type flags: 0x0 [] DIE offset: 0x2a parent: ((cooked_index_entry *) 0) ... Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR symtab/30739 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30739
2023-08-10[gdb/symtab] Dump qualified name of cooked_index_entryTom de Vries1-0/+3
When doing "maint print objfiles" for the exec of test-case gdb.dwarf2/pr13961.exp, we get: ... [25] ((cooked_index_entry *) 0x37b25d0) name: foo canonical: foo DWARF tag: DW_TAG_class_type flags: 0x0 [] DIE offset: 0x2a parent: ((cooked_index_entry *) 0) [26] ((cooked_index_entry *) 0x37b2630) name: foo canonical: foo DWARF tag: DW_TAG_class_type flags: 0x0 [] DIE offset: 0x25 parent: ((cooked_index_entry *) 0x37b25d0) [foo] ... By following the parent links in the text, we can conclude that the qualified name of DIE 0x25 is foo::foo (which is incorrect, that's PR symtab/30739). But it's not evident, and also hard to verify in a test-case. Add dumping of the qualified name, such that we have: ... [25] ((cooked_index_entry *) 0x333b5d0) name: foo canonical: foo qualified: foo DWARF tag: DW_TAG_class_type flags: 0x0 [] DIE offset: 0x2a parent: ((cooked_index_entry *) 0) [26] ((cooked_index_entry *) 0x333b630) name: foo canonical: foo qualified: foo::foo DWARF tag: DW_TAG_class_type flags: 0x0 [] DIE offset: 0x25 parent: ((cooked_index_entry *) 0x333b5d0) [foo] ... Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2023-08-10Fix gdb.ada/O2_float_param.exp for PowerPCCarl Love1-1/+8
The frame command on Power pc prints the address in hex between the #0 and in calle.increment. For example (gdb) frame #0 0x0000000010010a88 in callee.increment (val=val@entry=99.0, msg=...) at /home/.../gdb/testsuite/gdb.ada/O2_float_param/callee.adb:19 19 procedure Increment (Val : in out Float; Msg: String) is The printing of the address for the frame is done by function print_frame in gdb/stack.c. If SAL.IS_stmt is false for the frame, function frame_show_address returns true and print_frame prints the address. Currently, SAL.IS is false on PowerPC and true on X86-64. Update the set re string to accept the hex address if it exits. Fixes two failures on PowerPC. Patch tested on Power10 with no new regressions. Approved-By: Tom Tromey <tom@tromey.com>
2023-08-10Change py-thread-exited.exp to work with gdbserverTom Tromey2-5/+13
gdbserver does not notify gdb of new threads when they are created. I'm not sure if this is documented anywhere, but it is mentioned on this page: https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity Search for "Finding new threads in the inferior". This behavior is a bit unfortunate -- I would think that it would be better to arrange for such notification if something on the gdb side is interested. Meanwhile, this patch fixes py-thread-exited.exp to work around this problem. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30677
2023-08-10Pass unique_ptr to add_thread_with_infoTom Tromey5-7/+12
This changes add_thread_with_info to accept a unique_ptr, making it clear that it takes ownership of the passed-in pointer. I can't test the AIX or Darwin changes, but I think they are relatively obvious.
2023-08-10aarch64: Enable Cortex-A520 CPURichard Ball3-0/+7
This patch adds support for the Cortex-A520 CPU to gas. No regressions on aarch64-none-elf. gas/ChangeLog: * NEWS: Update docs. * config/tc-aarch64.c: Add Cortex-A520. * doc/c-aarch64.texi: Update docs.
2023-08-10[gdb/testsuite] Fix gdb.dwarf2/enqueued-cu-base-addr.exp with ↵Tom de Vries1-1/+1
cc-with-gnu-debuglink When running test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board cc-with-gnu-debuglink, I run into: ... (gdb) PASS: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo maint print symbols -objfile enqueued-cu-base-addr^M (gdb) FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found ... The problem is that the CU we're trying to print is in objfile enqueued-cu-base-addr.debug instead of enqueued-cu-base-addr. Fix this by replacing "-objfile enqueued-cu-base-addr" with "-source cu2". Tested on x86_64-linux.
2023-08-10[gdb/testsuite] Improve failure mode in gdb.dwarf2/enqueued-cu-base-addr.expTom de Vries1-1/+9
I ran test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board cc-with-debug-names, and ran into: ... FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo (GDB internal error) FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found ... The first FAIL is a known issue, PR symtab/29572. The following FAIL is a consequence of the first FAIL, so require for the second test that the first test passes. Tested on x86_64-linux, with target boards unix and cc-with-debug-names.
2023-08-10[gdb/symtab] Fix assertion in write_debug_namesTom de Vries1-1/+1
When running test-case gdb.dwarf2/pr13961.exp with target-board cc-with-debug-names, I run into: ... Running gdb.dwarf2/pr13961.exp ... gdb compile failed, gdb/dwarf2/index-write.c:1305: internal-error: \ write_debug_names: Assertion `counter == per_bfd->all_units.size ()' failed. ... This is a regression since commit 542a33e348a ("Only use the per-BFD object to write a DWARF index"), which did: ... - gdb_assert (counter == per_objfile->per_bfd->all_comp_units.size ()); + gdb_assert (counter == per_bfd->all_units.size ()); ... Fix this by reverting to using all_comp_units: ... gdb_assert (counter == per_bfd->all_comp_units.size ()); ... Tested on x86_64-linux, using target boards unix and cc-with-debug-names. PR symtab/30741 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30741
2023-08-10Automatic date update in version.inGDB Administrator1-1/+1
2023-08-09bpf: use w regs in 32-bit non-fetch atomic pseudo-cDavid Faust4-19/+19
The 32-bit non-fetching atomic instructions treat the source register as 32-bits, which means in the pseudo-c syntax the "w" registers should be used rather than the "r" registers. opcodes/ * bpf-opc-c (bpf_opcodes): Use %sw for AAD32, AOR32, AAND32 and AXOR32 pseudo-c dialect asm templates. gas/ * testsuite/gas/bpf/atomic-be-pseudoc.d: Use "w" for source reg in non-fetching 32-bit atomic instructions. * testsuite/gas/bpf/atomic-pseudoc.d: Likewise. * testsuite/gas/bpf/atomic-pseudoc.s: Likewise.
2023-08-09gdb, breakpoint: add breakpoint location debugging logsMihails Strasuns4-0/+126
Add new commands: set debug breakpoint on|off show debug breakpoint This patch introduces new debugging information that prints breakpoint location insertion and removal flow. The debug output looks like: ~~~ (gdb) set debug breakpoint on (gdb) disassemble main Dump of assembler code for function main: 0x0000555555555129 <+0>: endbr64 0x000055555555512d <+4>: push %rbp 0x000055555555512e <+5>: mov %rsp,%rbp => 0x0000555555555131 <+8>: mov $0x0,%eax 0x0000555555555136 <+13>: pop %rbp 0x0000555555555137 <+14>: ret End of assembler dump. (gdb) break *0x0000555555555137 Breakpoint 2 at 0x555555555137: file main.c, line 4. [breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT (gdb) c Continuing. [breakpoint] update_global_location_list: insert_mode = UGLL_INSERT [breakpoint] insert_bp_location: Breakpoint 2 (0x5565daddb1e0) at address 0x555555555137 in main at main.c:4 [breakpoint] insert_bp_location: Breakpoint -2 (0x5565dab51c10) at address 0x7ffff7fd37b5 [breakpoint] insert_bp_location: Breakpoint -5 (0x5565dab68f30) at address 0x7ffff7fe509e [breakpoint] insert_bp_location: Breakpoint -7 (0x5565dab694f0) at address 0x7ffff7fe63f4 [breakpoint] remove_breakpoint_1: Breakpoint 2 (0x5565daddb1e0) at address 0x555555555137 in main at main.c:4 due to regular remove [breakpoint] remove_breakpoint_1: Breakpoint -2 (0x5565dab51c10) at address 0x7ffff7fd37b5 due to regular remove [breakpoint] remove_breakpoint_1: Breakpoint -5 (0x5565dab68f30) at address 0x7ffff7fe509e due to regular remove [breakpoint] remove_breakpoint_1: Breakpoint -7 (0x5565dab694f0) at address 0x7ffff7fe63f4 due to regular remove Breakpoint 2, 0x0000555555555137 in main () at main.c:4 4 } ~~~ Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
2023-08-09Automatic date update in version.inGDB Administrator1-1/+1
2023-08-09Rename bfd_bread and bfd_bwriteAlan Modra93-965/+928
These were renamed from bfd_read and bfd_write back in 2001 when they lost an unnecessary parameter. Rename them back, and get rid of a few casts that are only needed without prototyped functions (K&R C).
2023-08-09Add ld makefile dependenciesAlan Modra2-3/+6
* Makefile.am (EXTRA_ld_new_SOURCES): Add pep-dll-aarch64.c and pep-dll-x86_64.c. * Makefile.in: Regenerate.
2023-08-09PR30724, cygwin ld performance regression since 014a602b86Alan Modra3-0/+67
According to the reporter of this bug the newlib fseek implementation is likely slowed down by locking and fflush, only attempting to optimise seeks when the file is opened read-only. Thus when writing the output we get a dramatic slowdown due to commit 014a602b86. PR 30724 * bfd.c (enum bfd_last_io): New. (struct bfd): Add last_io field. * bfd-in2.h: Regenerate. * bfd-io.c (bfd_bread, bfd_bwrite): Force seek if last_io is opposite direction. (bfd_seek): Reinstate optimisation for seek to same position.
2023-08-09[gdb/build] Use move capture in gdb_demangleTom de Vries1-1/+7
Use move capture in gdb_demangle when compiling for c++14 or higher, to save a std::string copy. Tested on x86_64-linux. Reported-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
2023-08-08ld: Fix retain7a.d XFAIL/notarget entry for hppaSam James1-1/+1
PR 30733 * ld/testsuite/ld-elf/retain7a.d: Fix XFAIL entry for hppa to match hppa{1.1,2.0}*, like hppa2.0-unknown-linux-gnu which Gentoo uses. Signed-off-by: Sam James <sam@gentoo.org>
2023-08-08ld: Fix relocatable.d XFAIL/notarget entry for hppaSam James1-1/+1
PR 30734 * ld/testsuite/ld-elf/relocatable.d: Fix notarget entry for hppa to match hppa{1.1,2.0}*, like hppa2.0-unknown-linux-gnu which Gentoo uses. Signed-off-by: Sam James <sam@gentoo.org>
2023-08-08Update my name in maintainers fileGuinevere Larsen1-1/+1
2023-08-08Guard against killing unrelated processes in amd64-disp-step.expRainer Orth1-1/+6
When testing current gdb trunk on Solaris/amd64, the whole session was reliably terminated by make check. I could trace this to the following entry in gdb.arch/amd64-disp-step/gdb.log: FAIL: gdb.arch/amd64-disp-step.exp: add into rcx: send_signal=on: get inferior pid Executing on target: kill -ALRM -1 (timeout = 300) builtin_spawn -ignore SIGHUP kill -ALRM -1 If $inferior_pid doesn't refer to a single process for some reason, this kill would terminate either a process group or the whole session. This patch avoids this by ensuring that the pid arg is positive. Tested on amd64-pc-solaris2.11 and x86_64-pc-linux-gnu. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
2023-08-08[gdb/build] Fix build breaker with -std=c++11Tom de Vries1-1/+6
When building with -std=c++11 I run into: ... gdb/dwarf2/cooked-index.c: In member function \ ‘void cooked_index::start_writing_index(dwarf2_per_bfd*)’: gdb/dwarf2/cooked-index.c:469:10: error: lambda capture initializers only \ available with -std=c++14 or -std=gnu++14 [-Werror] ctx = std::move (ctx)] () ^~~ ... Fix this by capturing a copy instead when using -std=c++11: ... = gdb::thread_pool::g_thread_pool->post_task ([this, per_bfd, ctx] () ... Tested by building with and without -stdc=++11 on x86_64-linux. Reported-By: Tom Tromey <tom@tromey.com> Reviewed-by: John Baldwin <jhb@FreeBSD.org>
2023-08-08RISC-V: Update ratified 'Ztso' extension versionTsukasa OI1-1/+1
Because the 'Ztso' extension is now ratified, it has a version number of 1.0 (not 0.1). This commit updates the number. bfd/ChangeLog: * elfxx-riscv.c (riscv_supported_std_z_ext): Update the version number of the 'Ztso' extension since it's ratified.
2023-08-08Automatic date update in version.inGDB Administrator1-1/+1
2023-08-07gprofng: 30700 tmpdir/gp-collect-app_F test failsVladimir Mezentsev1-2/+2
gprofng/ChangeLog 2023-08-03 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> PR gprofng/30700 * testsuite/gprofng.display/gp-collect-app_F.exp: Fix -name argument for sub-experiment filtering.
2023-08-07RISC-V: move comment describing rules for riscv_opcodes[]Jan Beulich1-10/+10
It makes little sense to have this comment meanwhile over a hundred lines ahead of the array. In fact until spotting the comment, I was wondering why those pretty important aspects aren't spelled out anywhere.
2023-08-07gdb/fortran: Align intrinsic/variable precedenceRichard Bunt4-19/+163
Fortran allows variables and function to be named after language defined intrinsics as they are not reserved keywords. For example, the abs maths intrinsic can be hidden by a user declaring a variable called abs. The behavior before this patch was to favour the intrinsic, which meant that any variables named, for example "allocated", could not be inspected by GDB. This patch inverts this priority to bring GDB's behaviour closer to the Fortran language, where the user defined symbol can hide the intrinsic. Special care was need to prevent any C symbols from overriding either Fortran intrinsics or user defined variables. This was observed to be the case when GDB has access to symbols for abs from libm. This was solved by only allowing symbols not marked with language_fortran to be overridden. In total this brings the order of precedence to the following (highest first): 1. User defined Fortran variable or function. 2. Fortran intrinsic. 3. Symbols from languages other than Fortran. The sizeof intrinsic is now case insensitive. This is closer to the Fortran language. I believe this change is safe enough as it increases the acceptance of the grammar, rather than restricts it. I.e. it should not break any existing scripts which rely on it. Unless of course they rely on SIZEOF being rejected. GDB built with GCC 13. No test suite regressions detected. Compilers: GCC, ACfL, Intel, Intel LLVM, NVHPC; Platforms: x86_64, aarch64. Existing tests in gdb.fortran cover the invocation of intrinsics including: intrinsics.exp, shape.exp, rank.exp, lbound-ubound.exp. Approved-By: Tom Tromey <tom@tromey.com>
2023-08-07Automatic date update in version.inGDB Administrator1-1/+1