binutils-gdb

Commit Graph

Author	SHA1	Message	Date
Andrew Burgess	e840e61cac	opcodes/riscv: style csr names as registers While reviewing another patch I noticed that RISC-V CSR names are given the text style, not the register style. This patch fixes this mistake.	4 years ago
Luis Machado	f4b581f2d1	[AArch64] Update FPSR/FPCR fields for FPU and SVE I noticed some missing flags/fields from FPSR and FPCR registers in both the FPU and SVE target descriptions. This patch adds those and makes the SVE versions of FPSR and FPCR use the proper flags/bitfields types.	4 years ago
Alan Modra	758dd750bc	Support objcopy changing compression to or from zstd Commit `2cac01e3ff` lacked support for objcopy changing compression style. Add that support, which meant a rewrite of bfd_compress_section_contents. In the process I've fixed some memory leaks. * compress.c (bfd_is_section_compressed_info): Rename from bfd_is_section_compressed_with_header and add ch_type param to return compression header ch_type field. Update all callers. (decompress_section_contents): Remove buffer and size params. Rewrite. Update callers. (bfd_init_section_compress_status): Free contents on failure. (bfd_compress_section): Likewise. * elf.c (_bfd_elf_make_section_from_shdr): Support objcopy changing between any of the three compression schemes. Report "unable to compress/decompress" rather than "unable to initialize compress/decompress status" on compress/decompress failures. * bfd-in2.h: Regenerate.	4 years ago
Alan Modra	034235cebd	Re: compress .gnu.debuglto_.debug_* sections if requested Enable zlib-gnu compression for .gnu.debuglto_.debug_. This differs from zlib-gnu for .debug_ where the name is changed to .zdebug_. The name change isn't really needed. bfd/ elf.c (elf_fake_sections): Replace "." with ".z" in debug section names only when name was ".d", ie. ".debug_". (_bfd_elf_assign_file_positions_for_non_load): Likewise. gas/ * write.c (compress_debug): Compress .gnu.debuglto_.debug_* for zlib-gnu too. Compress .gnu.linkonce.wi.*.	4 years ago
Martin Liska	7afbac7ddd	compress .gnu.debuglto_.debug_* sections if requested Right now, when using LTO, the intermediate object files do contain debug info in sections starting with .gnu.debuglto_ prefix and are not compressed when --compress-debug-sections is used. It's a mistake and we can save quite some disk space. The following example comes from tramp3d when the corresponding LTO sections are compressed with zlib: $ bloaty tramp3d-v4-v2.o -- tramp3d-v4.o FILE SIZE VM SIZE -------------- -------------- +83% +10 [ = ] 0 [Unmapped] -68.0% -441 [ = ] 0 .gnu.debuglto_.debug_line -52.3% -759 [ = ] 0 .gnu.debuglto_.debug_line_str -62.4% -3.24Ki [ = ] 0 .gnu.debuglto_.debug_abbrev -64.8% -1.12Mi [ = ] 0 .gnu.debuglto_.debug_info -88.8% -4.58Mi [ = ] 0 .gnu.debuglto_.debug_str -27.7% -5.70Mi [ = ] 0 TOTAL bfd/ChangeLog: * elf.c (_bfd_elf_make_section_from_shdr): Compress all debug info sections. gas/ChangeLog: * write.c (compress_debug): Compress also ".gnu.debuglto_.debug_" if the compression algorithm is different from zlib-gnu.	4 years ago
Jan Beulich	bb996692bd	RISC-V/gas: allow generating up to 176-bit instructions with .insn For the time being simply utilize O_big to avoid widening other fields, bypassing append_insn() etc.	4 years ago
Jan Beulich	8c07e983a2	RISC-V/gas: don't open-code insn_length() Use the helper when it can be used.	4 years ago
Jan Beulich	3b25fc4884	RISC-V/gas: drop stray call to install_insn() add_fixed_insn(), by calling move_insn(), already invokes install_insn().	4 years ago
Jan Beulich	f5cb31a8ba	RISC-V/gas: drop riscv_subsets static variable It's fully redundant with the subset_list member of riscv_rps_as.	4 years ago
Jan Beulich	021205d021	RISC-V: don't cast expressions' X_add_number to long in diagnostics There's no need for such workarounds anymore now that we use C99 uniformly. This addresses several testsuite failures encountered when (cross-)building on a 32-bit host.	4 years ago
Potharla, Rupesh	09fbd1cf93	ignore DWARF debug information for -gsplit-dwarf with dwarf-5 Skip dwo_id for split dwarf. * dwarf2.c (parse_comp_unit): Skip DWO_id for DW_UT_skeleton.	4 years ago
GDB Administrator	cf0136a276	Automatic date update in version.in	4 years ago
Jan-Benedict Glaw	aef1974a66	Fix self-move warning check for GCC 13+ GCC 13 got the self-move warning (0abb78dda084a14b3d955757c6431fff71c263f3), but that warning is only checked for clang, resulting in: /usr/lib/gcc-snapshot/bin/g++ -x c++ -I. -I. -I./config -DLOCALEDIR="\"/tmp/gdb-m68k-linux/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/readline/.. -I./../zlib -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./../gnulib/import -I../gnulib/import -I./.. -I.. -I./../libbacktrace/ -I../libbacktrace/ -DTUI=1 -I./.. -pthread -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor -Wredundant-move -Wmissing-declarations -Wstrict-null-sentinel -Wformat -Wformat-nonliteral -Werror -g -O2 -c -o unittests/environ-selftests.o -MT unittests/environ-selftests.o -MMD -MP -MF unittests/.deps/environ-selftests.Tpo unittests/environ-selftests.c unittests/environ-selftests.c: In function 'void selftests::gdb_environ_tests::test_self_move()': unittests/environ-selftests.c:228:7: error: moving 'env' of type 'gdb_environ' to itself [-Werror=self-move] 228 \| env = std::move (env); \| ~~~~^~~~~~~~~~~~~~~~~ unittests/environ-selftests.c:228:7: note: remove 'std::move' call cc1plus: all warnings being treated as errors make[1]: * [Makefile:1896: unittests/environ-selftests.o] Error 1 make[1]: Leaving directory '/var/lib/laminar/run/gdb-m68k-linux/3/binutils-gdb/gdb' make: * [Makefile:13193: all-gdb] Error 2	4 years ago
Simon Marchi	d1d3123c7b	gdb: constify inferior::target_is_pushed Change-Id: Ia4143b9c63cb76e2c824ba773c66f5c5cd94b2aa	4 years ago
Luis Machado	e63ae49b6a	[AArch64] Handle W registers as pseudo-registers instead of aliases of X registers The aarch64 port handles W registers as aliases of X registers. This is incorrect because X registers are 64-bit and W registers are 32-bit. This patch teaches GDB how to handle W registers as pseudo-registers of 32-bit, the bottom half of the X registers. Testcase included.	4 years ago
Luis Machado	1ba3a32220	[AArch64] Fix pseudo-register numbering in the presence of unexpected additional registers When using AArch64 GDB with the QEMU debugging stub (in user mode), we get additional system registers that GDB doesn't particularly care about, so it doesn't number those explicitly. But given the pseudo-register numbers are above the number of real registers, we need to setup/account for the real registers first before going ahead and numbering the pseudo-registers. This has to happen at the end of aarch64_gdbarch_init, after the call to tdesc_use_registers, as that updates the total number of real registers. This is in preparation to supporting pointer authentication for bare metal aarch64 (QEMU).	4 years ago
Nick Clifton	907b52f4ce	readelf: DO not load section headers from file offset zero * readelf.c (get_32bit_section_headers): Return false if the e_shoff field is zero. (get_64bit_section_headers): Likewise.	4 years ago
Tsukasa OI	0129298796	RISC-V: Move supervisor instructions after all unprivileged ones This location of supervisor instructions is out of place (because many other privileged instructions are located at the tail but after the supervisor instructions, we have many unprivileged instructions including bit manipulation / crypto / vector instructions). Not only that, this is harmful to implement pseudoinstructions in the latest 'P'-extension proposal (CLROV and RDOV). This commit moves supervisor instructions after all unprivileged instructions. opcodes/ChangeLog: * riscv-opc.c (riscv_opcodes): Adjust indents. Move supervisor instructions after all unprivileged instructions.	4 years ago
Bruno Larsen	2820f08f23	Improve GDB's baseclass detection with typedefs When a class inherits from a typedef'd baseclass, GDB may be unable to find the baseclass if the user is not using the typedef'd name, as is tested on gdb.cp/virtbase2.exp; the reason that test case is working under gcc is that the dwarf generated by gcc links the class to the original definition of the baseclass, not to the typedef. If the inheritance is linked to the typedef, such as how clang does it, gdb.cp/virtbase2.exp starts failing. This can also be seen in gdb.cp/impl-this.exp, when attempting to print D::Bint::i, and GDB not being able to find the baseclass Bint. This happens because searching for baseclasses only uses the macro TYPE_BASECLASS_NAME, which returns the typedef'd name. However, we can't switch that macro to checking for typedefs, otherwise we wouldn't be able to find the typedef'd name anymore. This is fixed by searching for members or baseclasses by name, we check both the saved name and the name after checking for typedefs. This also fixes said long-standing bug in gdb.cp/impl-this.exp when the compiler adds information about typedefs in the debuginfo.	4 years ago
Tsukasa OI	7b4f240762	RISC-V: Assign DWARF numbers to vector registers This commit assigns DWARF register numbers to vector registers (v0-v31: 96..127) to implement RISC-V DWARF Specification version 1.0-rc4 (now in the frozen state): https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0-rc4 binutils/ChangeLog: * dwarf.c (dwarf_regnames_riscv): Assign DWARF register numbers 96..127 to vector registers v0-v31. gas/ChangeLog: * config/tc-riscv.c (tc_riscv_regname_to_dw2regnum): Support vector registers. * testsuite/gas/riscv/dw-regnums.s: Add vector registers to the DWARF register number test. * testsuite/gas/riscv/dw-regnums.d: Likewise.	4 years ago
Tsukasa OI	61233edc75	RISC-V: Add testcase for DWARF register numbers Although it had csr-dw-regnums.d (for CSRs), it didn't have DWARF register number test for GPRs/FPRs. This commit adds dw-regnums.{s,d} to test such registers. gas/ChangeLog: * testsuite/gas/riscv/dw-regnums.s: New DWARF register number test for GPRs/FPRs. * testsuite/gas/riscv/dw-regnums.d: Likewise.	4 years ago
GDB Administrator	e1fc9bcfac	Automatic date update in version.in	4 years ago
Tom de Vries	4cfa9edb35	[gdb/testsuite] Fix waitpid testing in next-fork-other-thread.c In next-fork-other-thread.c, there's this loop: ... do { ret = waitpid (pid, &stat, 0); } while (ret == EINTR); ... The loop condition tests for "ret == EINTR" but waitpid signals EINTR by returning -1 and setting errno to EINTR. Fix this by changing the loop condition to "ret == -1 && errno == EINTR". Tested on x86_64-linux.	4 years ago
Andrew Burgess	c3d64d467d	gdb/testsuite: handle invalid .exp names passed in TESTS I ran some tests like: $ make check-gdb TESTS="gdb.base/break.exp" then, then I went to rerun the tests later, I managed to corrupt the command line, like this: $ make check-gdb TESTS="gdb.base/breakff.exp" the make command did exit with an error, but DejaGnu appeared to report that every test passed! The tail end of the output looks like this: Illegal Argument "no-matching-tests-found" try "runtest --help" for option list === gdb Summary === # of expected passes 115 /tmp/build/gdb/gdb version 13.0.50.20220831-git -nw -nx -iex "set height 0" -iex "set width 0" -data-directory /tmp/build/gdb/testsuite/../data-directory make[3]: * [Makefile:212: check-single] Error 1 make[3]: Leaving directory '/tmp/build/gdb/testsuite' make[2]: * [Makefile:161: check] Error 2 make[2]: Leaving directory '/tmp/build/gdb/testsuite' make[1]: * [Makefile:1916: check] Error 2 make[1]: Leaving directory '/tmp/build/gdb' make: * [Makefile:13565: check-gdb] Error 2 For a while, I didn't spot that DejaGnu had failed at all, I saw the 115 passes, and thought everything had run correctly - though I was puzzled that make was reporting an error. What happens is that in gdb/testsuite/Makefile, in the check-single rule, we first run DejaGnu, then run the dg-add-core-file-count.sh script, and finally, we use sed to extract the results from the gdb.sum file. In my case, with the invalid test name, DejaGnu fails, but the following steps are still run, the final result, the 115 passes, is then extracted from the pre-existing gdb.sum file. If I use 'make -jN' then the 'check-parallel' rule, rather than the 'check-single' rule is used. In this case the behaviour is slightly different, the tail end of the output now looks like this: No matching tests found. make[4]: Leaving directory '/tmp/build/gdb/testsuite' find: ‘outputs’: No such file or directory Usage: ../../../src/gdb/testsuite/../../contrib/dg-extract-results.py [-t tool] [-l variant-list] [-L] log-or-sum-file ... tool The tool (e.g. g++, libffi) for which to create a new test summary file. If not specified then output is created for all tools. variant-list One or more test variant names. If the list is not specified then one is constructed from all variants in the files for <tool>. sum-file A test summary file with the format of those created by runtest from DejaGnu. If -L is used, merge .log files instead of .sum. In this mode the exact order of lines may not be preserved, just different Running .exp chunks should be in correct order. find: ‘outputs’: No such file or directory Usage: ../../../src/gdb/testsuite/../../contrib/dg-extract-results.py [-t tool] [-l variant-list] [-L] log-or-sum-file ... tool The tool (e.g. g++, libffi) for which to create a new test summary file. If not specified then output is created for all tools. variant-list One or more test variant names. If the list is not specified then one is constructed from all variants in the files for <tool>. sum-file A test summary file with the format of those created by runtest from DejaGnu. If -L is used, merge .log files instead of .sum. In this mode the exact order of lines may not be preserved, just different Running .exp chunks should be in correct order. make[3]: Leaving directory '/tmp/build/gdb/testsuite' make[2]: Leaving directory '/tmp/build/gdb/testsuite' make[1]: Leaving directory '/tmp/build/gdb' Rather than DejaGnu failing, we now get a nice 'No matching tests found' message, followed by some other noise. This other noise is first `find` failing, followed by the dg-extract-results.py script failing. What happens here is that, in the check-parallel rule, the outputs directory is deleted before DejaGnu is invoked. Then we try to run all the tests, and finally we use find and dg-extract-results.py to combine all the separate .sun and .log files together. However, if there are no tests run then the outputs/ directory is never created, so the find command and consequently the dg-extract-results.py script, fail. This commit aims to fix the following issues: (1) For check-single and check-parallel rules, don't run any of the post-processing steps if DejaGnu failed to run. This will avoid all the noise after the initial failure of DejaGnu, (2) For check-single ensure that we don't accidentally report previous results, this is related to the above, but is worth calling out as a separate point, and (3) For check-single, print the 'No matching tests found' message just like we do for a parallel test run. This makes the parallel and non-parallel testing behaviour more similar, and I think is clearer than the current 'Illegal Argument' error message. Points (1) and (2) will be handled by moving the post processing steps inside an if block within the recipe. For check-single I propose deleting the gdb.sum and gdb.log files before running DejaGnu, this is similar (I think) to how we delete the outputs/ directory in the check-parallel rule. For point (3) I plan to split the check-single rule in two, the existing check-single will be renamed do-check-single, then a new check-single rule will be added. The new check-single rule can either depend on the new do-check-single, or will ensure the 'No matching tests found' message is printed when appropriate.	4 years ago
Andrew Burgess	6deb7a8185	gdb/disasm: better intel flavour disassembly styling with Pygments This commit was inspired by this stackoverflow post: https://stackoverflow.com/questions/73491793/why-is-there-a-%C2%B1-in-lea-rax-rip-%C2%B1-0xeb3 One of the comments helpfully links to this Python test case: from pygments import formatters, lexers, highlight def colorize_disasm(content, gdbarch): try: lexer = lexers.get_lexer_by_name("asm") formatter = formatters.TerminalFormatter() return highlight(content, lexer, formatter).rstrip().encode() except: return None print(colorize_disasm("lea [rip+0x211] # COMMENT", None).decode()) Run the test case and you should see that the '+' character is underlined, and could be confused with a combined +/- symbol. What's happening is that Pygments is failing to parse the input text, and the '+' is actually being marked in the error style. The error style is red and underlined. It is worth noting that the assembly instruction being disassembled here is an x86-64 instruction in the 'intel' disassembly style, rather than the default att style. Clearly the Pygments module expects the att syntax by default. If we change the test case to this: from pygments import formatters, lexers, highlight def colorize_disasm(content, gdbarch): try: lexer = lexers.get_lexer_by_name("asm") lexer.add_filter('raiseonerror') formatter = formatters.TerminalFormatter() return highlight(content, lexer, formatter).rstrip().encode() except: return None res = colorize_disasm("lea rax,[rip+0xeb3] # COMMENT", None) if res: print(res.decode()) else: print("No result!") Here I've added the call: lexer.add_filter('raiseonerror'), and I am now checking to see if the result is None or not. Running this and the test now print 'No result!' - instead of styling the '+' in the error style, we instead give up on the styling attempt. There are two things we need to fix relating to this disassembly text. First, Pygments is expecting att style disassembly, not the intel style that this example uses. Fortunately, Pygments also supports the intel style, all we need to do is use the 'nasm' lexer instead of the 'asm' lexer. However, this leads to the second problem; in our disassembler line we have '# COMMENT'. The "official" Intel disassembler style uses ';' for its comment character, however, gas and libopcodes use '#' as the comment character, as gas uses ';' for an instruction separator. Unfortunately, Pygments expects ';' as the comment character, and treats '#' as an error, which means, with the addition of the 'raiseonerror' filter, that any line containing a '#' comment, will not get styled correctly. However, as the i386 disassembler never produces a '#' character other than for comments, we can easily "fix" Pygments parsing of the disassembly line. This is done by creating a filter. This filter looks for an Error token with the value '#', we then change this into a comment token. Every token after this (until the end of the line) is also converted into a comment. In this commit I do the following: 1. Check the 'disassembly-flavor' setting and select between the 'asm' and 'nasm' lexers based on the setting. If the setting is not available then the 'asm' lexer is used by default, 2. Use "add_filter('raiseonerror')" to ensure that the formatted output will not include any error text, which would be underlined, and might be confusing, 3. If the 'nasm' lexer is selected, then add an additional filter that will format '#' and all other text on the line, as a comment, and 4. If Pygments throws an exception, instead of returning None, return the original, unmodified content. This will mean that this one instruction is printed without styling, but GDB will continue to call into the Python code to style later instructions. I haven't included a test specifically for the above error case, though I have manually check that the above case now styles correctly (with no underline). The existing style tests check that the disassembler styling still works though, so I know I've not generally broken things. One final thought I have after looking at this issue is that I wonder now if using Pygments for styling disassembly from every architecture is actually a good idea? Clearly, the 'asm' lexer is OK with att style x86-64, but not OK with intel style x86-64, so who knows how well it will handle other random architectures? When I first added this feature I tested it against some random RISC-V, ARM, and X86-64 (att style) code, and it seemed fine, but I never tried to make an exhaustive check of all instructions, so its quite possible that there are corner cases where things are styled incorrectly. With the above changes I think that things should be a bit better now. If a particular instruction doesn't parse correctly then our Pygments based styling code will just not style that one instruction. This is combined with the fact that many architectures are now moving to libopcodes based styling, which is much more reliable. So, I think it is fine to keep using Pygments as a fallback mechanism for styling all architectures, even if we know it might not be perfect in all cases.	4 years ago
Andrew Burgess	f22c50c22c	gdb: improve disassembler styling when Pygments raises an exception While working on another issue relating to GDB's use of the Python Pygments package for disassembly styling I noticed an issue in the case where the Pygments package raises an exception. The intention of the current code is that, should the Pygments package raise an exception, GDB will disable future attempts to call into the Pygments code. This was intended to prevent repeated errors during disassembly if, for some reason, the Pygments code isn't working. Since the Pygments based styling was added, GDB now supports disassembly styling using libopcodes, but this is only available for some architectures. For architectures not covered by libopcodes Pygments is still the only option. What I observed is that, if I disable the libopcodes styling, then setup GDB so that the Pygments based styling code will indicate an error (by returning None), GDB does, as expected, stop using the Pygments based styling. However, the libopcodes based styling will instead be used, despite this feature having been disabled. The problem is that the disassembler output is produced into a string_file buffer. When we are using Pygments, this buffer is created without styling support. However, when Pygments fails, we recreate the buffer with styling support. The problem is that we should only recreate the buffer with styling support only if libopcodes styling is enabled. This was an oversight in commit: commit `4cbe4ca5da` Date: Mon Feb 14 14:40:52 2022 +0000 gdb: add support for disassembler styling using libopcodes This commit: 1. Factors out some of the condition checking logic into two new helper functions use_ext_lang_for_styling and use_libopcodes_for_styling, 2. Reorders gdb_disassembler::m_buffer and gdb_disassembler::m_dest, this allows these fields to be initialised m_dest first, which means that the new condition checking functions can rely on m_dest being set, even when called from the gdb_disassembler constructor, 3. Make use of the new condition checking functions each time m_buffer is initialised, 4. Add a new test that forces the Python disassembler styling function to return None, this will cause GDB to disable use of Pygments for styling, and 5. When we reinitialise m_buffer, and re-disassemble the instruction, call reset the in-comment flag. If the instruction being disassembler ends in a comment then the first disassembly pass will have set the in-comment flag to true. This shouldn't be a problem as we will only be using Pygments, and thus performing a re-disassembly pass, if libopcodes is disabled, so the in-comment flag will never be checked, even if it is set incorrectly. However, I think that having the flag set correctly is a good thing, even if we don't check it (you never know what future uses might come up).	4 years ago
Andrew Burgess	5b0e2b48ed	gdb/testsuite: extend styling test for libopcodes styling This commit extends the gdb.base/style.exp test to cover disassembler styling using libopcodes (where available). The test will try to enable libopcode based styling, if this works (because such styling is available) then some tests are run to check that the output is styled, and that the styling can be disabled using 'set style disassembler enabled off'. If libopcodes styling is not available on the current architecture then these new tests will be skipped. I've moved the Python Pygments module check inside the test_disable_disassembler_styling function now, so that the test will be run even when Python Pygments is not available, this allows the new tests discussed above. If the Pygments module is not available then the Pygments based tests will be skipped just as they were before.	4 years ago
Andrew Burgess	637b2f8613	gdb: update now gdbarch_register_name doesn't return nullptr After the previous few commit, gdbarch_register_name no longer returns nullptr. This commit audits all the calls to gdbarch_register_name and removes any code that checks the result against nullptr. There should be no visible change after this commit.	4 years ago
Andrew Burgess	9b9e61c7cf	gdb: final cleanup of various gdbarch_register_name methods Building on the previous commits, this commit goes through the various gdbarch_register_name methods and removes all the remaining 'return NULL' cases, I claim that these either couldn't be hit, or should be returning the empty string. In all cases the return of NULL was used if the register number being passed to gdbarch_register_name was "invalid", i.e. negative, or greater than the total number of declared registers. I don't believe either of these cases can occur, and the previous commit asserts that this is the case. As a result we can simplify the code by removing these checks. In many cases, where the register names are held in an array, I was able to add a static assert that the array contains the correct number of strings, after that, a direct access into the array is fine. I don't have any means of testing these changes.	4 years ago
Andrew Burgess	7ac20d65a8	gdb/csky: remove nullptr return from csky_pseudo_register_name Building on the previous commits, in this commit I remove two instances of 'return NULL' from csky_pseudo_register_name, and replace them with a return of the empty string. These two are particularly interesting, and worth pulling into their own commit, because these returns of NULL appear to be depended on within other parts of the csky code. In csky-linux-tdep.c in the register collect/supply code, GDB checks for the register name being nullptr in order to decide if a target supports a particular feature or not. I've updated the code to check for the empty string. I have no way of testing this change.	4 years ago
Andrew Burgess	7df4240040	gdb: add asserts to gdbarch_register_name This commit adds asserts to gdbarch_register_name that validate the parameters, and the return value. The interesting thing here is that gdbarch_register_name is generated by gdbarch.py, and so, to add these asserts, I need to update the generation script. I've added two new arguments for Functions and Methods (as declared in gdbarch-components.py), these arguments are 'param_checks' and 'result_checks'. Each of these new arguments can be used to list some expressions that are then used within gdb_assert calls in the generated code. The asserts that validate the API as described in the comment I added to gdbarch_register_name a few commits back; the register number passed in needs to be a valid cooked register number, and the result being returned should not be nullptr.	4 years ago
Andrew Burgess	9a103324fe	gdb: check for duplicate register names in selftest Building on the previous commit, this commit extends the register_name selftest to check for duplicate register names. If two registers in the cooked register set (real + pseudo registers) have the same name, then this will show up as duplicate registers in the 'info all-registers' output, but the user will only be able to interact with one copy of the register. In this commit I extend the selftest that I added in the previous commit to check for duplicate register names, I didn't include this functionality in the previous commit because one architecture needed fixing, and I wanted to keep those fixes separate from the fixes in the previous commit. The problematic architecture(s) are powerpc:750 and powerpc:604. In both of these cases the 'dabr' register appears twice, there's a definition of dabr in power-oea.xml which is included into both powerpc-604.xml and powerpc-750.xml. Both of these later two xml files also define the dabr register. I'm hopeful that this change shouldn't break anything, but I don't have the ability to actually test this change, however: On the gdbserver side, neither powerpc-604.xml nor powerpc-750.xml are mentioned in gdbserver/configure.srv, which I think means that gdbserver will never use these descriptions, and, Within GDB the problematic descriptions are held in the variables tdesc_powerpc_604 and tdesc_powerpc_750, which are only mentioned in the variants array in rs6000-tdep.c, this is used when looking up a description based on the architecture. For a native Linux target however, this will not be used as ppc_linux_nat_target::read_description exists, which calls ppc_linux_match_description, which I don't believe can return either of the problematic descriptions. This leaves the other native targets, FreeBSD, AIX, etc. These don't appear to override the ::read_description method, so will potentially return the problematic descriptions, but, in each case I think the ::fetch_registers and ::store_registers methods will ignore the dabr register, which will leave the register as <unavailable>. So, my proposed solution is to just remove the duplicate register from each of powerpc-604.xml and powerpc-750.xml, then regenerate the corresponding C++ source file. With this change made, the selftest now passes for all architectures.	4 years ago
Andrew Burgess	9a972b5404	gdb: add a gdbarch_register_name self test, and fix some architectures This commit adds a self-test that checks that gdbarch_register_name never returns nullptr for any valid register number. Most architectures already met this requirement, there were just 6 that failed the new selftest, and are updated in this commit. Beyond the self-tests I don't have any facilities to test that the architectures I've adjusted still work correctly. If you review all the various gdbarch_register_name implementations then you will see that there are far more architectures that seem like they might return nullptr in some situations, e.g. alpha, avr, bpf, etc. This commit doesn't attempt to address these cases as non of them are hit during the selftest. Many of these cases can never be hit, for example, in alpha_register_name GDB checks for a register number less than zero, this case can't happen and could be changed into an assert. A later commit in this series will have a general cleanup of all the various register_name methods, and remove all references to NULL from their code, however, as that commit will be mostly adjusting code that is never hit, I want to keep those changes separate. The selftest has been tested on x86-64, but I don't have access to suitable systems to fully test any of the *-tdep.c code I've changed in this commit.	4 years ago
Andrew Burgess	89e601ac3a	gdb/gdbarch: add a comment to gdbarch_register_name After the previous commit, this commit sets out to formalise the API for gdbarch_register_name. Not every architecture is actually in compliance with the API I set out here, but I believe that most are. I think architectures that don't comply with the API laid out here will fail the gdb.base/completion.exp test. The claims in the comment are I feel, best demonstrated with the asserts in this code: const char * gdbarch_register_name (struct gdbarch gdbarch, int regnr) { gdb_assert (regnr >= 0); gdb_assert (regnr < gdbarch_num_cooked_regs (gdbarch)); const char name = gdbarch->register_name (gdbarch, regnr); gdb_assert (name != nullptr); return name; } Like I said, I don't believe every architecture follows these rules right now, which is why I'm not actually adding any asserts. Instead, this commit adds a comment to gdbarch_register_name, this comment is where I'd like to get to, rather than where we are right now. Subsequent commits will fix all targets to be in compliance with this comment, and will even add the asserts shown above to gdbarch_register_name.	4 years ago
Andrew Burgess	bd93abe8d5	gdb/riscv: fix failure in gdb.base/completion.exp I noticed a test failure in gdb.base/completion.exp for RISC-V on a native Linux target, this is the failure: (gdb) FAIL: gdb.base/completion.exp: complete 'info registers ' The problem is caused by a mismatch in the output of 'maint print registers' and the completion list for 'info registers'. The 'info registers' completion list contains less registers than expected. Additionally, the list of registers extracted from the 'maint print registers' list was wrong too, in some cases the test was grabbing the register number, rather than a register name, Both of these problems have the same root cause, riscv_register_name returns nullptr for some registers when it should return an empty string. The gdbarch_register_name API is not clearly documented anywhere, and at first glance it would appear that the function can return either nullptr, or an empty string to indicate that a register is not available on the current target. Indeed, there are plenty of places in GDB where we compare the output of gdbarch_register_name to both nullptr and '\0' in order to see if a register is supported or not, and there are plenty of targets that return empty string in some cases, and nullptr in others. However, the 'info registers' completion code (reg_or_group_completer) clearly depends on user_reg_map_regnum_to_name only returning nullptr when the passed in regnum is greater than the maximum possible register number (i.e. after all physical registers, pseudo-registers, and user-registers), this means that gdbarch_register_name should not be returning nullptr. I did consider "fixing" user_reg_map_regnum_to_name, if gdbarch_register_name returns nullptr, I could convert to an empty string at this point, but that felt like a real hack, so I discarded that plan. The next possibility I considered was "fixing" reg_or_group_completer to not rely on nullptr to indicate the end marker. Or rather, I could have reg_or_group_completer use gdbarch_num_cooked_regs, we know that we should check at least that many register numbers. Then, once we're passed that limit, we keep checking until we hit a nullptr. This would absolutely work, and didn't actually feel that bad, but, it still felt a little weird that gdbarch_register_name could return nullptr OR the empty string to mean the same thing, so I wondered if the "right" solution was to have gdbarch_register_name not return nullptr. With this in mind I tried an experiment: I added a self-test that, for each architecture, calls gdbarch_register_name for every register number up to the gdbarch_num_cooked_regs limit, and checks that the name is not nullptr. Only a handful of architectures failed this test, RISC-V being one of them. This seems to suggest that most architectures agree that the correct API for gdbarch_register_name is to return an empty string for registers that are not supported on the current target, and that returning nullptr is really a mistake. In this commit I will update the RISC-V target so that GDB no longer returns nullptr from riscv_register_name, instead we return the empty string. In subsequent commits I will add the selftest that I mention above, and will fix the targets that fail the selftest. With this change the gdb.base/completion.exp test now passes.	4 years ago
Andrew Burgess	e7b1ba07bc	gdb/testsuite: rewrite capture_command_output proc I noticed a test failure in gdb.base/completion.exp for RISC-V on a native Linux target. Upon investigation I discovered a couple of reasons for the failure, this commit addresses one of them. A later commit will address the other issue. The completion.exp test makes use of the capture_command_output proc to collect the output of the 'maint print registers' command. For RISC-V this command produces a lot of output. Currently the capture_command_output proc tries to collect the complete command output in a single expect buffer, and what I see is an error caused by the expect buffer becoming full. This commit rewrites capture_command_output to make use of gdb_test_multiple to collect the command output line at a time, in this way we avoid overflowing the expect buffer. The capture_command_output proc has some logic for skipping a prefix pattern, which is passed in to the proc as an argument. In order to handle this correctly (only matching the prefix at the start of the command output), I use two gdb_test_multiple calls, the first spots and discards the echoed command and the (optional) prefix pattern, the second gdb_test_multiple call then collects the rest of the command output line at a time until a prompt is seen. There is one slight oddity with the current implementation, which I have changed in my rewrite, this does, slightly, change the behaviour of the proc. The current implementation uses this pattern: -re "[string_to_regexp ${command}]\[\r\n\]+${prefix}(.)\[\r\n\]+$gdb_prompt $" Now a typical command output will look like this: output here\r\n (gdb) As the TCL regexp matching is greedy, TCL will try to match as much as possible in one part of the pattern before moving on to the next. Thus, when this matches against (.)[\r\n]+, the (.*) will end up matching against 'output here\r' and the [\r\n]+ will match '\n' only. In short the previous implementation would leave the '\r' on the end of the returned text, but not the final trailing '\n'. Now clearly I could make a new version of capture_command_output that maintained this behaviour, but I couldn't see any reason to do this. So, my new implementation drops the final '\r\n' completely, in our example above we now return 'output here' with no '\r'. This change doesn't seem to affect any of the existing tests, but I thought it was worth mentioning.	4 years ago
Andrew Burgess	08f406e9a1	gdb/mi: new options for -data-disassemble command Now that the disassembler has two different strategies for laying out the opcode bytes of an instruction (see /r vs /b for the disassemble command), I wanted to add support for this to the MI disassemble command. Currently the -data-disassemble command takes a single 'mode' value, which currently has 6 different values (0 -> 5), 3 of these modes relate to opcode display. So, clearly I should just add an additional 3 modes to handle the new opcode format, right? No, I didn't think that was a great idea either. So, I wonder, could I adjust the -data-disassemble command in a backward compatible way, that would allow GDB to move away from using the mode value altogether? I think we can. In this commit, I propose adding two new options to -data-disassemble, these are: --opcodes none\|bytes\|display --source Additionally, I will make the mode optional, and default to mode 0 if no mode value is given. Mode 0 is the simplest, no source code, no opcodes disassembly mode. The two new options are only valid for mode 0, if they are used with any other mode then an error is thrown. The --opcodes option can add opcodes to the result, with 'bytes' being equivalent to 'disassemble /b' and 'display' being 'disassemble /r'. The --source option will enable the /s style source code display, this is equivalent to modes 4 and 5. There is no way, using the new command options to get the now deprecated /m style source code display, that is mode 1 and 3. My hope is that new users of the MI will not use the mode at all, and instead will just use the new options to achieve the output they need. Existing MI users can continue to use the mode, and will not need to be updated to use the new options.	4 years ago
Andrew Burgess	924272f2bf	gdb/mi: some int to bool conversion Just some simple int to bool conversion in mi_cmd_disassemble. There should be no user visible changes after this commit.	4 years ago
Andrew Burgess	48883ade64	gdb/doc: update syntax of -data-disassemble command arguments The argument documentation for -data-disassemble looks like this: -data-disassemble [ -s @var{start-addr} -e @var{end-addr} ] \| [ -a @var{addr} ] \| [ -f @var{filename} -l @var{linenum} [ -n @var{lines} ] ] -- @var{mode} However, I believe, according to the 'Notation and Terminology' section, this means that the there are 3 optional location specification argument groups for the command, followed by a non-optional '-- mode'. However, this is not true, one of the location specifications must be given, i.e. we can't choose to give NO location specification, which is what the above implies. I propose that we change this to instead be: -data-disassemble ( -s @var{start-addr} -e @var{end-addr} \| -a @var{addr} \| -f @var{filename} -l @var{linenum} [ -n @var{lines} ] ) -- @var{mode} By placing all the location specifications within '( ... )' we indication that these are a group, from which one of the options, separated by '\|', must be selected. However, the 'Notation and Terminology' section only describes two uses for parenthesis: '( GROUP )*' and '( GROUP )+', in the first case GROUP is repeated zero or more times, and in the second GROUP is repeated 1 or more times. Neither of those exactly describe what I want, which is GROUP must appear exactly once. I propose to extend 'Notation and Terminology' to include '( GROUP )' which means that GROUP should appear exactly once. This change is important because, in a later commit, I want to add additional optional arguments to the -data-disassemble command, and things start to get confusing with the original syntax.	4 years ago
Andrew Burgess	2bfed4e872	gdb: make gdb_disassembly_flag unsigned In a later commit I want to use operator~ on a gdb_disassembly_flag flag value. This is currently not possible as gdb_disassembly_flag is, by default, signed. This commit just makes this enum unsigned. There should be no user visible changes after this commit.	4 years ago
Andrew Burgess	d4ce49b7ac	gdb: disassembler opcode display formatting This commit changes the format of 'disassemble /r' to match GNU objdump. Specifically, GDB will now display the instruction bytes in as 'objdump --wide --disassemble' does. Here is an example for RISC-V before this patch: (gdb) disassemble /r 0x0001018e,0x0001019e Dump of assembler code from 0x1018e to 0x1019e: 0x0001018e <call_me+66>: 03 26 84 fe lw a2,-24(s0) 0x00010192 <call_me+70>: 83 25 c4 fe lw a1,-20(s0) 0x00010196 <call_me+74>: 61 65 lui a0,0x18 0x00010198 <call_me+76>: 13 05 85 6a addi a0,a0,1704 0x0001019c <call_me+80>: f1 22 jal 0x10368 <printf> End of assembler dump. And here's an example after this patch: (gdb) disassemble /r 0x0001018e,0x0001019e Dump of assembler code from 0x1018e to 0x1019e: 0x0001018e <call_me+66>: fe842603 lw a2,-24(s0) 0x00010192 <call_me+70>: fec42583 lw a1,-20(s0) 0x00010196 <call_me+74>: 6561 lui a0,0x18 0x00010198 <call_me+76>: 6a850513 addi a0,a0,1704 0x0001019c <call_me+80>: 22f1 jal 0x10368 <printf> End of assembler dump. There are two differences here. First, the instruction bytes after the patch are grouped based on the size of the instruction, and are byte-swapped to little-endian order. Second, after the patch, GDB now uses the bytes-per-line hint from libopcodes to add whitespace padding after the opcode bytes, this means that in most cases the instructions are nicely aligned. It is still possible for a very long instruction to intrude into the disassembled text space. The next example is x86-64, before the patch: (gdb) disassemble /r main Dump of assembler code for function main: 0x0000000000401106 <+0>: 55 push %rbp 0x0000000000401107 <+1>: 48 89 e5 mov %rsp,%rbp 0x000000000040110a <+4>: c7 87 d8 00 00 00 01 00 00 00 movl $0x1,0xd8(%rdi) 0x0000000000401114 <+14>: b8 00 00 00 00 mov $0x0,%eax 0x0000000000401119 <+19>: 5d pop %rbp 0x000000000040111a <+20>: c3 ret End of assembler dump. And after the patch: (gdb) disassemble /r main Dump of assembler code for function main: 0x0000000000401106 <+0>: 55 push %rbp 0x0000000000401107 <+1>: 48 89 e5 mov %rsp,%rbp 0x000000000040110a <+4>: c7 87 d8 00 00 00 01 00 00 00 movl $0x1,0xd8(%rdi) 0x0000000000401114 <+14>: b8 00 00 00 00 mov $0x0,%eax 0x0000000000401119 <+19>: 5d pop %rbp 0x000000000040111a <+20>: c3 ret End of assembler dump. Most instructions are aligned, except for the very long instruction. Notice too that for x86-64 libopcodes doesn't request that GDB group the instruction bytes. This matches the behaviour of objdump. In case the user really wants the old behaviour, I have added a new modifier 'disassemble /b', this displays the instruction byte at a time. For x86-64, which never groups instruction bytes, /b and /r are equivalent, but for RISC-V, using /b gets the old layout back (except that the whitespace for alignment is still present). Consider our original RISC-V example, this time using /b: (gdb) disassemble /b 0x0001018e,0x0001019e Dump of assembler code from 0x1018e to 0x1019e: 0x0001018e <call_me+66>: 03 26 84 fe lw a2,-24(s0) 0x00010192 <call_me+70>: 83 25 c4 fe lw a1,-20(s0) 0x00010196 <call_me+74>: 61 65 lui a0,0x18 0x00010198 <call_me+76>: 13 05 85 6a addi a0,a0,1704 0x0001019c <call_me+80>: f1 22 jal 0x10368 <printf> End of assembler dump. Obviously, this patch is a potentially significant change to the behaviour or /r. I could have added /b with the new behaviour and left /r alone. However, personally, I feel the new behaviour is significantly better than the old, hence, I made /r be what I consider the "better" behaviour. The reason I prefer the new behaviour is that, when I use /r, I almost always want to manually decode the instruction for some reason, and having the bytes displayed in "instruction order" rather than memory order, just makes this easier. The 'record instruction-history' command also takes a /r modifier, and has been modified in the same way as disassemble; /r gets the new behaviour, and /b has been added to retain the old behaviour. Finally, the MI command -data-disassemble, is unchanged in behaviour, this command now requests the raw bytes of the instruction, which is equivalent to the /b modifier. This means that the MI output will remain backward compatible.	4 years ago
Andrew Burgess	d309a8f9b3	gdb/disasm: read opcodes bytes with a single read_code call This commit reduces the number of times we call read_code when printing the instruction opcode bytes during disassembly. I've added a new gdb::byte_vector within the gdb_pretty_print_disassembler class, in line with all the other buffers that gdb_pretty_print_disassembler needs. This byte_vector is then resized as needed, and filled with a single read_code call for each instruction. There should be no user visible changes after this commit.	4 years ago
Andrew Burgess	21a52f7d82	gdb/testsuite: new test for -data-disassemble opcodes format Add another test for the output of MI command -data-disassemble. The new check validates the format of the 'opcodes' field, specifically, this test checks that the field contains a series of bytes, separated by a single space. We also check that the bytes are in the correct order, that is, the first byte is from the lowest address, and subsequent bytes are from increasing addresses. The motivation for this test (besides more tests being generally good) is that I plan to make changes to how opcode bytes are displayed in the disassembler output, and I want to ensure that I don't break any existing MI behaviour. There should be no user visible changes to GDB after this commit.	4 years ago
GDB Administrator	f7052ade77	Automatic date update in version.in	4 years ago
GDB Administrator	06bed95d8d	Automatic date update in version.in	4 years ago
Tsukasa OI	cfc0ffd31e	RISC-V: Relax "fmv.[sdq]" requirements This commit relaxes requirements to "fmv.s" instructions from 'F' to ('F' or 'Zfinx'). The same applies to "fmv.d" and "fmv.q". Note that 'Zhinx' extension already contains "fmv.h" instruction (as well as 'Zfh'). gas/ChangeLog: * testsuite/gas/riscv/zfinx.s: Add "fmv.s" instruction. * testsuite/gas/riscv/zfinx.d: Likewise. * testsuite/gas/riscv/zdinx.s: Add "fmv.d" instruction. * testsuite/gas/riscv/zdinx.d: Likewise. * testsuite/gas/riscv/zqinx.d: Add "fmv.q" instruction. * testsuite/gas/riscv/zqinx.s: Likewise. opcodes/ChangeLog: * riscv-opc.c (riscv_opcodes): Relax requirements to "fmv.[sdq]" instructions to support those in 'Zfinx'/'Zdinx'/'Zqinx'.	5 years ago
Tsukasa OI	38cb335c76	RISC-V: Reorganize and enhance 'Zfinx' tests This commit adds certain test cases for 'Zfinx'/'Zdinx'/'Zqinx' extensions and reorganizes them, fixing coding style while improving coverage. This is partially based on jiawei's 'Zhinx' testcases. gas/ChangeLog: * testsuite/gas/riscv/zfinx.s: Use different registers for better encode space testing. Make indentation consistent. Add tests for instruction with rounding mode. Change march to minimum required extensions. Remove source line. * testsuite/gas/riscv/zfinx.d: Likewise. * testsuite/gas/riscv/zdinx.s: Likewise. * testsuite/gas/riscv/zdinx.d: Likewise. * testsuite/gas/riscv/zqinx.s: Likewise. Also use even-numbered registers to use valid register pairs. * testsuite/gas/riscv/zqinx.d: Likewise. Signed-off-by: Tsukasa OI <research_trasio@irq.a4lg.com> Signed-off-by: jiawei <jiawei@iscas.ac.cn>	4 years ago
Christoph Müllner	a6eeb20a42	RISC-V: Eliminate long-casts of X_add_number in diagnostics There is no need for casts to (signed/unsigned) long, as we can use C99's PRId64/PRIu64 format specifiers.	4 years ago
Jan Beulich	0b8c36f717	RISC-V: fallout from "re-arrange opcode table for consistent alias handling" Several new testcasee have appeared since the submission of said change, some of which now also need adjustment.	4 years ago
Jan Beulich	b0423163b8	RISC-V: fix build after "Add support for arbitrary immediate encoding formats" Pre- and post-increment/decrement are side effects, the behavior of which is undefined when combined with passing an address of the accessed variable in the same function invocation. There's no need for the increments here - simply adding 1 achieves the intended effect without triggering compiler diagnostics (which are fatal with -Werror).	4 years ago

1 2 3 4 5 ...

111429 Commits (e840e61cacd49836b0bdf692bb2ff7f66f969765) All Branches Search

111429 Commits (e840e61cacd49836b0bdf692bb2ff7f66f969765)

All Branches