binutils-gdb

Commit Graph

Author	SHA1	Message	Date
Andrew Burgess	f7f904e4fd	binutils-gdb/git: highlight whitespace errors in source files For a long time I've had this in my ~/.gitconfig: [core] whitespace = space-before-tab,indent-with-non-tab,trailing-space which causes git to show me if I muck up and use spaces instead of tabs, or leave in trailing whitespace. I find this really useful. I recently proposed adding something like this to the .gitattributes files for the GDB sub-directories (gdb, gdbsupport, and gdbserver)[1], however, the question was asked - couldn't this be done at the top level? So, in this commit, I propose to update the top-level .gitattributes file, after this commit, any git diff on a C, C++, Expect, or TCL source file, will highlight the following whitespace errors: (a) Use a space before a tab at the start of a line, (b) Use of spaces where a tab could be used at the start of a line, and (c) Any trailing whitespace. Errors are only highlighted in the diff on new or modified lines, so you don't get spammed for errors on context lines that you haven't modified. The only downside I see to adding this at the top level is if there are any sub-directories that don't follow the tabs/spaces indentation rules very well already, in those directories you'll end up hitting issues any time you edit a line. For GDB we're usually pretty good, so having this highlighting isn't an issue. [1] https://sourceware.org/pipermail/gdb-patches/2022-July/190843.html	4 years ago
Yvan Roux	a6e4a48c02	gdb/arm: Sync sp with other *sp registers For Arm Cortex-M33 with security extensions, there are 4 different stack pointers (msp_s, msp_ns, psp_s, psp_ns), without security extensions and for other Cortex-M targets, there are 2 different stack pointers (msp and psp). With this patch, sp will always be in sync with one of the real stack pointers on Arm targets that contain more than one stack pointer. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>	4 years ago
Torbjörn SVENSSON	42e11f363c	gdb/arm: Use if-else if instead of switch As the register numbers for the alternative Arm SP registers are not constant, it's not possible to use switch statement to define the rules. In order to not have a mix, replace the few existing switch statements with regular if-else if statements	4 years ago
Tom Tromey	eea2d83593	Remove dead code from windows_nat_target::detach windows_nat_target::detach has a variable 'detached' that is only set after a call to 'error'. However, this can't happen because 'error' throws an exception. This patch removes the dead code.	4 years ago
Andrew Burgess	90ed159321	gdb: handle dis_style_sub_mnemonic disassembler style In commit: commit `4f46c0bc36` Date: Mon Jul 4 17:45:25 2022 +0100 opcodes: add new sub-mnemonic disassembler style I added a new disassembler style dis_style_sub_mnemonic, but forgot to add GDB support for this style. Fix this oversight in this commit.	4 years ago
Andrew Burgess	36d94bd42b	libopcodes/ppc: add support for disassembler styling This commit adds disassembler styling to the libopcodes ppc disassembler. This conversion was pretty straight forward, I just converted the fprintf_func calls to fprintf_styled_func calls and added an appropriate style. For testing the new styling I just assembled then disassembled the source files in gas/testsuite/gas/ppc and manually checked that the styling looked reasonable. I think the only slightly weird case was how things like '4cr1+eq' are styled. As best I can tell, this construct, used for example in this instruction: crand 4cr1+lt,4cr1+gt,4cr1+eq is used to access a field of a control register. I initially tried styling this whole construct as a register[1], but during review it was suggested that instead different parts of the text should have different styles. In this commit I propose styling '4cr1+lt' like this: 4 - immediate, - text, cr1 - register + - text lt - sub-mnemonic If the user does not request styled output from objdump, then there should be no change in the disassembler output after this commit. [1] https://sourceware.org/pipermail/binutils/2022-July/121771.html	4 years ago
Andrew Burgess	4f46c0bc36	opcodes: add new sub-mnemonic disassembler style When adding libopcodes disassembler styling support for AArch64, it feels like the results would be improved by having a new sub-mnemonic style. This will be used in cases like: add w16, w7, w1, uxtb #2 ^^^^----- Here And: cinc w0, w1, ne ^^----- Here This commit just adds the new style, and prepares objdump to handle the style. A later commit will add AArch64 styling, and will actually make use of the style. As this style is currently unused, there should be no user visible changes after this commit.	4 years ago
liuzhensong	2cb10f02b0	LoongArch: Add testcases for new relocate types. gas/testsuite/gas/all/ gas.exp gas/testsuite/gas/loongarch/ jmp_op.d jmp_op.s macro_op.d macro_op.s macro_op_32.d macro_op_32.s macro_op_large_abs.d macro_op_large_abs.s macro_op_large_pc.d macro_op_large_pc.s reloc.d reloc.s ld/testsuite/ld-elf/ pr26936.d shared.exp ld/testsuite/ld-loongarch-elf/ attr-ifunc-4.c attr-ifunc-4.out disas-jirl.d ifunc.exp jmp_op.d jmp_op.s libnopic-global.s macro_op.d macro_op.s macro_op_32.d macro_op_32.s nopic-global-so.rd nopic-global-so.sd nopic-global.out nopic-global.s nopic-global.sd nopic-global.xd nopic-local.out nopic-local.rd nopic-local.s nopic-local.sd nopic-local.xd nopic-weak-global-so.rd nopic-weak-global-so.sd nopic-weak-global.out nopic-weak-global.s nopic-weak-global.sd nopic-weak-global.xd nopic-weak-local.out nopic-weak-local.rd nopic-weak-local.s nopic-weak-local.sd nopic-weak-local.xd pic.exp pic.ld	4 years ago
liuzhensong	9801120721	bfd: Delete R_LARCH_NONE from dyn info of LoongArch. Some R_LARCH_64 in section .eh_frame will to generate R_LARCH_NONE, we change relocation to R_LARCH_32_PCREL from R_LARCH_64 in setction .eh_frame and not generate dynamic relocation for R_LARCH_32_PCREL. Add New relocate type R_LARCH_32_PCREL for .eh_frame. include/elf/ loongarch.h bfd/ bfd/bfd-in2.h libbfd.h reloc.c elfxx-loongarch.c elfnn-loongarch.c gas/config/ tc-loongarch.c binutils/ readelf.c ld/testsuite/ld-elf/ eh5.d	4 years ago
liuzhensong	bc2a35c0b4	LoongArch: Move ifunc info to rela.dyn from rela.plt. Delete R_LARCH_IRELATIVE from dynamic loader (glibc ld.so) when loading lazy function (rela.plt section). In dynamic programes, move ifunc dynamic relocate info to section srelgot from srelplt. bfd/ elfnn-loongarch.c	4 years ago
liuzhensong	f09482a874	LoongArch: gas: Add new reloc types. Generate new relocate types while use new macro insns. gas/config/ loongarch-lex.h loongarch-parse.y tc-loongarch.c tc-loongarch.h	4 years ago
liuzhensong	cbdbf44535	LoongArch:opcodes: Add new reloc types. opcodes: Replace old insns with news and generate new relocate types while macro insns expanding. opcodes/ loongarch-opc.c	4 years ago
liuzhensong	6d13722a97	bfd: Add supported for LoongArch new relocations. Define new reloc types according to linker needs. include/elf/ loongarch.h bfd/ bfd-in2.h libbfd.h reloc.c elfnn-loongarch.c elfxx-loongarch.c elfxx-loongarch.h	4 years ago
Alan Modra	5d471bd907	Re: PowerPC64 .branch_lt address On seeing PR29369 my suspicion was naturally on a recent powerpc64 change, commit 0ab80031430e. Without a reproducer, I spent time wondering what could have gone wrong, and while I doubt this patch would have fixed the PR, there are some improvements that can be made to cater for user silliness. I also noticed that when -z relro -z now sections are created out of order, with .got before .plt in the section headers but .got is laid out at a higher address. That's due to the address expression for .branch_lt referencing SIZEOF(.got) and so calling init_os (which creates a bfd section) for .got before the .plt section is created. Fix that by ignoring SIZEOF in exp_init_os. Unlike ADDR and LOADADDR which need to reference section vma and lma respectively, SIZEOF can and does cope with a missing bfd section by returning zero for its size, which of course is correct. PR 29369 * ldlang.c (exp_init_os): Don't create a bfd section for SIZEOF. * emulparams/elf64ppc.sh (OTHER_RELRO_SECTIONS_2): Revise .branch_lt address to take into account possible user sections with alignment larger than 8 bytes.	4 years ago
GDB Administrator	5d8af25542	Automatic date update in version.in	4 years ago
Enze Li	ea892bdc4b	gdb/testsuite: add a clear test to py-breakpoint.exp This patch adds a test case to try to clear an internal python breakpoint using the clear command. This was suggested by Pedro during a code review of the following commit. commit `a5c69b1e49` Date: Sun Apr 17 15:09:46 2022 +0800 gdb: fix using clear command to delete non-user breakpoints(PR cli/7161) Tested on x86_64 openSUSE Tumbleweed.	4 years ago
Enze Li	c444385fad	gdb/testsuite: rename get_maint_bp_addr and move it to gdb-utils.exp The get_maint_bp_addr procedure will be shared by other test suite, so move it to gdb-utils.exp. Following Andrew's suggestion, I renamed get_maint_bp_addr to gdb_get_bp_addr, since it would have handled normal breakpoints in addition to the internal ones. Note that there is still room for improvement in this procedure, which I indicated in comments nearby.	4 years ago
GDB Administrator	561e83f7c5	Automatic date update in version.in	4 years ago
GDB Administrator	4c70437ddc	Automatic date update in version.in	4 years ago
Tom de Vries	263ad5cc81	[gdb/symtab] Fix duplicate CUs in all_comp_units When running test-case gdb.cp/cpexprs-debug-types.exp with target board cc-with-debug-names on a system with gcc 12.1.1 (defaulting to dwarf 5), I run into: ... (gdb) file cpexprs-debug-types^M Reading symbols from cpexprs-debug-types...^M warning: Section .debug_aranges in cpexprs-debug-types has duplicate \ debug_info_offset 0x0, ignoring .debug_aranges.^M gdb/dwarf2/read.h:309: internal-error: set_length: \ Assertion `m_length == length' failed.^M ... The exec contains a .debug_names section, which gdb rejects due to .debug_names containing a list of TUs, while the exec doesn't contain a .debug_types section (which is what you'd expect for dwarf 4). Gdb then falls back onto the cooked index, which calls create_all_comp_units to create all_comp_units. However, the failed index reading left some elements in all_comp_units, so we end up with duplicates in all_comp_units, which causes the misleading complaint and the assert. Fix this by: - asserting at the start of create_all_comp_units that all_comp_units is empty, as we do in create_cus_from_index and create_cus_from_debug_names, and - cleaning up all_comp_units when failing in dwarf2_read_debug_names. Add a similar cleanup in dwarf2_read_gdb_index. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29381	4 years ago
Simon Marchi	5ae3df226b	gdb/testsuite: give binaries distinct names in Ada tests Some Ada tests repeat their test sequence with different gnat-encodings, typically "all" and "minimal". However, they give the same name to both binaries, meaning the second run overwrites the binary of the first run. This makes it difficult and confusing when trying to reproduce problems manually with the test artifacts. Change those tests to use unique names for each pass. Change-Id: Iaa3c9f041241249a7d67392e785c31aa189dcc88	4 years ago
Tom Tromey	4a570176b4	Change target_ops::async to accept bool This changes the parameter of target_ops::async from int to bool. Regression tested on x86-64 Fedora 34.	4 years ago
Tom Tromey	36da255e7c	Fix typo in windows-nat.c I noticed a typo in a printf in windows-nat.c. This fixes it.	4 years ago
Tom de Vries	9083a323bc	[gdb] Add empty range unit test for gdb::parallel_for_each Add a unit test that verifies that we can call gdb::parallel_for_each with an empty range. Tested on x86_64-linux.	4 years ago
Alan Modra	6577f365eb	PR17122, OSX 10.9 build failure sbrk hasn't been used in binutils/ or ld/ for quite some time (so the PR was fixed a while ago). Tidy up configury. PR 17122 binutils/ * configure.ac: Don't check for sbrk. * sysdep.h (sbrk): Don't supply fallback declaration. * config.in: Regenerate. * configure: Regenerate. ld/ * configure.ac: Don't check for sbrk. * config.in: Regenerate. * configure: Regenerate.	4 years ago
Jiangshuai Li	4686f81068	gdb/csky modify registers list for general_reggroup There are two modification points here: 1. For the debugging of csky architecture, after executing "info register", we hope to print out GPRs, PC and the registers related to exceptions. 2. With tdesc-xml, users can view the register groups described in XML.	4 years ago
Alan Modra	b5375c5da9	PR15951, binutils testsuite builds status wrapper unconditionally PR 15951 * testsuite/binutils-all/objcopy.exp: Build testglue.o when needs_status_wrapper.	4 years ago
GDB Administrator	13391ff8bc	Automatic date update in version.in	4 years ago
Peter Bergner	c07ec968f7	Add ChangeLog entry from previous commit	4 years ago
Peter Bergner	0a24685343	PowerPC: Create new MMA instruction masks and use them The MMA instructions use XX3_MASK\|3<<21 as an instruction mask, but that misses the RC bit/bit 31, so if we disassemble a .long that represents an MMA instruction except that it also has bit 31 set, we will erroneously disassemble it to that MMA instruction. We create new masks defines that contain bit 31 so that doesn't happen anymore. opcodes/ * ppc-opc.c (XACC_MASK, XX3ACC_MASK): New defines. (P_GER_MASK, xxmfacc, xxmtacc, xxsetaccz, xvi8ger4pp, xvi8ger4, xvf16ger2pp, xvf16ger2, xvf32gerpp, xvf32ger, xvi4ger8pp, xvi4ger8, xvi16ger2spp, xvi16ger2s, xvbf16ger2pp, xvbf16ger2, xvf64gerpp, xvf64ger, xvi16ger2, xvf16ger2np, xvf32gernp, xvi8ger4spp, xvi16ger2pp, xvbf16ger2np, xvf64gernp, xvf16ger2pn, xvf32gerpn, xvbf16ger2pn, xvf64gerpn, xvf16ger2nn, xvf32gernn, xvbf16ger2nn, xvf64gernn: Use them.	4 years ago
H.J. Lu	8f29211c3f	i386: Don't allow GOTOFF relocation against IFUNC symbol for PIC We can't use the PLT entry as the function address for PIC since the PIC register may not be set up properly for indirect call. bfd/ PR ld/27998 * elf32-i386.c (elf_i386_relocate_section): Don't allow GOTOFF relocation against IFUNC symbol for PIC. ld/ PR ld/27998 * testsuite/ld-i386/pr27998a.d: Replace -shared with -e bar. * testsuite/ld-i386/pr27998b.d: Expect a linker error. * testsuite/ld-ifunc/ifunc-2-i386-now.d: Updated. * testsuite/ld-ifunc/ifunc-2-local-i386-now.d: Likewise. * testsuite/ld-ifunc/ifunc-2-i386.s: Replace @GOTOFF with @GOT. * testsuite/ld-ifunc/ifunc-2-local-i386.s: Likewise.	4 years ago
Andrew Burgess	c44885db3b	gdb: ensure the cast in gdbarch_tdep is valid This commit makes use of gdb::checked_static_cast when casting the generic gdbarch_tdep pointer to a specific sub-class type. This means that, when compiled in developer mode, GDB will validate that the cast is correct. In order to use gdb::checked_static_cast the types involved must have RTTI, which is why the gdbarch_tdep base class now has a virtual destructor. Assuming there are no bugs in GDB where we cast a gdbarch_tdep pointer to the wrong type, then there should be no changes after this commit. If any bugs do exist, then GDB will now assert (in a developer build).	4 years ago
Andrew Burgess	11da1b13b3	gdbsupport: add checked_static_cast This commit was inspired by these mailing list posts: https://sourceware.org/pipermail/gdb-patches/2022-June/190323.html https://sourceware.org/pipermail/gdb-patches/2022-April/188098.html The idea is to add a new function gdb::checked_static_cast, which can, in some cases, be used as a drop-in replacement for static_cast. And so, if I previously wrote this: BaseClass base = get_base_class_pointer (); DerivedClass derived = static_cast<DerivedClass > (base); I can now write: BaseClass base = get_base_class_pointer (); DerivedClass derived = gdb::checked_static_cast<DerivedClass > (base); The requirement is that BaseClass and DerivedClass must be polymorphic. The benefit of making this change is that, when GDB is built in developer mode, a run-time check will be made to ensure that `base` really is of type DerivedClass before the cast is performed. If `base` is not of type DerivedClass then GDB will assert. In a non-developer build gdb::checked_static_cast is equivalent to a static_cast, and there should be no performance difference. This commit adds the support function, but does not make use of this function, a use will be added in the next commit. Co-Authored-By: Pedro Alves <pedro@palves.net> Co-Authored-By: Tom Tromey <tom@tromey.com>	4 years ago
Andrew Burgess	08106042d9	gdb: move the type cast into gdbarch_tdep I built GDB for all targets on a x86-64/GNU-Linux system, and then (accidentally) passed GDB a RISC-V binary, and asked GDB to "run" the binary on the native target. I got this error: (gdb) show architecture The target architecture is set to "auto" (currently "i386"). (gdb) file /tmp/hello.rv32.exe Reading symbols from /tmp/hello.rv32.exe... (gdb) show architecture The target architecture is set to "auto" (currently "riscv:rv32"). (gdb) run Starting program: /tmp/hello.rv32.exe ../../src/gdb/i387-tdep.c:596: internal-error: i387_supply_fxsave: Assertion `tdep->st0_regnum >= I386_ST0_REGNUM' failed. What's going on here is this; initially the architecture is i386, this is based on the default architecture, which is set based on the native target. After loading the RISC-V executable the architecture of the current inferior is updated based on the architecture of the executable. When we "run", GDB does a fork & exec, with the inferior being controlled through ptrace. GDB sees an initial stop from the inferior as soon as the inferior comes to life. In response to this stop GDB ends up calling save_stop_reason (linux-nat.c), which ends up trying to read register from the inferior, to do this we end up calling target_ops::fetch_registers, which, for the x86-64 native target, calls amd64_linux_nat_target::fetch_registers. After this I eventually end up in i387_supply_fxsave, different x86 based targets will end in different functions to fetch registers, but it doesn't really matter which function we end up in, the problem is this line, which is repeated in many places: i386_gdbarch_tdep tdep = (i386_gdbarch_tdep ) gdbarch_tdep (arch); The problem here is that the ARCH in this line comes from the current inferior, which, as we discussed above, will be a RISC-V gdbarch, the tdep field will actually be of type riscv_gdbarch_tdep, not i386_gdbarch_tdep. After this cast we are relying on undefined behaviour, in my case I happen to trigger an assert, but this might not always be the case. The thing I tried that exposed this problem was of course, trying to start an executable of the wrong architecture on a native target. I don't think that the correct solution for this problem is to detect, at the point of cast, that the gdbarch_tdep object is of the wrong type, but, I did wonder, is there a way that we could protect ourselves from incorrectly casting the gdbarch_tdep object? I think that there is something we can do here, and this commit is the first step in that direction, though no actual check is added by this commit. This commit can be split into two parts: (1) In gdbarch.h and arch-utils.c. In these files I have modified gdbarch_tdep (the function) so that it now takes a template argument, like this: template<typename TDepType> static inline TDepType * gdbarch_tdep (struct gdbarch gdbarch) { struct gdbarch_tdep tdep = gdbarch_tdep_1 (gdbarch); return static_cast<TDepType > (tdep); } After this change we are no better protected, but the cast is now done within the gdbarch_tdep function rather than at the call sites, this leads to the second, much larger change in this commit, (2) Everywhere gdbarch_tdep is called, we make changes like this: - i386_gdbarch_tdep tdep = (i386_gdbarch_tdep ) gdbarch_tdep (arch); + i386_gdbarch_tdep tdep = gdbarch_tdep<i386_gdbarch_tdep> (arch); There should be no functional change after this commit. In the next commit I will build on this change to add an assertion in gdbarch_tdep that checks we are casting to the correct type.	4 years ago
Andrew Burgess	602707187f	gdb: select suitable thread for gdbarch_adjust_breakpoint_address The three targets that implement gdbarch_adjust_breakpoint_address are arm, frv, and mips. In each of these targets the adjust breakpoint address function does some combination of reading the symbol table, or reading memory at the location the breakpoint could be placed. The problem is that performing these actions requires that the current inferior and program space be the one in which the breakpoint will be placed, and this is not currently always the case. Consider a GDB session with multiple inferiors. One inferior might be a native target while another could be a remote target of a completely different architecture. Alternatively, if we consider ARM and AArch64, one native inferior might be AArch64, while a second native inferior could be ARM. In these cases it is possible, and valid, for a user to have one inferior selected, and place a breakpoint in the other inferior by placing a breakpoint on a particular symbol. If this happens, then currently, when gdbarch_adjust_breakpoint_address is called, the wrong inferior (and program space) will be selected, and memory reads, and symbol look ups, will not return the expected results, this could lead to breakpoints being placed in the wrong location. There are currently two places where gdbarch_adjust_breakpoint_address is called: 1. In infrun.c, in the function handle_step_into_function. In this case, I believe that the correct inferior and program space will already be selected as this is called as part of the stop event handling, so I don't think we need to worry about this case, and 2. In breakpoint.c, in the function adjust_breakpoint_address, which is itself called from code_breakpoint::add_location and watch_command_1. The watch_command_1 case I don't think we need to worry about, this is for when a local watch expression is created, which can only be in the currently selected inferior, so this case should be fine. The code_breakpoint::add_location case is the one that needs fixing, this is what allows a breakpoint to be created between inferiors. To fix the code_breakpoint::add_location case, I propose that we pass the "correct" program_space (i.e. the program space in which the breakpoint will be created) to the adjust_breakpoint_address function. Then in adjust_breakpoint_address we can make use of switch_to_program_space_and_thread to switch program_space and inferior before calling gdbarch_adjust_breakpoint_address. I discovered this issue while working on a later patch in this series. This later patch will detect when we cast the result of gdbarch_tdep to the wrong type. With this later patch in place I ran gdb.multi/multi-arch.exp on an AArch64 target. In this situation, two inferiors are created, an AArch64 inferior, and an ARM inferior. The test selected the AArch64 inferior and tries to create a breakpoint in the ARM inferior. As a result of this we end up in arm_adjust_breakpoint_address, which calls arm_pc_is_thumb. Before this commit the AArch64 inferior would be current. As a result, all of the checks in arm_pc_is_thumb would fail (they rely on reading symbols from the current program space), and so, at the end of arm_pc_is_thumb we would call arm_frame_is_thumb. However, remember, at this point the current inferior is the AArch64 inferior, so the current frame is an AArch64 frame. In arm_frame_is_thumb we call arm_psr_thumb_bit, which calls gdbarch_tdep and casts the result to arm_gdbarch_tdep. This is wrong, the tdep field is of type aarch64_gdbarch_tdep. After this we have undefined behaviour. With this patch in place, we will have switched to a thread in the ARM program space before calling arm_adjust_breakpoint_address. As a result, we now succeed in looking up the required symbols in arm_pc_is_thumb, and so we never call arm_frame_is_thumb. However, in the worst case scenario, if we did end up calling arm_frame_is_thumb, as the current inferior should now be the ARM inferior, the current frame should be an ARM frame, so we still should not hit undefined behaviour. I have added an assert to arm_frame_is_thumb.	4 years ago
Andrew Burgess	52abb4de08	gdb/mips: rewrite show_mask_address This commit is similar to the previous commit, but in this case GDB is actually relying on undefined behaviour. Consider building GDB for all targets on x86-64/GNU-Linux, then doing this: (gdb) show mips mask-address Zeroing of upper 32 bits of 64-bit addresses is auto. The 32 bit address mask is set automatically. Currently disabled (gdb) The 'show mips mask-address' command ends up in show_mask_address in mips-tdep.c, and this function does this: mips_gdbarch_tdep tdep = (mips_gdbarch_tdep ) gdbarch_tdep (target_gdbarch ()); Later we might pass TDEP to mips_mask_address_p. However, in my example above, on an x86-64 native target, the current target architecture will be an x86-64 gdbarch, and the tdep field within the gdbarch will be of type i386_gdbarch_tdep, not of type mips_gdbarch_tdep, as a result the cast above was incorrect, and TDEP is not pointing at what it thinks it is. I also think the current output is a little confusing, we appear to have two lines that show the same information, but using different words. The first line comes from calling deprecated_show_value_hack, while the second line is printed directly from show_mask_address. However, both of these lines are printing the same mask_address_var value. I don't think the two lines actually adds any value here. Finally, none of the text in this function is passed through the internationalisation mechanism. It would be nice to remove another use of deprecated_show_value_hack if possible, so this commit does a complete rewrite of show_mask_address. After this commit the output of the above example command, still on my x86-64 native target is: (gdb) show mips mask-address Zeroing of upper 32 bits of 64-bit addresses is "auto" (current architecture is not MIPS). The 'current architecture is not MIPS' text is only displayed when the current architecture is not MIPS. If the architecture is mips then we get the more commonly seen 'currently "on"' or 'currently "off"', like this: (gdb) set architecture mips The target architecture is set to "mips". (gdb) show mips mask-address Zeroing of upper 32 bits of 64-bit addresses is "auto" (currently "off"). (gdb) All the text is passed through the internationalisation mechanism, and we only call gdbarch_tdep when we know the gdbarch architecture is bfd_arch_mips.	4 years ago
Andrew Burgess	6dff2a6ffe	gdb/arm: move fetch of arm_gdbarch_tdep to a more inner scope This is a small refactor to resolve an issue before it becomes a problem in a later commit. Move the fetching of an arm_gdbarch_tdep into a more inner scope within two functions in arm-tdep.c. The problem with the current code is that the functions in question are used as the callbacks for two set/show parameters. These set/show parameters are available no matter the current architecture, but are really about controlling an ARM architecture specific setting. And so, if I build GDB for all targets on an x86-64/GNU-Linux system, I can still do this: (gdb) show arm fpu (gdb) show arm abi After these calls we end up in show_fp_model and arm_show_abi respectively, where we unconditionally do this: arm_gdbarch_tdep tdep = (arm_gdbarch_tdep ) gdbarch_tdep (target_gdbarch ()); However, the gdbarch_tdep() result will only be a arm_gdbarch_tdep if the current architecture is ARM, otherwise the result will actually be of some other type. This isn't actually a problem, as in both cases the use of tdep is guarded by a later check that the gdbarch architecture is bfd_arch_arm. This commit just moves the call to gdbarch_tdep() after the architecture check. In a later commit gdbarch_tdep() will be able to spot when we are casting the result to the wrong type, and this function will trigger assertion failures if things are not fixed. There should be not user visible changes after this commit.	4 years ago
Torbjörn SVENSSON	d65edaa0bc	[arm] Rename arm_cache_is_sp_register to arm_is_alternative_sp_register All usages of this helper are really made to check if the register is one of the alternative SP registers (MSP/MSP_S/MSP_NS/PSP/PSP_S/PSP_NS) with the ARM_SP_REGNUM case being handled separately. Signed-off-by: Luis Machado <luis.machado@arm.com> Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>	4 years ago
Tom de Vries	5c3392f981	[gdb/python] Fix typo in test_python Fix typo in ref_output_0 variable in test_python. Tested by running the selftest on x86_64-linux with python 3.11.	4 years ago
Tom de Vries	c57ac51086	[gdb/python] Fix python selftest with python 3.11 With python 3.11 I noticed: ... $ gdb -q -batch -ex "maint selftest python" Running selftest python. Self test failed: self-test failed at gdb/python/python.c:2246 Ran 1 unit tests, 1 failed ... In more detail: ... (gdb) p output $5 = "Traceback (most recent call last):\n File \"<string>\", line 0, \ in <module>\nKeyboardInterrupt\n" (gdb) p ref_output $6 = "Traceback (most recent call last):\n File \"<string>\", line 1, \ in <module>\nKeyboardInterrupt\n" ... Fix this by also allowing line number 0. Tested on x86_64-linux. This should hopefully fix buildbot builder gdb-rawhide-x86_64.	4 years ago
Tom de Vries	9b89bf16c3	[gdbsupport] Fix type of parallel_for_each_debug When I changed the initialization of parallel_for_each_debug from 0 to false, I forgot to change the type from int to bool. Fix this. Tested by rebuilding on x86_64-linux.	4 years ago
Tom de Vries	2fe9a3c41f	[gdb/symtab] Fix bad compile unit index complaint I noticed this code in dw2_debug_names_iterator::next: ... case DW_IDX_compile_unit: /* Don't crash on bad data. / if (ull >= per_bfd->all_comp_units.size ()) { complaint (_(".debug_names entry has bad CU index %s" " [in module %s]"), pulongest (ull), objfile_name (objfile)); continue; } per_cu = per_bfd->get_cu (ull); break; ... This code used to DTRT, before we started keeping both CUs and TUs in all_comp_units. Fix by using "per_bfd->all_comp_units.size () - per_bfd->tu_stats.nr_tus" instead. It's hard to produce a test-case for this, but let's try at least to trigger the complaint somehow. We start out by creating an exec with .debug_types and .debug_names: ... $ gcc -g ~/hello.c -fdebug-types-section $ gdb-add-index -dwarf-5 a.out ... and verify that we don't see any complaints: ... $ gdb -q -batch -iex "set complaints 100" ./a.out ... We look at the CU and TU table using readelf -w and conclude that we have nr_cus == 6 and nr_tus == 1. Now override ull in dw2_debug_names_iterator::next for the DW_IDX_compile_unit case to 6, and we have: ... $ gdb -q -batch -iex "set complaints 100" ./a.out During symbol reading: .debug_names entry has bad CU index 6 [in module a.out] ... After this, it still crashes because this code in dw2_debug_names_iterator::next: ... / Skip if already read in. */ if (m_per_objfile->symtab_set_p (per_cu)) goto again; ... is called with per_cu == nullptr. Fix this by skipping the entry if per_cu == nullptr. Now revert the fix and observe that the complaint disappears, so we've confirmed that the fix is required. A somewhat similar issue for .gdb_index in dw2_symtab_iter_next has been filed as PR29367. Tested on x86_64-linux, with native and target board cc-with-debug-names. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29336	4 years ago
Jan Beulich	ea09fe9259	x86: replace wrong attributes on VCVTDQ2PH{X,Y} A standalone (without SAE) StaticRounding attribute is meaningless, and indeed all other similar insns have ATTSyntax there instead. I can only assume this was some strange copy-and-paste mistake.	4 years ago
Jan Beulich	987e8a90fa	x86/Intel: correct AVX512F scatter insn element sizes I clearly screwed up in `6ff00b5e12` ("x86/Intel: correct permitted operand sizes for AVX512 scatter/gather") giving all AVX512F scatter insns Dword element size. Update testcases (also their gather parts), utilizing that there previously were two identical lines each (for no apparent reason).	4 years ago
Alan Modra	e4e340a3ff	PR29390, DW_CFA_AARCH64_negate_ra_state vs. DW_CFA_GNU_window_save PR 29390 binutils/ * dwarf.c (is_aarch64, DW_CFA_GNU_window_save_name): New. (display_debug_frames): Use them. (init_dwarf_regnames_aarch64): Set is_aarch64. (init_dwarf_regnames_by_elf_machine_code): Clear is_aarch64. (init_dwarf_regnames_by_bfd_arch_and_mach): Likewise. gas/ * testsuite/gas/aarch64/pac_ab_key.d: Adjust expected output. * testsuite/gas/aarch64/pac_negate_ra_state.d: Likewise.	4 years ago
Alan Modra	e82295b23d	PR29337, readelf CU/TU mixup in .gdb_index Commit `244e19c791` changed a number of variables in display_gdb_index to count entries rather than words. PR 29337 * dwarf.c (display_gdb_index): Correct use of cu_list_elements.	4 years ago
Alan Modra	695c6dfe7e	PR29370, infinite loop in display_debug_abbrev The PR29370 testcase is a fuzzed object file with multiple .trace_abbrev sections. Multiple .trace_abbrev or .debug_abbrev sections are not a violation of the DWARF standard. The DWARF5 standard even gives an example of multiple .debug_abbrev sections contained in groups. Caching and lookup of processed abbrevs thus needs to be done by section and offset rather than base and offset. (Why base anyway?) Or, since section contents are kept, by a pointer into the contents. PR 29370 * dwarf.c (struct abbrev_list): Replace abbrev_base and abbrev_offset with raw field. (find_abbrev_list_by_abbrev_offset): Delete. (find_abbrev_list_by_raw_abbrev): New function. (process_abbrev_set): Set list->raw and list->next. (find_and_process_abbrev_set): Replace abbrev list lookup with new function. Don't set list abbrev_base, abbrev_offset or next.	4 years ago
Alan Modra	f07c08e115	binutils/dwarf.c: abbrev caching I'm inclined to think that abbrev caching is counter-productive. The time taken to search the list of abbrevs converted to internal form is non-zero, and it's easy to decode the raw abbrevs. It's especially silly to cache empty lists of decoded abbrevs (happens with zero padding in .debug_abbrev), or abbrevs as they are displayed when there is no further use of those abbrevs. This patch stops caching in those cases. * dwarf.c (record_abbrev_list_for_cu): Add free_list param. Put abbrevs on abbrev_lists here. (new_abbrev_list): Delete function. (process_abbrev_set): Return newly allocated list. Move abbrev base, offset and size checking to.. (find_and_process_abbrev_set): ..here, new function. Handle lookup of cached abbrevs here, and calculate start and end for process_abbrev_set. Return free_list if newly alloc'd. (process_debug_info): Consolidate cached list lookup, new list alloc and processing into find_and_process_abbrev_set call. Free list when not cached. (display_debug_abbrev): Similarly.	4 years ago
Alan Modra	175b91507b	miscellaneous dwarf.c tidies * dwarf.c: Leading and trailing whitespace fixes. (free_abbrev_list): New function. (free_all_abbrevs): Use the above. Free cu_abbrev_map here too. (process_abbrev_set): Print actual section name on error. (get_type_abbrev_from_form): Add overflow check. (free_debug_memory): Don't free cu_abbrev_map here.. (process_debug_info): ..or here. Warn on another case of not finding a neeeded abbrev.	4 years ago
Alan Modra	590207aa6e	PowerPC64: fix build error on 32-bit hosts elf64-ppc.c:11673:33: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘bfd_vma’ {aka ‘long long unsigned int’} [-Werror=format=] 11673 \| fprintf (stderr, "offset = %#lx:", stub_entry->stub_offset); \| ~~~^ ~~~~~~~~~~~~~~~~~~~~~~~ \| \| \| \| \| bfd_vma {aka long long unsigned int} \| long unsigned int \| %#llx * elf64-ppc.c (dump_stub): Use BFD_VMA_FMT.	4 years ago

1 2 3 4 5 ...

110819 Commits (f7f904e4fda6fb571d40a3547ed03ec6028e6694) All Branches Search

110819 Commits (f7f904e4fda6fb571d40a3547ed03ec6028e6694)

All Branches