binutils-gdb

Commit Graph

Author	SHA1	Message	Date
Mike Frysinger	4935610a57	sim: iq2000: add fallback for exit syscall Make sure this syscall always exits regardless of the exit code.	2 years ago
Mike Frysinger	cc6aaa3149	sim: cr16: add missing break statement Doesn't seem to make sense for this to fall through (although I'm not an expert in this ISA).	2 years ago
Mike Frysinger	3cf7f9363d	sim: arm: add missing breaks to SWI processing Seems unlikely we want the remove syscall to fallthrough into the rename syscall since we can't rename files that have been removed.	2 years ago
Mike Frysinger	c5190830db	sim: common: mark engine restart as noreturn This helps the compiler with optimization and fixes fallthru warnings.	2 years ago
Mike Frysinger	cbdfef872b	sim: ppc: phb: add missing break to address decoder I don't know what this emulation does exactly, but it missing a break statement seems kind of obvious based on the 32-bit case above it.	2 years ago
Mike Frysinger	5eba9ae8d5	sim: ppc: mark halt & restart funcs as noreturn This helps the compiler with optimization and fixes fallthru warnings.	2 years ago
Mike Frysinger	95cd009f5d	sim: warnings: enable -Wduplicated-cond	2 years ago
Mike Frysinger	0960c785ac	sim: mn10300: fix LAST_TIMER_REG typo The compiler pointed out that we're testing LAST_TIMER_REG and LAST_COUNTER which are the same value ... and that's because we set LAST_TIMER_REG to the wrong register. Fix the typo.	2 years ago
Mike Frysinger	2f84390fd4	sim: bfin: clean up astat reg name decode a little The compiler pointed out we checked AZ twice. Sort by name to avoid that in the future, and to make it clearer that we have coverage of all the bits. And add the bits we were missing. The order here doesn't matter as it's just turning a pointer into a human readable string when store tracing is enabled.	2 years ago
Mike Frysinger	a4de6c88c9	sim: common: delete unused scache in some mloop paths The scache vars aren't used by ports in the pbb & fast codepaths, nor are they documented as inputs to the callbacks, so delete them to avoid unused variable compiler warnings.	2 years ago
Mike Frysinger	09d4e6bb2f	sim: cgen: unify the genmloop logic a bit Pull out the common parts of the genmloop invocation into the common code. This will make it easier to add more, and make the per-port differences a little more obvious.	2 years ago
GDB Administrator	515603a732	Automatic date update in version.in	2 years ago
Vladimir Mezentsev	0b3ad397ef	gprofng: 31169 Source code locations can not be found in a C++ application gprofng incorrectly reads the form of the DW_FORM_ref_addr attribute for DWARF Version 3 or later. From DWARF specification: References that use the attribute form DW_FORM_ref_addr are specified to be four bytes in the DWARF 32-bit format and eight bytes in the DWARF 64-bit format, while DWARF Version 2 specifies that such references have the same size as an address on the target system. 2023-12-18 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> PR gprofng/31169 * src/DwarfLib.cc: Fix the reader for DW_FORM_ref_addr.	2 years ago
Pedro Alves	33179c5b57	Fix handling of vanishing threads that were stepping/stopping Downstream, AMD is carrying a testcase (gdb.rocm/continue-over-kernel-exit.exp) that exposes a couple issues with the amd-dbgapi target's handling of exited threads. The test can't be added upstream yet, unfortunately, due to dependency on DWARF extensions that can't be upstreamed yet. However, it can be found on the mailing list on the same series as this patch. The test spawns a kernel with a number of waves. The waves do nothing but exit. There is a breakpoint on the s_endpgm instruction. Once that breakpoint is hit, the test issues a "continue" command. We should see one breakpoint hit per wave, and then the whole program exiting. We do see that, however we also see this: [New AMDGPU Wave ?:?:?:1 (?,?,?)/?] [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited] repeat for other waves ... [Thread 0x7ffff626f640 (LWP 3048491) exited] [Thread 0x7fffeb7ff640 (LWP 3048488) exited] [Inferior 1 (process 3048475) exited normally] That "New AMDGPU Wave" output comes from infrun.c itself adding the thread to the GDB thread list, because it got an event for a thread not on the thread list yet. The output shows "?"s instead of proper coordinates, because the event was a TARGET_WAITKIND_THREAD_EXITED, i.e., the wave was already gone when infrun.c added the thread to the thread list. That shouldn't ever happen for the amd-dbgapi target, threads should only ever be added by the backend. Note "New AMDGPU Wave ?:?:?:1" is for wave 1. What happened was that wave 1 terminated previously, and a previous call to amd_dbgapi_target::update_thread_list() noticed the wave had vanished and removed it from the GDB thread list. However, because the wave was stepping when it terminated (due to the displaced step over the s_endpgm) instruction, it is guaranteed that the amd-dbgapi library queues a WAVE_COMMAND_TERMINATED event for the exit. When we process that WAVE_COMMAND_TERMINATED event, in amd-dbgapi-target.c:process_one_event, we return it to the core as a TARGET_WAITKIND_THREAD_EXITED event: static void process_one_event (amd_dbgapi_event_id_t event_id, amd_dbgapi_event_kind_t event_kind) { ... if (status == AMD_DBGAPI_STATUS_ERROR_INVALID_WAVE_ID && event_kind == AMD_DBGAPI_EVENT_KIND_WAVE_COMMAND_TERMINATED) ws.set_thread_exited (0); ... } Recall the wave is already gone from the GDB thread list. So when GDB sees that TARGET_WAITKIND_THREAD_EXITED event for a thread it doesn't know about, it adds the thread to the thread list, resulting in that: [New AMDGPU Wave ?:?:?:1 (?,?,?)/?] and then, because it was a TARGET_WAITKIND_THREAD_EXITED event, GDB marks the thread exited right afterwards: [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited] The fix is to make amd_dbgapi_target::update_thread_list() _not_ delete vanishing waves iff they were stepping or in progress of being stopped. These two cases are the ones dbgapi guarantees will result in a WAVE_COMMAND_TERMINATED event if the wave terminates: /** * A command for a wave was not able to complete because the wave has * terminated. * * Commands that can result in this event are ::amd_dbgapi_wave_stop and * ::amd_dbgapi_wave_resume in single step mode. Since the wave terminated * before stopping, this event will be reported instead of * ::AMD_DBGAPI_EVENT_KIND_WAVE_STOP. * * The wave that terminated is available by the ::AMD_DBGAPI_EVENT_INFO_WAVE * query. However, the wave will be invalid since it has already terminated. * It is the client's responsibility to know what command was being performed * and was unable to complete due to the wave terminating. / AMD_DBGAPI_EVENT_KIND_WAVE_COMMAND_TERMINATED = 2, As the comment says, it's GDB's responsability to know whether the wave was stepping or being stopped. Since we now have a wave_info map with one entry for each wave, that seems like the place to store that information. However, I still decided to put all the coordinate information in its own structure. I.e., basically renamed the existing wave_info to wave_coordinates, and then added a new wave_info structure that holds the new state, plus a wave_coordinates object. This seemed cleaner as there are places where we only need to instantiate a wave_coordinates object. There's an extra twist. The testcase also exercises stopping at a new kernel right after the first kernel fully exits. In that scenario, we were hitting this assertion after the first kernel fully exits and the hit of the breakpoint at the second kernel is handled: [amd-dbgapi] process_event_queue: Pulled event from dbgapi: event_id.handle = 26, event_kind = WAVE_STOP [amd-dbgapi-lib] suspending queue_3, queue_2, queue_1 (refresh wave list) ../../src/gdb/amd-dbgapi-target.c:1625: internal-error: amd_dbgapi_thread_deleted: Assertion `it != info->wave_info_map.end ()' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. This is the exact same problem as above, just a different manifestation. In this scenario, we end up in update_thread_list successfully deleting the exited thread (because it was no longer the current thread) that was incorrectly added by infrun.c. Because it was added by infrun.c and not by amd-dbgapi-target.c:add_gpu_thread, it doesn't have an entry in the wave_info map, so amd_dbgapi_thread_deleted trips on this assertion: gdb_assert (it != info->wave_info_map.end ()); here: ... -> stop_all_threads -> update_thread_list -> target_update_thread_list -> amd_dbgapi_target::update_thread_list -> thread_db_target::update_thread_list -> linux_nat_target::update_thread_list -> delete_exited_threads -> delete_thread -> delete_thread_1 -> gdb::observers::observable<thread_info>::notify -> amd_dbgapi_thread_deleted -> internal_error_loc The testcase thus tries both running to exit after the first kernel exits, and running to a breakpoint in a second kernel after the first kernel exits. Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu) Change-Id: I43a66f060c35aad1fe0d9ff022ce2afd0537f028	2 years ago
Pedro Alves	7d1fd67135	Fix thread target ID of exited waves Currently, if you step over kernel exit, you see: stepi [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited] Command aborted, thread exited. (gdb) Those '?' are because the thread/wave is already gone by the time GDB prints the "exited" notification, we can't ask dbgapi for any info about the wave anymore. This commit fixes it by caching the wave's coordinates as soon as GDB sees the wave for the first time, and making amd_dbgapi_target::pid_to_str use the cached info. At first I thought of clearing the wave_info object from a thread_exited observer. However, that is too soon, resulting in this: (gdb) si [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited] Command aborted, thread exited. (gdb) thread [Current thread is 6 (AMDGPU Wave ?:?:?:0 (?,?,?)/?) (exited)] We need instead to clear the wave info when the thread is ultimately deleted, so we get: (gdb) si [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited] Command aborted, thread exited. (gdb) thread [Current thread is 6 (AMDGPU Wave 1:4:1:1 (0,0,0)/0) (exited)] And for that, we need a new thread_deleted observable. Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu) Change-Id: I6c3e22541f051e1205f75eb657b04dc15e547580	2 years ago
Pedro Alves	45fd40cf54	Step over thread exit, always delete the thread non-silently With AMD GPU debugging, I noticed that when stepping over a breakpoint placed on top of the s_endpgm instruction inline (displaced=off), GDB would behave differently -- it wouldn't print the wave exit. E.g: With displaced stepping, or no breakpoint at all: stepi [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited] Command aborted, thread exited. (gdb) With inline stepping: stepi Command aborted, thread exited. (gdb) In the cases we see the "exited" notification, handle_thread_exit is what first called delete_thread on the exiting thread, which is non-silent. With inline stepping, however, handle_thread_exit ends up in update_thread_list (via restart_threads) before any delete_thread call. Thus, amd_dbgapi_target::update_thread_list notices that the wave is gone and deletes it with delete_thread_silent. This commit fixes it, by making handle_thread_exited call set_thread_exited (with the default silent=false) early, which emits the user-visible notification. Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: I22ab3145e18d07c99dace45576307b9f9d5d966f	2 years ago
Pedro Alves	249d081287	displaced_step_finish: Don't fetch the regcache of exited threads displaced_step_finish can be called with event_status.kind == TARGET_WAITKIND_THREAD_EXITED, and in that case it is not possible to get at the already-exited thread's registers. This patch moves the get_thread_regcache calls to branches that actually need it, where we know the thread is still alive. It also adds an assertion to get_thread_regcache, to help catching these broken cases sooner. Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: I63b5eacb3e02a538fc5087c270d8025adfda88c3	2 years ago
Pedro Alves	d0b5914979	Ensure selected thread after thread exit stop While making step over thread exit work properly on AMDGPU, I noticed that if there's a breakpoint on top of the exit syscall, and, displaced stepping is off, then when GDB reports "Command aborted, thread exited.", GDB also switches focus to a random thread, instead of leaving the exited thread as selected: (gdb) thread [Current thread is 6, lane 0 (AMDGPU Lane 1:4:1:1/0 (0,0,0)[0,0,0])] (gdb) si Command aborted, thread exited. (gdb) thread [Current thread is 5 (Thread 0x7ffff626f640 (LWP 3248392))] (gdb) The previous patch extended gdb.threads/step-over-thread-exit.exp to exercise this on GNU/Linux (on the CPU side), and there, after that "si", we always end up with the exiting thread as selected even without this fix, but that's just a concidence, there's a code path that happens to select the exiting thread for an unrelated reason. This commit add the explict switch, fixing the latent problem for GNU/Linux, and the actual problem on AMDGPU. I wrote a gdb.rocm/ testcase for this, but it can't be upstreamed yet, until more pieces of the DWARF machinery are upstream as well. Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: I6ff57a79514ac0142bba35c749fe83d53d9e4e51	2 years ago
Pedro Alves	4ea7412e53	gdb.threads/step-over-thread-exit.exp improvements This commit makes the following improvements to gdb.threads/step-over-thread-exit.exp: - Add a third axis to stepping over the breakpoint with displaced vs inline stepping -- also test with no breakpoint at all. - Check that when GDB reports "Command aborted, thread exited.", the selected thread is the thread that exited. This is always true currently on GNU/Linux by coincidence, but a similar testcase on AMD GPU exposed a problem here. Better make the testcase catch any potential regression. - Fixes a race that Simon ran into with GDBserver testing. (gdb) next [New Thread 2143071.2143438] Thread 3 "step-over-threa" hit Breakpoint 2, 0x000055555555524e in my_exit_syscall () at .../testsuite/lib/my-syscalls.S:74 74 SYSCALL (my_exit, __NR_exit) (gdb) FAIL: gdb.threads/step-over-thread-exit.exp: displaced-stepping=auto: non-stop=on: target-non-stop=on: schedlock=off: cmd=next: ns_stop_all=0: command aborts when thread exits I was not able to reproduce it, but I believe that what happens is the following: Once we continue, the thread 2 exits, and the main thread thus unblocks from its pthread_join, and spawns a new thread. That new thread may hit the breakpoint at my_exit_syscall very quickly. GDB could then see/process that breakpoint event before the thread exit event for the thread we care about, which would result in the failure seen above. The fix here is to not loop and start a new thread at all in the scenario where the race can happen. We only need to loop and spawn new threads when testing with "cmd=continue" and schedlock off, in which case GDB doesn't abort the command when the thread exits. Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: I90c95c32f00630a3f682b1541c23aff52451f9b6	2 years ago
Pedro Alves	aed77b16f1	Fix bug in previous remote unique_ptr change By inspection, I noticed that the previous patch went too far, here: @@ -7705,7 +7713,8 @@ remote_target::discard_pending_stop_replies (struct inferior inf) if (rs->remote_desc == NULL) return; - reply = (struct stop_reply ) rns->pending_event[notif_client_stop.id]; + stop_reply_up reply + = as_stop_reply_up (std::move (rns->pending_event[notif_client_stop.id])); /* Discard the in-flight notification. / if (reply != NULL && reply->ptid.pid () == inf->pid) That is always moving the stop reply from pending_event, when we only really want to peek into it. The code further below that even says: / Discard the in-flight notification. / if (reply != NULL && reply->ptid.pid () == inf->pid) { / Leave the notification pending, since the server expects that we acknowledge it with vStopped. But clear its contents, so that later on when we acknowledge it, we also discard it. */ This commit reverts that hunk back, adjusted to use unique_ptr::get(). Change-Id: Ifc809d1a8225150a4656889f056d51267100ee24	2 years ago
Pedro Alves	e216338123	Complete use of unique_ptr with notif_event and stop_reply We already use unique_ptr with notif_event and stop_reply in some places around the remote target, but not fully. There are several code paths that still use raw pointers. This commit makes all of the ownership of these objects tracked by unique pointers, making the lifetime flow much more obvious, IMHO. I notice that it fixes a leak -- in remote_notif_stop_ack, We weren't destroying the stop_reply object if it was of TARGET_WAITKIND_IGNORE kind. Approved-By: Tom Tromey <tom@tromey.com> Change-Id: Id81daf39653d8792c8795b2a145772176bfae77c	2 years ago
Pedro Alves	d5cebea18e	Make cached_reg_t own its data struct cached_reg_t owns its data buffer, but currently that is managed manually. Convert it to use a unique_xmalloc_ptr. Approved-By: Tom Tromey <tom@tromey.com> Change-Id: I05a107098b717299e76de76aaba00d7fbaeac77b	2 years ago
Simon Marchi	5ac2d81b64	gdb: remove stale comment and ctor in gdbarch_info tdesc_data is not part of a union, since commit `4f3681cc33` ("Fix thread's gdbarch when SVE vector length changes"). Remove the stale comment and constructor. Change-Id: Ie895ce36614930e8bd9c4967174c8bf1b321c503	2 years ago
Jens Remus	1c354ebcba	s390: Add suffix to conditional branch instruction descriptions Suffix the instruction description of conditional branch extended mnemonics with their condition (e.g. "on A high"). This complements the optional printing of instruction descriptions as comments in the disassembly. Due to the added text the maximum description length is increased from 80 to 128 characters (including the trailing '\0' character). opcodes/ * s390-mkopc.c: Add suffix to conditional branch extended mnemonic instruction descriptions. gas/ * testsuite/gas/s390/zarch-insndesc.s: Add test cases for printing of suffixed instruction description of conditional branch extended mnemonics. * testsuite/gas/s390/zarch-insndesc.d: Likewise. Signed-off-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>	2 years ago
Jens Remus	f96fe7f454	s390: Optionally print instruction description in disassembly Print instruction description as comment in disassembly with s390 architecture specific option "insndesc": - For objdump it can be enabled with option "-M insndesc" - In gdb it can be enabled with "set disassembler-options insndesc" Since comments are not column aligned the output can enhanced for readability by postprocessing using a filter such as "expand": ... \| expand -t 8,16,24,32,40,80 Or when using in combination with objdump option --visualize-jumps: ... \| expand \| sed -e 's/ #/\t#/' \| expand -t 1,80 Note that the instruction descriptions add about 128 KB to s390-opc.o: s390-opc.o without instruction descriptions: 216368 bytes s390-opc.o with instruction descriptions : 348432 bytes binutils/ NEWS: Mention new s390-specific disassembler option "insndesc". include/ * opcode/s390.h (struct s390_opcode): Add field to hold instruction description. opcodes/ * s390-mkopc.c: Copy instruction description from s390-opc.txt into generated operation code table s390-opc.tab. * s390-opc.c (s390_opformats): Provide NULL as description in .insn pseudo-mnemonics opcode table. * s390-dis.c: Add s390-specific disassembler option "insndesc" and optionally print the instruction description as comment in the disassembly when it is specified. gas/ * testsuite/gas/s390/s390.exp: Add new test disassembly test case "zarch-insndesc". * testsuite/gas/s390/zarch-insndesc.s: New test case for s390- specific disassembler option "insndesc". * testsuite/gas/s390/zarch-insndesc.d: Likewise. Signed-off-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>	2 years ago
Jens Remus	a3fa108623	s390: Use safe string functions and length macros in s390-mkopc Use strncpy() and snprintf() instead of strcpy() and strcat(). Define and use macros for string lengths, such as mnemonic, instruction format, and instruction description. This is a mechanical change, although some buffers have increased in length by one character. This has been confirmed by verifying that the generated opcode/s390-opc.tab is unchanged. opcodes/ * s390-mkopc.c: Use strncpy() and strncat(). Suggested-by: Nick Clifton <nickc@redhat.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>	2 years ago
Jens Remus	730e7ddc24	s390: Enhance error handling in s390-mkopc When the s390-mkopc utility detects an error it prints an error message to strerr and either continues processing or exists with a non-zero return code. If it continues without detecting any further error the final return code was zero, potentially hiding the detected error. Introduce a global variable to hold the final return code and initialize it to EXIT_SUCCESS. Introduce a helper function print_error() that prints an error message to stderr and sets the final return code to EXIT_FAILURE. Use it to print all error messages. Return the final return code at the end of the processing. While at it enhance error messages to state more clearly which mnemonic an error was detected for. Also continue processing for cases where subsequent mnemonics can be processed. opcodes/ * s390-mkopc.c: Enhance error handling. Return EXIT_FAILURE in case of an error, otherwise EXIT_SUCCESS. Signed-off-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>	2 years ago
Jens Remus	2ff609b4ce	s390: Provide IBM z16 (arch14) instruction descriptions Provide descriptions for instructions introduced with commit `ba2b480f10` ("IBM Z: Implement instruction set extensions"). This complements commit `69341966de` ("IBM zSystems: Add support for z16 as CPU name."). Use instruction names from IBM z/Architecture Principles of Operation [1] as instruction description. [1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16, https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf opcodes/ * s390-opc.txt: Add descriptions for IBM z16 (arch14) instructions. Signed-off-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>	2 years ago
Jens Remus	8e194ff8cc	s390: Align letter case of instruction descriptions Change the bitwise operations names "and" and "or" to lower case. Change the register name abbreviations "FPR", "GR", and "VR" to upper case. opcodes/ * s390-opc.txt: Align letter case of instruction descriptions. Signed-off-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>	2 years ago
Jens Remus	78aa7688e8	s390: Fix build when using EXEEXT_FOR_BUILD Suffix the s390-mkopc build utility executable file name with EXEEXT_FOR_BUILD. Otherwise it cannot be located when building with EXEEXT_FOR_BUILD. Use pattern used for other architecture build utilities and compile and link s390-mkopc in two steps. While at it also specify the dependencies of s390-mkopc.c. opcodes/ * Makefile.am: Add target to build s390-mkopc.o. Correct target to build s390-mkopc$(EXEEXT_FOR_BUILD). * Makefile.in: Regenerate. Signed-off-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>	2 years ago
Mike Frysinger	06f05f3585	sim: frv: enable warnings in memory.c Fix one minor pointer-sign warning to enable warnings in general for this file. Reading the data as signed and then returning it as unsigned should be functionally the same in this case.	2 years ago
GDB Administrator	90bfe9e2b4	Automatic date update in version.in	2 years ago
Alan Modra	cf86e13d8b	Re: PR31145, potential memory leak in binutils/ld Revert most of this patch, it isn't correct to free the BFD_IN_MEMORY iostream in io_reinit. PR 31145 * format.c (io_reinit): Revert last change. Comment. * opncls.c (_bfd_delete_bfd): Likewise.	2 years ago
Simon Marchi	80d2ef0c44	gdb: use put_frame_register instead of put_frame_register_bytes in pseudo_to_concat_raw Here, we write single complete registers, we don't need the functionality of put_frame_register_bytes, use put_frame_register instead. Change-Id: I987867a27249db4f792a694b47ecb21c44f64d08 Approved-By: Tom Tromey <tom@tromey.com>	2 years ago
Simon Marchi	f00c5474ef	gdb: remove stale comment in value_assign This comment is no longer relevant, put_frame_register_bytes now accepts the "next frame". Change-Id: I077933a03f8bdb886f8ba10a98d1202a38bce0a9 Approved-By: Tom Tromey <tom@tromey.com>	2 years ago
Andrea Corallo	d645278cdf	aarch64: Add FEAT_ITE support This patch add support for FEAT_ITE "Instrumentation Extension" adding the "trcit" instruction. This is enabled by the +ite march flag.	3 years ago
Andrea Corallo	db168da2e0	aarch64: Add FEAT_ECBHB support This patch add support for FEAT_ECBHB "Exploitative control using branch history information" adding the "clrbhb" instruction. AFAIU the same alias was originally added as "clearbhb" before the architecture was finalized (Mandatory v8.9-a/v9.4-a; Optional v8.0-a+/v9.0-a+).	3 years ago
Andrea Corallo	88b5a8ae13	aarch64: Add FEAT_SPECRES2 support This patch add supports for FEAT_SPECRES2 "Enhanced speculation restriction instructions" adding the "cosp" instruction. This is mandatory v8.9-a/v9.4-a and optional v8.0-a+/v9.0-a+. It is enabled by the +predres2 march flag.	3 years ago
Guinevere Larsen	25bb95ea6d	gdb: register frame_destroyed function for amd64 gdbarch gdbarches usually register functions to check when a frame is destroyed which is used with software watchpoints, since the expression of the watchpoint is no longer vlaid at this point. On amd64, this wasn't done anymore because GCC started using CFA for variable locations instead. However, clang doesn't use the CFA and instead relies on specifying when an epilogue has started, meaning software watchpoints get a spurious hit when a frame is destroyed. This patch re-adds the code to register the function that detects when a frame is destroyed, but only uses this when the producer is LLVM, so gcc code isn't affected. The logic that identifies the epilogue has been factored out into the new function amd64_stack_frame_destroyed_p_1, so the frame sniffer can call it directly, and its behavior isn't changed. This can also remove the XFAIL added to gdb.python/pq-watchpoint tests that handled this exact flaw in clang. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>	2 years ago
Mike Frysinger	e875d98ee5	sim: common: delete unused argbuf in generated mloop code This function only uses prev_abuf, not abuf, and doesn't inline code from the various ports on the fly, so abuf will never be used.	2 years ago
Mike Frysinger	e7198a4305	sim: v850: fix -Wunused-variable warnings	2 years ago
Mike Frysinger	67df132b65	sim: sh: fix -Wunused-variable warnings	2 years ago
Mike Frysinger	5daeb7f67a	sim: moxie: fix -Wunused-variable warnings	2 years ago
Mike Frysinger	eade758025	sim: msp430: fix -Wunused-variable warnings	2 years ago
Mike Frysinger	7704565d2f	sim: mn10300: fix -Wunused-variable warnings	2 years ago
Mike Frysinger	bb2f91823f	sim: mips: fix -Wunused-variable warnings	2 years ago
Mike Frysinger	96967be368	sim: microblaze: fix -Wunused-variable warnings	2 years ago
Mike Frysinger	2705c08342	sim: mcore: fix -Wunused-variable warnings	2 years ago
Mike Frysinger	568b2f90c7	sim: m32r: fix -Wunused-variable warnings	2 years ago
Mike Frysinger	9340c17241	sim: lm32: fix -Wunused-variable warnings	2 years ago

1 2 3 4 5 ...

117052 Commits (4935610a577445aef20643a226bca7e6bd11fcb4) All Branches Search

117052 Commits (4935610a577445aef20643a226bca7e6bd11fcb4)

All Branches