aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-12-19aarch64: Add FEAT_SPECRES2 supportAndrea Corallo11-2075/+2112
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.
2023-12-19gdb: register frame_destroyed function for amd64 gdbarchGuinevere Larsen2-24/+25
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>
2023-12-19sim: common: delete unused argbuf in generated mloop codeMike Frysinger1-2/+0
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.
2023-12-19sim: v850: fix -Wunused-variable warningsMike Frysinger1-1/+0
2023-12-19sim: sh: fix -Wunused-variable warningsMike Frysinger1-3/+1
2023-12-19sim: moxie: fix -Wunused-variable warningsMike Frysinger1-8/+1
2023-12-19sim: msp430: fix -Wunused-variable warningsMike Frysinger1-5/+2
2023-12-19sim: mn10300: fix -Wunused-variable warningsMike Frysinger2-9/+0
2023-12-19sim: mips: fix -Wunused-variable warningsMike Frysinger5-21/+12
2023-12-19sim: microblaze: fix -Wunused-variable warningsMike Frysinger1-6/+0
2023-12-19sim: mcore: fix -Wunused-variable warningsMike Frysinger1-4/+3
2023-12-19sim: m32r: fix -Wunused-variable warningsMike Frysinger1-2/+0
2023-12-19sim: lm32: fix -Wunused-variable warningsMike Frysinger4-15/+1
2023-12-19sim: iq2000: fix -Wunused-variable warningsMike Frysinger2-2/+0
2023-12-19sim: h8300: fix -Wunused-variable warningsMike Frysinger1-7/+0
2023-12-19sim: ft32: fix -Wunused-variable warningsMike Frysinger1-6/+0
2023-12-19sim: frv: fix -Wunused-variable warningsMike Frysinger6-19/+3
2023-12-19sim: erc32: fix -Wunused-variable warningsMike Frysinger3-5/+4
2023-12-19sim: cris: fix -Wunused-variable warningsMike Frysinger3-6/+0
2023-12-19sim: cr16: fix -Wunused-variable warningsMike Frysinger1-3/+2
2023-12-19sim: bpf: fix -Wunused-variable warningsMike Frysinger1-2/+0
2023-12-19sim: bfin: fix -Wunused-variable warningsMike Frysinger1-1/+0
2023-12-19sim: aarch64: fix -Wunused-variable warningsMike Frysinger1-1/+0
2023-12-19sim: common: fix -Wunused-variable warningsMike Frysinger6-14/+10
2023-12-19cpu: cris: drop some unused varsMike Frysinger3-9/+11
These fix unused variable warnings in the generated sim.
2023-12-19x86: Remove the restriction for size of the mask register in AVX10Haochen Jiang7-4008/+3792
Since AVX10.1/256 will also allow 64 bit mask register, we will remove the restriction for size of the mask register in AVX10. gas/ChangeLog: * config/tc-i386.c (VSZ128, VSZ256, VSZ512): New. (VEX_check_encoding): Remove opcode_modifier check for vsz. * testsuite/gas/i386/avx10-vsz.l: Remove testcases for mask registers since they are not needed. * testsuite/gas/i386/avx10-vsz.s: Ditto. opcodes/ChangeLog: * i386-gen.c: Remove Vsz. * i386-opc.h: Ditto. * i386-opc.tbl: Remove kvsz. * i386-tbl.h: Regenerated.
2023-12-19LoongArch: Allow la.got -> la.pcrel relaxation for shared objectXi Ruoyao1-2/+1
Even in shared objects, la.got -> la.pcrel relaxation can still be performed for symbols with hidden visibility. For example, if a.c is: extern int x; int f() { return x++; } and b.c is: int x = 114514; If compiling and linking with: gcc -shared -fPIC -O2 -fvisibility=hidden a.c b.c Then the la.got in a.o should be relaxed to la.pcrel, and the resulted f should be like: pcaddi $t0, x ldptr.w $a0, $t0, 0 addi.w $t1, $a0, 1 stptr.w $t1, $t0, 0 ret Remove bfd_link_executable from the condition of la.got -> la.pcrel relaxation so this will really happen. The SYMBOL_REFERENCES_LOCAL check is enough not to wrongly relax preemptable symbols (for e.g. when -fvisibility=hidden is not used). Note that on x86_64 this is also relaxed and the produced code is like: lea x(%rip), %rdx mov (%rdx), %rax lea 1(%rax), %ecx mov %ecx, (%rdx) ret Tested by running ld test suite, bootstrapping and regtesting GCC with the patched ld, and building and testing Glibc with the patched ld. No regression is observed. Signed-off-by: Xi Ruoyao <xry111@xry111.site>
2023-12-18Yet another fix for mcore-sim (rotli)Jeff Law2-1/+32
This came up testing the CRC optimization work from Mariam@RAU. Basically to optimize some CRC loops into table lookups or carryless multiplies, we may need to do a bit reflection, which on the mcore processor is done using a rotate instruction. Unfortunately the simulator implementation of rotates has the exact same problem as we saw with right shifts. The input value may have been sign extended from 32 to 64 bits. When we rotate the extended value, we get those sign extension bits and thus the wrong result. The fix is the same. Rather than using a "long", use a uint32_t for the type of the temporary. This fixes a handful of tests in the GCC testsuite:
2023-12-19Automatic date update in version.inGDB Administrator1-1/+1
2023-12-18gettext: disable install, docs targets, libasprintf, threadsArsen Arsenović2-175/+40
This fixes issues reported by David Edelsohn <dje.gcc@gmail.com>, and by Eric Gallager <egallager@gcc.gnu.org>. ChangeLog: * Makefile.def (gettext): Disable (via missing) {install-,}{pdf,html,info,dvi} and TAGS targets. Set no_install to true. Add --disable-threads --disable-libasprintf. * Makefile.in: Regenerate.
2023-12-18ld: Print 0 size in B and not in GBTorbjörn SVENSSON3-1/+5
When using --print-memory-usage, the printed size can be zero and in that case, the unit should be B and not GB. ld/ * ldlang.c (lang_print_memory_size) Print 0 B instead of 0 GB. * testsuite/ld-scripts/print-memory-usage-1.l: Validate emplty region. * testsuite/ld-scripts/print-memory-usage-1.t: Define empty region. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
2023-12-18PR31162, Memory Leak in ldwrite.cAlan Modra1-6/+11
This isn't a particularly worrying memory leak, but fix it anyway. PR 31162 * ldwrite.c (build_link_order): Use bfd_alloc rather than xmalloc. Add %E to error messages.
2023-12-18gdb/testsuite: another attempt to fix gdb.threads/thread-specific-bp.expAndrew Burgess1-18/+6
The gdb.threads/thread-specific-bp.exp test has been a little problematic, see commits: commit 89702edd933a5595557bcd9cc4a0dcc3262226d4 Date: Thu Mar 9 12:31:26 2023 +0100 [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver and commit 2e5843d87c4050bf1109921481fb29e1c470827f Date: Fri Nov 19 14:33:39 2021 +0100 [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp But I recently saw a test failure for that test, which looked like this: ... (gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=on: thread 1 selected continue -a Continuing. Thread 1 "thread-specific" hit Breakpoint 4, end () at /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c:29 29 } (gdb) [Thread 0x7ffff7c5c700 (LWP 1552086) exited] Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list. FAIL: gdb.threads/thread-specific-bp.exp: non_stop=on: continue to end (timeout) ... This only crops up (for me) when running on a loaded machine, and still only occurs sometimes. I've had to leave the test running in a loop for 10+ minutes sometimes in order to see the failure. The problem is that we use gdb_test_multiple to try and match two patterns: (1) The 'Thread-specific breakpoint 3 deleted ....' message, and (2) The GDB prompt. As written in the test, we understand that these patterns can occur in any order, and we have a flag for each pattern. Once both patterns have been seen then we PASS the test. The problem is that once expect has matched a pattern, everything up to, and including the matched text is discarded from the input buffer. Thus, if the input buffer contains: <PATTERN 2><PATTERN 1> Then expect will first try to match <PATTERN 1>, which succeeds, and then expect discards the entire input buffer up to the end of the <PATTERN 1>. As a result, we will never spot <PATTERN 2>. Obviously we can't just reorder the patterns within the gdb_test_multiple, as the output can legitimately (and most often does) occur in the other order, in which case the test would mostly fail, and only occasionally pass! I think the easiest solution here is just to have the gdb_test_multiple contain two patterns, each pattern consists of the two parts, but in the alternative orders, thus, for a particular output configuration, only one regexp will match. With this change in place, I no longer see the intermittent failure. Approved-By: Tom Tromey <tom@tromey.com>
2023-12-18LoongArch: Add call36 and tail36 pseudo instructions for medium code modelmengqinggang4-2/+23
For tail36, it is necessary to explicitly indicate the temporary register. Therefore, the compiler and users will know that the tail will use a register. call36 func pcalau18i $ra, %call36(func) jirl $ra, $ra, 0; tail36 $t0, func pcalau18i $t0, %call36(func) jirl $zero, $t0, 0;
2023-12-18LoongArch: Add new relocation R_LARCH_CALL36mengqinggang11-7/+89
R_LARCH_CALL36 is used for medium code model function call pcaddu18i+jirl, and these two instructions must adjacent. The LoongArch ABI v2.20 at here: https://github.com/loongson/la-abi-specs.
2023-12-18PR31177: Let region text start at __TEXT_REGION_ORIGIN___Georg-Johann Lay1-1/+2
The start of MEMORY region text currently starts hard-coded at 0. The linker can produce more exact diagnostics when it knows the exact placements of the memory regions. For some old devices, program memory starts at 0x8000, so allow to specify program memory start at __TEXT_REGION_ORIGIN__ similar to how the data region is described. If ok, please apply to master. This one is also fine to back-port. Johann -- AVR: Use __TEXT_REGION_ORIGIN__ as start for MEMORY region text. ld/ PR 31177 * scripttempl/avr.sc (__TEXT_REGION_ORIGIN__): New symbol. (MEMORY): Use as start address for the text region.
2023-12-18Automatic date update in version.inGDB Administrator1-1/+1
2023-12-17sim: warnings: add more flagsMike Frysinger2-0/+6
We already build cleanly with these.
2023-12-17Automatic date update in version.inGDB Administrator1-1/+1
2023-12-16Use function entry point record only for entry valuesHannes Domani3-5/+7
PR28987 notes that optimized code sometimes shows the wrong value of variables at the entry point of a function, if some code was optimized away and the variable has multiple values stored in the debug info for this location. In this example: ``` void foo() { int l_3 = 5, i = 0; for (; i < 8; i++) ; test(l_3, i); } ``` When compiled with optimization, the entry point of foo is at the test() function call, since everything else is optimized away. The debug info of i looks like this: ``` (gdb) info address i Symbol "i" is multi-location: Base address 0x140001600 Range 0x13fd41600-0x13fd41600: the constant 0 Range 0x13fd41600-0x13fd41600: the constant 1 Range 0x13fd41600-0x13fd41600: the constant 2 Range 0x13fd41600-0x13fd41600: the constant 3 Range 0x13fd41600-0x13fd41600: the constant 4 Range 0x13fd41600-0x13fd41600: the constant 5 Range 0x13fd41600-0x13fd41600: the constant 6 Range 0x13fd41600-0x13fd41600: the constant 7 Range 0x13fd41600-0x13fd4160f: the constant 8 (gdb) p i $1 = 0 ``` Currently, when at the entry point of a function, it will always show the initial value (here 0), while the user would expect the last value (here 8). This logic was introduced for showing the entry-values of function arguments if they are available, but for some reason this was added for non-entry-values as well. One of the tests of amd64-entry-value.exp shows the same problem for function arguments, if you "break stacktest" in the following example, you stop at this line: ``` 124 static void __attribute__((noinline, noclone)) 125 stacktest (int r1, int r2, int r3, int r4, int r5, int r6, int s1, int s2, 126 double d1, double d2, double d3, double d4, double d5, double d6, 127 double d7, double d8, double d9, double da) 128 { 129 s1 = 3; 130 s2 = 4; 131 d9 = 3.5; 132 da = 4.5; 133 -> e (v, v); 134 asm ("breakhere_stacktest:"); 135 e (v, v); 136 } ``` But `bt` still shows the entry values: ``` s1=s1@entry=11, s2=s2@entry=12, ..., d9=d9@entry=11.5, da=da@entry=12.5 ``` I've fixed this by only using the initial values when explicitely looking for entry values. Now the local variable of the first example is as expected: ``` (gdb) p i $1 = 8 ``` And the test of amd64-entry-value.exp shows the expected current and entry values of the function arguments: ``` s1=3, s1@entry=11, s2=4, s2@entry=12, ..., d9=3.5, d9@entry=11.5, da=4.5, da@entry=12.5 ``` Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28987 Tested-By: Guinevere Larsen <blarsen@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
2023-12-16[gdb/build] Remove dependency on _rl_term_autowrapTom de Vries1-8/+11
Commit deb1ba4e38b ("[gdb/tui] Fix TUI resizing for TERM=ansi") introduced a dependency on readline private variable _rl_term_autowrap. There is precedent for this, but it's something we want to get rid of (PR build/10723). Remove the dependency on _rl_term_autowrap, and instead calculate readline_hidden_cols by comparing the environment variable COLS with cols as returned by rl_get_screen_size. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=10723
2023-12-16[gdb/tui] Show regs when switching to regs layoutTom de Vries3-8/+22
When starting gdb in CLI mode, running to main and switching into the TUI regs layout: ... $ gdb -q a.out -ex start -ex "layout regs" ... we get: ... +---------------------------------+ | | | [ Register Values Unavailable ] | | | +---------------------------------+ ... Fix this by handling this case in tui_data_window::rerender. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR tui/28600 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28600
2023-12-16[gdb/tui] Use more box_width in tui-regs.cTom de Vries1-2/+6
While experimenting with can_box () == false by default, I noticed two places in tui-regs.c where we can replace a hardcoded 1 with box_width (). It also turned out to be necessary to set scrollok to false, otherwise writing the last char of the last line with register info will cause a scroll. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2023-12-16sim: cr16: clean up unused insn operandsMike Frysinger1-4/+2
The push/pop insns only have 2 operands, so delete unused "c". The pushret/popret insns use 2 operands, but they don't implement the logic directly, they call the push/pop implementations. So delete the unused "a" & "b".
2023-12-15sim: sh: adjust some dsp insn masksMike Frysinger1-3/+3
The pmuls encoding is incorrect -- it looks like a copy & paste error from the padd pmuls variant. The SuperH software manual covers this. On the flip side, the manual lists pwsb & pwad as insns that exist, but no description of what they do, what the insn name means, or the actual encoding. Our sim implementation stubs them both out as nops. Let's mark the fields to avoid unused variable warnings.
2023-12-15sim: sh: tidy up gencode slightlyMike Frysinger1-68/+72
Mark a few things static/const, and clean up trailing whitespace.
2023-12-15sim: bfin: fix typo in bf52x portsMike Frysinger1-6/+6
These should be using the BF52x set of ports, not BF51x.
2023-12-15sim: warnings: enable -Wunused-but-set-variableMike Frysinger2-2/+2
2023-12-15sim: mn10300: fix incorrect implementation of a few insnsMike Frysinger1-7/+7
Fix a few problems caught by compiler warnings: * Some of the asr & lsr insns were setting up the c state flag, but then forgetting to set it in the PSW. Add it like the other asr & lsr variants. * Some of the dmulh insns were multiplying one of the source regs against itself instead of against the other source reg. * The sat16_cmp parallel insn was using the wrong register in the compare -- the reg1 src/dst pair are used in the sat16 op, and the reg2 src/dst pair are used in the add op.
2023-12-16Automatic date update in version.inGDB Administrator1-1/+1