aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-04-01LoongArch: Fix the issue of excessive relocation generated by GD and IELulu Cai3-135/+142
Currently, whether GD and IE generate dynamic relocation is determined by SYMBOL_REFERENCES_LOCAL and bfd_link_executable. This results in dynamic relocations still being generated in some situations where dynamic relocations are not necessary (such as the undefined weak symbol in static links). We use RLARCH_TLS_GD_IE_NEED_DYN_RELOC macros to determine whether GD/IE needs dynamic relocation. If GD/IE requires dynamic relocation, set need_reloc to true and indx to be a dynamic index. At the same time, some test cases were modified to use regular expression matching instead of complete disassembly matching.
2024-04-01LoongArch: gas: Ignore .align if it is at the start of a sectionmengqinggang6-25/+157
Ignore .align if it is at the start of a section and the alignment can be divided by the section alignment, the section alignment can ensure this .align has a correct alignment.
2024-04-01Automatic date update in version.inGDB Administrator1-1/+1
2024-03-31gdb: build dprintf commands just once in code_breakpoint constructorAndrew Burgess1-7/+7
I noticed in code_breakpoint::code_breakpoint that we are calling update_dprintf_command_list once for each breakpoint location, when we really only need to call this once per breakpoint -- the data updated by this function, the breakpoint command list -- is per breakpoint, not per breakpoint location. Calling update_dprintf_command_list multiple times is just wasted effort, there's no per location error checking, we don't even pass the current location to the function. This commit moves the update_dprintf_command_list call outside of the per-location loop. There should be no user visible changes after this commit.
2024-03-31gdb: the extra_string in a dprintf breakpoint is never nullptrAndrew Burgess1-11/+5
Given the changes in the previous couple of commits, this commit cleans up some of the asserts and 'if' checks related to the extra_string within a dprintf breakpoint. This commit: 1. Adds some asserts to update_dprintf_command_list about the breakpoint type, and that the extra_string is not nullptr, 2. Given that we know extra_string is not nullptr (this is enforced when the breakpoint is created), we can simplify code_breakpoint::code_breakpoint -- it no longer needs to check for the extra_string is nullptr case, 3. In dprintf_breakpoint::re_set we can remove the assert (this will be checked within update_dprintf_command_list, we can also remove the redundant 'if' check. There should be no user visible changes after this commit.
2024-03-31gdb: change 'if' to gdb_assert in update_dprintf_command_listAndrew Burgess1-2/+3
I noticed in update_dprintf_command_list that we handle the case where the bp_dprintf style breakpoint doesn't have a format and args string. However, I don't believe such a situation is possible. The obvious approach certainly already catches this case: (gdb) dprintf main Format string required If it is possible to create a dprintf breakpoint without a format and args string then I think we should be catching this case and handling it at creation time, rather than having GDB just ignore the situation later on. And so, I propose that we change the 'if' that ignores the case where the format/args string is empty, and instead assert that we do always have a format/args string. The original code, that handled an empty format/args string has existed since commit e7e0cddfb0d4, which is when dprintf support was added to GDB. If I'm correct and this situation can't ever happen then there should be no user visible changes after this commit.
2024-03-31gdb: create_breakpoint: asserts relating to extra_string/parse_extraAndrew Burgess2-30/+55
The goal of this commit is to better define the API for create_breakpoint especially around the use of extra_string and parse_extra. This will be useful in the next commit when I plan to make some changes to create_breakpoint. This commit makes one possibly breaking change: until this commit it was possible to create thread-specific dprintf breakpoint like this: (gdb) dprintf call_me, thread 1 "%s", "hello" Dprintf 2 at 0x401152: file /tmp/hello.c, line 8. (gdb) info breakpoints Num Type Disp Enb Address What 2 dprintf keep y 0x0000000000401152 in call_me at /tmp/hello.c:8 thread 1 stop only in thread 1 printf "%s", "hello" (gdb) This feature of dprintf was not documented, was not tested, and is slightly different in syntax to how we create thread specific breakpoints and/or watchpoints -- the thread condition appears after the first ','. I believe that this worked at all was simply by luck. We happen to pass the parse_extra flag as true from dprintf_command to create_breakpoint. So in this commit I made the choice to change this. We now pass parse_extra as false from dprintf_command to create_breakpoint. With this done it is assumed that the only thing in the extra_string is the dprintf format and arguments. Beyond this change I've updated the comment on create_breakpoint in breakpoint.h, and I've then added some asserts into create_breakpoint as well as moving around some of the error handling. - We now assert on the incoming argument values, - I've moved an error check to sit after the call to find_condition_and_thread_for_sals, this ensures the extra_string was parsed correctly, In dprintf_command: - We now throw an error if there is no format string after the dprintf location. This error was already being thrown, but was being caught later in the process. With this change we catch the missing string earlier, - And, as mentioned earlier, we pass parse_extra as false when calling create_breakpoint, In create_tracepoint_from_upload: - We now throw an error if the parsed location doesn't completely consume the addr_str variable. This error has now effectively moved out of create_breakpoint.
2024-03-31gdb: create_breakpoint: add asserts and additional commentsAndrew Burgess2-0/+22
This commit extends the asserts on create_breakpoint (in the header file), and adds some additional assertions into the definition. The new assert confirms that when the thread and inferior information is going to be parsed from the extra_string, then the thread and inferior arguments should be -1. That is, the caller of create_breakpoint should not try to create a thread/inferior specific breakpoint by *both* specifying thread/inferior *and* asking to parse the extra_string, it's one or the other. There should be no user visible changes after this commit.
2024-03-31BFD: Fix the bug of R_LARCH_AGLIN caused by discard sectionmengqinggang9-8/+66
To represent the first and third expression of .align, R_LARCH_ALIGN need to associate with a symbol. We define a local symbol for R_LARCH_AGLIN. But if the section of the local symbol is discarded, it may result in a undefined symbol error. Instead, we use the section name symbols, and this does not need to add extra symbols. During partial linking (ld -r), if the symbol associated with a relocation is STT_SECTION type, the addend of relocation needs to add the section output offset. We prevent it for R_LARCH_ALIGN. The elf_backend_data.rela_normal only can set all relocations of a target to rela_normal. Add a new function is_rela_normal to elf_backend_data, it can set part of relocations to rela_normal.
2024-03-31Automatic date update in version.inGDB Administrator1-1/+1
2024-03-30Lower variable definitions in tui_redisplay_readlineTom Tromey1-18/+9
I noticed a redundant assignment to 'prev_col' in tui_redisplay_readline, and then went ahead and lowered most of the variable definitions in that function to their initialization point.
2024-03-30Automatic date update in version.inGDB Administrator1-1/+1
2024-03-29gdb/testsuite: don't include port numbers in test namesAndrew Burgess1-1/+2
The gdb.python/py-cmd-prompt.exp script includes a test that has a gdbserver port number within a test name. As port numbers can change from one test run to the next (depending on what else is running on the machine at the time), this can make it hard to compare test results between runs. Give the test a specific name to avoid including the port number. There is no change in what is tested after this commit.
2024-03-29gdb/testsuite: avoid $pc/$sp values in test namesAndrew Burgess1-1/+2
Provide an explicit name for a test in gdb.base/pc-not-saved.exp to avoid printing $pc and $sp values in the test name -- these values might change between different test runs, which makes it harder to compare test results. There is no change in what is actually being tested with this commit.
2024-03-29[gdb/testsuite] Add missing includes in gdb.trace/collection.cTom de Vries1-0/+3
On fedora rawhide, with test-case gdb.trace/collection.exp, I get: ... gdb compile failed, collection.c: In function 'strings_test_func': collection.c:227:13: error: implicit declaration of function 'malloc' \ [-Wimplicit-function-declaration] 227 | longloc = malloc(500); | ^~~~~~ collection.c:1:1: note: \ include '<stdlib.h>' or provide a declaration of 'malloc' +++ |+#include <stdlib.h> 1 | /* This testcase is part of GDB, the GNU debugger. collection.c:228:3: error: implicit declaration of function 'strcpy' \ [-Wimplicit-function-declaration] 228 | strcpy(longloc, ... ); | ^~~~~~ collection.c:1:1: note: include '<string.h>' or provide a declaration of \ 'strcpy' +++ |+#include <string.h> 1 | /* This testcase is part of GDB, the GNU debugger. collection.c:230:8: error: implicit declaration of function 'strlen' \ [-Wimplicit-function-declaration] 230 | i += strlen (locstr); | ^~~~~~ collection.c:230:8: note: include '<string.h>' or provide a declaration of \ 'strlen' ... Fix this by adding the missing includes. Tested on aarch64-linux. Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-03-29[gdb/testsuite] Fix missing return type in gdb.linespec/break-asm-file.cTom de Vries1-1/+1
On fedora rawhide, when running test-case gdb.linespec/break-asm-file.exp, I get: ... gdb compile failed, break-asm-file.c:21:8: error: \ return type defaults to 'int' [-Wimplicit-int] 21 | static func() | ^~~~ ... Fix this by adding the missing return type. Tested on aarch64-linux. Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-03-29Automatic date update in version.inGDB Administrator1-1/+1
2024-03-28Make pascal_language::print_type handle varstring==nullptrTom Tromey1-1/+2
PR gdb/31524 points out a crash when pascal_language::print_type is called with varstring==nullptr. This crash is a regression arising from the printf/pager rewrite -- that indirectly removed a NULL check from gdb's "puts". This patch instead fixes the problem by adding a check to print_type. Passing nullptr here seems to be expected in other places (e.g., there is a call to type_print like this in expprint.c), and other implementations of this method (or related helpers) explicitly check for NULL. I didn't write a test case for this because it seemed like overkill for a Pascal bug that only occurs with -i=mi. However, if you want one, let me know and I will do it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31524 Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-03-28gas: gcfg: fix handling of non-local direct jmps in gcfgIndu Bhagat5-19/+104
The ginsn infrastructure in GAS includes the ability to create a GCFG (ginsn CFG). A GCFG is currently used for SCFI passes. This patch fixes the following invalid assumptions / code blocks: - The function ginsn_direct_local_jump_p () was erroneously _not_ checking whether the symbol is locally defined (i.e., within the scope of the code block for which GCFG is desired). Fix the code to do so. - Similarly, the GCFG creation code, in gcfg_build () itself had an assumption that a GINSN_TYPE_JUMP to a non-local symbol will not be seen. The latter can indeed be seen, and in fact, needs to be treated the same way as an exit from the function in terms of control-flow. gas/ * ginsn.c (ginsn_direct_local_jump_p): Check if the symbol is local to the code block or function being assembled. (add_bb_at_ginsn): Remove buggy assumption. (frch_ginsn_data_append): Direct jmps do not disqualify a stream of ginsns from GCFG creation. gas/testsuite/ * gas/scfi/x86_64/scfi-cfg-3.d: New test. * gas/scfi/x86_64/scfi-cfg-3.l: New test. * gas/scfi/x86_64/scfi-cfg-3.s: New test. * gas/scfi/x86_64/scfi-x86-64.exp: Add new test.
2024-03-28x86/SSE2AVX: move checkingJan Beulich1-11/+10
It has always been looking a little odd to me that this was done deep in cpu_flags_match(). Move it to match_template() itself - there's no need to do anything complex when encountering such a template while it cannot possibly be used.
2024-03-28x86/SSE2AVX: respect prefixesJan Beulich3-2/+21
1) Without -msse2avx we unconditionally honor REX.W. Hence we ought to also do so with -msse2avx, converting to VEX.W. 2) {rex} doesn't prevent conversion to VEX encodings. Thus {rex2} shouldn't either.
2024-03-28gas: drop integer_constant()'s maxdigJan Beulich1-8/+4
Once properly set, it's only ever holding the same value as "radix". Even if there was some plan with it, that plan hasn't made it anywhere in over 20 years.
2024-03-28gas: drop dead check for double quoteJan Beulich1-3/+0
FB and dollar label definitions can't be enclosed in double quotes. In fact at that point nul_char is the same as next_char, which we know is a digit.
2024-03-28gas: sanitize FB- and dollar-label usesJan Beulich4-20/+31
I don't view it as sensible to be more lax when it comes to references to (uses of) such labels compared to their definition: The latter has been limited to decimal numerics, while the former permitted any radix. Beyond that leading zeroes on such labels aren't helpful either. Imo labels and their use sites would better match literally, to avoid confusion. As it turns out, one z80 testcase actually had such an odd use of labels where definition and use don't match in spelling. That testcase is being adjusted accordingly. While there also adjust a comment on a local variable in integer_constant().
2024-03-28x86: templatize RAO-INT insnsJan Beulich1-8/+4
It's only four of them, but still better to reduce redundancy.
2024-03-28x86: templatize ADX insnsJan Beulich1-6/+5
It's only two of them, but still better to reduce redundancy.
2024-03-28x86: templatize shift-double insnsJan Beulich2-331/+303
With the multitude of new APX templates, it finally becomes desirable to further remove redundancy by also templatizing basic arithmetic insns. Continue with the shift-double ones. While there also drop the APX form with ShiftCount omitted. Other shift and rotate insns were deliberately left without this form as well. Note that there's also no testsuite adjustment needed for this, indicating that the form wasn't tested either.
2024-03-28x86: templatize shift/rotate insnsJan Beulich2-264/+379
With the multitude of new APX templates, it finally becomes desirable to further remove redundancy by also templatizing basic arithmetic insns. Continue with the "ordinary" shift and rotate ones. While there also drop the APX form of RCL/RCR with Imm1 omitted. Other shift insns as well as ROR/ROL were deliberately left without this form as well. Note that there's also no testsuite adjustment needed for this, indicating that the form wasn't tested either. Furthermore since RCL/RCR already had non-NDD APX forms, those end up being added for the other 6 mnemonics, too.
2024-03-28x86: templatize binary ALU insnsJan Beulich2-449/+473
With the multitude of new APX templates, it finally becomes desirable to further remove redundancy by also templatizing basic arithmetic insns. Continue with a the more complex binary (two source) cases. Note how this adds a missing CheckOperandSize to one of the APX sub forms. Furthermore since SBB already had a non-NDD APX form, one ends up being added for the other 6 mnemonics, too.
2024-03-28x86: templatize unary ALU insnsJan Beulich2-16/+22
With the multitude of new APX templates, it finally becomes desirable to further remove redundancy by also templatizing basic arithmetic insns. Continue with a few simple unary (single source) cases.
2024-03-28x86: templatize INC/DECJan Beulich3-68/+80
With the multitude of new APX templates, it finally becomes desirable to further remove redundancy by also templatizing basic arithmetic insns. Start with the simplest case, accompanied by a necessary adjustment to i386-gen (such that template uses can also be at the start of a line). While there also drop a bogus (meaningless / unreachable) "break" as well as a unused variable (which I'm surprised compilers didn't warn about).
2024-03-28[gdb/testsuite] Fix gdb.base/ending-run.exp on manjaro linuxTom de Vries1-2/+2
On aarch64-linux, using the manjaro linux distro, I run into: ... (gdb) next^M 32 }^M (gdb) next^M 0x0000fffff7d67b80 in ?? () from /usr/lib/libc.so.6^M (gdb) FAIL: gdb.base/ending-run.exp: step out of main ... What happens here is described in detail in this clause: ... -re "0x.*\\?\\? \\(\\) from /lib/powerpc.*$gdb_prompt $" { # This case occurs on Powerpc when gdb steps out of main and the # needed debug info files are not loaded on the system, preventing # GDB to determine which function it reached (__libc_start_call_main). # Ideally, the target system would have the necessary debugging # information, but in its absence, GDB's behavior is as expected. ... } ... but the clause only matches for powerpc. Fix this by: - making the regexp generic enough to also match /usr/lib/libc.so.6, and - updating the comment to not mention powerpc. Tested on aarch64-linux. PR testsuite/31450 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31450
2024-03-28[gdb/testsuite] Fix test-case gdb.threads/attach-stopped.exp on manjaro linuxTom de Vries1-2/+4
When running test-case gdb.threads/attach-stopped.exp on aarch64-linux, using the manjaro linux distro, I get: ... (gdb) thread apply all bt^M ^M Thread 2 (Thread 0xffff8d8af120 (LWP 278116) "attach-stopped"):^M #0 0x0000ffff8d964864 in clock_nanosleep () from /usr/lib/libc.so.6^M #1 0x0000ffff8d969cac in nanosleep () from /usr/lib/libc.so.6^M #2 0x0000ffff8d969b68 in sleep () from /usr/lib/libc.so.6^M #3 0x0000aaaade370828 in func (arg=0x0) at attach-stopped.c:29^M #4 0x0000ffff8d930aec in ?? () from /usr/lib/libc.so.6^M #5 0x0000ffff8d99a5dc in ?? () from /usr/lib/libc.so.6^M ^M Thread 1 (Thread 0xffff8db62020 (LWP 278111) "attach-stopped"):^M #0 0x0000ffff8d92d2d8 in ?? () from /usr/lib/libc.so.6^M #1 0x0000ffff8d9324b8 in ?? () from /usr/lib/libc.so.6^M #2 0x0000aaaade37086c in main () at attach-stopped.c:45^M (gdb) FAIL: gdb.threads/attach-stopped.exp: threaded: attach2 to stopped bt ... The problem is that the test-case expects to see start_thread: ... gdb_test "thread apply all bt" ".*sleep.*start_thread.*" \ "$threadtype: attach2 to stopped bt" ... but lack of symbols makes that impossible. Fix this by allowing " in ?? () from " as well. Tested on aarch64-linux. PR testsuite/31451 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31451
2024-03-28[gdb/testsuite] Add missing include in gdb.base/rtld-step.expTom de Vries1-1/+4
On fedora rawhide, with test-case gdb.base/rtld-step.exp I get: ... static-pie-static-libc.c: In function '_start':^M static-pie-static-libc.c:1:22: error: \ implicit declaration of function '_exit' [-Wimplicit-function-declaration]^M 1 | void _start (void) { _exit (0); }^M | ^~~~~^M compiler exited with status 1 ... UNTESTED: gdb.base/rtld-step.exp: failed to compile \ (-static-pie not supported or static libc missing) ... Fix this by adding the missing include. Tested on aarch64-linux. Approved-by: Kevin Buettner <kevinb@redhat.com>
2024-03-28RISC-V: Removed privileged spec 1.9.1 support in assembler.Nelson Chu29-3099/+218
Removed since it's may have lots of conflicts with the newer extensions, but still keep linker recognizes it in case of linking old objects. gas/ * NEWS: Updated. * config/tc-riscv.c (riscv_set_default_priv_spec): Regard 1.9.1 as an unknown version. (md_show_usage): Removed privileged spec 1.9.1 information. * testsuite/gas/riscv/attribute-05.s: Updated since privileged spec 1.9.1 is unsupported. * testsuite/gas/riscv/attribute-05.d: Likewise. * testsuite/gas/riscv/attribute-12.d: Likewise. * testsuite/gas/riscv/attribute-13.d: Likewise. * testsuite/gas/riscv/csr-dw-regnums.d: Likewise. * testsuite/gas/riscv/csr-dw-regnums.s: Likewise. * testsuite/gas/riscv/csr.s: Likewise. * testsuite/gas/riscv/csr-version-1p10.d: Likewise. * testsuite/gas/riscv/csr-version-1p10.l: Likewise. * testsuite/gas/riscv/csr-version-1p11.d: Likewise. * testsuite/gas/riscv/csr-version-1p11.l: Likewise. * testsuite/gas/riscv/csr-version-1p12.d: Likewise. * testsuite/gas/riscv/csr-version-1p12.l: Likewise. * testsuite/gas/riscv/csr-version-1p9p1.d: Removed. * testsuite/gas/riscv/csr-version-1p9p1.l: Removed. include/ * opcode/riscv-opc.h: Updated since privileged spec 1.9.1 is unsupported. ld/ * testsuite/ld-riscv-elf/attr-merge-priv-spec-01.d: Updated since privileged spec 1.9.1 is unsupported. * testsuite/ld-riscv-elf/attr-merge-priv-spec-02.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-priv-spec-03.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-priv-spec-a.s: Likewise. * testsuite/ld-riscv-elf/attr-merge-priv-spec-b.s: Likewise. * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-01.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-02.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-03.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-04.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-05.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-06.d: Likewise.
2024-03-28Automatic date update in version.inGDB Administrator1-1/+1
2024-03-27Fix clang buildTom Tromey1-1/+9
Simon pointed out that commit 818ef5f4 ("Capture warnings when writing to the index cache") broke the build with clang. This patch fixes the breakage.
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi892-902/+1
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-03-26gdb, gdbserver, gdbsupport: include early header files with `-include`Simon Marchi4-3/+16
The motivation for this change is for analysis tools and IDEs to be better at analyzing header files on their own. There are some definitions and includes we want to occur at the very beginning of all translation units. The way we currently do that is by requiring all source files (.c and .cc files) to include one of defs.h (for gdb), server.h (for gdbserver) of common-defs.h (for gdbsupport and shared source files). These special header files define and include everything that needs to be included at the very beginning. Other header files are written in a way that assume that these special "prologue" header files have already been included. My problem with that is that my editor (clangd-based) provides a very bad experience when editing header files. Since clangd doesn't know that one of defs.h/server.h/common-defs.h was included already, a lot of things are flagged as errors. For instance, CORE_ADDR is not known. It's possible to edit the files in this state, but a lot of the power of the editor is unavailable. My proposal to help with this is to include those things we always want to be there using the compilers' `-include` option. Tom Tromey said that the current approach might exist because not all compilers used to have an option like this. But I believe that it's safe to assume they do today. With this change, clangd picks up the -include option from the compile command, and is able to analyze the header file correctly, as it sees all that stuff included or defined by that -include option. That works because when editing a header file, clangd tries to get the compilation flags from a source file that includes said header file. This change is a bit self-serving, because it addresses one of my frustrations when editing header files, but it might help others too. I'd be curious to know if others encounter the same kinds of problems when editing header files. Also, even if the change is not necessary by any means, I think the solution of using -include for stuff we always want to be there is more elegant than the current solution. Even with this -include flag, many header files currently don't include what they use, but rather depend on files included before them. This will still cause errors when editing them, but it should be easily fixable by adding the appropriate include. There's no rush to do so, as long as the code still compiles, it's just a convenience thing. The changes are: - Add the appropriate `-include` option to the various Makefiles. - There is one particularity for gdbserver's Makefile: we do not want to include server.h when building `gdbreplay.o`, as `gdbreplay.cc` doesn't include it. So we can't simply put the `-include` in `INTERNAL_CFLAGS`. Add the `-include server.h` option to the `COMPILE` and `IPAGENT_COMPILE` variables, and added a special rule to compile `gdbreplay.o` with `-include gdbsupport/common-defs.h`. - Remove the `-include` option from the `check-headers` rule in gdb/Makefile.in, since it is already included in `INTERNAL_CFLAGS`. Change-Id: If3e345d00a9fc42336322f1d8286687d22134340 Approved-By: Pedro Alves <pedro@palves.net>
2024-03-26{gdb,gdbserver}/Makefile.in: remove unnecessary intermediary variablesSimon Marchi2-13/+7
Remove `INTERNAL_CFLAGS_BASE` and `INTERNAL_WARN_CFLAGS`, inline their contents in `INTERNAL_CFLAGS`. Not functional changes expected. Change-Id: I6a09794835ca2cfd4a88a3e9f2e627c8f5bd569f Approved-By: Pedro Alves <pedro@palves.net>
2024-03-26gdb, gdbserver, gdbsupport: reformat some Makefile variables, one entry per lineSimon Marchi4-29/+90
Reformat some variables definitions. I think it makes them easier to read, and it also makes diffs clearer. Change-Id: I82f63ba0e6d0fe268eb1f1ad5ab22c3cd016ab02 Approved-By: Pedro Alves <pedro@palves.net>
2024-03-26gdb: make gdbarch_types.py non-executableSimon Marchi1-0/+0
I noticed that gdbarch_types.py is executable. It's not needed, since it's only imported from gdbarch.py. Change-Id: I481170714af66fc3fc3a48c55a7268e0789cf83e
2024-03-27Automatic date update in version.inGDB Administrator1-1/+1
2024-03-26Revert "gdbserver: convert have_ptrace_getregset to a tribool"Andrew Burgess4-10/+10
This reverts commit 5920765d7513aaae9241a1850d62d73e0477f81c.
2024-03-26Revert "gdb/x86: move reading of cs and ds state into gdb/nat directory"Andrew Burgess3-80/+37
This reverts commit 01ed1674d4435aa4e194fd9373b7705e425ef354.
2024-03-26Revert "gdbserver/x86: move no-xml code earlier in x86_linux_read_description"Andrew Burgess1-16/+11
This reverts commit 0a7bb97ad2f2fe2d18a442dad265051e34eab13e.
2024-03-26Revert "gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition"Andrew Burgess5-23/+41
This reverts commit 7816b81e9b36ea0f57662bfd7446b573bf0c9e54.
2024-03-26Revert "gdb/gdbserver: share some code relating to target description creation"Andrew Burgess15-267/+199
This reverts commit cd9b374ffe372dcaf7e4c15548cf53a301d8dcdd.
2024-03-26Revert "gdb/arch: assert that X86_XSTATE_MPX is not set for x32"Andrew Burgess1-6/+2
This reverts commit efba976d9713a92b4507ccfef2257e4589da2798.
2024-03-26Revert "gdbserver: update target description creation for x86/linux"Andrew Burgess5-277/+168
This reverts commit 61bb321605fc74703adc994fd7a78e9d2495ca7a.