aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-08-24gdb: new 'maint print frame-id' commandAndrew Burgess5-0/+157
When debugging a certain class of GDB bug, I often end up wanting to know what GDB thinks the frame-id is in a particular frame. It's not too hard to pull this from some debug output, but I thought it might be nice if there was a maintenance command that could tell us. This commit adds 'maint print frame-id' which prints the frame-id of the currently selected frame. You can also pass a frame level number to find the frame-id for a specific frame. There's a new test too.
2022-08-24LoongArch: ld: Fix bug not generate plt when link a dsoliuzhensong4-0/+49
Fix the bug that can not generate func@plt when linking a undefined function with cmodel=medium. Add testcase. bfd/ * elfnn-loongarch.c ld/testsuite/ld-loongarch-elf/ * cmodel-libjirl.dd * cmodel.exp * libjirl.s
2022-08-24Automatic date update in version.inGDB Administrator1-1/+1
2022-08-23SHT_RELR sh_link and sh_infoAlan Modra1-0/+1
I don't think it makes any sense for a SHT_RELR section to specify a symbol table with sh_link. SHT_RELR relocations don't use symbols. There is no real need to specify sh_info either, SHT_RELR is not for relocatable object files. Anyway, fuzzers of course don't restrict themselves to even half-sensible objects. So they found a hole in objcopy using a non-alloc SHT_RELR in an ET_EXEC. In that case BFD set up the SHT_RELR section as if it were a SHT_REL against the sh_info target section. When it came to reading in the target section relocs, the count was horribly wrong which caused a buffer overflow. * elf.c (bfd_section_from_shdr <SHT_RELR>): Always just make a normal section, don't treat it as a reloc section.
2022-08-23Re: bfd_elf_set_group_contents assertionAlan Modra1-5/+19
Further to commit 7744e3278b9f. * elf.c (bfd_elf_set_group_contents): Restrict loc in loop writing contents, and add another assertion.
2022-08-23Add an option to dlltool to allow the creation of deterministic libraries.Nick Clifton4-38/+91
PR 29489 * dlltool.c (deterministic): New variable. (gen_lib_file): If deterministic is true set the BFD_DETERMINISTIC_OUTPUT flag. (usage): Mention --deterministic-libraries and --non-deterministic-libraries. (long_options): Add new options. (main): Parse new options. * doc/binutils.texi: Document the new options. * NEWS: Mention the new feature.
2022-08-23binutils: Updated my email address.Nelson Chu1-1/+1
binutils/ * MAINTAINERS (RISC-V): Updated my email address.
2022-08-23Automatic date update in version.inGDB Administrator1-1/+1
2022-08-22Implement target async for WindowsTom Tromey2-15/+110
This implements target async for Windows. The basic idea is to have the worker thread block in WaitForDebugEvent, then notify the event loop when an event is seen. In a few situations, this blocking behavior is undesirable, so the functions passed to do_synchronously are changed to return a boolean indicating which behavior is needed.
2022-08-22Move some Windows operations to worker threadTom Tromey1-75/+182
On Windows, certain debugging APIs can only be called from the thread that started (or attached) to the inferior. Also, there is no way on Windows to wait for a debug event in addition to other events. Therefore, in order to implement target async for Windows, gdb will have to call some functions in a worker thread. This patch implements the worker thread and moves the necessary operations there. Target async isn't yet implemented, so this patch does not cause any visible changes.
2022-08-22Avoid crash with Ravenscar tasksTom Tromey1-4/+8
When using Ravenscar, gdb can crash if the user sets a breakpoint very early in task startup. This happens because gdb thinks the runtime is initialized, but in practice the particular task isn't sufficiently initialized. This patch avoids the issue by turning an assertion into an early return. I tested this using the AdaCore internal test suite. I don't know how to test Ravenscar using the FSF test suite.
2022-08-22Fix compile time warning from Clang about error messages not being printed ↵Nick Clifton1-2/+2
safely.
2022-08-22Have readelf warn users if it is asked to decode a LLVM bitcode file or a ↵Nick Clifton2-9/+67
golang object file. * readelf.c (check_magic_number): New function. Checks the magic bytes at the start of a file. If they are not the ELF format magic values, then attempts to generate a helpful error message. (process_file_header): Call check_magic_number.
2022-08-22Add OpenBSD AArch64 Little Endian BFD support.Frederic Cambus2-0/+9
* config.bfd (aarch64-*-openbsd*): Add target.
2022-08-22LoongArch: gas: add support using constant variable in instructions.tangxiaolin11-18/+352
Instructions that can load immediate support using constant variable like ".equ var, 123 li.w/d resgister, var". gas/ * config/loongarch-parse.y * config/tc-loongarch.c Add four testcases.One is a program using constant variable, one test using label is unsupported, and another two test almost instructions that can load immediate. gas/ * testsuite/gas/loongarch/li.d * testsuite/gas/loongarch/li.s * testsuite/gas/loongarch/imm_ins_label-fail.d * testsuite/gas/loongarch/imm_ins_label-fail.l * testsuite/gas/loongarch/imm_ins_label-fail.s * testsuite/gas/loongarch/imm_ins.d * testsuite/gas/loongarch/imm_ins.s * testsuite/gas/loongarch/imm_ins_32.d * testsuite/gas/loongarch/imm_ins_32.s
2022-08-22Automatic date update in version.inGDB Administrator1-1/+1
2022-08-21Fix crash in gdbpy_parse_register_idTom Tromey7-20/+48
I noticed that gdbpy_parse_register_id would assert if passed a Python object of a type it was not expecting. The included test case shows this crash. This patch fixes the problem and also changes gdbpy_parse_register_id to be more "Python-like" -- it always ensures the Python error is set when it fails, and the callers now simply propagate the existing exception.
2022-08-21Automatic date update in version.inGDB Administrator1-1/+1
2022-08-21symbols for bfd_simple_get_relocated_section_contentsAlan Modra1-27/+15
If symbols are provided by the caller of this function they are passed on to bfd_get_relocated_section_contents. No surprises there. It gets a little weird if they are not provided. In that case they are read from the bfd by _bfd_generic_link_add_symbols, and global symbols are added to the generic linker hash table. Global symbols are not added to the linker hash table if symbols *are* provided. Now the linker hash table symbols are not used by the generic bfd_get_relocated_section_conents, and also not by most target versions when called from bfd_simple_get_relocated_section_contents except for symbols like "_gp". So it mostly doesn't matter whether symbols are in the linker hash table, but it's odd that there is a difference. We could always add them, but I'm inclined to think that is unnecessary work so this patch always leaves them out. Also, symbols are canonicalized and written into a malloc'd buffer. The buffer isn't freed, see commit 8e16317ca5eb. I don't know whether that matters any more, but in any case I can't see why we need another copy of the symbols when _bfd_generic_link_read_symbols has already cached symbols. * simple.c (bfd_simple_get_relocated_section_contents): If not provided, read symbols via bfd_generic_link_read_symbols. Do not create another copy of symbols. Tidy failure exits. Minor tidy of bfd_get_relocated_section_contents and bfd_get_full_section_contents arguments.
2022-08-21Re: Missing linking test case for pe dll using a def fileAlan Modra1-11/+11
Fixes this when cross-compiling from x86_64-linux x86_64-w64-mingw32 +FAIL: compiling shared lib fastcall/stdcall * testsuite/ld-pe/pe-run2-def.exp (test_direct2_link_dll_def): Use CC_FOR_TARGET and CFLAGS_FOR_TARGET rather than CC and CFLAGS.
2022-08-20Automatic date update in version.inGDB Administrator1-1/+1
2022-08-19gdb_do_one_event: use integer test syntaxPatrick Monnerat1-2/+2
Timeout is an int, not a bool.
2022-08-19Remove two initialization functionsTom Tromey3-25/+8
I noticed a couple of initialization functions that aren't really needed, and that currently require explicit calls in gdb_init. This patch removes these functions, simplifying gdb a little. Regression tested on x86-64 Fedora 34.
2022-08-19gdb/testsuite: re-compile entry-value-typedef .S files with -fPIESimon Marchi2-54/+64
As Luis pointed out here [1], the AArch64 variant of the test doesn't work on systems that use PIE by default. For example, on this Debian 11: $ make check TESTS="gdb.dwarf2/entry-value-typedef.exp" gdb compile failed, /usr/bin/ld: /tmp/ccJE8ZSr.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' which may bind externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/ccJE8ZSr.o(.text+0x38): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' This is because entry-value-typedef-aarch64.S was generated on an old system that does not generate position-independent code by default, but the system the test runs on tries to link the test executable as position-independent. Fix this by regenerating the same binary on the same system as the original one, but with -fPIE this time. Do the same for the amd64 binary, although this one was already position-independent so the generated code doesn't change. With this patch applied, the test passes on the Debian 11 AArch64 system. [1] https://sourceware.org/pipermail/gdb-patches/2022-August/191462.html Change-Id: I68d55adaa56a7a3eddb0c13980b1a98b791f8144
2022-08-19gdb, testsuite: Adapt gdb.base/callfuncs.exp for new clang warning.Felix Willgerodt1-1/+3
Clang 15.0.0 enabled the warning for deprecated non-prototype functions by default: https://reviews.llvm.org/D122895 Callfuncs.exp is impacted and won't run due to new warnings: callfuncs.c:339:5: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype] int t_float_values (float_arg1, float_arg2) This patch disables those warnings with -Wno-deprecated-non-prototype. Removing the test for deprecated syntax would also be an option. But I will leave that up for others to decide/implement.
2022-08-19gdb, testsuite: Enable testcases that suppress specific warnings, for icc/icx.Felix Willgerodt1-3/+7
To cite gdb.exp: Some C/C++ testcases unconditionally pass -Wno-foo as additional options to disable some warning. That is OK with GCC, because by design, GCC accepts any -Wno-foo option, even if it doesn't support -Wfoo. Clang however warns about unknown -Wno-foo by default, unless you pass -Wno-unknown-warning-option as well. We do that here, so that individual testcases don't have to worry about it. This patch adds the same option that already exists for clang for icx and adds the equivalent icc option.
2022-08-19gdb: LoongArch: Handle variadic argumentsTiezhu Yang1-29/+76
According to LoongArch ELF ABI specification [1], variadic arguments are passed in GARs in the same manner as named arguments. And after a variadic argument has been passed on the stack, all future arguments will also be passed on the stack, i.e., the last argument register may be left unused due to the aligned register pair rule. long double data tpye is passed in an aligned GAR pair, the first register in the pair is even-numbered. [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-08-19loongarch64_pei_vec garbage in objcopy'd relocsAlan Modra1-0/+4
Like commit a9c09a3667cc, but for loongarch64. * coff-loongarch64.c (SWAP_IN_RELOC_OFFSET): Define. (SWAP_OUT_RELOC_OFFSET): Define.
2022-08-19Automatic date update in version.inGDB Administrator1-1/+1
2022-08-18gprofng: fix bug 29479 Collection fails when built without java supportVladimir Mezentsev2-0/+4
gprofng/ChangeLog 2022-08-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> PR gprofng/29479 * libcollector/collector.c: Add #if defined(GPROFNG_JAVA_PROFILING) for java specific code. * libcollector/unwind.c: Likewise.
2022-08-18gdb: call check_typedef at beginning of dwarf_expr_context::fetch_resultSimon Marchi5-0/+28516
Bug 29374 shows this crash: $ ./gdb -nx --data-directory=data-directory -q -batch -ex "catch throw" -ex r -ex bt a.out ... /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed. The backtrace is: #0 internal_error (file=0x5555606504c0 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h", line=217, fmt=0x55556064b700 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:51 #1 0x000055555d41c0bb in gdb::copy<unsigned char const, unsigned char> (src=..., dest=...) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217 #2 0x000055555deef28c in dwarf_expr_context::fetch_result (this=0x7fffffffb830, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1040 #3 0x000055555def0015 in dwarf_expr_context::evaluate (this=0x7fffffffb830, addr=0x62f00004313e "0", len=1, as_lval=false, per_cu=0x60b000069550, frame=0x621007c9e910, addr_info=0x0, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1091 #4 0x000055555e084327 in dwarf2_evaluate_loc_desc_full (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, subobj_type=0x621007a86830, subobj_byte_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1485 #5 0x000055555e0849e2 in dwarf2_evaluate_loc_desc (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1529 #6 0x000055555e0828c6 in dwarf_entry_parameter_to_value (parameter=0x621007a96e58, deref_size=0x0, type=0x621007a86830, caller_frame=0x621007c9e910, per_cu=0x60b000069550, per_objfile=0x613000006080) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1235 #7 0x000055555e082f55 in value_of_dwarf_reg_entry (type=0x621007a86890, frame=0x621007acc510, kind=CALL_SITE_PARAMETER_DWARF_REG, kind_u=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1332 #8 0x000055555e083449 in value_of_dwarf_block_entry (type=0x621007a86890, frame=0x621007acc510, block=0x61e000033568 "T\004\205\001\240\004\004\243\001T\237\004\240\004\261\004\001T\004\261\004\304\005\004\243\001T\237\004\304\005\310\005\001T\004\310\005\311\005\004\243\001T\237", block_len=1) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1365 #9 0x000055555e094d40 in loclist_read_variable_at_entry (symbol=0x621007a99bd0, frame=0x621007acc510) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:3889 #10 0x000055555f5192e0 in read_frame_arg (fp_opts=..., sym=0x621007a99bd0, frame=0x621007acc510, argp=0x7fffffffbf20, entryargp=0x7fffffffbf60) at /home/simark/src/binutils-gdb/gdb/stack.c:559 #11 0x000055555f51c352 in print_frame_args (fp_opts=..., func=0x621007a99ad0, frame=0x621007acc510, num=-1, stream=0x6030000bad90) at /home/simark/src/binutils-gdb/gdb/stack.c:887 #12 0x000055555f521919 in print_frame (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1390 #13 0x000055555f51f22e in print_frame_info (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, set_current_sal=0) at /home/simark/src/binutils-gdb/gdb/stack.c:1116 #14 0x000055555f526c6d in backtrace_command_1 (fp_opts=..., bt_opts=..., count_exp=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2079 #15 0x000055555f527ae5 in backtrace_command (arg=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2198 The problem is that the type that gets passed down to dwarf_expr_context::fetch_result (the type of a variable of which we're trying to read the entry value) is a typedef whose size has never been computed yet (check_typedef has never been called on it). As we get in the DWARF_VALUE_STACK case (line 1028 of dwarf2/expr.c), the `len` variable is therefore set to 0, instead of the actual type length. We then call allocate_value on subobj_type, which does call check_typedef, so the length of the typedef gets filled in at that point. We end up passing to the copy function a source array view of length 0 and a target array view of length 4, and the assertion fails. Fix this by calling check_typedef on both type and subobj_type at the beginning of fetch_result. I tried writing a test for this using the DWARF assembler, but I haven't succeeded. It's possible that we need to get into this specific code path (value_of_dwarf_reg_entry and all) to manage to get to dwarf_expr_context::fetch_result with a typedef type that has never been resolved. In all my attempts, the typedef would always be resolved already, so the bug wouldn't show up. As a fallback, I made a gdb.dwarf2 test with compiler-generated .S files. I don't particularly like those, but I think it's better than no test. The .cpp source code is the smallest reproducer I am able to make from the reproducer given in the bug (thanks to Pedro for suggestions on how to minimize it further than I had). Since I tested on both amd64 and aarch64, I added versions of the test for these two architectures. Change-Id: I182733ad08e34df40d8bcc47af72c482fabf4900 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29374
2022-08-18[aarch64] Remove handling of ADR/ADRP from prologue analyzerLuis Machado1-8/+0
As reported by Tom in https://sourceware.org/pipermail/gdb-patches/2022-August/191357.html, the aarch64 prologue analyzer considers the adrp instruction in the gdb.dwarf2/dw2-dir-file-name.exp testcase to be part of a prologue. The function has no prologue though, and it only loads the volatile variable from memory. GDB should not skip any instructions in this case. Doing some archaeology, it seems handling for adr/adrp in prologues was included with the original aarch64 port. It might've been an oversight. In the particular case of gdb.dwarf2/dw2-dir-file-name.exp, the analyzer skips a couple instructions and leaves us in a nice spot where the address to the variable "v" is already in w0. But no prologues exists. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29481
2022-08-18Change bookmark allocationTom Tromey1-90/+46
This changes how bookmarks are allocated and stored, replacing a linked list with a vector and removing some ALL_* iterator macros. Regression tested on x86-64 Fedora 34.
2022-08-18Add test for AArch64 Scalable Vector ExtensionThiago Jung Bauermann4-4/+171
It exercises a bug that GDB previously had where it would lose track of some registers when the inferior changed its vector length. It also checks that the vg register and the size of the z0-z31 registers correctly reflect the new vector length.
2022-08-18Fix thread's gdbarch when SVE vector length changesThiago Jung Bauermann4-31/+36
When the inferior program changes the SVE length, GDB can stop tracking some registers as it obtains the new gdbarch that corresponds to the updated length: Breakpoint 1, do_sve_ioctl_test () at sve-ioctls.c:44 44 res = prctl(PR_SVE_SET_VL, i, 0, 0, 0, 0); (gdb) print i $2 = 32 (gdb) info registers ⋮ [ snip registers x0 to x30 ] ⋮ sp 0xffffffffeff0 0xffffffffeff0 pc 0xaaaaaaaaa8ac 0xaaaaaaaaa8ac <do_sve_ioctl_test+112> cpsr 0x60000000 [ EL=0 BTYPE=0 C Z ] fpsr 0x0 0 fpcr 0x0 0 vg 0x8 8 tpidr 0xfffff7fcb320 0xfffff7fcb320 (gdb) next 45 if (res < 0) { (gdb) info registers ⋮ [ snip registers x0 to x30 ] ⋮ sp 0xffffffffeff0 0xffffffffeff0 pc 0xaaaaaaaaa8cc 0xaaaaaaaaa8cc <do_sve_ioctl_test+144> cpsr 0x200000 [ EL=0 BTYPE=0 SS ] fpsr 0x0 0 fpcr 0x0 0 vg 0x4 4 (gdb) Notice that register tpidr disappeared when vg (which holds the vector length) changed from 8 to 4. The tpidr register is provided by the org.gnu.gdb.aarch64.tls feature. This happens because the code that searches for a new gdbarch to match the new vector length in aarch64_linux_nat_target::thread_architecture doesn't take into account the features present in the target description associated with the previous gdbarch. This patch makes it do that. Since the id member of struct gdbarch_info is now unused, it's removed.
2022-08-18Missing linking test case for pe dll using a def file.Ralf Habacker2-0/+164
PR 28362 * testsuite/ld-pe/pe-run2-def.exp: New file.
2022-08-18gdbsupport/event-loop: add a timeout parameter to gdb_do_one_eventPatrick Monnerat2-11/+36
Since commit b2d8657, having a per-interpreter event/command loop is not possible anymore. As Insight uses a GUI that has its own event loop, gdb and GUI event loops have then to be "merged" (i.e.: work together). But this is problematic as gdb_do_one_event is not aware of this alternate event loop and thus may wait forever. A solution is to delegate GUI events handling to the gdb events handler. Insight uses Tck/Tk as GUI and the latter offers a "notifier" feature to implement such a delegation. The Tcl notifier spec requires the event wait function to support a timeout parameter. Unfortunately gdb_do_one_event does not feature such a parameter. This timeout cannot be implemented externally with a gdb timer, because it would become an event by itself and thus can cause a legitimate event to be missed if the timeout is 0. Tcl implements "idle events" that are (internally) triggered only when no other event is pending. For this reason, it can call the event wait function with a 0 timeout quite often. This patch implements a wait timeout to gdb_do_one_event. The initial pending events monitoring is performed as before without the possibility to enter a wait state. If no pending event has been found during this phase, a timer is then created for the given timeout in order to re-use the implemented timeout logic and the event wait is then performed. This "internal" timer only limits the wait time and should never be triggered. It is deleted upon gdb_do_one_event exit. The new parameter defaults to "no timeout" (-1): as it is used by Insight only, there is no need to update calls from the gdb source tree.
2022-08-18gdb: add Patrick Monnerat to gdb/MAINTAINERSPatrick Monnerat1-0/+1
2022-08-18x86: move / quiesce pre-386 non-16-bit warningJan Beulich1-6/+12
Emitting this warning for every insn, including ones having actual errors, is annoying. Introduce a boolean variable to emit the warning just once on the first insn after .arch may have changed the things, and move the warning to output_insn(). (I didn't want to go as far as checking whether the .arch actually turned off the i386 bit, but doing so would be an option.)
2022-08-18x86: insert "no error" enumerator in i386_error enumerationJan Beulich1-0/+1
The value of zero would better not indicate any error, but rather hit the abort() at the top of the consuming switch().
2022-08-18Automatic date update in version.inGDB Administrator1-1/+1
2022-08-17GDB/testsuite: Fix PARAM_ZUINTEGER reported for PARAM_ZUINTEGER_UNLIMITEDMaciej W. Rozycki1-2/+2
Correctly report PARAM_ZUINTEGER_UNLIMITED rather than PARAM_ZUINTEGER in testing a Python parameter of the PARAM_ZUINTEGER_UNLIMITED type.
2022-08-17bfd_elf_set_group_contents assertionAlan Modra1-1/+6
objcopy of broken SHT_GROUP sections shouldn't write garbage. * elf.c (bfd_elf_set_group_contents): If number of entries is unexpected, fill out section with zeros.
2022-08-17timeout in mmo_get_symbolsAlan Modra1-7/+6
Fix mmo_get_byte to return a fail-safe value, not just on the first call with a read error but on subsequent calls too. * mmo.c (mmo_get_byte): Return the fail-safe value on every call after a read error.
2022-08-17mmo.c leak in mmo_make_sectionAlan Modra1-7/+5
* mmo.c (mmo_make_section): Alloc name using bfd_alloc. Use bfd_error_no_memory. (mmo_decide_section): Check for NULL return from mmo_make_section.
2022-08-17asan: heap buffer overflow in mmo_scanAlan Modra1-12/+14
mmo_get_loc needs to handle arbitrary vma and size chunks. Fuzzers found that it wasn't working so well when the end of chunks were getting close to address wrap-around. * mmo.c (mmo_get_loc): Make "size" unsigned. Avoid arithmetic overflow when calculating whether range hits an existing chunk.
2022-08-17elf.c tidyAlan Modra1-138/+160
Swap params of is_note, so they are section, segment like others used in rewrite_elf_program_header. Whitespace fixes, plus wrapping of overlong lines.
2022-08-17Automatic date update in version.inGDB Administrator1-1/+1
2022-08-16bfd: Define ___lc_codepage_func prototype for older MinGW-w64Torbjörn SVENSSON1-0/+5
In commit 68e80d96a84282d547f3b3c1234c99009521630c, the usage of ___lc_codepage_func was introduced to determine the current encoding. Prior to version 9.0 of MinGW-w64, the function prototype for ___lc_codepage_func was missing and trying to build BFD caused the following error: error: implicit declaration of function ‘___lc_codepage_func’ This changeset adds a conditonal definition of ___lc_codepage_func to allow a sucessful build with MinGW-w64. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
2022-08-16i386: Add MAX_OPERAND_BUFFER_SIZEH.J. Lu4-3/+20
When displaying operands, invalid opcodes may overflow operand buffer due to additional styling characters. Each style is encoded with 3 bytes. Define MAX_OPERAND_BUFFER_SIZE for operand buffer size and increase it from 100 bytes to 128 bytes to accommodate 9 sets of styles in an operand. gas/ PR binutils/29483 * testsuite/gas/i386/i386.exp: Run pr29483. * testsuite/gas/i386/pr29483.d: New file. * testsuite/gas/i386/pr29483.s: Likewise. opcodes/ PR binutils/29483 * i386-dis.c (MAX_OPERAND_BUFFER_SIZE): New. (obuf): Replace 100 with MAX_OPERAND_BUFFER_SIZE. (staging_area): Likewise. (op_out): Likewise.
generated by cgit v1.1 at 2024-10-15 01:22:47 +0000