aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-01-16tidy binary, ihex and verilogAlan Modra3-62/+3
* binary.c (binary_sizeof_headers): Delete function. Define instead. * ihex.c (ihex_sizeof_headers): Likewise. (ihex_vec): Use _bfd_nosymbols for BFD_JUMP_TABLE_SYMBOLS. Delete now unused defines. * verilog.c: Delete unused defines.
2025-01-16genlink tidyAlan Modra2-34/+29
Some of the declarations in genlink.h are not used in current sources apart from needing them in linker.c, so delete and/or move them there. The patch also fixes a FIXME. It's actually quite easy to return a failure from a hash traversal function. * genlink.h (_bfd_generic_link_hash_newfunc): Delete. (_bfd_generic_link_output_symbols), (generic_write_global_symbol_info), (_bfd_generic_link_write_global_symbol): Move to.. * linker.c: ..here, making functions static. (generic_write_global_symbol_info): Add "failed". (_bfd_generic_final_link): Handle wginfo.failed. (_bfd_generic_link_write_global_symbol): Set wginfo->failed on memory failures and return false rather than aborting.
2025-01-16[gdb/testsuite] Fix timeouts in gdb.threads/step-over-thread-exit.expTom de Vries2-3/+11
Once in a while, I run into a timeout in test-case gdb.threads/step-over-thread-exit.exp: ... (gdb) continue^M Continuing.^M [New Thread 0xfffff7cff1a0 (LWP 2874854)]^M ^M Thread 97 "step-over-threa" hit Breakpoint 2, 0x0000000000410314 in \ my_exit_syscall () at gdb/testsuite/lib/my-syscalls.S:74^M 74 SYSCALL (my_exit, __NR_exit)^M (gdb) [Thread 0xfffff7cff1a0 (LWP 2874853) exited]^M FAIL: $exp: step_over_mode=displaced: non-stop=on: target-non-stop=on: \ schedlock=off: cmd=continue: ns_stop_all=0: iter 95: continue (timeout) ... I can reproduce it more frequently by running with taskset -c <slow core id>. Fix this by using -no-prompt-anchor. This requires us to add -no-prompt-anchor to proc gdb_test_multiple. Tested on aarch64-linux. PR testsuite/32489 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32489
2025-01-16[gdb/python] Run black on gdb/gdbarch_components.pyTom de Vries1-4/+1
The sourceware buildbot reported "python black formatter ( failure )" at commit b034bb38772 ("[gdb] Add gdbarch_dwarf2_reg_piece_offset hook"). Fix this by running the precommit hooks in a container with Python 3.11 using: ... $ pre-commit run --files gdb*/* ...
2025-01-15gdbserver: Fix build on MIPSSergio Durigan Junior1-1/+1
Commit 3470a0e144df6c01f8479fa649f43aa907936e7e inadvertently broke the build on MIPS because it's passing a non-existent "pid" argument to "proc->for_each_thread". This commit fixes the problem by removing the argument from the call. Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net>
2025-01-16Automatic date update in version.inGDB Administrator1-1/+1
2025-01-16x86 relr memory leaksAlan Modra1-3/+9
This fixes some x86 memory leaks. I think it would be possible to free the relr data in _bfd_elf_x86_finish_relative_relocs if we wanted to reclaim some memory earlier, but for tidying after errors we likely would need to free in the hash_table_free function anyway. _bfd_x86_elf_link_relax_section is called via bfd_relax_section, ie. whenever relaxation is enabled. This is a waste of time if dt_relr relocs are not enabled since the function is there only to handle relr. * elfxx-x86.c (elf_x86_link_hash_table_free): Free relr data. (_bfd_x86_elf_link_relax_section): Return early if !info->enable_dt_relr. Do set "again" false before early returns.
2025-01-16Tidy elf_mmap_section_contentsAlan Modra1-13/+6
It is simpler to clear the buffer pointer in the caller than pass a param that controls clearing. * elf.c (elf_mmap_section_contents): Remove final_link param. (_bfd_elf_mmap_section_contents): Instead set *buf to NULL here. (_bfd_elf_link_mmap_section_contents): Adjust.
2025-01-16elf_x86_64_scan_relocs error pathsAlan Modra1-6/+12
Fix some memory leaks. * elf64-x86-64.c (elf_x86_64_scan_relocs): Ensure error return paths that should free relocs go via error_return.
2025-01-15Add support for IMPORT_CONST in ILF (MSVC style) import librariesMartin Storsjö1-7/+6
This is a very strange and obsolete kind of import type; it is used for imported data just like IMPORT_DATA - but with an extra odd caveat. The behaviour is explained at [1]; generating such import libraries with current MSVC tools produces "warning LNK4087: CONSTANT keyword is obsolete; use DATA". While obsolete, some import libraries within the Microsoft WDK (Windows Driver Kit) do contain such symbols, which currently are ignored by binutils and produce warnings about "file format not recognized". For IMPORT_CONST for a DLL exported symbol "foo", we should provide the import library symbols "__imp_foo" and "foo". For IMPORT_DATA, we only provide "__imp_foo", and for IMPORT_CODE, "foo" points at a thunk. The odd/surprising thing for IMPORT_CONST is that the "foo" symbol also points at the same thing as "__imp_foo", i.e. directly at the IAT entry. [1] https://learn.microsoft.com/en-us/cpp/build/importing-using-def-files Signed-off-by: Martin Storsjö <martin@martin.st>
2025-01-15aarch64: GCS tests for linking issues with dynamic objectsMatthieu Longo18-0/+247
2025-01-15aarch64: check GCS feature in GNU properties of input dynamic objectsMatthieu Longo5-31/+185
The Guarded Control Stack (GCS) feature requires that two things: - at static link time, all the input objects of a link unit have to be compatible with GCS. - at runtime, the executable and the shared libraries which it depends on have to be compatible with GCS. Both of those criteria are checked with the GCS feature stored in the GNU property note. The previous patch, adding support for the GCS feature check in GNU note properties for input objects, ignored the input dynamic objects. Although this support was better than no check, it was still delaying the detection of compatibility issues up to the runtime linker. In order to help the developer in detecting such an incompatibility issue as early as possible, this patch adds a check for input dynamic objects lacking the GCS marking. This check can be controlled via the linker option '-z gcs-report-dynamic[=none|warning|error]'. By default, if the option is omitted, it inherits the value from '-z gcs-report'. However, the inherited value is capped to 'warning' as a user might want to only report errors in the currently built module, and not the shared dependencies. If a user also wants to error on GCS issues in the shared libraries, '-z gcs-report-dynamic=error' will have to be specified explicitly.
2025-01-15gdb: boolify the 'in_g_packet' field of remote's 'packet_reg'Tankut Baris Aktemur1-4/+4
Boolify the 'in_g_packet' of the 'packet_reg' struct that is used in remote.c.
2025-01-15gdbserver: remove an obsolete comment in tracepoint.ccTankut Baris Aktemur1-2/+0
The comment /* Functions local to this file. */ has somehow been positioned above struct definitions, not functions. Some static function declarations are given after the structs, to where the comment could be moved, but the comment is not really helpful. Therefore remove it.
2025-01-15gdbserver: remove forward declaration of struct tracepoint_hit_ctxTankut Baris Aktemur1-2/+0
Remove the unnecessary forward declaration for `struct tracepoint_hit_ctx`.
2025-01-15[gdb/tdep] Fix gdb.base/store.exp on s390xTom de Vries1-0/+23
On s390x-linux, I get: ... (gdb) print l^M $29 = 0^M (gdb) FAIL: gdb.base/store.exp: var doublest l; print old l, expecting -1 ... So, we're in wack_doublest trying to print l, which is a copy of parameter u: ... register doublest l = u, r = v; ... which does have the expected value: ... (gdb) p u $1 = -1 ... which is a long double, 16 bytes and looks like this: ... (gdb) p /x u $3 = 0xbfff0000000000000000000000000000 ... Parameter u is passed in two registers: ... <2><6a5>: Abbrev Number: 15 (DW_TAG_formal_parameter) <6a6> DW_AT_name : v <69e> DW_AT_location : 6 byte block: 50 93 8 51 93 8 \ (DW_OP_reg0 (r0); DW_OP_piece: 8; DW_OP_reg1 (r1); DW_OP_piece: 8) ... and indeed we find the msw in r0 and the lsw in r1: ... (gdb) p /x $r0 $4 = 0xbfff000000000000 (gdb) p /x $r1 $5 = 0x0 (gdb) ... Likewise, variable l consists of two registers: ... <2><6b5>: Abbrev Number: 13 (DW_TAG_variable) <6b6> DW_AT_name : l <6be> DW_AT_location : 6 byte block: 68 93 8 69 93 8 \ (DW_OP_reg24 (f8); DW_OP_piece: 8; DW_OP_reg25 (f10); DW_OP_piece: 8) ... and we find the same values there: ... (gdb) p /x $f8 $6 = 0xbfff000000000000 (gdb) p /x $f10 $7 = 0x0 ... So, we get the expected results when fetching the value from two gprs, but not when fetching the value from two fprs. When fetching the values from the two fprs, we stumble upon a particularity of the DWARF register numbers as defined by the s390x ABI [1]: dwarf register 24 maps to both floating-point register f8 (8 bytes), and vector register v8 (16 bytes). In s390_dwarf_reg_to_regnum, it's determined which of the two is chosen, and if available vector registers are preferred over floating-point registers, so v8 is chosen, and used to fetch the value. Since the size of the DW_OP_piece is 8 bytes, and the register size is 16 bytes, this bit in rw_pieced_value is activated: ... /* If the piece is located in a register, but does not occupy the entire register, the placement of the piece within that register is defined by the ABI. */ bits_to_skip += 8 * gdbarch_dwarf2_reg_piece_offset (arch, gdb_regnum, p->size / 8); ... but since the default implemention default_dwarf2_reg_piece_offset does not match the s390x ABI, we get the wrong answer. This is a known problem, see FOSDEM 2018 presentation "DWARF Pieces And Other DWARF Location Woes" [2]. Fix this by adding s390_dwarf2_reg_piece_offset, roughly implementing the same logic as in s390_value_from_register. Tested on s390x-linux. Approved-By: Tom Tromey <tom@tromey.com> [1] https://github.com/IBM/s390x-abi [2] https://archive.fosdem.org/2018/schedule/event/dwarfpieces
2025-01-15[gdb] Add gdbarch_dwarf2_reg_piece_offset hookTom de Vries6-6/+91
In rw_pieced_value, when reading/writing part of a register, DW_OP_piece and DW_OP_bit_piece are handled the same, but the standard tells us: - DW_OP_piece: if the piece is located in a register, but does not occupy the entire register, the placement of the piece within that register is defined by the ABI. - DW_OP_bit_piece: if the location is a register, the offset is from the least significant bit end of the register. Add a new hook gdbarch_dwarf2_reg_piece_offset that allows us to define the ABI-specific behaviour for DW_OP_piece. The default implementation of the hook is the behaviour of DW_OP_bit_piece, so there should not be any functional changes. Tested on s390x-linux. Approved-By: Tom Tromey <tom@tromey.com>
2025-01-15[gdb/symtab] Add dwarf_expr_piece.opTom de Vries2-5/+11
Add a new field "dwarf_location_atom op" to dwarf_expr_piece to keep track of which dwarf_location_atom caused a dwarf_expr_piece to be added. This is used in the following patch. Tested on s390x-linux. Approved-By: Tom Tromey <tom@tromey.com>
2025-01-15Fix help formatting for string and filename optionsTom Tromey2-2/+8
I happened to notice that "help add-inferior" said: -execFILENAME FILENAME is the file name of the executable to use as the main program. This is missing a space after "-exec". This patch fixes the bug. If ok'd on time I plan to check this in to the gdb-16 branch as well. Approved-by: Kevin Buettner <kevinb@redhat.com>
2025-01-15gdbserver: LoongArch: Add hardware watchpoint/breakpoint supportHui Li2-0/+267
LoongArch defines hardware watchpoint functions for fetch and load/store operations, the related support for gdb was added in the following two commit c1cdee0e2c17 ("gdb: LoongArch: Add support for hardware watchpoint") commit 6ced1278fc00 ("gdb: LoongArch: Add support for hardware breakpoint") Now, add hardware watchpoint and breakpoint support for gdbserver on LoongArch. Here is a simple example $ cat test.c #include <stdio.h> int a = 0; int b = 0; int main() { printf("start test\n"); a = 1; printf("a = %d\n", a); a = 2; printf("a = %d\n", a); b = 2; printf("b = %d\n", b); return 0; } $ gcc -g test.c -o test Execute on the target machine: $ gdbserver 192.168.1.100:1234 ./test Execute on the host machine: $ gdb ./test ... (gdb) target remote 192.168.1.100:1234 ... (gdb) b main Breakpoint 1 at 0x1200006b8: file test.c, line 6. (gdb) c Continuing. ... Breakpoint 1, main () at test.c:6 6 printf("start test\n"); (gdb) watch a Hardware watchpoint 2: a (gdb) hbreak 11 Hardware assisted breakpoint 3 at 0x120000700: file test.c, line 11. (gdb) c Continuing. Hardware watchpoint 2: a Old value = 0 New value = 1 main () at test.c:8 8 printf("a = %d\n", a); (gdb) c Continuing. Hardware watchpoint 2: a Old value = 1 New value = 2 main () at test.c:10 10 printf("a = %d\n", a); (gdb) c Continuing. Breakpoint 3, main () at test.c:11 11 b = 2; (gdb) c Continuing. [Inferior 1 (process 696656) exited normally] Output on the target machine: Process ./test created; pid = 696708 Listening on port 1234 Remote debugging from host 192.168.1.200, port 60742 start test a = 1 a = 2 b = 2 Child exited with status 0 Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2025-01-15gdb: LoongArch: Adjust loongarch_stopped_data_address()Hui Li3-27/+32
loongarch_stopped_data_address() is a common function and will be used by gdb and gdbserver, so move its definition from gdb/loongarch-linux-nat.c to gdb/nat/loongarch-hw-point.c. This is preparation for later gdbserver patch on LoongArch and is no effect for the current code. Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2025-01-15gdb: LoongArch: Adjust loongarch_{get,remove}_debug_reg_state()Hui Li3-30/+24
loongarch_{get,remove}_debug_reg_state() are used as helper functions by loongarch_linux_nat_target. We should move their definitions from gdb/nat/loongarch-linux-hw-point.c to gdb/loongarch-linux-nat.c. Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2025-01-15gdb: LoongArch: Remove loongarch_lookup_debug_reg_state()Hui Li2-18/+0
loongarch_lookup_debug_reg_state() is a unused function, so we can remove it. Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2025-01-15ld: Update gld${EMULATION_NAME}_place_orphan for PE/PEPH.J. Lu2-22/+42
Similar to ldelf_place_orphan, initialize hold from orig_hold at run-time in PE and PEP gld${EMULATION_NAME}_place_orphan. * emultempl/pe.em (orphan_init_done): Make it file scope. (gld${EMULATION_NAME}_finish): Set orphan_init_done to false for the object-only output. (gld${EMULATION_NAME}_place_orphan): Rename hold to orig_hold. Initialize hold from orig_hold at run-time. * emultempl/pep.em (orphan_init_done): Make it file scope. (gld${EMULATION_NAME}_finish): Set orphan_init_done to false for the object-only output. (gld${EMULATION_NAME}_place_orphan): Rename hold to orig_hold. Initialize hold from orig_hold at run-time. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-01-15ld: Correct ldelf_place_orphanH.J. Lu1-7/+5
Remove the extra for loop and if statement in ldelf_place_orphan. * ldelf.c (ldelf_place_orphan): Remove the extra for loop and if statement. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-01-15gdb/testsuite: make gdb.reverse/i386-avx-reverse.exp require also avx2Jan Vrany2-0/+46
The test gdb.reverse/i386-avx-reverse.exp requires CPU to have AVX instructions but it actually also uses AVX2 instructions (like vpcmpeqd). This caused the test to fail on CPUs that have AVX but not AVX2. This commit adds check for AVX2. Tested on Intel Xeon CPU E3-1265L (no AVX2) and Intel Core i7-1355U (has AVX2).
2025-01-15bfd_get_unique_section_name leakAlan Modra1-1/+1
The name returned by this function is used in asection->name, so needs to persist until a bfd is closed. * section.c (bfd_get_unique_section_name): Return an alloc'd string.
2025-01-15Free symtab_hdr.contents and a cache_size correctionAlan Modra2-2/+4
symtab_hdr.contents looks to be malloc'd memory, except in one case. Change that one case to also be malloc'd and free when we are done. * elf.c (swap_out_syms): bfd_malloc outbound_syms. (_bfd_elf_free_cached_info): Free symtab_hdr.contents. * elflink.c (init_reloc_cookie): Correct cache_size. locsyms is an array of Elf_Internal_Sym.
2025-01-15elflink.c memory leaksAlan Modra1-67/+27
Many targets leaked parts of the elf_link_hash_table. Fix that by making _bfd_elf_link_hash_table_init set up hash_table_free correctly, so that targets that extend elf_link_hash_table without adding anything that needs freeing, will use _bfd_elf_link_hash_table_free. * elflink.c (elf_link_add_object_symbols): Always free nondeflt_vers. Don't return false without freeing. (_bfd_elf_link_hash_table_init): Set hash_table_free here.. (_bfd_elf_link_hash_table_create): ..rather than here. (elf_link_swap_symbols_out): Don't free strtab here.. (elf_link_add_object_symbols): ..do so here instead. Don't omit freeing on some error return paths.
2025-01-15sframe memory leakAlan Modra1-5/+4
This is another case where an array isn't freed anywhere and needs to persist a while, so allocate it with bfd_alloc. * elf-sframe.c (sframe_decoder_init_func_bfdinfo): Add abfd param. bfd_zalloc std_func_bfdinfo. (_bfd_elf_parse_sframe): Adjust to suit.
2025-01-15eh-frame memory leaksAlan Modra2-6/+8
The set_loc array attached to eh-frame sec_info isn't freed, and is used in _bfd_elf_eh_frame_section_offset. Rather than finding a suitable late stage of linking past any b_e_e_f_s_o use, I decided this might as well persist until the bfd is closed. Some memory is freed in _bfd_elf_discard_section_eh_frame_hdr, but the function isn't always called, so fix that too. * elf-eh-frame.c (_bfd_elf_parse_eh_frame): bfd_alloc the set_loc array. (find_merged_cie): Use bfd_malloc rather than malloc. (_bfd_elf_discard_section_eh_frame_hdr): Move condition under which this function does anything except free memory from.. * elflink.c (bfd_elf_discard_info): ..here.
2025-01-15Fix known minor objdump leakAlan Modra1-2/+4
* objdump.c (main): Free disassembler_options.
2025-01-15gdbserver: convert program_args to a single stringAndrew Burgess8-30/+25
This commit changes how gdbserver stores the inferior arguments from being a vector of separate arguments into a single string with all of the arguments combined together. Making this change might feel a little strange; intuitively it feels like we would be better off storing the arguments as a vector, but this change is part of a larger series of work that aims to improve GDB's inferior argument handling. The full series was posted here: https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com But asking people to review a 14 patch series in unreasonable, so I'm instead posting the patches in smaller batches. This patch can stand alone, and I do think this change makes sense on its own: First, GDB already stores the inferior arguments as a single string, so doing this moves gdbserver into line with GDB. The common code into which gdbserver calls requires the arguments to be a single string, so currently each target's create_inferior implementation merged the arguments anyway, so all this commit really does is move the merging up the call stack, and store the merged result rather than storing the separate parts. However, the biggest reason for why this commit is needed, is an issue with passing arguments from GDB to gdbserver when starting a new inferior. Consider: (gdb) set args $VAR (gdb) run ... When using a native target the inferior will see the value of $VAR expanded by the shell GDB uses to start the inferior. However, if using an extended-remote target the inferior will see literally $VAR, the unexpanded name of the variable, the reason for this is that, although GDB sends '$VAR' to gdbserver, when gdbserver receives this, it converts this to '\$VAR', which prevents the variable from being expanded by the shell. The reason for this is that construct_inferior_arguments escapes all special shell characters within its arguments, and it is construct_inferior_arguments that is used to combine the separate arguments into a single string. In the future I will change construct_inferior_arguments so that it can apply different escaping strategies. When this happens we will want to escape arguments coming from the gdbserver command line differently than arguments coming from GDB (via a vRun packet), which means we need to call construct_inferior_arguments earlier, at the point where we know if the arguments came from the gdbserver command line, or from the vRun packet. This argument escaping issue is discussed in PR gdb/28392. This commit doesn't fix any issues, nor does it change construct_inferior_arguments to actually do different escaping, that will all come later. This is purely a restructuring. There should be no user visible changes after this commit. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392 Tested-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-01-15PR32560 stack-buffer-overflow at objdump disassemble_bytesAlan Modra1-4/+6
There's always someone pushing the boundaries. PR 32560 * objdump.c (MAX_INSN_WIDTH): Define. (insn_width): Make it an unsigned long. (disassemble_bytes): Use MAX_INSN_WIDTH to size buffer. (main <OPTION_INSN_WIDTH>): Restrict size of insn_width.
2025-01-15[gdb/symtab] Require current language before symbol lookupsTom de Vries1-0/+41
Test-case gdb.python/py-symbol.exp fails with various target boards, including fission and gold-gdb-index. The problem here is that, in this test, the current language is still unset (i.e., lazy) when the symbol lookup is done. It is eventually set deep in the lookup -- but this then requires a reentrant symbol lookup, which fails. (DWARF symbol lookup is not reentrant.) Fix this by: - detecting symbol lookup reentrance using an assert, and - requiring the current language to be set when entering symbol lookup. Tested on x86_64-linux. Co-Authored-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com> PR symtab/32490 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32490
2025-01-15Re: elf: Add GNU_PROPERTY_MEMORY_SEAL gnu propertyAlan Modra9-40/+30
Don't run tests on targets without required support. Supply an explicit -z nomemory-seal rather then relying on the harness default, to lessen confusion for people looking at the test. Don't use numeric labels for the sake of hppa64*-hpux, and run the tests there. Remove incorrect comment about source editing. Also, xfail rather than notarget failing tests with a list of target triples so we check that the list is correct.
2025-01-15Re: ld: Add --enable-memory-seal configure optionAlan Modra1-3/+2
Commit 80dc29527ff9 accidentally removed an assignment to board_flags, resulting in tcl errors 'can't read "board_flags": no such variable' on sh4-linux-gnu. Fix that by calling [get_board_flags] in the condition rather than reinstating the removed line since it seems most configurations don't have a null STATIC_LDFLAGS. Do the same in another similar test too.
2025-01-15Automatic date update in version.inGDB Administrator1-1/+1
2025-01-14Use bool in decode_line_2_itemTom Tromey1-4/+3
This changes decode_line_2_item::selected to bool. There was no benefit to keeping this as a bitfield, so I removed that. Note that the constructor already uses bool here. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-01-14Use bool for parameter of add_sal_to_salsTom Tromey1-8/+8
This changes add_sal_to_sals to use 'bool' rather than 'int'. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-01-14Use filename style in "show" commandsTom Tromey2-4/+10
I found a few filename-related "show" commands that do not use the filename style when displaying the file. This patch fixes the oversight. Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-01-15ld: Parse linker script only onceH.J. Lu3-40/+28
Parsing linker script twice caused FAIL: ld-plugin/lto-3r FAIL: ld-plugin/lto-5r FAIL: PR ld/19317 (2) for x86_64-w64-mingw32 with the linker error: ./ld-new:built in linker script:27 assignment to location counter invalid outside of SECTIONS ldscripts/i386pep.xr has 24 .rdata : 25 { 26 *(.rdata) 27 . = ALIGN(4); 28 /* .ctors & .dtors */ 29 /* .CRT */ 30 /* ___crt_xl_end__ is defined in the TLS Directory support code */ 31 } Remove ld_parse_linker_script to parse linker script only once. * ldlang.c (cmdline_emit_object_only_section): Don't call ld_parse_linker_script. * ldmain.c (main): Fold ld_parse_linker_script. (ld_parse_linker_script): Removed. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-01-15ld: Call cmdline_check_object_only_section only if plugin is enabledH.J. Lu1-1/+1
* ldmain.c (add_archive_element): Call cmdline_check_object_only_section only if BFD_SUPPORTS_PLUGINS is defined. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-01-14gdb/jit: fix jit-reader linetable integrityYang Liu2-0/+14
The custom linetable functionality in GDB's JIT Interface has been broken since commit 1acc9dca423f78e44553928f0de839b618c13766. In that commit, linetables were made independent from the objfile, which requires objfile->section_offsets to be initialized. However, section_offsets were never initialized in objfiles generated by GDB's JIT Interface with custom jit-readers, leading to GDB crashes when stepping into JITed code blocks with the following command already executed: jit-reader-load libmygdbjitreader.so This patch fixes the issue by initializing the minimum section_offsets required for linetable parsing procedures. A minimal test is included. The test sets up some very simple line table information, which is enough to trigger the bug. However, the line table information is crafted such that none of the line table entries will end up being displayed in GDB's output when the test is run, as such, none of the expected output actually changes. It might be nice in the future to extend some of the jit tests to actually test hitting line table entries added via the jit reader. Approved-By: Tom Tromey <tom@tromey.com>
2025-01-14gdb/record: add support for AVX floating point arithmetic instructionsGuinevere Larsen3-2/+169
This commit adds support for the following types of instructions relating to floating poitn values: add, mul, sub, min, div, max. These are supported with packed or single values, and single or double precision. Some of the instructions had opcode clashes, however, considering the mechanics of recording the registers is the same on both instructions, this is just marked with a comment. Approved-By: Guinevere Larsen <guinevere@redhat.com>
2025-01-14gdb/record: add support for floating point vunpck instructionsGuinevere Larsen3-4/+50
This commit adds support for the AVX instructions vunpck[l|h][ps|pd] instructions, which was pretty straightforward. This commit also fixes a mistake in the test, where "record stop" was used after the recording was already stopped, if it failed during vpunpck_test recording. It also improved the documentation at the start of the relevant .c function. Approved-By: Guinevere Larsen <guinevere@redhat.com>
2025-01-14gdb/record: add support for floating point vmov instructionsGuinevere Larsen3-0/+151
This commit updates GDB's record-full to be able to record vmov[ss|sd] and vmov [u|a] [ps|pd] AVX instructions, and tests for them. Unlike the vmovdq[u|a] instructions, the aligned and unalgined versions of vmov?[ps|pd] have different opcodes. The mechanics of recording them is the same, but the aligned version has opcodes 0x28 and 0x29, while the unaligned has the same opcode as vmov[ss|sd] instruction, 0x10 and 0x11. Approved-By: Guinevere Larsen <guinevere@redhat.com>
2025-01-14ld: regenerateSam James2-10/+9
80dc29527ff9b5179741c360418e77e5064f2b69 contained some changes from non-vanilla autoconf. Regenerate. ChangeLog: * config.in: Regenerate. * configure: Regenerate.
2025-01-14ld: Add --enable-memory-seal configure optionAdhemerval Zanella10-9/+102
Add --enable-memory-seal linker configure option to enable memory sealing (GNU_PROPERTY_MEMORY_SEAL) by default. Change-Id: I4ce4ff33657f0f09b1ceb06210b6fcaa501f1799
2025-01-14elf: Add GNU_PROPERTY_MEMORY_SEAL gnu propertyAdhemerval Zanella18-18/+235
The GNU_PROPERTY_MEMORY_SEAL gnu property is a way to mark binaries to be memory sealed by the loader, to avoid further changes of PT_LOAD segments (such as unmapping or change permission flags). This is done along with Linux kernel (the mseal syscall [1]), and C runtime supports to instruct the kernel on the correct time during program startup (for instance, after RELRO handling). This support is added along the glibc support to handle the new gnu property [2]. This is a opt-in security features, like other security hardening ones like NX-stack or RELRO. The new property is ignored if present on ET_REL objects, and only added on ET_EXEC/ET_DYN if the linker option is used. A gnu property is used instead of DT_FLAGS_1 flag to allow memory sealing to work with ET_EXEC without PT_DYNAMIC support (at least on glibc some ports still do no support static-pie). [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8be7258aad44b5e25977a98db136f677fa6f4370 [2] https://sourceware.org/pipermail/libc-alpha/2024-September/160291.html Change-Id: Id47fadabecd24be0e83cff45653f7ce9a900ecf4