aboutsummaryrefslogtreecommitdiff
path: root/bfd
AgeCommit message (Collapse)AuthorFilesLines
13 hoursAutomatic date update in version.inHEADmasterGDB Administrator1-1/+1
37 hoursAutomatic date update in version.inGDB Administrator1-1/+1
2 daysRemove Solaris/PowerPC supportRainer Orth2-2/+5
Solaris/PowerPC was a shortlived Solaris port with limited hardware support. It was released with Solaris 2.5.1 back in 1996, with support removed again only a year later in Solaris 2.6. Since this is long obsolete, this patch removes the remains of the support. Tested by a cross to ppc-unknown-linux-gnu to ascertain the build didn't get broken. 2025-09-15 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> bfd: * config.bfd <powerpc-*-solaris2*>: Remove. gas: * NEWS: Mention Solaris/PowerPC removal. * configure.ac <ppc-*-solaris*>: Remove. * configure: Regenerate. * configure.in: Regenerate. * configure.tgt <ppc-*-solaris*>: Remove. * config/tc-ppc.c (ppc_solaris_comment_chars): Remove. (ppc_eabi_comment_chars): Remove. (SOLARIS_P): Remove. (msolaris): Remove. (md_parse_option): Remove "solaris", "no-solaris" hangling. (md_show_usage): Likewise. (md_begin): Remove msolaris handling. * config/tc-ppc.h (ppc_comment_chars): Fix declaration. * stabs.c (s_stab_generic) [TC_PPC && OBJ_ELF]: Remove 4-arg .stabd support. * doc/as.texi (Overview, Target PowerPC options): Remove -msolaris, -mno-solaris. * doc/c-ppc.texi (PowerPC-Opts): Remove -msolaris, -mno-solaris. (PowerPC-Chars): Remove ! as line comment character. ld: * configure.tgt <powerpc*-*-solaris*>: Remove.
3 daysAutomatic date update in version.inGDB Administrator1-1/+1
3 daysRISC-V: Add support for sdtrig and ssstrict extensions.Dongyan Chen1-0/+5
This implements the sdtrig extension, version 1.0[1] and ssstrict extension, version 1.0[2]. [1]https://github.com/riscv/riscv-debug-spec/blob/main/Sdtrig.adoc [2]https://github.com/riscv/riscv-profiles/issues/173 bfd/ChangeLog: * elfxx-riscv.c: Added sdtrig and ssstrict v1.0, and imply rules. gas/ChangeLog: * NEWS: Updated for sdtrig and ssstrict. * testsuite/gas/riscv/imply.d: DItto. * testsuite/gas/riscv/imply.s: Ditto. * testsuite/gas/riscv/march-help.l: Ditto.
4 daysAutomatic date update in version.inGDB Administrator1-1/+1
5 daysAutomatic date update in version.inGDB Administrator1-1/+1
6 daysAutomatic date update in version.inGDB Administrator1-1/+1
7 daysAutomatic date update in version.inGDB Administrator1-1/+1
7 daysx86: Copy non_got_ref_without_indirect_extern_accessH.J. Lu1-0/+6
Copy non_got_ref_without_indirect_extern_access when copying indirect symbol for weak alias so that _bfd_x86_elf_adjust_dynamic_symbol will properly handle GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS. bfd/ PR ld/33409 * elfxx-x86.c (_bfd_x86_elf_copy_indirect_symbol): Copy non_got_ref_without_indirect_extern_access. ld/ PR ld/33409 * testsuite/config/default.exp (NO_DIRECT_EXTERN_ACCESS_CFLAGS): New. * testsuite/ld-elf/shared.exp: Run PR ld/33409 tests. * testsuite/ld-elf/pr33409a.c: New file. * testsuite/ld-elf/pr33409b.c: Likewise. * testsuite/ld-elf/pr33409c.c: Likewise. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
7 daysx86-64: Update R_X86_64_TPOFF32 error messageH.J. Lu1-1/+1
Change R_X86_64_TPOFF32 error message from relocation R_X86_64_TPOFF32 against symbol `foo' can not be used when making a shared object; replace local-exec with initial-exec TLS model to relocation R_X86_64_TPOFF32 against symbol `foo' can not be used when making a shared object; local-exec is incompatible with -shared bfd/ PR ld/33408 * elf64-x86-64.c (elf_x86_64_need_pic): Suggest "replace local-exec with initial-exec TLS model" for R_X86_64_TPOFF32. ld/ PR ld/33408 * testsuite/ld-x86-64/tls-le-pic-1-x32.d: Updated. * testsuite/ld-x86-64/tls-le-pic-1.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-2-x32.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-2.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-3-x32.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-3.d: Likewise. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
8 daysAutomatic date update in version.inGDB Administrator1-1/+1
8 daysx86-64: Fix misleading R_X86_64_TPOFF32 error messageH.J. Lu1-2/+4
R_X86_64_TPOFF32 relocation of local-exec TLS model can only be used in executable, not in a shared library, even if the source code is compiled with -fPIC. Change the linker error message from relocation R_X86_64_TPOFF32 against symbol `foo' can not be used when making a shared object; recompile with -fPIC to relocation R_X86_64_TPOFF32 against symbol `foo' can not be used when making a shared object; replace local-exec with initial-exec TLS model bfd/ PR ld/33408 * elf64-x86-64.c (elf_x86_64_need_pic): Suggest "replace local-exec with initial-exec TLS model" for R_X86_64_TPOFF32. (elf_x86_64_scan_relocs): Drop ABI_64_P check for R_X86_64_TPOFF32. ld/ PR ld/33408 * testsuite/ld-x86-64/tls-le-pic-1-x32.d: New file. * testsuite/ld-x86-64/tls-le-pic-1.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-1.s: Likewise. * testsuite/ld-x86-64/tls-le-pic-2-x32.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-2.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-2.s: Likewise. * testsuite/ld-x86-64/tls-le-pic-3-x32.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-3.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-3.s: Likewise. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
8 daysx86: Correct _bfd_x86_elf_copy_indirect_symbol commentsH.J. Lu1-1/+1
Since commit eeb2f20a764bee3a6a1edb9872467d044aaad848 Author: H.J. Lu <hjl.tools@gmail.com> Date: Fri Sep 1 13:03:40 2017 -0700 x86: Add _bfd_x86_elf_adjust_dynamic_symbol replaced elf_i386_adjust_dynamic_symbol with _bfd_x86_elf_copy_indirect_symbol, correct the comments. * elfxx-x86.c (_bfd_x86_elf_copy_indirect_symbol): Replace elf_i386_adjust_dynamic_symbol with _bfd_x86_elf_copy_indirect_symbol in comments. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
9 daysAutomatic date update in version.inGDB Administrator1-1/+1
10 daysAutomatic date update in version.inGDB Administrator1-1/+1
10 daysChange return value of _bfd_mmap_temporaryTom Tromey3-21/+19
_bfd_mmap_temporary will return MAP_FAILED in some cases, but only one caller was prepared for this. This caused a couple of issues in gdb. This patch chnages _bfd_mmap_temporary to always return NULL on failure. It also changes the logic to fall back to bfd_malloc if mmap fails. I took the opportunity to change some "(void *) -1" to MAP_FAILED where appropriate. Tested by "make check" in binutils, and also by applying a hack from bug 33354 to gdb and testing something approximating the original report. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32542 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33354
10 daysvms-alpha: sections array index sanity checksAlan Modra1-1/+7
Adds a couple of missing bound checks. * vms-alpha.c (alpha_vms_fix_sec_rel): Sanity check relocation section index. (alpha_vms_bfd_final_link): Assert that section index is sane.
10 daysvms-alpha: ehdr checksAlan Modra1-29/+28
I noticed that _bfd_vms_slurp_ehdr wrongly used buf_size (rather than rec_size) when sanity checking. * vms-alpha.c (_bfd_vms_slurp_ehdr): Don't allow access to uninitialised buffer memory. Tidy code generally, using remaining record length for sanity checks.
10 daysPR 33385 vms archivesAlan Modra3-0/+14
Commit 5c4ce239a3ab "Tidy bfdio to consistenly use containing archive" broke vms archive handling, which has some horrible hacks involving use of a special iovec for archive elements. Modify the generic archive handling code to not use the archive iovec when it differs from the element iovec. Also, various commits involving seek optimisation broke the vms archive handling, which needs to see a rewind on an archive element. * bfdio.c (bfd_read, bfd_write, bfd_tell, bfd_flush), (bfd_stat, bfd_seek, bfd_mmap): Do not use the archive bfd for IO when the archive and element iovec differ. * plugin.c (bfd_plugin_open_input), (bfd_plugin_close_file_descriptor): Likewise. * vms-lib.c (vms_lib_bopen): Force bfd_seek to call iovec seek.
10 daysPR 33385 unsupported relocsAlan Modra1-2/+2
Commit 96d3b80f5498 changed a couple of reloc functions to return false, and propagated the error. They previously did nothing, so revert to that sad state. * vms-alpha.c (alpha_vms_add_lw_reloc): Return true. (alpha_vms_add_qw_reloc): Likewise.
10 daysPR 33385 DST handlingAlan Modra1-23/+31
Commit 816995444667, a fix for a fuzzer testcase resulting in a buffer overflow, broke reading of DST. DST is a special case where a first pass over the section just sizes it. Commit a3c0896d80d2, another buffer overflow fix, wrongly removed a line incrementing DST record length. * vms-alpha.c (image_write): Don't do bounds check for sections in memory without contents. (evax_bfd_print_dst): Add one to length.
10 daysPR 33385 EOMAlan Modra1-2/+2
Another PR 21813 modification. * vmd-alpha.c (_bfd_vms_slurp_eeom): Allow 10 byte EOM. Don't set has_transfer or access fields past 10 bytes unless the entire EEOM is there.
10 daysPR 33385, Extended Image HeaderAlan Modra1-19/+15
This modifies some of the PR 21813 fixes, allowing for smaller EIHD. Not knowing any better, I chose to use EIHD__C_LENGTH as the minimum length. include/ * vms/eihd.h (EIHD__C_LENGTH): Comment. bfd/ * vms-alpha.c (_bfd_vms_slurp_eihd): Remove size check duplicating that done by the caller of this function. (alpha_vms_object_p): Allow smaller EIHD. (evax_bfd_print_image): Likewise. Don't print fields past the record size.
10 daysbfd: Add i386_pe_big_vec vector to win64 targetsJeffrey Knockel1-1/+1
251dae91074170036c1a76c5e5df1f45197d7feb added i386_pe_big_vec to win32 targets but did not add it to win64 ones. Adding i386_pe_big_vec vector to win64 targets fixes an issue where a 64-bit assembler on windows would fail to create bigobj files when operating with 32-bit word size. E.g., before this change, with a 64-bit toolchain: $ echo 'int main(void) { return 100; }' \ | gcc -m32 -Wa,-mbig-obj -x c -c -o main.o - $ objdump.exe -f main.o main.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 But after this change, the output file format is correctly bigobj: $ echo 'int main(void) { return 100; }' \ | gcc -m32 -Wa,-mbig-obj -x c -c -o main.o - $ objdump.exe -f main.o main.o: file format pe-bigobj-i386 architecture: i386, flags 0x0000003d: HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 Although the above multilib compilation issue was the motivation for this patch, this change has other positive consequences, such as allowing the 64-bit windows build of objdump to disassemble pe-bigobj-i386 format object files, etc. Signed-off-by: Jeffrey Knockel <jeff@jeffreyknockel.com>
11 daysAutomatic date update in version.inGDB Administrator1-1/+1
12 daysAutomatic date update in version.inGDB Administrator1-1/+1
13 daysAutomatic date update in version.inGDB Administrator1-1/+1
13 daysbfd: configure.ac: Fix mention of flag to enable 64-bit BFD in commentThiago Jung Bauermann2-2/+2
It was changed back in 1994. Fixing because it misled me into using the wrong flag in a build.
14 daysAutomatic date update in version.inGDB Administrator1-1/+1
2025-09-04RISC-V: Don't generate R_RISCV_RELATIVE if symbol referenced section is SH_ABSNelson Chu1-1/+2
It's werid if it's absolute symbol but have a relative reloc for got entry under pie. So don't generate relative reloc if symbol referenced section is SH_ABS. However, x86 allows the absolute symbol defined in linker script has a relative reloc, not sure if risc-v needs this or not.
2025-09-04RISC-V: Don't overwrite got entry to zero for IRELATIVE/RELATIVE relocationNelson Chu1-11/+5
Even the final result is correct since we encode the relocation into r_addend, so glibc won't need to get the content of got entry when resolving relative relocation, it still werid that finish_dynamic_symbol cleans what we filled in the relocate_section.
2025-09-04Automatic date update in version.inGDB Administrator1-1/+1
2025-09-03x86: Check plt_got_offset for lazy IBT PLTH.J. Lu2-4/+4
Lazy IBT PLT entries look like static const bfd_byte elf_i386_lazy_ibt_plt_entry[LAZY_PLT_ENTRY_SIZE] = { 0xf3, 0x0f, 0x1e, 0xfb, /* endbr32 */ 0x68, 0, 0, 0, 0, /* pushl immediate */ 0xe9, 0, 0, 0, 0, /* jmp relative */ 0x66, 0x90 /* xchg %ax,%ax */ }; static const bfd_byte elf_x86_64_lazy_ibt_plt_entry[LAZY_PLT_ENTRY_SIZE] = { 0xf3, 0x0f, 0x1e, 0xfa, /* endbr64 */ 0x68, 0, 0, 0, 0, /* pushq immediate */ 0xe9, 0, 0, 0, 0, /* jmpq relative */ 0x66, 0x90 /* xchg %ax,%ax */ }; They only have unsigned int plt_reloc_offset; /* ... offset into relocation table. */ and don't have unsigned int plt_got_offset; /* ... address of this symbol in .got. */ We should use plt_reloc_offset, not plt_got_offset, to check IBT PLT. PR binutils/33358 * elf32-i386.c (elf_i386_get_synthetic_symtab): Check plt_reloc_offset for lazy IBT PLT. * elf64-x86-64.c (elf_x86_64_get_synthetic_symtab): Likewise. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-09-03Automatic date update in version.inGDB Administrator1-1/+1
2025-09-02LoongArch: Fix incorrect display of FDEs address ranges when using objdump -WfLulu Cai1-2/+2
When parsing FDEs in `.eh_frame` using `objdump -Wf`, it is necessary to resolve `BFD_RELOC_LARCH_32_PCREL` to determine the address ranges of the FDEs. Set the `pcrel_offset` field of `BFD_RELOC_LARCH_32_PCREL` to help `objdump` correctly compute the address ranges of the FDEs. Apply the same modification to BFD_RELOC_LARCH_64_PCREL.
2025-09-02Automatic date update in version.inGDB Administrator1-1/+1
2025-09-01Automatic date update in version.inGDB Administrator1-1/+1
2025-08-31Automatic date update in version.inGDB Administrator1-1/+1
2025-08-30Automatic date update in version.inGDB Administrator1-1/+1
2025-08-29ld: drop bogus %F format modifiersJan Beulich1-2/+2
Support for %F was dropped in 6d74c1f313df ("PR 32603 followup, remove %F from einfo").
2025-08-29Automatic date update in version.inGDB Administrator1-1/+1
2025-08-28Automatic date update in version.inGDB Administrator1-1/+1
2025-08-26x86: Don't put R_386_TLS_DESC/R_X86_64_TLSDESC in .rel.plt/.rela.pltH.J. Lu4-16/+32
Since lazy tlsdesc relocation has data races: https://sourceware.org/bugzilla/show_bug.cgi?id=27137 put R_386_TLS_DESC and R_X86_64_TLSDESC relocation in .rela.tls/.rel.tls section, instead of .rel.plt/.rela.plt section. Tested with glibc/i686 and glibc/x86-64 compiled with -mtls-dialect=gnu2 as well as GCC 16 configured with --with-tls=gnu2. bfd/ PR ld/28387 * elf32-i386.c (elf_i386_relocate_section): Put R_386_TLS_DESC in rel_tls_desc instead of elf.srelplt. * elf64-x86-64.c (elf_x86_64_relocate_section): Put R_X86_64_TLSDESC in rel_tls_desc instead of elf.srelplt. * elfxx-x86.c (elf_x86_allocate_dynrelocs): Use rel_tls_desc, instead of elf.srelplt, for GOT_TLS_GDESC_P. (_bfd_elf_x86_get_reloc_section): New function. (_bfd_x86_elf_late_size_sections): Use rel_tls_desc, instead of elf.srelplt, for GOT_TLS_GDESC_P. Remove next_tls_desc_index. (_bfd_x86_elf_link_setup_gnu_properties): Allocate .rela.tls/.rel.tls section for rel_tls_desc. * elfxx-x86.h (elf_x86_link_hash_table): Add rel_tls_desc. Remove next_tls_desc_index. (_bfd_elf_x86_get_reloc_section): New. (elf_backend_get_reloc_section): Likewise. ld/ PR ld/28387 * emulparams/elf32_x86_64.sh (OTHER_GOT_RELOC_SECTIONS): New. * emulparams/elf_i386.sh (OTHER_GOT_RELOC_SECTIONS): Likewise. * emulparams/elf_x86_64.sh (OTHER_GOT_RELOC_SECTIONS): Likewise. * testsuite/ld-i386/i386.exp: Run pr28387. * testsuite/ld-i386/pr17057.d: Adjusted * testsuite/ld-i386/tlsdesc.rd: Likewise. * testsuite/ld-i386/tlsdesc2.d: Likewise. * testsuite/ld-i386/tlsgdesc.rd: Likewise. * testsuite/ld-x86-64/tlsdesc.pd: Likewise. * testsuite/ld-x86-64/tlsdesc.rd: Likewise. * testsuite/ld-x86-64/tlsdesc2.d: Likewise. * testsuite/ld-x86-64/tlsgdesc.rd: Likewise. * testsuite/ld-i386/pr28387.d: New file. * testsuite/ld-i386/pr28387.s: Likewise. * testsuite/ld-x86-64/pr28387-x32.d: Likewise. * testsuite/ld-x86-64/pr28387.d: Likewise. * testsuite/ld-x86-64/pr28387.s: Likewise. * testsuite/ld-x86-64/x86-64.exp: Run pr28387 and pr28387-x32. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-08-27Automatic date update in version.inGDB Administrator1-1/+1
2025-08-26Automatic date update in version.inGDB Administrator1-1/+1
2025-08-25Fix tekhex format related gdb.base/dump.exp failuresKevin Buettner1-1/+1
On s390x, a big-endian machine, I'm seeing these test failures: FAIL: gdb.base/dump.exp: array as memory, tekhex; file restored ok FAIL: gdb.base/dump.exp: array as memory, tekhex; value restored ok FAIL: gdb.base/dump.exp: array as value, tekhex; file restored ok FAIL: gdb.base/dump.exp: array as value, tekhex; value restored ok FAIL: gdb.base/dump.exp: array copy, tekhex; file restored ok FAIL: gdb.base/dump.exp: array copy, tekhex; value restored ok FAIL: gdb.base/dump.exp: array partial, tekhex; file restored ok FAIL: gdb.base/dump.exp: array partial, tekhex; value restored ok FAIL: gdb.base/dump.exp: dump array as memory, tekhex FAIL: gdb.base/dump.exp: dump array as value, tekhex FAIL: gdb.base/dump.exp: dump struct as memory, tekhex FAIL: gdb.base/dump.exp: dump struct as value, tekhex FAIL: gdb.base/dump.exp: reload array as memory, tekhex; value restored ok FAIL: gdb.base/dump.exp: reload array as value, tekhex; value restored ok FAIL: gdb.base/dump.exp: reload struct as memory, tekhex; value restored ok FAIL: gdb.base/dump.exp: reload struct as value, tekhex; value restored ok FAIL: gdb.base/dump.exp: struct as memory, tekhex; file restored ok FAIL: gdb.base/dump.exp: struct as memory, tekhex; value restored ok FAIL: gdb.base/dump.exp: struct as value, tekhex; file restored ok FAIL: gdb.base/dump.exp: struct as value, tekhex; value restored ok FAIL: gdb.base/dump.exp: struct copy, tekhex; file restored ok FAIL: gdb.base/dump.exp: struct copy, tekhex; value restored ok It turns out that there's a subtle bug in move_section_contents in bfd/tekhex.c. The bug is that when attempting to write a buffer that starts with a zero byte, the function will return false, an error condition, without writing anything. But it also doesn't set bfd_error, so GDB ends up displaying whatever the last unrelated error was, e.g.: warning: writing dump file '.../intstr1.tekhex' (No such file or directory) When I investigated this, the bfd error was set during failure to open a separate debug file for the test case, which is totally unrelated to this problem. The reason this fails on big endian machines is that the test case writes out structs and arrays of int initialized to small values. On little endian machines, the small integer is the first byte, so the error doesn't occur. On big endian machines, a zero byte occurs first, triggering the error. On the GDB side of things, I've made a one line change to the test case to cause the error to also happen on little endian machines. I simply shift value of the first field in the struct left by 16 bits. That leaves at least one zero byte on both sides of the non-zero part of the int. I shifted it by 16 because, for a moment, there was a question in my mind about what would happen with a second zero byte, but it turns out that it's not a problem. On the bfd side of things, take a look at move_section_contents() and find_chunk() in tekhex.c. The scenario is this: we enter move_section_contents with locationp pointing at a character buffer whose first byte is zero. The 'get' parameter is false, i.e. we're writing, not reading. The other critical fact is that the abfd->tdata.tekhex_data->data is NULL (0). I'm going to go through the execution path pretty much line by line with commentary below the line(s) just executed. char *location = (char *) locationp; bfd_vma prev_number = 1; /* Nothing can have this as a high bit. */ I can't say that the comment provides the best explanation about what's happening, but the gist is this: later on, chunk_number will have it's low bits masked away, therefore no matter what it is, it can't possibly be equal to prev_number when it's set to 1. struct data_struct *d = NULL; BFD_ASSERT (offset == 0); for (addr = section->vma; count != 0; count--, addr++) { Set d to NULL and enter the loop. /* Get high bits of address. */ bfd_vma chunk_number = addr & ~(bfd_vma) CHUNK_MASK; bfd_vma low_bits = addr & CHUNK_MASK; Use CHUNK_MASK, which is 0x1fff, to obtain the chunk number, i.e. whatever's left after masking off the low 13 bits of addr, and low_bits, which are the low 13 bits of addr. chunk_number matters for understanding this bug, low_bits does not. Remember that no matter what addr is, once you mask off the low 13 bits, it can't be equal to 1. bool must_write = !get && *location != 0; !get is true, *location != 0 is false, therefore the conjunction is false, and furthermore must_write is false. I.e. even though we are writing, we don't transfer zero bytes to the chunk - this is why must_write is false. (The reason this works is that a chunk, once allocated, is zero'd as part of the allocation using bfd_zalloc. Therefore we can skip transferring zero bytes and, if enough of them are skipped one after another, chunk allocation simply doesn't happen. That's a good thing.) if (chunk_number != prev_number || (!d && must_write)) For the reason provided above, chunk_number != prev_number is true. The other part of the disjunction doesn't matter since the first part is true. This means that the if-block is entered. /* Different chunk, so move pointer. */ d = find_chunk (abfd, chunk_number, must_write); find_chunk is entered with must_write set to false. Now, remember where we left off here, because we're going to switch to find_chunk. static struct data_struct * find_chunk (bfd *abfd, bfd_vma vma, bool create) { (Above 3 lines indented to distinguish code from commentary.) When we enter find_chunk, create is false because must_write was false. struct data_struct *d = abfd->tdata.tekhex_data->data; d is set to NULL since abfd->tdata.texhex_data->data is NULL (one of the conditions for the scenario). vma &= ~CHUNK_MASK; while (d && (d->vma) != vma) d = d->next; d is NULL, so the while loop doesn't execute. if (!d && create) ... d is NULL so !d is true, but create is false, so the condition evaluates to false, meaning that the if-block is skipped. return d; find_chunk returns NULL, since d is NULL. Back in move_section_contents: if (!d) return false; d is NULL (because that's what find_chunk returned), so move_section_contents returns false at this point. Note that find_section_contents has allocated no memory, nor even tried to transfer any bytes beyond the first (zero) byte. This is a bug. The key to understanding this bug is to observe that find_chunk can return NULL to indicate that no chunk was found. This is especially important for the read (get=true) case. But it can also be NULL to indicate a memory allocation error. I toyed around with the idea of using a different value to distinguish these cases, i.e. something like (struct data_struct *) -1, but although bfd contains plenty of code where -1 is used to indicate various interesting conditions for scalars, there's no prior art where this is done for a pointer. Therefore the idea was discarded in favor of modifying this statement: if (!d) return false; to: if (!d && must_write) return false; This works because, in find_chunk, the only way to return a NULL memory allocation error is for must_write / create to be true. When it is true, if bfd_zalloc successfully allocates a chunk, then that (non-NULL) chunk will be returned at the end of the function. When it fails, it'll return NULL early. The point is that when bfd_zalloc() fails and returns NULL, must_write (in move_section_contents) / create (in find_chunk) HAD to be true. That provides us with an easy test back in move_section_contents to distinguish a memory-allocation-NULL from a block-not-found-NULL. The other NULL return case happens when the end of the function is reached when either searching for a chunk to read or attempting to find a chunk to write when abfd->tdata.tekhex_data->data is NULL. But for the latter case, must_write was false, which does not (now, with the above fix) trigger the early return of false. (Alan Modra approved the bfd/tekhex.c change.) Approved-By: Simon Marchi <simon.marchi@efficios.com> (GDB)
2025-08-25Automatic date update in version.inGDB Administrator1-1/+1
2025-08-25PR 33302, Symbols truncated on i386pep targetAlan Modra2-12/+12
Commit 012d44268695 effectively made peXXigen.c _bfd_XXi_swap_aux_out always use the COFF E_FILNMLEN of 14. The problem was that the auxent x_fname field was defined in include/coff/external.h using a length of 14. Later, E_FILNMLEN is redefined to 18 in coff/pe.h. This no doubt falsely tripped memory checking tools. AUXESZ is 18, so no actual buffer overrun. This patch defines x_fname as an 18 char field, the full auxent, and uses E_FILNMLEN when accessing. PR 33302 include/ * coff/external.h (union external_auxent): Make x_fname AUXESZ chars. bfd/ * coffswap.h (coff_swap_aux_in): Correct #error message. (coff_swap_aux_out): Likewise. Use E_FILNMLEN when copying to ext field. * peXXigen.c (_bfd_XXi_swap_aux_in): Add #error. Style fix. (_bfd_XXi_swap_aux_out): Add #error. Don't use sizeof, use E_FILNMLEN when copying to ext field. gas * testsuite/gas/pe/long_file_symbol.d, * testsuite/gas/pe/long_file_symbol.s: New test. * testsuite/gas/pe/pe.exp: Run it. Reported-By: Frediano Ziglio <freddy77@gmail.com>
2025-08-25bfd/pe*.c including bfd/coff*.cAlan Modra9-18/+20
The model of a coff-<arch>.c file providing older COFF support, with a pe-<arch>.c file defining some macros then including the coff-<arch>.c file to provide PE support has been followed by a number of architectures. Some of them have PE specific code in their coff-<arch>.c files, unconditionally compiled. ie. they are not for old COFF support, and there was no reason to follow the model. They now get an error if they are compiled stand-alone rather than being included from pe-<arch>.c or pei-<arch>.c. * coff-aarch64.c (COFF_WITH_peAArch64): Don't define here. (COFF_WITH_PE): Error if not defined. * coff-ia64.c (COFF_WITH_PE): Error if not defined. * coff-loongarch64.c (COFF_WITH_peLoongArch64): Don't define here. (COFF_WITH_PE): Error if not defined. * coff-mcore.c (COFF_WITH_PE): Error if not defined. * coff-riscv64.c (COFF_WITH_PE): Error if not defined. * pei-aarch64.c: Remove duplicate includes. * pei-loongarch64.c: Likewise. * pei-riscv64.c: Likewise. * pei-x86_64.c: Likewise.
generated by cgit v1.1 at 2025-09-18 13:06:03 +0000