binutils-gdb

Commit Graph

Author	SHA1	Message	Date
Tom de Vries	94aadbf48f	[gdb/testsuite] Fix license text in gdb.reverse/map-to-same-line.{c,exp} I noticed in gdb.reverse/map-to-same-line.{c,exp} that the license urls are using some kind of indirection via urldefense.proofpoint.com. Fix this by removing this indirection. Tested on x86_64-linux. PR testsuite/31358 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31358	3 years ago
Tom de Vries	706c6624c2	[gdb/dap] Fix race between dap exit and gdb exit When DAP shuts down due to an EOF event, there's a race between: - gdb's main thread handling a SIGHUP, and - the DAP main thread exiting. Fix this by waiting for DAP's main thread exit during the gdb_exiting event. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR dap/31380 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31380	3 years ago
Tom de Vries	05bf17f03b	[gdb/dap] Fix race between dap startup and dap log file In dap_gdb_start we do: ... append GDBFLAGS " -iex \"set debug dap-log-file $logfile\" -q -i=dap" ... While the dap log file setting comes before the dap interpreter setting, the order is the other way around: - first, the dap interpreter is started - second, the -iex commands are executed and the log file is initialized. Consequently, there's a race between dap interpreter startup and dap log file initialization. This cannot be fixed by using -eiex instead. Before the interpreter is started, the "set debug dap-log-file" command is not yet registered. Fix this by postponing the start of the DAP server until GDB has processed all command files. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR dap/31386 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31386	3 years ago
Tom de Vries	67cf0bd885	[gdb/dap] Factor out thread_log In thread_wrapper I used a style where a message is prefixed with the thread name. Factor this out into a new function thread_log. Also treat the GDB main thread special, because it's usual name is MainThread: ... MainThread: <msg> ... which is the default name assigned by python, so instead use the more explicit: ... GDB main: <msg> ... Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
GDB Administrator	852784a936	Automatic date update in version.in	3 years ago
Tom Tromey	a4af05ca66	Don't allow multiple request registrations in DAP This changes the DAP code to check that a given request or capability is only registered a single time. This is just a precaution against accidentally introducing a second definition of a request somewhere.	3 years ago
Alan Modra	fddee222e5	Leak in i386_elf_section_change_hook notes_alloc is perfect for assorted memory you can't free easily and/or would rather leave freeing until just before exit. * config/tc-i386.c (i386_elf_section_change_hook): Use notes_alloc.	3 years ago
Simon Marchi	23acbfee6a	gdbsupport: assume that compiler supports std::{is_trivially_constructible,is_trivially_copyable} This code was there to support g++ 4, which didn't support std::is_trivially_constructible and std::is_trivially_copyable. Since we now require g++ >= 9, I think it's fair to assume that GDB will always be compiled with a compiler that supports those. Change-Id: Ie7c1649139a2f48bf662cac92d7f3e38fb1f1ba1	3 years ago
Simon Marchi	aca8a74923	gdb: remove some GCC version checks Since we now require C++17, and therefore gcc >= 9, it's no longer useful to have gcc version checks for older gcc version. Change-Id: I3a87baa03c475f2b847b422b16b69c5ff7215b54 Reviewed-by: Kevin Buettner <kevinb@redhat.com> Approved-By: Pedro Alves <pedro@palves.net>	3 years ago
Tom de Vries	99eeecc8d2	[gdb/testsuite] Fix error handling in _dap_read_json In _dap_read_json we have a gdb_expect with clauses that generate errors: ... timeout { error "timeout reading json header" } eof { error "eof reading json header" } ... Proc gdb_expect uses dejagnu's remote_expect, which has some peculiar semantics related to errors: ... # remote_expect works basically the same as standard expect, but it # also takes care of getting the file descriptor from the specified # host and also calling the timeout/eof/default section if there is an # error on the expect call. ..... When a timeout triggers, it generates a timeout error, which is reported by gdb_expect, after which it runs the timeout/eof/default clauses, which generates an eof error, which is reported by runtest. I think the intention here is to generate just a one error, a timeout error. Fix this by postponing generating the error until after gdb_expect. Tested on x86_64-linux, by: - running all the DAP test-cases and observing no regressions, and - modifying the gdb.dap/eof.exp test-case to trigger a timeout error, and observing only a timeout error. PR testsuite/31382 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31382	3 years ago
Yuriy Kolerov	33283d91d9	arc: Determine a branch target of DBNZ correctly DBNZ instruction was moved from BRANCH class to a separate one - DBNZ. Thus, it must be processed separately in arc_insn_get_branch_target to correctly determine an offset for a possible branch. The testsuite for DBNZ instruction verifies these cases: 1. Check that dbnz does not branch and falls through if its source register is 0 after decrementing. GDB must successfully break on the following instruction after stepping over. 2. Check that dbnz branches to the target correctly if its source register is not 0 after decrementing - GDB must successfully break on the target instruction if a forward branch is performed after stepping over. 3. The same as point 2 but for a backward branching case. Signed-off-by: Yuriy Kolerov <kolerov93@gmail.com>	3 years ago
Alan Modra	f961273101	Re: PR29785, memory bloat after `b43771b045` Commit `7bd1e04a35` introduced "dwarf2.c:2152:29: runtime error: shift exponent 64 is too large". This is on the bucket_high_pc calculation which was moved to the top of insert_arange_in_trie where previously it was later, at a point where the overflow could not occur. Move it back and arrange for a duplicate calculation of bucket_high_pc which is also protected from overflow. PR 29785 * dwarf2.c (insert_arange_in_trie): Split bucket_high_pc. Move trie_pc_bits < VMA_BITS into splitting_leaf_will_help.	3 years ago
Alan Modra	f618d7fda2	Remove is_relocatable_executable from backend code With the removal of symbian support, most targets no longer or never did set is_relocatable_executable. Remove the backend support that is no longer relevant. * elf32-arm.c (record_arm_to_thumb_glue, elf32_arm_create_thumb_stub), (elf32_arm_final_link_relocate, elf32_arm_check_relocs), (elf32_arm_adjust_dynamic_symbol, allocate_dynrelocs_for_symbol), (elf32_arm_output_arch_local_syms): Remove is_relocatable_executable code and comments. * elf32-csky.c (csky_elf_adjust_dynamic_symbol): Likewise. * elfnn-aarch64.c (elfNN_aarch64_final_link_relocate): Likewise. * elfnn-kvx.c (elfNN_kvx_final_link_relocate): Likewise. * elfxx-mips.c (count_section_dynsyms): Likewise.	3 years ago
Matthieu Longo	44f85d2d79	aarch64: testsuite: move sysreg tests into sysreg sub-directory This patch moves the existing sysreg tests for AArch64 into a subdirectory (sysreg). The number of test files related to system registers grew relatively big with time and makes the browsing of those files difficult. Moreover, the difference of naming for the failure, working, and feature-specific scenarios causes the tests not to appear next to one another in the exploration tree when it is ordered alphabetically.	3 years ago
Tom de Vries	7c34de9efd	[gdb/dap] Join JSON writer thread with DAP thread The DAP interpreter runs in its own thread, and starts a few threads: - the JSON reader thread, - the JSON writer thread, and - the inferior output reader thread. As part of the DAP shutdown, both the JSON reader thread and the JSON writer thread, as well as the DAP main thread run to exit, but these exits are not ordered in any way. Wait in the main DAP thread for the exit of the JSON writer thread. This makes sure that the responses are flushed to the DAP client before DAP shutdown. An earlier version of this patch used Queue.task_done() to accomplish the same, but that didn't guarantee writing the "<thread name>: terminating" log entry from thread_wrapper before DAP shutdown. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR dap/31380 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31380	3 years ago
Tom de Vries	d619334108	[gdb/dap] Make dap log printing thread-safe I read that printing from different python threads is thread-unsafe, and I noticed that the dap log printing is used from different threads, but doesn't take care to make the printing thread-safe. Fix this by using a lock to access LoggingParam.log_file. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Tom de Vries	84a227694d	[gdb/dap] Flush after printing in log_stack I noticed that function log flushes the dap log file after printing, but that function log_stack doesn't. Fix this by also flushing the dap log file in log_stack. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Tom de Vries	3c3fe724f5	[gdb/testsuite] Set up dap log file in gdb.dap/type_checker.exp While debugging a slow-down in test-case gdb.dap/type_checker.exp due to a WIP patch, I noticed that test-case gdb.dap/type_checker.exp doesn't have a dap log file. This is normally set up by dap_gdb_start, but the test-case doesn't use it. Fix this by doing "set debug dap-log-file $logfile" in the test-case. To make it easy to do so, I've factored out a new proc new_dap_log_file, and while at likewise a new proc current_dap_log_file. Note that the log file is currently empty. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Felix Willgerodt	9eb450d26f	gdb: Document C++17 build requirement. We require C++17 to build for a while now: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f74dc26792a0679e29db45e56367331ff48666d1 Reviewed-By: Lancelot Six <lancelot.six@amd.com>	3 years ago
Tatsuyuki Ishi	0ac6b8701f	RISC-V: Fix local GOT and reloc size calculation for TLS. The previous code did not account correctly for two cases: * A TLS symbol can be referenced with multiple TLS types (although rare), in which case it only allocated the maximum slot size among the types, instead of the sum. * TLS relocations are only needed for DLLs, unlike normal symbols which requires relocations for all PIE code. Modify the logic to account for the two cases, so this fixes the redundant dynamic R_RISCV_NONE in .rela.dyn when using --no-pie for TLS GD and IE. Passed the gcc/binutils regressions of riscv-gnu-toolchain. bfd/ * elfnn-riscv.c (riscv_elf_size_dynamic_sections): Handle relocation sizing for TLS and non-TLS symbols differently, with the former requiring relocs on DLL while the latter requiring on PIE. Allocate GOT slots and relocation slots for each TLS type separately, accounting for the possibility of a TLS variable getting referenced by multiple symbols. ld/ * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. * testsuite/ld-riscv-elf/tls*: New testcase for TLS GD and IE, with symbols referred by both types and global and local symbols.	3 years ago
Nelson Chu	af514e5f6d	RISC-V: Don't generate branch/jump relocation if symbol is local when no-relax. Refer to commit, `dff565fcca`. Theoretically, assembler don't need to generate the pc-relative relocation and the refered local .L symbol when relaxation is disabled. The above commit improved the pcrel_hi/pcrel_lo relocations, and this commit improves branch and jump relocations. Passed the gcc/binutils regressions of riscv-gnu-toolchain. gas/ * config/tc-riscv.c (md_apply_fix): Raise fixP->fx_done for all branch and jump relocations when -mno-relax.	3 years ago
GDB Administrator	67db6ada63	Automatic date update in version.in	3 years ago
Tom Tromey	b0dd661fa1	Rewrite Rust slice type handling This patch rewrites the handling of slice types in Rust. More recent versions of the Rust compiler changed how unsized types were emitted, letting gdb inspect them more nicely. However, gdb did not do this, and in fact treated all such types as if they were slices of arrays, which is incorrect. This patch rewrites this handling and removes the restriction that unsized types must be array slices. I've added a comment explaining how unsized types are represented to rust-lang.c as well. I looked into a different approach, namely changing the DWARF reader to fix up slice types to have a dynamic type. However, the approach taken here turned out to be simpler. Tested on x86-64 Fedora 38 with a variety of Rust compiler versions. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30330	3 years ago
Tom Tromey	94a75b0363	Add obj_section::contains method I noticed a number of spots checking whether an address is in an obj_section. This patch introduces a new method for this and changes some code to use it. Regression tested on x86-64 Fedora 38. Approved-By: Andrew Burgess <aburgess@redhat.com>	3 years ago
Simon Marchi	8480a37e14	gdb: pass frames as `const frame_info_ptr &` We currently pass frames to function by value, as `frame_info_ptr`. This is somewhat expensive: - the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass by value - the constructors and destructor link/unlink the object in the global `frame_info_ptr::frame_list` list. This is an `intrusive_list`, so it's not so bad: it's just assigning a few points, there's no memory allocation as if it was `std::list`, but still it's useless to do that over and over. As suggested by Tom Tromey, change many function signatures to accept `const frame_info_ptr &` instead of `frame_info_ptr`. Some functions reassign their `frame_info_ptr` parameter, like: void the_func (frame_info_ptr frame) { for (; frame != nullptr; frame = get_prev_frame (frame)) { ... } } I wondered what to do about them, do I leave them as-is or change them (and need to introduce a separate local variable that can be re-assigned). I opted for the later for consistency. It might not be clear why some functions take `const frame_info_ptr &` while others take `frame_info_ptr`. Also, if a function took a `frame_info_ptr` because it did re-assign its parameter, I doubt that we would think to change it to `const frame_info_ptr &` should the implementation change such that it doesn't need to take `frame_info_ptr` anymore. It seems better to have a simple rule and apply it everywhere. Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0 Approved-By: Andrew Burgess <aburgess@redhat.com>	3 years ago
Tom de Vries	1b2c120daf	[gdb] Don't init history in batch mode I noticed in captured_main_1 that init_history is called just before bailing out if batch_flag is true. The history is used only in an interactive session, so there's no need to initialize it in batch mode. Fix this by moving init_history to after the batch mode check. Tested on x86_64-linux. Approved-By: Andrew Burgess <aburgess@redhat.com>	3 years ago
Paul Iannetta	9012a09f4f	kvx: gas: missing aliases for $r14r15 in assembler. Most registers from a register-pair suffixed by .lo and .hi suffixes. This was not the case of $r14 and $r15 since they are defined by the ABI: $r14 is the frame pointer, and $r15 is used to return aggregates from functions. We do not add aliases for $r12 (the stack pointer) and $r13 (the tls register). opcodes/ChangeLog: * kvx-opc.c: Regenerate. gas/ChangeLog: * config/kvx-parse.h: Regenerate.	3 years ago
Paul Iannetta	9798722ef6	kvx: enable magic immediates for integer multiply-accumulate and CMOVE* Affected instructions: - alu unit: cmovewp cmovehq - mau unit: maddwdp madduwdp maddsuwdp mma msbfwdp msbfuwdp msbfsuwdp mms mulwdp muluwdp mulsuwdp mm opcodes/ChangeLog: * kvx-opc.c (struct kvxopc): Regenerate. gas/ChangeLog: * config/kvx-parse.h: Regenerate.	3 years ago
Paul Iannetta	0593f8d6f7	kvx: gas: rename: or -> ior, xor -> eor TCA instructions start with an X, this introduces ambiguities when it comes to XOR (Is it the OR on the TCA or the XOR of the core?). For this reason, we rename OR to IOR and XOR to EOR. OR and XOR variants are still valid on KV3-1 and KV3-2. However, they have been completely removed from KV4-1. opcodes/ChangeLog: * kvx-opc.c: Regenerate. include/ChangeLog: * opcode/kvx.h: Regenerate. gas/ChangeLog: * config/kvx-parse.h: Regenerate. * testsuite/gas/kvx/kv3-1-insns-32.d: Regenerate. * testsuite/gas/kvx/kv3-1-insns-32.s: Regenerate. * testsuite/gas/kvx/kv3-1-insns-64.d: Regenerate. * testsuite/gas/kvx/kv3-1-insns-64.s: Regenerate. * testsuite/gas/kvx/kv3-2-insns-32.d: Regenerate. * testsuite/gas/kvx/kv3-2-insns-32.s: Regenerate. * testsuite/gas/kvx/kv3-2-insns-64.d: Regenerate. * testsuite/gas/kvx/kv3-2-insns-64.s: Regenerate. * testsuite/gas/kvx/kv4-1-insns-32.d: Regenerate. * testsuite/gas/kvx/kv4-1-insns-32.s: Regenerate. * testsuite/gas/kvx/kv4-1-insns-64.d: Regenerate. * testsuite/gas/kvx/kv4-1-insns-64.s: Regenerate.	3 years ago
Paul Iannetta	3c85dd404f	kvx: gas: move the splat modifier to the immediate The position of the splat modifier is now after the operand it modifies and not attached directly to the opcode. opcodes/ChangeLog: * kvx-opc.c: Regenerate. include/ChangeLog: * opcode/kvx.h: Regenerate. gas/ChangeLog: * config/kvx-parse.h: Regenerate. * testsuite/gas/kvx/kv3-1-insns-32.d: Regenerate. * testsuite/gas/kvx/kv3-1-insns-32.s: Regenerate. * testsuite/gas/kvx/kv3-1-insns-64.d: Regenerate. * testsuite/gas/kvx/kv3-1-insns-64.s: Regenerate. * testsuite/gas/kvx/kv3-2-insns-32.d: Regenerate. * testsuite/gas/kvx/kv3-2-insns-32.s: Regenerate. * testsuite/gas/kvx/kv3-2-insns-64.d: Regenerate. * testsuite/gas/kvx/kv3-2-insns-64.s: Regenerate. * testsuite/gas/kvx/kv4-1-insns-32.d: Regenerate. * testsuite/gas/kvx/kv4-1-insns-32.s: Regenerate. * testsuite/gas/kvx/kv4-1-insns-64.d: Regenerate. * testsuite/gas/kvx/kv4-1-insns-64.s: Regenerate.	3 years ago
Paul Iannetta	3bf43af5f7	kvx: gas: fix leak gas/ChangeLog: * config/tc-kvx.c (md_apply_fix): Free memory at this end.	3 years ago
Paul Iannetta	512707c2e2	kvx: Improve lexing & parsing Up until now, we used ENV.PROMOTE_IMMEDIATE to get the next candidates, however this candidate can be directly extracted from the array (in kvx-parse.h) registering all the immediates. During lexing, we ignored trailing characters after a number, this is not good enough since now number can be followed by a modifier. The function READ_TOKEN and GET_TOKEN_CLASS have been update to take this into account. gas/ChangeLog: * config/kvx-parse.c (promote_token): Do not rely on env.promote_immediate anymore. (get_token_class): Do not ignore trailing characters after a number. (read_token): Likewise. (print_token_list): THIS SHOULD NOT BE HERE.	3 years ago
Paul Iannetta	04e46d3bd9	kvx: gas: fix the detection of negative powers of 2 The detection of negative powers of 2 was wrong and could lead to well-formed bundles ending up taking more syllables than necessary. gas/ChangeLog: * config/kvx-parse.c (get_token_class): Use the signed value. * testsuite/gas/kvx/np2-detection.d: New test. * testsuite/gas/kvx/np2-detection.s: New test.	3 years ago
Jose E. Marchesi	f1efdade94	bpf: gas: add missing indcall-badoperand.* test files This adds teh following files that were missing in the previous commit `ecd16ae4e4` testsuite/gas/bpf/indcall-badoperand.d testsuite/gas/bpf/indcall-badoperand.l testsuite/gas/bpf/indcall-badoperand.s	3 years ago
GDB Administrator	a62320ed08	Automatic date update in version.in	3 years ago
Will Hawkins	ecd16ae4e4	bpf: fix bpf expression parsing regression in GAS As a result of a switch instead of an if, as would issue non-specific error messages when it encountered an operand it could not parse in bpf. This patch fixes that regression and adds a test to prevent it from reoccurring. Tested for bpf-unknown-none on x86_64-redhat-linux. gas/ChangeLog: * config/tc-bpf.c (parse_expression): Change switch to if so that error * condition is handled. * testsuite/gas/bpf/bpf.exp: Invoke new test. * testsuite/gas/bpf/indcall-badoperand.d: New test. * testsuite/gas/bpf/indcall-badoperand.l: New test. * testsuite/gas/bpf/indcall-badoperand.s: New test.	3 years ago
Jose E. Marchesi	b86b514aac	bpf: gas: avoid UB in pointer subtraction The PARSE_ERROR macro in md_assemble performs pointer subtraction. If parse_expression returns NULL then the later will be part of the subtraction and therefore UB will be incurred. This patch changes md_assemble to: 1. Accommodate all invocations to parse_expression to the fact it will return NULL when a parse error occurs. 2. Avoid UB in PARSE_ERROR. Tested in bpf-unknown-none target / x86_64-linux-gnu host. gas/ChangeLog: * config/tc-bpf.c (md_assemble): Fix to take into account that parse_expression can return NULL. (PARSE_ERROR): Avoid passing invalid length to parse_error.	3 years ago
Claudio Bantaloukas	b47cef7ca8	arm: Add support for Armv9.5-A	3 years ago
Yury Khrustalev	1bc24c0dab	aarch64: Add support for the id_aa64isar3_el1 system register Hi, [PATCH][Binutils] aarch64: Add support for the id_aa64isar3_el1 system register AArch64 defines a read-only system register called id_aa64isar3_el1. This patch also adds relevant tests. Regression tested on the aarch64-none-elf and aarch64-none-linux-gnu targets and no regressions was found. Is this Ok for trunk? I do not have commit rights, if OK, can someone commit on my behalf? Thanks, Yury Khrustalev From e42c835e8f2ee81150f498675f2faf108bbe79f8 Mon Sep 17 00:00:00 2001 From: Yury Khrustalev <yury.khrustalev@arm.com> Date: Tue, 6 Feb 2024 11:05:39 +0000 Subject: [PATCH] [PATCH][Binutils] aarch64: Add support for the id_aa64isar3_el1 system register AArch64 defines a read-only system register called id_aa64isar3_el1. This patch also adds relevant tests. Regression tested on the aarch64-none-elf and aarch64-none-linux-gnu targets and no regressions was found.	3 years ago
Tankut Baris Aktemur	d0446acf3d	testsuite, python: reformat python files using black In the recent patch titled "gdb, python: selectively omit enabling stdin in gdb.execute", the black tool found formatting issues. Fix them.	3 years ago
Zac Walker	f87eaf8ff3	aarch64: Add new relocations and limit COFF AArch64 relocation offsets The patch adds support for the IMAGE_REL_ARM64_REL32 coff relocation type. This is needed for 32-bit relative address. It also adds a check for relocation offsets over 21 bits. Offsets inside coff files are stored in instruction code. In the case of ADRP the actual value is stored, not a downshifted page offset. This means values over 21 bits would otherwise be truncated. Finally it adds a mapping for BFD_RELOC_AARCH64_ADR_GOT_PAGE and BFD_RELOC_AARCH64_LD64_GOT_LO12_NC that were previously skipped. ChangeLog: * bfd/coff-aarch64.c (coff_aarch64_reloc_type_lookup): Add BFD_RELOC_AARCH64_ADR_GOT_PAGE, BFD_RELOC_AARCH64_LD64_GOT_LO12_NC and IMAGE_REL_ARM64_REL32 relocations. (coff_pe_aarch64_relocate_section): Likewise. * gas/write.c (adjust_reloc_syms): COFF AArch64 relocation offsets need to be limited to 21bits (defined): Likewise.	3 years ago
Tankut Baris Aktemur	046a94c18c	gdb, python: selectively omit enabling stdin in gdb.execute From the Python API, we can execute GDB commands via gdb.execute. If the command gives an exception, however, we need to recover the GDB prompt and enable stdin, because the exception does not reach top-level GDB or normal_stop. This was done in commit commit `1ba1ac8801` Author: Andrew Burgess <andrew.burgess@embecosm.com> Date: Tue Nov 19 11:17:20 2019 +0000 gdb: Enable stdin on exception in execute_gdb_command with the following code: catch (const gdb_exception &except) { /* If an exception occurred then we won't hit normal_stop (), or have an exception reach the top level of the event loop, which are the two usual places in which stdin would be re-enabled. So, before we convert the exception and continue back in Python, we should re-enable stdin here. / async_enable_stdin (); GDB_PY_HANDLE_EXCEPTION (except); } In this patch, we explain what happens when we run a GDB command in the context of a synchronous command, e.g. via Python observer notifications. As an example, suppose we have the following objfile event listener, specified in a file named file.py: ~~~ import gdb class MyListener: def __init__(self): gdb.events.new_objfile.connect(self.handle_new_objfile_event) self.processed_objfile = False def handle_new_objfile_event(self, event): if self.processed_objfile: return print("loading " + event.new_objfile.filename) self.processed_objfile = True gdb.execute('add-inferior -no-connection') gdb.execute('inferior 2') gdb.execute('target remote \| gdbserver - /tmp/a.out') gdb.execute('inferior 1') the_listener = MyListener() ~~~ Using this Python file, we see the behavior below: $ gdb -q -ex "source file.py" -ex "run" --args a.out Reading symbols from a.out... Starting program: /tmp/a.out loading /lib64/ld-linux-x86-64.so.2 [New inferior 2] Added inferior 2 [Switching to inferior 2 [<null>] (<noexec>)] stdin/stdout redirected Process /tmp/a.out created; pid = 3075406 Remote debugging using stdio Reading /tmp/a.out from remote target... ... [Switching to inferior 1 [process 3075400] (/tmp/a.out)] [Switching to thread 1.1 (process 3075400)] #0 0x00007ffff7fe3290 in ?? () from /lib64/ld-linux-x86-64.so.2 (gdb) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Inferior 1 (process 3075400) exited normally] Note how the GDB prompt comes in-between the debugger output. We have this obscure behavior, because the executed command, "target remote", triggers an invocation of `normal_stop` that enables stdin. After that, however, the Python notification context completes and GDB continues with its normal flow of executing the 'run' command. This can be seen in the call stack below: (top-gdb) bt #0 async_enable_stdin () at src/gdb/event-top.c:523 #1 0x00005555561c3acd in normal_stop () at src/gdb/infrun.c:9432 #2 0x00005555561b328e in start_remote (from_tty=0) at src/gdb/infrun.c:3801 #3 0x0000555556441224 in remote_target::start_remote_1 (this=0x5555587882e0, from_tty=0, extended_p=0) at src/gdb/remote.c:5225 #4 0x000055555644166c in remote_target::start_remote (this=0x5555587882e0, from_tty=0, extended_p=0) at src/gdb/remote.c:5316 #5 0x00005555564430cf in remote_target::open_1 (name=0x55555878525e "\| gdbserver - /tmp/a.out", from_tty=0, extended_p=0) at src/gdb/remote.c:6175 #6 0x0000555556441707 in remote_target::open (name=0x55555878525e "\| gdbserver - /tmp/a.out", from_tty=0) at src/gdb/remote.c:5338 #7 0x00005555565ea63f in open_target (args=0x55555878525e "\| gdbserver - /tmp/a.out", from_tty=0, command=0x555558589280) at src/gdb/target.c:824 #8 0x0000555555f0d89a in cmd_func (cmd=0x555558589280, args=0x55555878525e "\| gdbserver - /tmp/a.out", from_tty=0) at src/gdb/cli/cli-decode.c:2735 #9 0x000055555661fb42 in execute_command (p=0x55555878529e "t", from_tty=0) at src/gdb/top.c:575 #10 0x0000555555f1a506 in execute_control_command_1 (cmd=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:529 #11 0x0000555555f1abea in execute_control_command (cmd=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:701 #12 0x0000555555f19fc7 in execute_control_commands (cmdlines=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:411 #13 0x0000555556400d91 in execute_gdb_command (self=0x7ffff43b5d00, args=0x7ffff440ab60, kw=0x0) at src/gdb/python/python.c:700 #14 0x00007ffff7a96023 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 #15 0x00007ffff7a4dadc in _PyObject_MakeTpCall () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 #16 0x00007ffff79e9a1c in _PyEval_EvalFrameDefault () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 #17 0x00007ffff7b303af in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 #18 0x00007ffff7a50358 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 #19 0x00007ffff7a4f3f4 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 #20 0x00007ffff7a4f883 in PyObject_CallFunctionObjArgs () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 #21 0x00005555563a9758 in evpy_emit_event (event=0x7ffff42b5430, registry=0x7ffff42b4690) at src/gdb/python/py-event.c:104 #22 0x00005555563cb874 in emit_new_objfile_event (objfile=0x555558761700) at src/gdb/python/py-newobjfileevent.c:52 #23 0x00005555563b53bc in python_new_objfile (objfile=0x555558761700) at src/gdb/python/py-inferior.c:195 #24 0x0000555555d6dff0 in std::__invoke_impl<void, void (&)(objfile), objfile> (__f=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile)>) at /usr/include/c++/11/bits/invoke.h:61 #25 0x0000555555d6be18 in std::__invoke_r<void, void (&)(objfile), objfile> (__fn=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile)>) at /usr/include/c++/11/bits/invoke.h:111 #26 0x0000555555d69661 in std::_Function_handler<void (objfile), void ()(objfile)>::_M_invoke(std::_Any_data const&, objfile&&) (__functor=..., __args#0=@0x7fffffffd080: 0x555558761700) at /usr/include/c++/11/bits/std_function.h:290 #27 0x0000555556314caf in std::function<void (objfile)>::operator()(objfile) const (this=0x5555585b5860, __args#0=0x555558761700) at /usr/include/c++/11/bits/std_function.h:590 #28 0x000055555631444e in gdb::observers::observable<objfile>::notify (this=0x55555836eea0 <gdb::observers::new_objfile>, args#0=0x555558761700) at src/gdb/../gdbsupport/observable.h:166 #29 0x0000555556599b3f in symbol_file_add_with_addrs (abfd=..., name=0x55555875d310 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1125 #30 0x0000555556599ca4 in symbol_file_add_from_bfd (abfd=..., name=0x55555875d310 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1160 #31 0x0000555556546371 in solib_read_symbols (so=..., flags=...) at src/gdb/solib.c:692 #32 0x0000555556546f0f in solib_add (pattern=0x0, from_tty=0, readsyms=1) at src/gdb/solib.c:1015 #33 0x0000555556539891 in enable_break (info=0x55555874e180, from_tty=0) at src/gdb/solib-svr4.c:2416 #34 0x000055555653b305 in svr4_solib_create_inferior_hook (from_tty=0) at src/gdb/solib-svr4.c:3058 #35 0x0000555556547cee in solib_create_inferior_hook (from_tty=0) at src/gdb/solib.c:1217 #36 0x0000555556196f6a in post_create_inferior (from_tty=0) at src/gdb/infcmd.c:275 #37 0x0000555556197670 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at src/gdb/infcmd.c:486 #38 0x000055555619783f in run_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:512 #39 0x0000555555f0798d in do_simple_func (args=0x0, from_tty=1, c=0x555558567510) at src/gdb/cli/cli-decode.c:95 #40 0x0000555555f0d89a in cmd_func (cmd=0x555558567510, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:2735 #41 0x000055555661fb42 in execute_command (p=0x7fffffffe2c4 "", from_tty=1) at src/gdb/top.c:575 #42 0x000055555626303b in catch_command_errors (command=0x55555661f4ab <execute_command(char const, int)>, arg=0x7fffffffe2c1 "run", from_tty=1, do_bp_actions=true) at src/gdb/main.c:513 #43 0x000055555626328a in execute_cmdargs (cmdarg_vec=0x7fffffffdaf0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffda3c) at src/gdb/main.c:612 #44 0x0000555556264849 in captured_main_1 (context=0x7fffffffdd40) at src/gdb/main.c:1293 #45 0x0000555556264a7f in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1314 #46 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343 #47 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39 (top-gdb) The use of the "target remote" command here is just an example. In principle, we would reproduce the problem with any command that triggers an invocation of `normal_stop`. To omit enabling the stdin in `normal_stop`, we would have to check the context we are in. Since we cannot do that, we add a new field to `struct ui` to track whether the prompt was already blocked, and set the tracker flag in the Python context before executing a GDB command. After applying this patch, the output becomes ... Reading symbols from a.out... Starting program: /tmp/a.out loading /lib64/ld-linux-x86-64.so.2 [New inferior 2] Added inferior 2 [Switching to inferior 2 [<null>] (<noexec>)] stdin/stdout redirected Process /tmp/a.out created; pid = 3032261 Remote debugging using stdio Reading /tmp/a.out from remote target... ... [Switching to inferior 1 [process 3032255] (/tmp/a.out)] [Switching to thread 1.1 (process 3032255)] #0 0x00007ffff7fe3290 in ?? () from /lib64/ld-linux-x86-64.so.2 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Inferior 1 (process 3032255) exited normally] (gdb) Let's now consider a secondary scenario, where the command executed from the Python raises an error. As an example, suppose we have the Python file below: def handle_new_objfile_event(self, event): ... print("loading " + event.new_objfile.filename) self.processed_objfile = True gdb.execute('print a') The executed command, "print a", gives an error because "a" is not defined. Without this patch, we see the behavior below, where the prompt is again placed incorrectly: ... Reading symbols from /tmp/a.out... Starting program: /tmp/a.out loading /lib64/ld-linux-x86-64.so.2 Python Exception <class 'gdb.error'>: No symbol "a" in current context. (gdb) [Inferior 1 (process 3980401) exited normally] This time, `async_enable_stdin` is called from the 'catch' block in `execute_gdb_command`: (top-gdb) bt #0 async_enable_stdin () at src/gdb/event-top.c:523 #1 0x0000555556400f0a in execute_gdb_command (self=0x7ffff43b5d00, args=0x7ffff440ab60, kw=0x0) at src/gdb/python/python.c:713 #2 0x00007ffff7a96023 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 #3 0x00007ffff7a4dadc in _PyObject_MakeTpCall () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 #4 0x00007ffff79e9a1c in _PyEval_EvalFrameDefault () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 #5 0x00007ffff7b303af in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 #6 0x00007ffff7a50358 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 #7 0x00007ffff7a4f3f4 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 #8 0x00007ffff7a4f883 in PyObject_CallFunctionObjArgs () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 #9 0x00005555563a9758 in evpy_emit_event (event=0x7ffff42b5430, registry=0x7ffff42b4690) at src/gdb/python/py-event.c:104 #10 0x00005555563cb874 in emit_new_objfile_event (objfile=0x555558761410) at src/gdb/python/py-newobjfileevent.c:52 #11 0x00005555563b53bc in python_new_objfile (objfile=0x555558761410) at src/gdb/python/py-inferior.c:195 #12 0x0000555555d6dff0 in std::__invoke_impl<void, void (&)(objfile), objfile> (__f=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile)>) at /usr/include/c++/11/bits/invoke.h:61 #13 0x0000555555d6be18 in std::__invoke_r<void, void (&)(objfile), objfile> (__fn=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile)>) at /usr/include/c++/11/bits/invoke.h:111 #14 0x0000555555d69661 in std::_Function_handler<void (objfile), void ()(objfile)>::_M_invoke(std::_Any_data const&, objfile&&) (__functor=..., __args#0=@0x7fffffffd080: 0x555558761410) at /usr/include/c++/11/bits/std_function.h:290 #15 0x0000555556314caf in std::function<void (objfile)>::operator()(objfile) const (this=0x5555585b5860, __args#0=0x555558761410) at /usr/include/c++/11/bits/std_function.h:590 #16 0x000055555631444e in gdb::observers::observable<objfile>::notify (this=0x55555836eea0 <gdb::observers::new_objfile>, args#0=0x555558761410) at src/gdb/../gdbsupport/observable.h:166 #17 0x0000555556599b3f in symbol_file_add_with_addrs (abfd=..., name=0x55555875d020 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1125 #18 0x0000555556599ca4 in symbol_file_add_from_bfd (abfd=..., name=0x55555875d020 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1160 #19 0x0000555556546371 in solib_read_symbols (so=..., flags=...) at src/gdb/solib.c:692 #20 0x0000555556546f0f in solib_add (pattern=0x0, from_tty=0, readsyms=1) at src/gdb/solib.c:1015 #21 0x0000555556539891 in enable_break (info=0x55555874a670, from_tty=0) at src/gdb/solib-svr4.c:2416 #22 0x000055555653b305 in svr4_solib_create_inferior_hook (from_tty=0) at src/gdb/solib-svr4.c:3058 #23 0x0000555556547cee in solib_create_inferior_hook (from_tty=0) at src/gdb/solib.c:1217 #24 0x0000555556196f6a in post_create_inferior (from_tty=0) at src/gdb/infcmd.c:275 #25 0x0000555556197670 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at src/gdb/infcmd.c:486 #26 0x000055555619783f in run_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:512 #27 0x0000555555f0798d in do_simple_func (args=0x0, from_tty=1, c=0x555558567510) at src/gdb/cli/cli-decode.c:95 #28 0x0000555555f0d89a in cmd_func (cmd=0x555558567510, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:2735 #29 0x000055555661fb42 in execute_command (p=0x7fffffffe2c4 "", from_tty=1) at src/gdb/top.c:575 #30 0x000055555626303b in catch_command_errors (command=0x55555661f4ab <execute_command(char const*, int)>, arg=0x7fffffffe2c1 "run", from_tty=1, do_bp_actions=true) at src/gdb/main.c:513 #31 0x000055555626328a in execute_cmdargs (cmdarg_vec=0x7fffffffdaf0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffda3c) at src/gdb/main.c:612 #32 0x0000555556264849 in captured_main_1 (context=0x7fffffffdd40) at src/gdb/main.c:1293 #33 0x0000555556264a7f in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1314 #34 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343 #35 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39 (top-gdb) Again, after we enable stdin, GDB continues with its normal flow of the 'run' command and receives the inferior's exit event, where it would have enabled stdin, if we had not done it prematurely. (top-gdb) bt #0 async_enable_stdin () at src/gdb/event-top.c:523 #1 0x00005555561c3acd in normal_stop () at src/gdb/infrun.c:9432 #2 0x00005555561b5bf1 in fetch_inferior_event () at src/gdb/infrun.c:4700 #3 0x000055555618d6a7 in inferior_event_handler (event_type=INF_REG_EVENT) at src/gdb/inf-loop.c:42 #4 0x000055555620ecdb in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4316 #5 0x0000555556f33035 in handle_file_event (file_ptr=0x5555587024e0, ready_mask=1) at src/gdbsupport/event-loop.cc:573 #6 0x0000555556f3362f in gdb_wait_for_event (block=0) at src/gdbsupport/event-loop.cc:694 #7 0x0000555556f322cd in gdb_do_one_event (mstimeout=-1) at src/gdbsupport/event-loop.cc:217 #8 0x0000555556262df8 in start_event_loop () at src/gdb/main.c:407 #9 0x0000555556262f85 in captured_command_loop () at src/gdb/main.c:471 #10 0x0000555556264a84 in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1324 #11 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343 #12 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39 (top-gdb) The solution implemented by this patch addresses the problem. After applying the patch, the output becomes $ gdb -q -ex "source file.py" -ex "run" --args a.out Reading symbols from /tmp/a.out... Starting program: /tmp/a.out loading /lib64/ld-linux-x86-64.so.2 Python Exception <class 'gdb.error'>: No symbol "a" in current context. [Inferior 1 (process 3984511) exited normally] (gdb) Regression-tested on X86_64 Linux using the default board file (i.e. unix). Co-Authored-By: Oguzhan Karakaya <oguzhan.karakaya@intel.com> Reviewed-By: Guinevere Larsen <blarsen@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Tom de Vries	c3e06e640e	[gdb/exp] Fix printing of out of bounds struct members When building gdb with -O0 -fsanitize=address, and running test-case gdb.ada/uninitialized_vars.exp, I run into: ... (gdb) info locals a = 0 z = (a => 1, b => false, c => 2.0) ================================================================= ==66372==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000097f58 at pc 0xffff52c0da1c bp 0xffffc90a1d40 sp 0xffffc90a1d80 READ of size 4 at 0x602000097f58 thread T0 #0 0xffff52c0da18 in memmove (/lib64/libasan.so.8+0x6da18) #1 0xbcab24 in unsigned char* std::__copy_move_backward<false, true, std::random_access_iterator_tag>::__copy_move_b<unsigned char const, unsigned char>(unsigned char const, unsigned char const, unsigned char) /usr/include/c++/13/bits/stl_algobase.h:748 #2 0xbc9bf4 in unsigned char std::__copy_move_backward_a2<false, unsigned char const, unsigned char>(unsigned char const, unsigned char const, unsigned char) /usr/include/c++/13/bits/stl_algobase.h:769 #3 0xbc898c in unsigned char std::__copy_move_backward_a1<false, unsigned char const, unsigned char>(unsigned char const, unsigned char const, unsigned char) /usr/include/c++/13/bits/stl_algobase.h:778 #4 0xbc715c in unsigned char std::__copy_move_backward_a<false, unsigned char const, unsigned char>(unsigned char const, unsigned char const, unsigned char) /usr/include/c++/13/bits/stl_algobase.h:807 #5 0xbc4e6c in unsigned char std::copy_backward<unsigned char const, unsigned char>(unsigned char const, unsigned char const, unsigned char) /usr/include/c++/13/bits/stl_algobase.h:867 #6 0xbc2934 in void gdb::copy<unsigned char const, unsigned char>(gdb::array_view<unsigned char const>, gdb::array_view<unsigned char>) gdb/../gdbsupport/array-view.h:223 #7 0x20e0100 in value::contents_copy_raw(value, long, long, long) gdb/value.c:1239 #8 0x20e9830 in value::primitive_field(long, int, type) gdb/value.c:3078 #9 0x20e98f8 in value_field(value, int) gdb/value.c:3095 #10 0xcafd64 in print_field_values gdb/ada-valprint.c:658 #11 0xcb0fa0 in ada_val_print_struct_union gdb/ada-valprint.c:857 #12 0xcb1bb4 in ada_value_print_inner(value, ui_file, int, value_print_options const) gdb/ada-valprint.c:1042 #13 0xc66e04 in ada_language::value_print_inner(value, ui_file, int, value_print_options const) const (/home/vries/gdb/build/gdb/gdb+0xc66e04) #14 0x20ca1e8 in common_val_print(value, ui_file, int, value_print_options const, language_defn const) gdb/valprint.c:1092 #15 0x20caabc in common_val_print_checked(value, ui_file, int, value_print_options const, language_defn const) gdb/valprint.c:1184 #16 0x196c524 in print_variable_and_value(char const, symbol, frame_info_ptr, ui_file, int) gdb/printcmd.c:2355 #17 0x1d99ca0 in print_variable_and_value_data::operator()(char const, symbol) gdb/stack.c:2308 #18 0x1dabca0 in gdb::function_view<void (char const, symbol)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const, symbol)#1}::operator()(gdb::fv_detail::erased_callable, char const, symbol) const gdb/../gdbsupport/function-view.h:305 #19 0x1dabd14 in gdb::function_view<void (char const, symbol)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const, symbol)#1}::_FUN(gdb::fv_detail::erased_callable, char const, symbol) gdb/../gdbsupport/function-view.h:299 #20 0x1dab34c in gdb::function_view<void (char const, symbol)>::operator()(char const, symbol) const gdb/../gdbsupport/function-view.h:289 #21 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240 #22 0x1d99790 in iterate_over_block_local_vars(block const, gdb::function_view<void (char const, symbol)>) gdb/stack.c:2259 #23 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380 #24 0x1d9afac in info_locals_command(char const, int) gdb/stack.c:2458 #25 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95 #26 0xfe5a2c in cmd_func(cmd_list_element, char const, int) gdb/cli/cli-decode.c:2735 #27 0x1f03790 in execute_command(char const, int) gdb/top.c:575 #28 0x1384080 in command_handler(char const) gdb/event-top.c:566 #29 0x1384e2c in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:802 #30 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104 #31 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259 #32 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290 #33 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 #34 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 #35 0x1fe9b40 in stdin_event_handler gdb/ui.c:155 #36 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573 #37 0x35ff9d8 in gdb_wait_for_event gdbsupport/event-loop.cc:694 #38 0x35fd284 in gdb_do_one_event(int) gdbsupport/event-loop.cc:264 #39 0x1768080 in start_event_loop gdb/main.c:408 #40 0x17684c4 in captured_command_loop gdb/main.c:472 #41 0x176cfc8 in captured_main gdb/main.c:1342 #42 0x176d088 in gdb_main(captured_main_args) gdb/main.c:1361 #43 0xb73edc in main gdb/gdb.c:39 #44 0xffff519b09d8 in __libc_start_call_main (/lib64/libc.so.6+0x309d8) #45 0xffff519b0aac in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x30aac) #46 0xb73c2c in _start (/home/vries/gdb/build/gdb/gdb+0xb73c2c) 0x602000097f58 is located 0 bytes after 8-byte region [0x602000097f50,0x602000097f58) allocated by thread T0 here: #0 0xffff52c65218 in calloc (/lib64/libasan.so.8+0xc5218) #1 0xcbc278 in xcalloc gdb/alloc.c:97 #2 0x35f21e8 in xzalloc(unsigned long) gdbsupport/common-utils.cc:29 #3 0x20de270 in value::allocate_contents(bool) gdb/value.c:937 #4 0x20edc08 in value::fetch_lazy() gdb/value.c:4033 #5 0x20dadc0 in value::entirely_covered_by_range_vector(std::vector<range, std::allocator<range> > const&) gdb/value.c:229 #6 0xcb2298 in value::entirely_optimized_out() gdb/value.h:560 #7 0x20ca6fc in value_check_printable gdb/valprint.c:1133 #8 0x20caa8c in common_val_print_checked(value, ui_file, int, value_print_options const, language_defn const) gdb/valprint.c:1182 #9 0x196c524 in print_variable_and_value(char const, symbol, frame_info_ptr, ui_file, int) gdb/printcmd.c:2355 #10 0x1d99ca0 in print_variable_and_value_data::operator()(char const, symbol) gdb/stack.c:2308 #11 0x1dabca0 in gdb::function_view<void (char const, symbol)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const, symbol)#1}::operator()(gdb::fv_detail::erased_callable, char const, symbol) const gdb/../gdbsupport/function-view.h:305 #12 0x1dabd14 in gdb::function_view<void (char const, symbol)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const, symbol)#1}::_FUN(gdb::fv_detail::erased_callable, char const, symbol) gdb/../gdbsupport/function-view.h:299 #13 0x1dab34c in gdb::function_view<void (char const, symbol)>::operator()(char const, symbol) const gdb/../gdbsupport/function-view.h:289 #14 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240 #15 0x1d99790 in iterate_over_block_local_vars(block const, gdb::function_view<void (char const, symbol)>) gdb/stack.c:2259 #16 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380 #17 0x1d9afac in info_locals_command(char const, int) gdb/stack.c:2458 #18 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95 #19 0xfe5a2c in cmd_func(cmd_list_element, char const, int) gdb/cli/cli-decode.c:2735 #20 0x1f03790 in execute_command(char const, int) gdb/top.c:575 #21 0x1384080 in command_handler(char const*) gdb/event-top.c:566 #22 0x1384e2c in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:802 #23 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104 #24 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259 #25 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290 #26 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 #27 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 #28 0x1fe9b40 in stdin_event_handler gdb/ui.c:155 #29 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573 SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib64/libasan.so.8+0x6da18) in memmove ... The error happens when trying to print either variable y or y2: ... type Variable_Record (A : Boolean := True) is record case A is when True => B : Integer; when False => C : Float; D : Integer; end case; end record; Y : Variable_Record := (A => True, B => 1); Y2 : Variable_Record := (A => False, C => 1.0, D => 2); ... when the variables are uninitialized. The error happens only when printing the entire variable: ... (gdb) p y.a $2 = 216 (gdb) p y.b There is no member named b. (gdb) p y.c $3 = 9.18340949e-41 (gdb) p y.d $4 = 1 (gdb) p y <AddressSanitizer: heap-buffer-overflow> ... The error happens as follows: - field a functions as discriminant, choosing either the b, or c+d variant. - when y.a happens to be set to 216, as above, gdb interprets this as the variable having the c+d variant (which is why trying to print y.b fails). - when printing y, gdb allocates a value, copies the bytes into it from the target, and then prints the value. - gdb allocates the value using the type size, which is 8. It's 8 because that's what the DW_AT_byte_size indicates. Note that for valid values of a, it gives correct results: if a is 0 (c+d variant), size is 12, if a is 1 (b variant), size is 8. - gdb tries to print field d, which is at an 8 byte offset, and that results in a out-of-bounds access for the allocated 8-byte value. Fix this by handling this case in value::contents_copy_raw, such that we have: ... (gdb) p y $1 = (a => 24, c => 9.18340949e-41, d => <error reading variable: access outside bounds of object>) ... An alternative (additional) fix could be this: in compute_variant_fields_inner gdb reads the discriminant y.a to decide which variant is active. It would be nice to detect that the value (y.a == 24) is not a valid Boolean, and give up on choosing a variant altoghether. However, the situation regarding the internal type CODE_TYPE_BOOL is currently ambiguous (see PR31282) and it's not possible to reliably decide what valid values are. The test-case source file gdb.ada/uninitialized-variable-record/parse.adb is a reduced version of gdb.ada/uninitialized_vars/parse.adb, so it copies the copyright years. Note that the test-case needs gcc-12 or newer, it's unsupported for older gcc versions. [ So, it would be nice to rewrite it into a dwarf assembly test-case. ] The test-case loops over all languages. This is inherited from an earlier attempt to fix this, which had language-specific fixes (in print_field_values, cp_print_value_fields, pascal_object_print_value_fields and f_language::value_print_inner). I've left this in, but I suppose it's not strictly necessary anymore. Tested on x86_64-linux. PR exp/31258 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31258	3 years ago
GDB Administrator	d1648ffe80	Automatic date update in version.in	3 years ago
GDB Administrator	989aa9b8e8	Automatic date update in version.in	3 years ago
GDB Administrator	7d9548382a	Automatic date update in version.in	3 years ago
H.J. Lu	d9511b64b8	ld: Add -plugin-save-temps Add -plugin-save-temps to store plugin intermediate files permanently. It can be used to exam the final input object files generated from IR inputs. * NEWS: Mention -plugin-save-temps. * ld.h (ld_config_type): Add plugin_save_temps. * ld.texi: Document -plugin-save-temps. * ldlex.h (option_values): Add OPTION_PLUGIN_SAVE_TEMPS. * lexsup.c (ld_options): Add -plugin-save-temps. (parse_args): Handle OPTION_PLUGIN_SAVE_TEMPS. * plugin.c (plugin_call_cleanup): Don't call plugin cleanup_handler for -plugin-save-temps.	6 years ago
Alan Modra	900c0f0aa3	PR27597, nios: assertion fail in nios2_elf32_install_imm16 The assertion in nios2_elf32_install_imm16 triggers when the PLT is twice the maximum allowable size for a branch from PLTn to reach .PLTresolve, and on no other call to nios2_elf32_install_imm16. That makes the assertion completely useless. We can handle a PIC PLT exceeding 0x8000 in size by bouncing branches that won't reach through previous branches. PR 27597 * elf32-nios2.c (nios2_elf32_install_imm16): Delete BFD_ASSERT. (nios2_build_one_stub): Don't bother masking value passed to nios2_elf32_install_imm16. (nios2_elf32_finish_dynamic_symbol): Likewise. Handle overflow of PLTn branch to .PLTresolve by bouncing through prior branches.	3 years ago
Nick Clifton	bf4f7759ed	Update how-to-make-a-release document to reference new git repository for the documentation	3 years ago
Jan Beulich	c8054e730d	x86/APX: drop stray IgnoreSize While necessary on the legacy encodings, the EVEX ones don't need it. Even more so when they're available for 64-bit mode only, when the legacy encodings have the attribute only for correctly handling things in 16-bit mode.	3 years ago

1 2 3 4 5 ...

117874 Commits (cfe51255b892962c25166cc0afd8911caf9e1e56) All Branches Search

117874 Commits (cfe51255b892962c25166cc0afd8911caf9e1e56)

All Branches