aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-12-16Automatic date update in version.inGDB Administrator1-1/+1
2022-12-15libsframe asan: avoid generating misaligned loadsIndu Bhagat4-24/+42
There are two places where unaligned loads were seen on aarch64: - #1. access to the SFrame FRE stack offsets in the in-memory representation/abstraction provided by libsframe. - #2. access to the SFrame FRE start address in the on-disk representation of the frame row entry. For #1, we can fix this by reordering the struct members of sframe_frame_row_entry in libsframe/sframe-api.h. For #2, we need to default to using memcpy instead, and copy out the bytes to a location for output. SFrame format is an unaligned on-disk format. As such, there are other blobs of memory in the on-disk SFrame FRE that are on not on their natural boundaries. But that does not pose further problems yet, because the users are provided access to the on-disk SFrame FRE data via libsframe's sframe_frame_row_entry, the latter has its' struct members aligned on their respective natural boundaries (and initialized using memcpy). PR 29856 libsframe asan: load misaligned at sframe.c:516 ChangeLog: PR libsframe/29856 * bfd/elf64-x86-64.c: Adjust as the struct members have been reordered. * libsframe/sframe.c (sframe_decode_fre_start_address): Use memcpy to perform 16-bit/32-bit reads. * libsframe/testsuite/libsframe.encode/encode-1.c: Adjust as the struct members have been reordered. include/ChangeLog: PR libsframe/29856 * sframe-api.h: Reorder fre_offsets for natural alignment.
2022-12-15gdb/testsuite: don't delete command files in gdb.base/commands.expSimon Marchi1-10/+4
Don't delete the runtime-generated command files. This makes it easier to reproduce tests by hand. Change-Id: I4e53484eea216512f1c5d7dfcb5c464b36950946 Approved-By: Tom Tromey <tom@tromey.com>
2022-12-15Move streq and compare_cstrings to gdbsupportTom Tromey3-20/+16
It seems to me that streq and compare_cstrings belong near the other string utility functions in common-utils.h; and furthermore that streq ought to be inlined. This patch makes this change. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-12-15Remove subset_compareTom Tromey4-27/+5
I stumbled across subset_compare today, and after looking at the callers I realized it could be removed and replaced with calls to startswith. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-12-15gdb: use gdb_assert not internal_errorAndrew Burgess1-8/+2
Spotted a couple of places in findvar.c where we use: if ( ! CONDITION ) internal_error ("..."); this commit changes these to be: gdb_assert ( CONDITION ); which I think is better. Unless we happen to hit the internal_error calls (which was bad) there should be no user visible changes after this commit.
2022-12-15gdb: some int to bool conversion in remote-sim.cAndrew Burgess1-10/+10
Some obvious int to bool conversion in remote-sim.c, there should be no user visible changes after this commit.
2022-12-15gdb: make more use of make_target_connection_stringAndrew Burgess2-28/+11
I noticed that we have a function make_target_connection_string which wraps all the logic for creating a string that describes a target connection - but in some places we are not calling this function, instead we duplicate the function's logic. This commit cleans this up, and calls make_target_connection_string where possible. There should be no user visible changes after this commit.
2022-12-15gdb: int to bool conversion in tracefile.cAndrew Burgess1-3/+3
Some obvious int to bool conversion in tracefile.c. Should be no user visible changes after this commit.
2022-12-15[gdb/testsuite] Fix gdb.base/condbreak-multi-context.exp with gcc 4.8.5Tom de Vries1-3/+3
With gcc 4.8.5, I run into: ... Running gdb.base/condbreak-multi-context.exp ... gdb compile failed, condbreak-multi-context.cc:21:11: warning: non-static \ data member initializers only available with -std=c++11 or -std=gnu++11 \ [enabled by default] int b = 20; ^ ... Fix this by making it a static const. Tested on x86_64-linux, with gcc 4.8.5, 7.5.0 and clang 13.0.1.
2022-12-15Automatic date update in version.inGDB Administrator1-1/+1
2022-12-14gdb/maint: add core file name to 'maint info program-spaces' outputAndrew Burgess3-4/+26
Each program space can have an associated core file. Include this information in the output of 'maint info program-spaces'.
2022-12-14gdb: ensure all targets are popped before an inferior is destructedAndrew Burgess1-0/+15
Now that the inferiors target_stack automatically manages target reference counts, we might think that we don't need to unpush targets when an inferior is deleted... ...unfortunately that is not the case. The inferior::unpush function can do some work depending on the type of target, so it is important that we still pass through this function. To ensure that this is the case, in this commit I've added an assert to inferior::~inferior that ensures the inferior's target_stack is empty (except for the ever present dummy_target). I've then added a pop_all_targets call to delete_inferior, otherwise the new assert will fire in, e.g. the gdb.python/py-inferior.exp test.
2022-12-14gdb: remove the pop_all_targets (and friends) global functionsAndrew Burgess8-56/+67
This commit removes the global functions pop_all_targets, pop_all_targets_above, and pop_all_targets_at_and_above, and makes them methods on the inferior class. As the pop_all_targets functions will unpush each target, which decrements the targets reference count, it is possible that the target might be closed. Right now, closing a target, in some cases, depends on the current inferior being set correctly, that is, to the inferior from which the target was popped. To facilitate this I have used switch_to_inferior_no_thread within the new methods. Previously it was the responsibility of the caller to ensure that the correct inferior was selected. In a couple of places (event-top.c and top.c) I have been able to remove a previous switch_to_inferior_no_thread call. In remote_unpush_target (remote.c) I have left the switch_to_inferior_no_thread call as it is required for the generic_mourn_inferior call.
2022-12-14gdb: remove decref_targetAndrew Burgess2-8/+4
The decref_target function is not really needed. Calling target_ops::decref will just redirect to decref_target anyway, so why not just rename decref_target to target_ops::decref? That's what this commit does. It's not exactly renaming to target_ops::decref, because the decref functionality is handled by a policy class, so the new name is now target_ops_ref_policy::decref. There should be no user visible change after this commit.
2022-12-14gdb: have target_stack automate reference count handlingAndrew Burgess3-21/+118
This commit changes the target_stack class from using a C style array of 'target_ops *' to using a C++ std::array<target_ops_ref, ...>. The benefit of this change is that some of the reference counting of target_ops objects is now done automatically. This commit fixes a crash in gdb.python/py-inferior.exp where GDB crashes at exit, leaving a core file behind. The crash occurs in connpy_connection_dealloc, and is actually triggered by this assert: gdb_assert (conn_obj->target == nullptr); Now a little aside... ... the assert is never actually printed, instead GDB crashes due to calling a pure virtual function. The backtrace at the point of crash looks like this: #7 0x00007fef7e2cf747 in std::terminate() () from /lib64/libstdc++.so.6 #8 0x00007fef7e2d0515 in __cxa_pure_virtual () from /lib64/libstdc++.so.6 #9 0x0000000000de334d in target_stack::find_beneath (this=0x4934d78, t=0x2bda270 <the_dummy_target>) at ../../s> #10 0x0000000000df4380 in inferior::find_target_beneath (this=0x4934b50, t=0x2bda270 <the_dummy_target>) at ../.> #11 0x0000000000de2381 in target_ops::beneath (this=0x2bda270 <the_dummy_target>) at ../../src/gdb/target.c:3047 #12 0x0000000000de68aa in target_ops::supports_terminal_ours (this=0x2bda270 <the_dummy_target>) at ../../src/gd> #13 0x0000000000dde6b9 in target_supports_terminal_ours () at ../../src/gdb/target.c:1112 #14 0x0000000000ee55f1 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_li> Notice in frame #12 we called target_ops::supports_terminal_ours, however, this is the_dummy_target, which is of type dummy_target, and so we should have called dummy_target::supports_terminal_ours. I believe the reason we ended up in the wrong implementation of supports_terminal_ours (which is a virtual function) is because we made the call during GDB's shut-down, and, I suspect, the vtables were in a weird state. Anyway, the point of this patch is not to fix GDB's ability to print an assert during exit, but to address the root cause of the assert. With that aside out of the way, we can return to the main story... Connections are represented in Python with gdb.TargetConnection objects (or its sub-classes). The assert in question confirms that when a gdb.TargetConnection is deallocated, the underlying GDB connection has itself been removed from GDB. If this is not true then we risk creating multiple different gdb.TargetConnection objects for the same connection, which would be bad. To ensure that we have one gdb.TargetConnection object for each connection, the all_connection_objects map exists, this maps the process_stratum_target object (the connection) to the gdb.TargetConnection object that represents the connection. When a connection is removed in GDB the connection_removed observer fires, which we catch with connpy_connection_removed, this function then sets conn_obj->target to nullptr, and removes the corresponding entry from the all_connection_objects map. The first issue here is that connpy_connection_dealloc is being called as part of GDB's exit code, which is run after the Python interpreter has been shut down. The connpy_connection_dealloc function is used to deallocate the gdb.TargetConnection Python object. Surely it is wrong for us to be deallocating Python objects after the interpreter has been shut down. The reason why connpy_connection_dealloc is called during GDB's exit is that the global all_connection_objects map is still holding a reference to the gdb.TargetConnection object. When the map is destroyed during GDB's exit, the gdb.TargetConnection objects within the map can finally be deallocated. The reason why all_connection_objects has contents when GDB exits, and the reason the assert fires, is that, when GDB exits, there are still some connections that have not yet been removed from GDB, that is, they have a non-zero reference count. If we take a look at quit_force (top.c) you can see that, for each inferior, we call pop_all_targets before we (later in the function) call do_final_cleanups. It is the do_final_cleanups call that is responsible for shutting down the Python interpreter. The pop_all_targets calls should, in theory, cause all the connections to be removed from GDB. That this isn't working indicates that some targets have a non-zero reference count even after this final pop_all_targets call, and indeed, when I debug GDB, that is what I see. I tracked the problem down to delete_inferior where we do some house keeping, and then delete the inferior object, which calls inferior::~inferior. In neither delete_inferior or inferior::~inferior do we call pop_all_targets, and it is this missing call that means we leak some references to the target_ops objects on the inferior's target_stack. In this commit I will provide a partial fix for the problem. I say partial fix, but this will actually be enough to resolve the crash. In a later commit I will provide the final part of the fix. As mentioned at the start of the commit message, this commit changes the m_stack in target_stack to hold target_ops_ref objects. This means that when inferior::~inferior is called, and m_stack is released, we automatically decrement the target_ops reference count. With this change in place we no longer leak any references, and now, in quit_force the final pop_all_targets calls will release the final references. This means that the targets will be correctly closed at this point, which means the connections will be removed from GDB and the Python objects deallocated before the Python interpreter shuts down. There's a slight oddity in target_stack::unpush, where we std::move the reference out of m_stack like this: auto ref = std::move (m_stack[stratum]); the `ref' isn't used explicitly, but it serves to hold the target_ops_ref until the end of the scope while allowing the m_stack entry to be reset back to nullptr. The alternative would be to directly set the m_stack entry to nullptr, like this: m_stack[stratum] = nullptr; The problem here is that when we set the m_stack entry to nullptr we first decrement the target_ops reference count, and then set the array entry to nullptr. If the decrement means that the target_ops object reaches a zero reference count then the target_ops object will be closed by calling target_close. In target_close we ensure that the target being closed is not in any inferiors target_stack. As we decrement before clearing, then this check in target_close will fail, and an assert will trigger. By using std::move to move the reference out of m_stack, this clears the m_stack entry, meaning the inferior no longer contains the target_ops in its target_stack. Now when the REF object goes out of scope and the reference count is decremented, target_close can run successfully. I've made use of the Python connection_removed listener API to add a test for this issue. The test installs a listener and then causes delete_inferior to be called, we can then see that the connection is then correctly removed (because the listener triggers).
2022-12-14gdb/remote: remove some manual reference count handlingAndrew Burgess1-16/+22
While working on some other target_ops reference count related code, I spotted that in remote.c we do some manual reference count handling, i.e. we call target_ops::incref and decref_target (which wraps target_ops::decref). I think it would be better to make use of gdb::ref_ptr to automate the reference count management. So, this commit updates scoped_mark_target_starting in two ways, first, I use gdb::ref_ptr to handle the reference counts. Then, instead of using the scoped_mark_target_starting constructor and destructor to set and reset the starting_up flag, I now use a scoped_restore_tmpl object to set and restore the flag. The above changes mean that the scoped_mark_target_starting destructor can be completely removed, and the constructor body is now empty. I've also fixed a typo in the class comment. The only change in behaviour after this commit is that previously we didn't care what the value of starting_up was, we just set it to true in the constructor and false in the destructor. Now, I assert that the flag is initially false, then set the flag true when the scoped_mark_target_starting is created. As the starting_up flag is initialized to false then, for the assert to fire, we would need to recursively enter remote_target::start_remote_1, which I don't think is something we should be doing, so I think the new assert is an improvement.
2022-12-15Re: ld, gold: remove support for -z bndplt (MPX prefix)Alan Modra8-348/+44
Don't attempt to run gold tests with -z bndplt * testsuite/Makefile.am (exception_x86_64_bnd_test, bnd_plt_1.sh), (bnd_ifunc_1.sh, bnd_ifunc_2.sh): Delete rules. * testsuite/Makefile.in: Regenerate. * testsuite/bnd_ifunc_1.s: Delete. * testsuite/bnd_ifunc_1.sh: Delete. * testsuite/bnd_ifunc_2.s: Delete. * testsuite/bnd_ifunc_2.sh: Delete. * testsuite/bnd_plt_1.s: Delete. * testsuite/bnd_plt_1.sh: Delete.
2022-12-14asan: buffer overflow in sh_relocAlan Modra1-1/+2
* coff-sh.c (sh_reloc): Use bfd_reloc_offset_in_range.
2022-12-14Fix haiku ld dependenciesAlan Modra5-8/+8
I noticed after commit 8ad93045ed, "ld, gold: remove support for -z bndplt (MPX prefix)", that some of my builds were failing with eelf_x86_64_haiku.c:650:9: error: no member named 'bndplt' in 'struct elf_linker_x86_params' params.bndplt = true; ~~~~~~ ^ * emulparams/aarch64haiku.sh: Use "source_sh" rather than ".". * emulparams/armelf_haiku.sh: Likewise. * emulparams/elf32ppchaiku.sh: Likewise. * emulparams/elf_mipsel_haiku.sh: Likewise. * emulparams/elf_x86_64_haiku.sh: Likewise.
2022-12-14gdb: add SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXITAndrew Burgess3-23/+102
After the previous commit converted symbol-lookup debug to use the new debug scheme, this commit adds SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT. The previous commit didn't add SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT because symbol-lookup debug is controlled by an 'unsigned int' rather than a 'bool' control variable, we use the numeric value to offer different levels of verbosity for symbol-lookup debug. The *_SCOPED_DEBUG_ENTER_EXIT mechanism currently relies on capturing a reference to the bool control variable, and evaluating the variable both on entry, and at exit, this is done in the scoped_debug_start_end class (see gdbsupport/common-debug.h). This commit templates scoped_debug_start_end so that the class can accept either a 'bool &' or an invokable object, e.g. a lambda function, or a function pointer. The existing scoped_debug_start_end and scoped_debug_enter_exit macros in common-debug.h are updated to support scoped_debug_enter_exit being templated, however, nothing outside of common-debug.h needs to change. I've then added SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT in symtab.h, and added a couple of token uses in symtab.c. I didn't want to add too much in this first commit, this is really about updating common-debug.h to support this new functionality. Within symtab.h I created a couple of global functions that can be used to query the status of the symbol_lookup_debug control variable, these functions are then used within the two existing macros: symbol_lookup_debug_printf symbol_lookup_debug_printf_v and also in the new SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT macro.
2022-12-14gdb: convert 'set debug symbol-lookup' to new debug printing schemeAndrew Burgess6-276/+161
Convert the implementation of 'set debug symbol-lookup' to the new debug printing scheme. In a few places I've updated the debug output to remove places where the printed debug message included the function name, the new debug scheme already adds that, but I haven't done all the possible updates.
2022-12-14gdb/testsuite: new test for recent dwarf reader issueAndrew Burgess3-0/+167
This commit provides a test for this commit: commit 55fc1623f942fba10362cb199f9356d75ca5835b Date: Thu Nov 3 13:49:17 2022 -0600 Add name canonicalization for C Which resolves PR gdb/29105. My reason for writing this test was a desire to better understand the above commit, my process was to study the commit until I thought I understood it, then write a test to expose the issue. As the original commit didn't have a test, I thought it wouldn't hurt to commit this upstream. The problem tested for here is already described in the above commit, but I'll give a brief description here. This description describes GDB prior to the above commit: - Builtin types are added to GDB using their canonical name, e.g. "short", not "signed short", - When the user does something like 'p sizeof(short)', then this is handled in c-exp.y, and results in a call to lookup_signed_type for the name "int". The "int" here is actually being looked up as the type for the result of the 'sizeof' expression, - In lookup_signed_type GDB first adds a 'signed' and looks for that type, so in this case 'signed int', and, if that lookup fails, GDB then looks up 'int', - The problem is that 'signed int' is not the canonical name for a signed int, so no builtin type with that name will be found, GDB will then go to each object file in turn looking for a matching type, - When checking each object file, GDB will first check the partial symtab to see if the full symtab should be expanded or not. Remember, at this point GDB is looking for 'signed int', there will be no partial symbols with that name, so GDB will not expand anything, - However, GDB checks each partial symbol using multiple languages, not just the current language (C in this case), so, when GDB checks using the C++ language, the symbol name is first canonicalized (the code that does this can be found lookup_name_info::language_lookup_name). As the canonical form of 'signed int' is just 'int', GDB then looks for any symbols with the name 'int', most partial symtabs will contain such a symbol, so GDB ends up expanding pretty much every symtab. The above commit fixes this by avoiding the use of non-canonical names with C, now the initial builtin type lookup will succeed, and GDB never even considers whether to expand any additional symtabs. The test case creates a library that includes char, short, int, and long types, and a test program that links against the library. In the test script we start the inferior, but don't allow it to progress far enough that the debug information for the library has been fully expanded yet. Then we evaluate some 'sizeof(TYPE)' expressions. In the buggy version of GDB this would cause the debug information for the library to be fully expanded, while in the fixed version of GDB this will not be the case. We use 'info sources' to determine if the debug information has been fully expanded or not. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105
2022-12-14gdb/testsuite: fix readnow detectionAndrew Burgess4-53/+10
The following commit broke the readnow detection in the testsuite: commit dfaa040b440084dd73ebd359326752d5f44fc02c Date: Mon Mar 29 18:31:31 2021 -0600 Remove some "OBJF_READNOW" code from dwarf2_debug_names_index The testsuite checks if GDB was started with the -readnow flag by using the 'maintenance print objfiles' command, and looking for the string 'faked for "readnow"' in the output. This is implemented in two helper procs `readnow` (gdb.exp) and `mi_readnow` (mi-support.exp). The following tests all currently depend on this detection: gdb.base/maint.exp gdb.cp/nsalias.exp gdb.dwarf2/debug-aranges-duplicate-offset-warning.exp gdb.dwarf2/dw2-stack-boundary.exp gdb.dwarf2/dw2-zero-range.exp gdb.dwarf2/gdb-index-nodebug.exp gdb.mi/mi-info-sources.exp gdb.python/py-symbol.exp gdb.rust/traits.exp The following test also includes detection of 'readnow', but does the detection itself by checking $::GDBFLAGS for the readnow flag: gdb.opt/break-on-_exit.exp The above commit removed from GDB the code that produced the 'faked for "readnow"' string, as a consequence the testsuite can no longer correctly spot when readnow is in use, and many of the above tests will fail (at least partially). When looking at the above tests, I noticed that gdb.rust/traits.exp does call `readnow`, but doesn't actually use the result, so I've removed the readnow call, this simplifies the next part of this patch as gdb.rust/traits.exp was the only place an extra regexp was passed to the readnow call. Next I have rewritten `readnow` to check the $GDBFLAGS for the -readnow flag, and removed the `maintenance print objfiles` check. At least for all the tests above, when using the readnow board, this is good enough to get everything passing again. For the `mi_readnow` proc, I changed this to just call `readnow` from gdb.exp, I left the mi_readnow name in place - in the future it might be the case that we want to do some different checks here. Finally, I updated gdb.opt/break-on-_exit.exp to call the `readnow` proc. With these changes, all of the tests listed above now pass correctly when using the readnow board.
2022-12-14RISC-V: Add string length check for operands in ASLi Xu4-1/+9
The current AS accepts invalid operands due to miss of operands length check. For example, "e6" is an invalid operand in (vsetvli a0, a1, e6, mf8, tu, ma), but it's still accepted by assembler. In detail, the condition check "strncmp (array[i], *s, len) == 0" in arg_lookup function passes with "strncmp ("e64", "e6", 2)" in the case above. So the generated encoding is same as that of (vsetvli a0, a1, e64, mf8, tu, ma). This patch fixes issue above by prompting an error in such case and also adds a new testcase. gas/ChangeLog: * config/tc-riscv.c (arg_lookup): Add string length check for operands. * testsuite/gas/riscv/vector-insns-fail-vsew.d: New testcase for an illegal vsew. * testsuite/gas/riscv/vector-insns-fail-vsew.l: Likewise. * testsuite/gas/riscv/vector-insns-fail-vsew.s: Likewise.
2022-12-14x86: adjust type checking constructsJan Beulich1-2/+2
As Alan points out, ASAN takes issue with these constructs, for current_templates being NULL. Wrap them in sizeof(), so the expressions aren't actually evaluated.
2022-12-14ld, gold: remove support for -z bndplt (MPX prefix)Martin Liska54-1853/+12
bfd/ChangeLog: * elf-linker-x86.h (struct elf_linker_x86_params): Remove bndplt. * elf64-x86-64.c (elf_x86_64_scan_relocs): Ignore R_X86_64_PLT32_BND. (elf_x86_64_relocate_section): Similarly here. (elf_x86_64_link_setup_gnu_properties): Ignore bndplt. * elfxx-x86.c: Likewise. * elfxx-x86.h: Likewise. gold/ChangeLog: * NEWS: Document -z bndplt. * options.h (class General_options): Remove bndplt option. * x86_64.cc (class Output_data_plt_x86_64_bnd): Remove. (Target_x86_64::do_make_data_plt): Do not use Output_data_plt_x86_64_bnd. (Target_x86_64::Scan::get_reference_flags): Likewise. (Target_x86_64::Scan::check_non_pic): Likewise. (Target_x86_64::Scan::local): Likewise. (Target_x86_64::Scan::global): Likewise. ld/ChangeLog: * NEWS: Document -z bndplt. * emulparams/elf_x86_64.sh: Remove bndplt option. * ld.texi: Likewise. * testsuite/ld-x86-64/x86-64.exp: * testsuite/ld-x86-64/bnd-branch-1-now.d: Removed. * testsuite/ld-x86-64/bnd-branch-1.d: Removed. * testsuite/ld-x86-64/bnd-branch-1.s: Removed. * testsuite/ld-x86-64/bnd-ifunc-1-now.d: Removed. * testsuite/ld-x86-64/bnd-ifunc-1.d: Removed. * testsuite/ld-x86-64/bnd-ifunc-1.s: Removed. * testsuite/ld-x86-64/bnd-ifunc-2-now.d: Removed. * testsuite/ld-x86-64/bnd-ifunc-2.d: Removed. * testsuite/ld-x86-64/bnd-ifunc-2.s: Removed. * testsuite/ld-x86-64/bnd-plt-1-now.d: Removed. * testsuite/ld-x86-64/bnd-plt-1.d: Removed. * testsuite/ld-x86-64/mpx.exp: Removed. * testsuite/ld-x86-64/mpx1.out: Removed. * testsuite/ld-x86-64/mpx1a.c: Removed. * testsuite/ld-x86-64/mpx1a.rd: Removed. * testsuite/ld-x86-64/mpx1b.c: Removed. * testsuite/ld-x86-64/mpx1c.c: Removed. * testsuite/ld-x86-64/mpx1c.rd: Removed. * testsuite/ld-x86-64/mpx2.out: Removed. * testsuite/ld-x86-64/mpx2a.c: Removed. * testsuite/ld-x86-64/mpx2a.rd: Removed. * testsuite/ld-x86-64/mpx2b.c: Removed. * testsuite/ld-x86-64/mpx2c.c: Removed. * testsuite/ld-x86-64/mpx2c.rd: Removed. * testsuite/ld-x86-64/mpx3.dd: Removed. * testsuite/ld-x86-64/mpx3a.s: Removed. * testsuite/ld-x86-64/mpx3b.s: Removed. * testsuite/ld-x86-64/mpx3n.dd: Removed. * testsuite/ld-x86-64/mpx4.dd: Removed. * testsuite/ld-x86-64/mpx4a.s: Removed. * testsuite/ld-x86-64/mpx4b.s: Removed. * testsuite/ld-x86-64/mpx4n.dd: Removed. * testsuite/ld-x86-64/pr20800a.S: Removed. * testsuite/ld-x86-64/pr20800b.S: Removed. * testsuite/ld-x86-64/pr21038a-now.d: Removed. * testsuite/ld-x86-64/pr21038a.d: Removed. * testsuite/ld-x86-64/pr21038a.s: Removed. * testsuite/ld-x86-64/pr21038b-now.d: Removed. * testsuite/ld-x86-64/pr21038b.d: Removed. * testsuite/ld-x86-64/pr21038b.s: Removed. * testsuite/ld-x86-64/pr21038c-now.d: Removed. * testsuite/ld-x86-64/pr21038c.d: Removed. * testsuite/ld-x86-64/pr21038c.s: Removed.
2022-12-14asan: signed integer overflow in display_debug_framesAlan Modra1-108/+116
* dwarf.c (struct Frame_Chunk): Make col_offset an int64_t. Adjust all places allocating col_offset and col_type to use the size of the array element rather than the size of a type. (frame_display_row): Adjust printing of col_offset. (display_debug_frames): Factor out multiplication by code_factor and data_factor. Avoid signed overflow. Use 64-bit variables.
2022-12-14Don't access freed memory printing objcopy warningAlan Modra1-3/+5
abfd->filename will be freed if bfd_close gets far enough to delete the bfd. It's possible to have an error from fclose at this point. * objcopy.c (copy_archive): Dup filename before closing bfd for potential use in bfd_nonfatal_message.
2022-12-14Automatic date update in version.inGDB Administrator1-1/+1
2022-12-13Fix control-c handling on WindowsTom Tromey7-71/+99
As Hannes pointed out, the Windows target-async patches broke C-c handling there. Looking into this, I found a few oddities, fixed here. First, windows_nat_target::interrupt calls GenerateConsoleCtrlEvent. I think this event can be ignored by the inferior, so it's not a great way to interrupt. Instead, using DebugBreakProcess (or a more complicated thing for Wow64) seems better. Second, windows_nat_target did not implement the pass_ctrlc method. Implementing this lets us remove the special code to call SetConsoleCtrlHandler and instead integrate into gdb's approach to C-c handling. I believe that this should also fix the race that's described in the comment that's being removed. Initially, I thought a simpler version of this patch would work. However, I think what happens is that some other library (I'm not sure what) calls SetConsoleCtrlHandler while gdb is running, and this intercepts and handles C-c -- so that the gdb SIGINT handler is not called. C-break continues to work, presumably because whatever handler is installed ignores it. This patch works around this issue by ensuring that the gdb handler always comes first.
2022-12-13Refactor code to check for terminal sharingTom Tromey4-26/+63
This refactors the code to check for terminal sharing. is_gdb_terminal is exported, and sharing_input_terminal_1 is renamed, slightly refactored, and moved to posix-hdep.c. A new Windows-specific implementation of this function is added to mingw-hdep.c. MSDN has a warning about GetConsoleProcessList This API is not recommended and does not have a virtual terminal equivalent. [...] Applications remoting via cross-platform utilities and transports like SSH may not work as expected if using this API. However, we believe this isn't likely to be an issue for gdb.
2022-12-13Use gdb::optional for sigint_oursTom Tromey1-4/+8
sigint_ours (and sigquit_ours) can be used without being set. Avoid this problem by changing them to gdb::optional and checking that they are in fact set before using the value.
2022-12-13Rename install_sigint_handlerTom Tromey1-2/+2
A subsequent patch will introduce a global 'install_sigint_handler' function, so first rename the static one in extension.c.
2022-12-13[gdb/tdep] Fix s390_linux_nat_target::stopped_by_watchpointTom de Vries1-8/+7
On s390x-linux, I run into: ... (gdb) continue^M Continuing.^M breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: \ Assertion `!target_stopped_by_watchpoint ()' failed.^M A problem internal to GDB has been detected,^M further debugging may prove unreliable.^M FAIL: gdb.threads/watchpoint-fork.exp: parent: singlethreaded: \ breakpoint after the first fork (GDB internal error) ... What happens is the follow: - a watchpoint event triggers - the event is processed, s390_linux_nat_target::stopped_by_watchpoint is called and it returns true, as expected - the watchpoint event is reported by gdb, and gdb stops - we issue a continue command - a fork event triggers - the event is processed, and during processing that event s390_linux_nat_target::stopped_by_watchpoint is called again, and returns true - the assertion fails, because the function is expected to return false The function s390_linux_nat_target::stopped_by_watchpoint returns true the second time, because it looks at the exact same data that was looked at when it was called the first time, and that data hasn't changed. There's code in the same function that intends to prevent that from happening: ... /* Do not report this watchpoint again. */ memset (&per_lowcore, 0, sizeof (per_lowcore)); if (ptrace (PTRACE_POKEUSR_AREA, s390_inferior_tid (), &parea, 0) < 0) perror_with_name (_("Couldn't clear watchpoint status")); ... and that probably used to work for older kernels, but no longer does since linux kernel commit 5e9a26928f55 ("[S390] ptrace cleanup"). Fix this by copying this: ... siginfo_t siginfo; if (!linux_nat_get_siginfo (inferior_ptid, &siginfo)) return false; if (siginfo.si_signo != SIGTRAP || (siginfo.si_code & 0xffff) != TRAP_HWBKPT) return false; ... from aarch64_linux_nat_target::stopped_data_address and remove the obsolete watchpoint status clearing code. Tested on s390x-linux. Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
2022-12-13gold: Remove BND from 64-bit x86-64 IBT PLTH.J. Lu1-48/+9
Since MPX support has been removed from x86-64 psABI, remove BND from 64-bit IBT PLT by using 32-bit IBT PLT. PR gold/29851 * x86_64.cc (Output_data_plt_x86_64_ibt<32>::first_plt_entry): Renamed to ... (Output_data_plt_x86_64_ibt<size>::first_plt_entry): This. (Output_data_plt_x86_64_ibt<64>::first_plt_entry): Removed. (Output_data_plt_x86_64_ibt<size>::do_fill_first_plt_entry): Drop the size == 32 check. (Output_data_plt_x86_64_ibt<32>::plt_entry): Renamed to ... (Output_data_plt_x86_64_ibt<size>::plt_entry): This. (Output_data_plt_x86_64_ibt<64>::plt_entry): Removed. (Output_data_plt_x86_64_ibt<32>::aplt_entry): Renamed to ... (Output_data_plt_x86_64_ibt<size>::aplt_entry): This. (Output_data_plt_x86_64_ibt<64>::aplt_entry): Removed. (Output_data_plt_x86_64_ibt<size>::do_fill_plt_entry): Drop the size == 32 check. (Output_data_plt_x86_64_ibt<size>::fill_aplt_entry): Likewise.
2022-12-13Remove two unnecessary castsTom Tromey1-2/+2
A couple of calls to parse_probe_linespec had an unnecessary cast. I suspect this cast was never needed, but once commands were changed to take a 'const' argument, they became completely obsolete. Tested by rebuilding.
2022-12-13gdb/testsuite: avoid creating temp file in gdb/testsuite/ directoryAndrew Burgess1-1/+1
After this commit: commit 33c1395cf5e9deec7733691ba32c450e5c27f757 Date: Fri Nov 11 15:26:46 2022 +0000 gdb/testsuite: fix gdb.trace/unavailable-dwarf-piece.exp with Clang The gdb.trace/unavailable-dwarf-piece.exp test script was creating a temporary file in the build/gdb/testsuite/ directory, instead of in the expected place in the outputs directory. Fix this by adding a call to standard_output_file.
2022-12-13[gdb/testsuite] Fix gdb.python/py-disasm.exp on s390xTom de Vries2-8/+14
On s390x-linux, I run into: ... (gdb) disassemble test^M Dump of assembler code for function test:^M 0x0000000001000638 <+0>: stg %r11,88(%r15)^M 0x000000000100063e <+6>: lgr %r11,%r15^M 0x0000000001000642 <+10>: nop 0^M => 0x0000000001000646 <+14>: nop 0^M 0x000000000100064a <+18>: nop 0^M 0x000000000100064e <+22>: lhi %r1,0^M 0x0000000001000652 <+26>: lgfr %r1,%r1^M 0x0000000001000656 <+30>: lgr %r2,%r1^M 0x000000000100065a <+34>: lg %r11,88(%r11)^M 0x0000000001000660 <+40>: br %r14^M End of assembler dump.^M (gdb) FAIL: gdb.python/py-disasm.exp: global_disassembler=: disassemble test ... The problem is that the test-case expects "nop" but on s390x we have instead "nop\t0". Fix this by allowing the insn. Tested on s390x-linux and x86_64-linux.
2022-12-13gas: re-work line number tracking for macros and their expansionsJan Beulich62-2592/+9757
The PR gas/16908 workaround aimed at uniformly reporting line numbers to reference macro invocation sites. As mentioned in a comment this may be desirable for small macros, but often isn't for larger ones. As a first step improve diagnostics to report both locations, while aiming at leaving generated debug info unaltered. Note that macro invocation context is lost for any diagnostics issued only after all input was processed (or more generally for any use of as_*_where(), as the functions can't know whether the passed in location is related to [part of] the present stack of locations). To maintain the intended workaround behavior for PR gas/16908, a new as_where() is introduced to "look through" macro invocations, while the existing as_where() is renamed (and used in only very few places for now). Down the road as_where() will likely want to return a list of (file,line) pairs.
2022-12-13Arm: avoid unhelpful uses of .macro in testsuiteJan Beulich141-2306/+2237
Macros with just a single use site are a little pointless to have, and even in further cases .irp is more suitable for the purpose. Expand such inline, avoiding the need to touch the testcases when diagnostics are changed for code resulting from macro expansion. While there also make what was "iter_mla" in sp-usage-thumb2-relax cover smlatt as well, rather than testing smlabt twice.
2022-12-12Fix crash in is_nocall_functionTom Tromey3-5/+7
is_nocall_function anticipates only being called for a function or a method. However, PR gdb/29871 points out a situation where an unusual expression -- but one that parses to a valid, if extremely weird, function call -- breaks this assumption. This patch changes is_nocall_function to remove this assert and instead simply return 'false' in this case. Approved-By: Simon Marchi <simon.marchi@efficios.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29871
2022-12-12Replace gdbpy_should_stop with gdbpy_breakpoint_cond_says_stopJohnson Sun1-5/+5
In 2014, the function `gdbpy_should_stop' has been replaced with `gdbpy_breakpoint_cond_says_stop' This replaces `gdbpy_should_stop' with `gdbpy_breakpoint_cond_says_stop' in the comments. Since `gdbpy_should_stop' has been renamed as noted in `gdb/ChangeLog-2014': * python/py-breakpoint.c (gdbpy_breakpoint_cond_says_stop): Renamed from gdbpy_should_stop. Change result type to enum scr_bp_stop. Change-Id: I0ef3491ce5e057c5e75ef8b569803b30a5838575 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-12-13asan: mips_hi16_list segfault in bfd_get_section_limit_octetsAlan Modra5-24/+50
static variables like mips_hi16_list are nasty for applications using bfd. It is possible when opening and closing bfds with mis-matched hi/lo relocs to leave a stale section pointer on the list. That can cause a segfault if multiple bfds are being processed. Tidying the list when closing is sufficient to stop this happening (and fixes small memory leaks). This patch goes further and moves mips_hi16_list to where it belongs in the bfd tdata. * elf32-mips.c (bfd_elf32_close_and_cleanup(: Define. * elf64-mips.c (bfd_elf64_close_and_cleanup): Define. * elfn32-mips.c (bfd_elf32_close_and_cleanup(: Define. * elfxx-mips.c (struct mips_hi16): Move earlier. (mips_hi16_list): Move to.. (struct mips_elf_obj_tdata): ..here. (_bfd_mips_elf_close_and_cleanup): New function. (_bfd_mips_elf_hi16_reloc, _bfd_mips_elf_lo16_reloc), (_bfd_elf_mips_get_relocated_section_contents): Adjust uses of mips_hi16_list. * elfxx-mips.h (_bfd_mips_elf_close_and_cleanup): Declare.
2022-12-13Automatic date update in version.inGDB Administrator1-1/+1
2022-12-12libctf: remove unnecessary zstd constructsIndu Bhagat5-280/+6
This patch is essentially a revert of commit-id: 8818c80cbd4116ef5af171ec47c61167179e225c (libctf: Add ZSTD_LIBS to LIBS so that ac_cv_libctf_bfd_elf can be true) As the specific configure check now uses libtool, this explicit mention of the dependency $ZSTD_LIBS is not needed anymore. ChangeLog: * libctf/Makefile.in: Regenerated. * libctf/aclocal.m4: Likewise. * libctf/config.h.in: Likewise. * libctf/configure: Likewise. * libctf/configure.ac: Remove ZSTD_LIBS from LIBS. Cleanup unused AC_ZSTD.
2022-12-12libctf: remove AC_CONFIG_MACRO_DIRIndu Bhagat2-8/+2
ACLOCAL_AMFLAGS is being set already. So using AC_CONFIG_MACRO_DIR is unnecessary. ChangeLog: * libctf/configure: Regenerated. * libctf/configure.ac: remove AC_CONFIG_MACRO_DIR usage.
2022-12-12libctf: remove unnecessary zlib constructsIndu Bhagat2-6/+4
This dependency is managed via libtool. So explicit addition to LDFLAGS and LIBS is not necessary anymore. ChangeLog: * libctf/configure: Regenerated. * libctf/configure.ac: remove zlib from LDFLAGS and LIBS.
2022-12-12[gdb/testsuite] Fix PR20630 regression test in gdb.base/printcmds.expTom de Vries1-1/+3
On s390x-linux, I run into: ... (gdb) print {unsigned char}{65}^M $749 = 0 '\000'^M (gdb) FAIL: gdb.base/printcmds.exp: print {unsigned char}{65} ... In contrast, on x86_64-linux, we have: ... (gdb) print {unsigned char}{65}^M $749 = 65 'A'^M (gdb) PASS: gdb.base/printcmds.exp: print {unsigned char}{65} ... The first problem here is that the test is supposed to be a regression test for PR20630, which can be reproduced (for an unfixed gdb) like this: ... (gdb) p {unsigned char[]}{0x17} gdbtypes.c:4641: internal-error: copy_type: \ Assertion `TYPE_OBJFILE_OWNED (type)' failed. ... but it's not due to insufficient quoting (note the dropped '[]'). That's easy to fix, but after that we have on s390 (big endian): ... (gdb) print {unsigned char[]}{65}^M $749 = ""^M ... and on x86_64 (little endian): ... (gdb) print {unsigned char[]}{65}^M $749 = "A"^M ... Fix this by using 0xffffffff, such that in both cases we have: ... (gdb) print {unsigned char[]}{0xffffffff}^M $749 = "\377\377\377\377"^M ... Tested on x86_64-linux and s390x-linux.
2022-12-13PR29893, buffer overflow in display_debug_addrAlan Modra1-2/+7
PR 29893 * dwarf.c (display_debug_addr): Sanity check dwarf5 unit_length field. Don't read past end.