binutils-gdb

Commit Graph

Author	SHA1	Message	Date
Simon Marchi	978602e83f	bfd: add AMDGCN architecture Add support for the AMDGCN architecture to BFD. This is the bare minimum to get $ ./configure --target=amdgcn-hsa-amdhsa --disable-gas $ make all-binutils working later in this series. The specific AMDGCN models added here are a bit arbitrary, based on what we intend to initially support in GDB. This list will need to be updated in the future anyway. The complete up-to-date list of existing AMDGPU models can be found here: https://llvm.org/docs/AMDGPUUsage.html#processors The ELF format for this architecture is documented here: https://llvm.org/docs/AMDGPUUsage.html#elf-code-object The flags for the "HSA" OS ABI are properly versioned and documented on that page. But the NONE, PAL and MESA3D OS ABIs are not well documented nor versioned. Taking a peek at the LLVM source code, we see that they encode their flags the same way as HSA v3. For example, for PAL: `c8b614cd74/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp (L601)` So at least, we know that all AMDGPU objects (of which AMDGCN objects are a subset of) at the time of writing encode the specific GPU model in the EF_AMDGPU_MACH field of e_flags. bfd/ChangeLog: * Makefile.am (ALL_MACHINES, ALL_MACHINES_CFILES): Add cpu-amdgcn.c. (BFD64_BACKENDS): Add elf64-amdgcn.lo. (BFD64_BACKENDS_CFILES): Add elf64-amdgcn.c. * Makefile.in: Re-generate. * cpu-amdgcn.c: New. * elf64-amdgcn.c: New. * archures.c (bfd_architecture): Add bfd_arch_amdgcn and related mach defines. (bfd_amdgcn_arch): New. (bfd_archures_list): Add bfd_amdgcn_arch. * bfd-in2.h: Re-generate. * config.bfd: Handle amdgcn* target. * configure.ac: Handle amdgcn_elf64_le_vec. * configure: Re-generate. * elf-bfd.h (elf_target_id): Add AMDGCN_ELF_DATA. * targets.c (amdgcn_elf64_le_vec): New. (_bfd_target_vector): Add amdgcn_elf64_le_vec. include/ChangeLog: * elf/amdgpu.h: New. * elf/common.h (ELFOSABI_AMDGPU_HSA): Add. Change-Id: I969f7b14960797e88891c308749a6e341eece5b2	4 years ago
Nick Clifton	f4f95df31b	Updated Serbian (for binutils/) and Russian (for gprof/) translations	4 years ago
Pedro Alves	9bde221fec	Make gdb.fortran/{array-slices,lbound-ubound} work against gdbserver gdb.fortran/array-slices.exp and gdb.fortran/lbound-ubound.exp were recently disabled unless testing with the native target, because they rely on inferior I/O. However, when testing against gdbserver using the native-gdbserver/native-extended-gdbserver boards, we do have access to inferior I/O. The right way to check whether the board can do I/O, is via checking the gdb,noinferiorio board variable. Switch to using that. And then, tweak the testcases to expect output to appear in inferior_spawn_id, instead of gdb_spawn_id. When testing against the native target, inferior_spawn_id is the same as gdb_spawn_id. When testing against gdbserver, it maps to gdbserver_spawn_id. This exposed a buglet in gdb.fortran/array-slices.f90's show_1d subroutine -- it was missing printing newline at the end of the "Expected GDB Output" text, leading to a test timeout. All other subroutines end with advance=yes, except this one. Fix it by using advance=yes here too. Change-Id: I4640729f334431cfc24b0917e7d3977b677c6ca5	5 years ago
GDB Administrator	22546800ad	Automatic date update in version.in	4 years ago
Alan Modra	dc3ff92676	Delete PowerPC macro insn support Let's hope this stays dead, but it's here as a patch separate from those that removed use of powerpc_macros just in case it needs to be resurrected. include/ * opcode/ppc.h (struct powerpc_macro): Delete declaration. (powerpc_macros, powerpc_num_macros): Likewise.. opcodes/ * ppc-opc.c (powerpc_macros, powerpc_num_macros): Delete. gas/ * config/tc-ppc.c (ppc_macro): Delete function. (ppc_macro_hash): Delete. (ppc_setup_opcodes, md_assemble): Delete macro support.	4 years ago
Alan Modra	8736318e4e	PowerPC SPE/SPE2 aliases in powerpc_macros * ppc-opc.c (powerpc_macros): Move "evsadd", "evssub", "evsabs", "evsnabs", "evsneg", "evsmul", "evsdiv", "evscmpgt", "evsgmplt", "evsgmpeq", "evscfui", "evscfsi", "evscfuf", "evscfsf", "evsctui", "evsctsi", "evsctuf", "evsctsf", "evsctuiz", "evsctsiz", "evststgt", "evststlt", "evststeq".. (powerpc_opcodes): ..to here. (powerpc_macros): Move "evdotphsssi", "evdotphsssia", "evdotpwsssi", and "evdotpwsssia".. (spe2_opcodes): ..to here.	4 years ago
Alan Modra	51ba92c795	PowerPC VLE extended instructions in powerpc_macros This moves VLE insn out of the macro table. "e_slwi" and "e_srwi" already exist in vle_opcodes as distinct instructions rather than encodings of e_rlwinm. opcodes/ * ppc-opc.c (vle_opcodes): Typo fix e_rlwinm operand. Add "e_inslwi", "e_insrwi", "e_rotlwi", "e_rotrwi", "e_clrlwi", "e_clrrwi", "e_extlwi", "e_extrwi", and "e_clrlslwi". (powerpc_macros): Delete same. Delete "e_slwi" and "e_srwi" too. gas/ * testsuite/gas/ppc/vle-simple-5.d: Update.	4 years ago
Alan Modra	f304c63d24	PowerPC32 extended instructions in powerpc_macros As for PowerPC64, move instructions to the main opcode table. opcodes/ * ppc-opc.c (insert_crwn, extract_crwn, insert_elwn, extract_elwn), (insert_erwn, extract_erwn, insert_erwb, extract_erwb), (insert_cslwn, extract_cslwb, insert_ilwb, extract_ilwn), (insert_irwb, extract_irwn, insert_rrwn, extract_rrwn), (insert_slwn, extract_slwn, insert_srwn, extract_srwn): New functions. (CRWn, ELWn, ERWn, ERWb, CSLWb, CSLWn, ILWn, ILWb, IRWn, IRWb), (RRWn, SLWn, SRWn): Define and add powerpc_operands entries. (MMB_MASK, MME_MASK, MSHMB_MASK): Define. (powerpc_opcodes): Add "inslwi", "insrwi", "rotrwi", "clrrwi", "slwi", "srwi", "extlwi", "extrwi", "sli", "sri" and corresponding record (ie. dot suffix) forms. (powerpc_macros): Delete same. gas/ * testsuite/gas/ppc/476.d: Update. * testsuite/gas/ppc/simpshft.d: Update.	4 years ago
Alan Modra	42952a9605	PowerPC64 extended instructions in powerpc_macros The extended instructions implemented in powerpc_macros aren't used by the disassembler. That means instructions like "sldi r3,r3,2" appear in disassembly as "rldicr r3,r3,2,61", which is annoying since many other extended instructions are shown. Note that some of the instructions moved out of the macro table to the opcode table won't appear in disassembly, because they are aliases rather than a subset of the underlying raw instruction. If enabled, rotrdi, extrdi, extldi, clrlsldi, and insrdi would replace all occurrences of rotldi, rldicl, rldicr, rldic and rldimi. (Or many occurrences in the case of clrlsldi if n <= b was added to the extract functions.) The patch also fixes a small bug in opcode sanity checking. include/ * opcode/ppc.h (PPC_OPSHIFT_SH6): Define. opcodes/ * ppc-opc.c (insert_erdn, extract_erdn, insert_eldn, extract_eldn), (insert_crdn, extract_crdn, insert_rrdn, extract_rrdn), (insert_sldn, extract_sldn, insert_srdn, extract_srdn), (insert_erdb, extract_erdb, insert_csldn, extract_csldb), (insert_irdb, extract_irdn): New functions. (ELDn, ERDn, ERDn, RRDn, SRDn, ERDb, CSLDn, CSLDb, IRDn, IRDb): Define and add associated powerpc_operands entries. (powerpc_opcodes): Add "rotrdi", "srdi", "extrdi", "clrrdi", "sldi", "extldi", "clrlsldi", "insrdi" and corresponding record (ie. dot suffix) forms. (powerpc_macros): Delete same from here. gas/ * config/tc-ppc.c (insn_validate): Don't modify value passed to operand->insert for PPC_OPERAND_PLUS1 when calculating mask. Handle PPC_OPSHIFT_SH6. * testsuite/gas/ppc/prefix-reloc.d: Update. * testsuite/gas/ppc/simpshft.d: Update. ld/ * testsuite/ld-powerpc/elfv2so.d: Update. * testsuite/ld-powerpc/notoc.d: Update. * testsuite/ld-powerpc/notoc3.d: Update. * testsuite/ld-powerpc/tlsdesc2.d: Update. * testsuite/ld-powerpc/tlsget.d: Update. * testsuite/ld-powerpc/tlsget2.d: Update. * testsuite/ld-powerpc/tlsopt5.d: Update. * testsuite/ld-powerpc/tlsopt6.d: Update.	4 years ago
Tom Tromey	8f50b4b574	Do not capture updated 'pc' in add_local_symbols Simon pointed out that commit `13835d88` ("Use function view when iterating over block symbols") caused a regression. The bug is that the new closure captures 'pc' by reference, but later code updates this variable -- but the earlier code did not update the callback structure with the new value. This patch restores the old behavior by using a new varible name in an inner scope.	4 years ago
Jose E. Marchesi	6aa03e9c17	gprofng: avoid using `fallthrough' attributes gprofng didn't build with gcc 6.3 due to the usage of __attribute__ ((fallthrough)). This patch uses /* FALLTHROUGH / instead. 2022-03-15 Jose E. Marchesi <jose.marchesi@oracle.com> gprofng/src/gp-collect-app.cc (collect::check_args): Use fallthrough comment instead of attribute.	4 years ago
Tom Tromey	cda8dc94df	Fix bug in dwarf-mode.el I noticed that, occasionally, dwarf-mode would think that the objdump subprocess was still running after it had clearly exited. I managed to reliably reproduce this today and learned that a process sentinel is not guaranteed to be run with the current buffer set to the process buffer. This patch fixes the problem. I've bumped the version number of dwarf-mode.el to make it easier to install for users who already have an earlier one installed. I'm checking this in. 2022-03-15 Tom Tromey <tromey@adacore.com> * dwarf-mode.el: Now 1.7. (dwarf--sentinel): Switch to the process buffer.	4 years ago
Andrew Burgess	af481f0129	gdb/testsuite: rename a proc and fix a typo Rename a proc in gdb.mi/user-selected-context-sync.exp, I think the old name was most likely a typo. The old name match_re_or_ensure_not_output seems (to me) to imply we're in some way checking that the regexp was not output. But that's not what we are doing, we're checking either for the regexp, or for no output, hence the new name match_re_or_ensure_no_output. Additionally, I found a definite typo in one of the comments that I've also fixed. I also updated some test names. These tests (probably due to copy & paste errors) has 'on MI' on their name, when they were actually checking CLI output. For these test I changed the name to use 'on CLI'. There should be no change in what is tested after this commit.	4 years ago
Nick Clifton	4ec39c4bca	gprofng: Add a configure test for clock_gettime and a use of the test in getthrtime.c	4 years ago
H.J. Lu	a4eb1b3cf6	gprofng: Don't generate gprofng.info in source Add info-in-builddir to AUTOMAKE_OPTIONS. PR gprof/28967 * doc/Makefile.am (AUTOMAKE_OPTIONS): Add info-in-builddir. * doc/Makefile.in: Regenerate.	4 years ago
Tiezhu Yang	e34f44e1bf	gdb: LoongArch: fix failed testcases in gdb.base/align-c.exp When execute the following command on LoongArch: make check-gdb TESTS="gdb.base/align-c.exp" there exist some failed testcases: ... FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_float) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_double) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_long_double) ... According to LoongArch ELF ABI specification [1], set the target data types of floating-point to fix the above failed testcases. [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>	4 years ago
GDB Administrator	bf573a0cc6	Automatic date update in version.in	4 years ago
Andrew Burgess	740b42ceb7	gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>	6 years ago
Andrew Burgess	a5118a18db	gdb/gdbarch: compare some fields against 0 verify_gdbarch After the previous commit, which removes the predicate function gdbarch_register_type_p, I noticed that the gdbarch->register_type field was not checked at in the verify_gdbarch function. More than not being checked, the field wasn't mentioned at all. I find this strange, I would expect that every field would at least be mentioned - we already generate comments for some fields saying that this field is _not_ being checked, so the fact that this field isn't being checked looks (to me), like this field is somehow slipping through the cracks. The comment at the top of gdbarch-components.py tries to explain how the validation is done. I didn't understand this comment completely, but, I think this final sentence: "Otherwise, the check is done against 0 (really NULL for function pointers, but same idea)." Means that, if non of the other cases apply, then the field should be checked against 0, with 0 indicating that the field is invalid (was not set by the tdep code). However, this is clearly not being done. Looking in gdbarch.py at the code to generate verify_gdbarch we do find that there is a case that is not handled, the case where the 'invalid' field is set true True, but non of the other cases apply. In this commit I propose two changes: 1. Handle the case where the 'invalid' field of a property is set to True, this should perform a check for the field of gdbarch still being set to 0, and 2. If the if/else series that generates verify_gdbarch doesn't handle a property then we should raise an exception. This means that if a property is added which isn't handled, we should no longer silently ignore it. After doing this, I re-generated the gdbarch files and saw that the following gdbarch fields now had new validation checks: register_type believe_pcc_promotion register_to_value value_to_register frame_red_zone_size displaced_step_restore_all_in_ptid solib_symbols_extension Looking at how these are currently set in the various -tdep.c files, I believe the only one of these that is required to be set for all architectures is the register_type field. And so, for all of the other fields, I've changed the property definition on gdbarch-components.py, setting the 'invalid' field to False. Now, after re-generation, the register_type field is checked against 0, thus an architecture that doesn't set_gdbarch_register_type will now fail during validation. For all the other fields we skip the validation, in which case, it is find for an architecture to not set this field. My expectation is that there should be no user visible changes after this commit. Certainly for all fields except register_type, all I've really done is cause some extra comments to be generated, so I think that's clearly fine. For the register_type field, my claim is that any architecture that didn't provide this would fail when creating its register cache, and I couldn't spot an architecture that doesn't provide this hook. As such, I think this change should be fine too.	4 years ago
Andrew Burgess	23bade95de	gdb/gdbarch: remove the predicate function for gdbarch_register_type I don't believe that the gdbarch_register_type_p predicate is called anywhere in GDB, and the gdbarch_register_type function is called without checking the gdbarch_register_type_p predicate function everywhere it is used, for example in init_regcache_descr (regcache.c). My claim is that the gdbarch_register_type function is required for every architecture, and GDB will not work if this function is not supplied. And so, in this commit, I remove the 'predicate=True' from gdbarch-components.py for the 'register_type' field, and regenerate the gdbarch files. There should be no user visible changes after this commit.	4 years ago
Patrick Monnerat	fb85cece22	Replace deprecated_target_wait_hook by observers Commit `b60cea7` (Make target_wait options use enum flags) broke deprecated_target_wait_hook usage: there's a commit comment telling this hook has not been converted. Rather than trying to mend it, this patch replaces the hook by two target_wait observers: target_pre_wait (ptid_t ptid) target_post_wait (ptid_t event_ptid) Upon target_wait entry, target_pre_wait is notified with the ptid passed to target_wait. Upon exit, target_post_wait is notified with the event ptid returned by target_wait. Should an exception occur, event_ptid is null_ptid. This change benefits to Insight (out-of-tree): there's no real use of the late hook in gdb itself.	4 years ago
Tom Tromey	79a0742380	Correctly print subrange types in generic_value_print I noticed that generic_value_print assumes that a subrange type is always a subrange of an integer type. However, this isn't necessarily the case. In Ada, for example, one has subranges of character and enumeration types. This code isn't often exercised, I think, because languages with real subrange types tend to implement their own printers. However, it still seemed worth fixing.	4 years ago
Luis Machado	bab22d0640	[aarch64/arm] Properly extract the return value returned in memory When running gdb.cp/non-trivial-retval.exp, the following shows up for both aarch64-linux and armhf-linux: Breakpoint 3, f1 (i1=23, i2=100) at src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:35 35 A a; (gdb) finish Run till exit from #0 f1 (i1=23, i2=100) at src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:35 main () at /src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:163 163 B b = f2 (i1, i2); Value returned is $6 = {a = -11952} (gdb) The return value should be {a = 123} instead. This happens because the backends don't extract the return value from the correct location. GDB should fetch a pointer to the memory location from X8 for aarch64 and r0 for armhf. With the patch, gdb.cp/non-trivial-retval.exp has full passes on aarch64-linux and armhf-linux on Ubuntu 20.04/18.04. The problem only shows up with the "finish" command. The "call" command works correctly and displays the correct return value. This is also related to PR gdb/28681 (https://sourceware.org/bugzilla/show_bug.cgi?id=28681) and fixes FAIL's in gdb.ada/mi_var_array.exp. A new testcase is provided, and it exercises GDB's ability to "finish" a function that returns a large struct (> 16 bytes) and display the contents of this struct correctly. This has always been incorrect for these backends, but no testcase exercised this particular scenario.	5 years ago
GDB Administrator	d4661bf0e9	Automatic date update in version.in	4 years ago
Alan Modra	b508e46bf9	PR28959, obdump doesn't disassemble mftb instruction Without a -M cpu option given, powerpc objdump defaults currently to -Mpower10 but -Many is also given. Commit `1ff6a3b8e5` regressed -Many disassembly of instructions that are encoded differently depending on cpu, such as mftb which has pre- and post-power4 encodings. PR 28959 * ppc-dis.c (lookup_powerpc): Revert 2021-05-28 change. Instead only look at deprecated PPC_OPCODE_RAW bit when -Many.	4 years ago
GDB Administrator	4f4a30bee6	Automatic date update in version.in	4 years ago
Tom Tromey	4775334c6f	Relax regexp in gdb.rust/unsized.exp With nightly rustc, gdb.rust/unsized.exp fails: (gdb) ptype us Structure has no component named operator. rustc changed to emit a bit more debug info for unsized types. Because the original test is just to make sure that ptype of an unsized array looks right, this patch relaxes the regexp and changes the expression. I think this keeps the original test meaning, but also works with nightly. I also tested stable and 1.48.	4 years ago
GDB Administrator	9fb67c2345	Automatic date update in version.in	4 years ago
Tom Tromey	c0e0d6bcfe	Avoid crash with cross-linux core file An internal test case creates a core file using gcore, then restarts gdb with that core. When run with a cross-linux gdb (in this case, x86-64 host with ppc64-linux target), the test fails: \| (gdb) core core \| [New LWP 18437] \| warning: `/lib64/libc.so.6': Shared library architecture unknown is not compatible with target architecture powerpc:common64. \| warning: Could not load shared library symbols for /lib64/ld64.so.1. \| Do you need "set solib-search-path" or "set sysroot"? \| ../../src/gdb/gdbarch.c:3388: internal-error: int gdbarch_elf_make_msymbol_special_p(gdbarch*): Assertion `gdbarch != NULL' failed. \| A problem internal to GDB has been detected, \| further debugging may prove unreliable. \| Quit this debugging session? (y or n) y What's happening here is that the core file lists some shared libraries. These aren't available via the solib search path, and so gdb finds the local (x86-64) libraries. This is not ideal, but on the other hand, it is what was asked for -- while the test does set solib-search-path, it does not set the sysroot. But, because gdb isn't configured to handle these libraries, it crashes. It seems to me that it's better to avoid the crash by having solib_bfd_open fail in the case where a library is incompatible. That is what this patch does. Now it looks like: \| [New LWP 15488] \| Error while mapping shared library sections: \| `/lib64/libc.so.6': Shared library architecture unknown is not compatible with target architecture powerpc:common64. ... and does not crash gdb. I don't have a good setup for testing this using dejagnu, so I don't know whether an existing gdb test covers this scenario.	5 years ago
Andrew Burgess	8bdc7ff421	gdb/testsuite: remove duplicates from gdb.base/stap-probe.exp Remove the duplicate test names from gdb.base/stap-probe.exp, this is done by actually passing a unique test name in a couple of places (rather than using the command as the test name), and in another couple of places, a test has a duplicate name due to a cut & paste error, which I've fixed. There's no change in what is actually being tested after this commit.	4 years ago
Vladimir Mezentsev	bb368aad29	gprofng: a new GNU profiler top-level * Makefile.def: Add gprofng module. * configure.ac: Add --enable-gprofng option. * src-release.sh: Add gprofng. * Makefile.in: Regenerate. * configure: Regenerate. * gprofng: New directory. binutils * MAINTAINERS: Add gprofng maintainer. * README-how-to-make-a-release: Add gprofng. include. * collectorAPI.h: New file. * libcollector.h: New file. * libfcollector.h: New file.	4 years ago
GDB Administrator	a655f19af9	Automatic date update in version.in	4 years ago
Aaron Merey	e15454475f	gdb/auto-load: Remove repeating "auto-load" from debug message Remove "auto-load:" from a format string passed to auto_load_debug_printf. It is unnecessary since this function will prefix the string with "[auto-load]" when printing it.	4 years ago
Tom Tromey	56262a931b	Change how "print/x" displays floating-point value Currently, "print/x" will display a floating-point value by first casting it to an integer type. This yields weird results like: (gdb) print/x 1.5 $1 = 0x1 This has confused users multiple times -- see PR gdb/16242, where there are several dups. I've also seen some confusion from this internally at AdaCore. The manual says: 'x' Regard the bits of the value as an integer, and print the integer in hexadecimal. ... which seems more useful. So, perhaps what happened is that this was incorrectly implemented (or maybe correctly implemented and then regressed, as there don't seem to be any tests). This patch fixes the bug. There was a previous discussion where we agreed to preserve the old behavior: https://sourceware.org/legacy-ml/gdb-patches/2017-06/msg00314.html However, I think it makes more sense to follow the manual. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16242	5 years ago
Tom Tromey	fdda16e1fa	Simplify the ui-out progress API I noticed that 'progress' is a method on ui-out, but it seems to me that it would be better if the only API were via the progress_meter class. This patch makes this change, changing progress to be a method on the meter itself.	5 years ago
Andrew Burgess	00e5d9e9da	gdb/gdbarch: fix typo in gdbarch-components.py Fixes a minor typo, in a comment, in the gdbarch-components.py script. There should be no user visible changes after this commit.	4 years ago
Lancelot SIX	c6479f8b2a	Process exit status is leader exit status testcase This adds a multi-threaded testcase that has all threads in the process exit with a different exit code, and ensures that GDB reports the thread group leader's exit status as the whole-process exit status. Before this set of patches, this would randomly report the exit code of some other thread, and thus fail. Tested on Linux-x86_64, native and gdbserver. Co-Authored-By: Pedro Alves <pedro@palves.net> Change-Id: I30cba2ff4576fb01b5169cc72667f3268d919557	5 years ago
Pedro Alves	8a841a3579	Re-add zombie leader on exit, gdbserver/linux Same as the previous patch, but for GDBserver. In summary, the current zombie leader detection code in linux-low.cc has a race -- if a multi-threaded inferior exits just before check_zombie_leaders finds that the leader is now zombie via checking /proc/PID/status, check_zombie_leaders deletes the leader, assuming we won't get an event for that exit (which we won't in some scenarios, but not in this one), which is a false-positive scenario, where the whole process is simply exiting. Later when we see the last LWP in our list exit, we report that LWP's exit status as exit code, even though for the (real) parent process, the exit code that counts is the child's leader thread's exit code. Like for GDB, the solution here is to: - only report whole-process exit events for the leader. - re-add the leader back to the LWP list when we finally see it exit. Change-Id: Id2d7bbb51a415534e1294fff1d555b7ecaa87f1d	5 years ago
Pedro Alves	6cf20c46e3	Re-add zombie leader on exit, gdb/linux The current zombie leader detection code in linux-nat.c has a race -- if a multi-threaded inferior exits just before check_zombie_leaders finds that the leader is now zombie via checking /proc/PID/status, check_zombie_leaders deletes the leader, assuming we won't get an event for that exit (which we won't in some scenarios, but not in this one). That might seem mostly harmless, but it has some downsides: - later when we continue pulling events out of the kernel, we will collect the exit event of the non-leader threads, and once we see the last lwp in our list exit, we return _that_ lwp's exit code as whole-process exit code to infrun, instead of the leader's exit code. - this can cause a hang in stop_all_threads in infrun.c. Say there are 2 threads in the process. stop_all_threads stops each of those threads, and then waits for two stop or exit events, one for each thread. If the whole process exits, and check_zombie_leaders hits the false-positive case, linux-nat.c will only return one event to GDB (the whole-process exit returned when we see the last thread, the non-leader thread, exit), making stop_all_threads hang forever waiting for a second event that will never come. However, in this false-positive scenario, where the whole process is exiting, as opposed to just the leader (with pthread_exit(), for example), we _will_ get an exit event shortly for the leader, after we collect the exit event of all the other non-leader threads. Or put another way, we _always_ get an event for the leader after we see it become zombie. I tried a number of approaches to fix this: #1 - My first thought to address the race was to make GDB always report the whole-process exit status for the leader thread, not for whatever is the last lwp in the list. We _always_ get a final exit (or exec) event for the leader, and when the race triggers, we're not collecting it. #2 - My second thought was to try to plug the race in the first place. I thought of making GDB call waitpid/WNOHANG for all non-leader threads immediately when the zombie leader is detected, assuming there would be an exit event pending for each of them waiting to be collected. Turns out that that doesn't work -- you can see the leader become zombie _before_ the kernel kills all other threads. Waitpid in that small time window returns 0, indicating no-event. Thankfully we hit that race window all the time, which avoided trading one race for another. Looking at the non-leader thread's status in /proc doesn't help either, the threads are still in running state for a bit, for the same reason. #3 - My next attempt, which seemed promising, was to synchronously stop and wait for the stop for each of the non-leader threads. For the scenario in question, this will collect all the exit statuses of the non-leader threads. Then, if we are left with only the zombie leader in the lwp list, it means we either have a normal while-process exit or an exec, in which case we should not delete the leader. If _only_ the leader exited, like in gdb.threads/leader-exit.exp, then after pausing threads, we will still have at least one live non-leader thread in the list, and so we delete the leader lwp. I got this working and polished, and it was only after staring at the kernel code to convince myself that this would really work (and it would, for the scenario I considered), that I realized I had failed to account for one scenario -- if any non-leader thread is _already_ stopped when some thread triggers a group exit, like e.g., if you have some threads stopped and then resume just one thread with scheduler-locking or non-stop, and that thread exits the process. I also played with PTRACE_EVENT_EXIT, see if it would help in any way to plug the race, and I couldn't find a way that it would result in any practical difference compared to looking at /proc/PID/status, with respect to having a race. So I concluded that there's no way to plug the race, we just have to deal with it. Which means, going back to approach #1. That is the approach taken by this patch. Change-Id: I6309fd4727da8c67951f9cea557724b77e8ee979	5 years ago
Pedro Alves	aa40a989ef	gdbserver: Reindent check_zombie_leaders This fixes the indentation of linux_process_target::check_zombie_leaders, which will help with keeping its comments in sync with the gdb/linux-nat.c counterpart. Change-Id: I37332343bd80423d934249e3de2d04feefad1891	5 years ago
Pedro Alves	5406bc3f1b	gdbserver: Reorganize linux_process_target::filter_event Reorganize linux-low.cc:linux_process_target::filter_event such that all the handling for events for LWPs not in the LWP list is together. This helps make a following patch clearer. The comments and debug messages have also been tweaked to have them synchronized with the GDB counterpart. Change-Id: If9019635f63a846607cfda44b454b4254a404019	5 years ago
Pedro Alves	1abeb1e90d	gdb: Reorganize linux_nat_filter_event Reorganize linux-nat.c:linux_nat_filter_event such that all the handling for events for LWPs not in the LWP list is together. This helps make a following patch clearer. The comments and debug messages have also been tweaked - the end goal is to have them synchronized with the gdbserver counterpart. Change-Id: I8586d8dcd76d8bd3795145e3056fc660e3b2cd22	5 years ago
Pedro Alves	b7b1008c0b	Fix gdb.threads/current-lwp-dead.exp race If we make GDB report the process EXIT event for the leader thread, as will be done in a latter patch of this series, then gdb.threads/current-lwp-dead.exp starts failing: (gdb) break fn_return Breakpoint 2 at 0x5555555551b5: file /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/current-lwp-dead.c, line 45. (gdb) continue Continuing. [New LWP 2138466] [Inferior 1 (process 2138459) exited normally] (gdb) FAIL: gdb.threads/current-lwp-dead.exp: continue to breakpoint: fn_return (the program exited) The inferior exit reported is actually correct. The main thread has indeed exited, and that's the thread that has the right exit code to report to the user, as that's the exit code that is reported to the program's parent. In this case, GDB managed to collect the exit code for the leader thread before reaping the other thread, because in reality, the testcase isn't creating standard threads, it is using raw clone, and the new clones are put in their own thread group. Fix it by making the main "thread" not exit until the scenario we're exercising plays out. Also, run the program to completion for completeness. The original program really wanted the leader thread to exit before the fn_return function was reached -- it was important that the current thread as pointed by inferior_ptid was gone when infrun got the breakpoint event. I've tweaked the testcase to ensure that that condition is still held, though it is no longer the main thread that exits. This required a bit of synchronization between the threads, which required using CLONE_VM unconditionally. The #ifdef guards were added as a fix for https://sourceware.org/bugzilla/show_bug.cgi?id=11214, though I don't think they were necessary because the program is not using TLS. If it turns out they were necessary, we can link the testcase with "-z now" instead, which was mentioned as an alternative workaround in that Bugzilla. Change-Id: I7be2f0da4c2fe8f80a60bdde5e6c623d8bd5a0aa	5 years ago
Pedro Alves	cdff184f42	Fix gdb.threads/clone-new-thread-event.exp race If we make GDB report the process EXIT event for the leader thread, instead of whatever is the last thread in the LWP list, as will be done in a latter patch of this series, then gdb.threads/current-lwp-dead.exp starts failing: (gdb) FAIL: gdb.threads/clone-new-thread-event.exp: catch SIGUSR1 (the program exited) This is a testcase race -- the main thread does not wait for the spawned clone "thread" to finish before exiting, so the main program may exit before the second thread is scheduled and reports its SIGUSR1. With the change to make GDB report the EXIT for the leader, the race is 100% reproducible by adding a sleep(), like so: --- c/gdb/testsuite/gdb.threads/clone-new-thread-event.c +++ w/gdb/testsuite/gdb.threads/clone-new-thread-event.c @@ -51,6 +51,7 @@ local_gettid (void) static int fn (void *unused) { + sleep (1); tkill (local_gettid (), SIGUSR1); return 0; } Resulting in: Breakpoint 1, main (argc=1, argv=0x7fffffffd418) at gdb.threads/clone-new-thread-event.c:65 65 stack = malloc (STACK_SIZE); (gdb) continue Continuing. [New LWP 3715562] [Inferior 1 (process 3715555) exited normally] (gdb) FAIL: gdb.threads/clone-new-thread-event.exp: catch SIGUSR1 (the program exited) That inferior exit reported is actually correct. The main thread has indeed exited, and that's the thread that has the right exit code to report to the user, as that's the exit code that is reported to the program's parent. In this case, GDB managed to collect the exit code for the leader thread before reaping the other thread, because in reality, the testcase isn't creating standard threads, it is using raw clone, and the new clones are put in their own thread group. Fix it by making the main thread wait for the child to exit. Also, run the program to completion for completeness. Change-Id: I315cd3dc2b9e860395dcab9658341ea868d7a6bf	5 years ago
Pedro Alves	e48359eaa8	Fix gdbserver/linux target_waitstatus logging assert Turning on debug output in gdbserver leads to an assertion failure if gdbserver reports a non-signal event: [threads] wait_1: LWP 3273770: extended event with waitstatus status->kind = EXECD, execd_pathname = gdb.threads/non-ldr-exc-1/non-ldr-exc-1 [threads] wait_1: Hit a non-gdbserver trap event. ../../src/gdbserver/../gdb/target/waitstatus.h:365: A problem internal to GDBserver has been detected. sig: Assertion `m_kind == TARGET_WAITKIND_STOPPED \|\| m_kind == TARGET_WAITKIND_SIGNALLED' failed. Fix it in the obvious way, using target_waitstatus::to_string(), resulting in, for example: [threads] wait_1: ret = LWP 1542412.1542412, status->kind = STOPPED, sig = GDB_SIGNAL_TRAP Change-Id: Ia4832f9b4fa39f4af67fcaf21fd4d909a285a645	5 years ago
Nick Clifton	bed566bbf6	Add option to objdump/readelf to disable access to debuginfod servers. * dwarf.c (use_debuginfod): New variable. Set to 1. (load_separate_debug_info): Only call debuginfod_fetch_separate_debug_info is use_debuginfod is true. (dwarf_select_sections_by_names): Add do-not-use-debuginfod and use-debuginfod options. (dwarf_select_sections_by_letters): Add D and E options. * dwarf.h (use_debuginfod): New extern. * objdump.c (usage): Mention the new options. * readelf.c (usage): Likewise. * doc/binutils.texi: Document the new options. * doc/debug-options.texi: Describe the new options. * NEWS: Mention the new feature. * testsuite/binutils-all/debuginfod.exp: Add tests of the new options.	4 years ago
Alan Modra	d7c448293a	Re: ld: Add a before_plugin_all_symbols_read hook * testsuite/ld-plugin/pr28849.d: Adjust for powerpc64 function descriptors.	4 years ago
H.J. Lu	320fdefef1	ld: Add a before_plugin_all_symbols_read hook Add a before_plugin_all_symbols_read hook to load symbol references from DT_NEEDED entries, included from --copy-dt-needed-entries, before reading plugin symbols to properly resolve plugin symbol references. bfd/ PR ld/28849 * elf-bfd.h (elf_link_hash_table): Add handling_dt_needed. * elflink.c (_bfd_elf_merge_symbol): Don't set non_ir_ref_dynamic before plugin 'all symbols read' hook is called. ld/ PR ld/28849 * ldelf.c (ldelf_handle_dt_needed): New function. (ldelf_before_plugin_all_symbols_read): Likewise. (ldelf_after_open): Call ldelf_handle_dt_needed. * ldelf.h (ldelf_before_plugin_all_symbols_read): New. * ldemul.c (ldemul_before_plugin_all_symbols_read): Likewise. * ldemul.h (ldemul_before_plugin_all_symbols_read): Likewise. (ld_emulation_xfer_struct): Add before_plugin_all_symbols_read. * ldlang.c (lang_process): Call ldemul_before_plugin_all_symbols_read before calling plugin_call_all_symbols_read. * emultempl/elf.em (gld${EMULATION_NAME}_before_plugin_all_symbols_read): New. (LDEMUL_BEFORE_PLUGIN_ALL_SYMBOLS_READ): New. * emultempl/emulation.em (ld_${EMULATION_NAME}_emulation): Initialize the before_plugin_all_symbols_read field. * testsuite/ld-plugin/lto.exp: Run PR ld/28849 tests. * testsuite/ld-plugin/pr28849.d: New file. * testsuite/ld-plugin/pr28849a.c: Likewise. * testsuite/ld-plugin/pr28849b.c: Likewise.	5 years ago
GDB Administrator	399f9ba236	Automatic date update in version.in	4 years ago
Hans-Peter Nilsson	7dc7323c0b	toplevel: Makefile.def: Make configure-sim depend on all-readline Without this, a "make all-sim" without the equivalent of libreadline-dev installed on the build system, won't properly pick up the in-tree readline build, and you'll see: mkdir -p -- ./sim Configuring in ./sim configure: creating cache ./config.cache checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... cris-axis-elf checking for x86_64-pc-linux-gnu-gcc... gcc checking whether the C compiler works... yes ... checking for library containing tgetent... -ltermcap checking for readline in -lreadline... no configure: error: the required "readline" library is missing make[1]: *** [Makefile:11188: configure-sim] Error 1 make[1]: Leaving directory '/home/hp/sim/b' The sim dependency on readline is apparently (nominally) valid as there's a readline call in sim/erc32/sis.c. 2022-02-21 Hans-Peter Nilsson <hp@axis.com> * Makefile.def (dependencies): Make configure-sim depend on all-readline.	4 years ago

1 2 3 4 5 ...

109259 Commits (978602e83f038106c8254424ca83991d784b37cf) All Branches Search

109259 Commits (978602e83f038106c8254424ca83991d784b37cf)

All Branches