aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-07-11ld/PDB: fix off-by-1 in add_globals_ref()Jan Beulich1-1/+1
Copying one too many bytes can corrupt memory, detected/reported by glibc on a 32-bit distro.
2023-07-11Automatic date update in version.inGDB Administrator1-1/+1
2023-07-10Remove target_closeTom Tromey5-37/+19
I noticed that target_close is only called in two places: solib-svr4.c, and target_ops_ref_policy::decref. This patch fixes the former by changing target_bfd_reopen to return a target_ops_up and then fixing the sole caller. Then it removes target_close by inlining its body into the decref method. The advantage of this approach is that targets are now automatically managed. Regression tested on x86-64 Fedora 38. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-07-10Update TUI window title when changedTom Tromey5-1/+25
I wrote a TUI window in Python, and I noticed that setting its title did not result in a refresh, so the new title did not appear. This patch corrects this problem.
2023-07-10Add Ada scope test for DAPTom Tromey4-0/+154
This adds a DAP test for fetching scopes and variables with an Ada program. This test is the reason that the FrameVars code does not check is_constant on the symbols it returns. Note that this test also shows that string-printing is incorrect in Ada. This is a known bug but I'm still considering how to fix it.
2023-07-10Handle typedefs in no-op pretty printersTom Tromey2-14/+15
The no-ops pretty-printers that were introduced for DAP have a classic gdb bug: they neglect to call check_typedef. This will cause some strange behavior; for example not showing the children of a variable whose type is a typedef of a structure type. This patch fixes the oversight.
2023-07-10Reimplement DAP stack traces using frame filtersTom Tromey5-104/+81
This reimplements DAP stack traces using frame filters. This slightly simplifies the code, because frame filters and DAP were already doing some similar work. This also renames RegisterReference and ScopeReference to make it clear that these are private (and so changes don't have to worry about other files). Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30468
2023-07-10Simplify FrameVarsTom Tromey1-26/+1
FrameVars implements its own variant of Symbol.is_variable. This patch replaces this code.
2023-07-10Fix oversights in frame decorator codeTom Tromey1-4/+13
The frame decorator "FrameVars" code misses a couple of cases, discovered when working on related DAP changes. First, fetch_frame_locals does not stop when reaching a function boundary. This means it would return locals from any enclosing functions. Second, fetch_frame_args assumes that all arguments are at the outermost scope, but this doesn't seem to be required by gdb.
2023-07-10Add new interface to frame filter iterationTom Tromey1-26/+59
This patch adds a new function, frame_iterator, that wraps the existing code to find and execute the frame filters. However, unlike execute_frame_filters, it will always return an iterator -- whereas execute_frame_filters will return None if no frame filters apply. Nothing uses this new function yet, but it will used by a subsequent DAP patch.
2023-07-10Fix execute_frame_filters doc stringTom Tromey1-7/+9
When reading the doc string for execute_frame_filters, I wasn't sure if the ranges were inclusive or exclusive. This patch updates the doc string to reflect my findings, and also fixes an existing typo.
2023-07-10Change 'handle_id' to be a local variableTom Tromey1-2/+1
The global variable 'handle_id' in tracectf.c is only used in a single function, so change it to be a local variable. Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-07-10Move definition of ctf_target typeTom Tromey1-30/+30
This moves the definition of the ctf_target type into the HAVE_LIBBABELTRACE block. This type is only used in this block, so it makes sense to only define it there. Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-07-10Constify tfile_interp_lineTom Tromey1-4/+4
This adds 'const' to tfile_interp_line. Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-07-10Use function_view in traceframe_walk_blocksTom Tromey1-32/+18
This change traceframe_walk_blocks to take a function_view. This simplifies the code somewhat and lets us entirely remove one helper function. Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-07-10Use unique_ptr for trace_dirnameTom Tromey1-5/+4
This changes trace_dirname to use unique_ptr, removing some manual memory management. Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-07-10Use unique_ptr for trace_filenameTom Tromey1-7/+6
This changes trace_filename to use unique_ptr, removing some manual memory management. Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-07-10Replace use of xfree with byte_vectorTom Tromey1-4/+1
This replaces a use of xfree with a byte_vector. Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-07-10Remove a use of xfreeTom Tromey1-7/+4
This removes a use of xfree from tracefile-tfile.c, replacing it with a unique_xmalloc_ptr. Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-07-10Avoid crash with absolute symbolTom Tromey1-1/+2
A user supplied an executable and a remote logfile that could be used to crash gdb. The problem is that the BFD section for a particular symbol was null, because the section was not marked "allocated". Digging deeper, the problem was that elfread.c dropped the section for absolute symbols. This patch fixes the crash. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30431
2023-07-10gdbserver: handle all eval_result_type values in tracepoint.ccAndrew Burgess3-18/+50
It was pointed out[1] that after this commit: commit 3812b38d8de5804ad3eadd6c7a5d532402ddabab Date: Thu Oct 20 11:14:33 2022 +0100 gdbserver: allow agent expressions to fail with invalid memory access Now that agent expressions might fail with the error expr_eval_invalid_memory_access, we might overflow the eval_result_names array in tracepoint.cc. This is because the eval_result_names array does not include a string for either expr_eval_invalid_goto or expr_eval_invalid_memory_access. I don't know if having expr_eval_invalid_goto missing is also a problem, but it feels like eval_result_names should just include a string for every possible error. I could just add two more strings into the array, but I figure that a more robust solution will be to move all of the error types, and their associated strings, into a new ax-result-types.def file, and to then include this file in both ax.h and tracepoint.cc in order to build the enum eval_result_type and the eval_result_names string array. Doing this means it is impossible to have a missing error string in the future. [1] https://inbox.sourceware.org/gdb-patches/01059f8a-0e59-55b5-f530-190c26df5ba3@palves.net/ Approved-By: Pedro Alves <pedro@palves.net>
2023-07-10gdb/testsuite: avoid stack addresses in test namesAndrew Burgess1-1/+2
When comparing the test results for two different runs of GDB I noticed a difference in the results for gdb.base/frame-view.exp. The difference was caused by one of the tests including a stack address in the test name: PASS: gdb.base/frame-view.exp: with_pretty_printer=false: select-frame view 0x7ffff7c5cea8 0x40115b and PASS: gdb.base/frame-view.exp: with_pretty_printer=true: select-frame view 0x7ffff7c5cea8 0x40115b If for whatever reason the stack address changes between test runs then it becomes harder to compare results. Fix this by giving the test a descriptive name that doesn't include a stack address: PASS: gdb.base/frame-view.exp: with_pretty_printer=false: select thread 2 frame from thread 1 and PASS: gdb.base/frame-view.exp: with_pretty_printer=true: select thread 2 frame from thread 1 There's no change to what is actually tested after this commit.
2023-07-10gdb/testsuite: return after reporting a test unsupportedAndrew Burgess1-0/+1
In this commit: commit 8bcead69665af3a9f9867cd34c3a1daf22120027 Date: Tue May 23 11:25:01 2023 +0100 gdb/testsuite: add test for core file with a 0 pid a new test gdb.arch/core-file-pid0.exp was added. This test includes a pre-generated core file for x86-64 and for other architectures the test reports 'unsupported'. However, after reporting 'unsupported' the test failed to perform an early return, so the test would then carry on and try to actually perform the test, which resulted in some TCL errors. Fix this by returning after reporting the test unsupported.
2023-07-10gdb: include location number in breakpoint error messageAndrew Burgess3-15/+45
This commit improves the output of this previous commit: commit 2dc3457a454a35d0617dc1f9cc1db77468471f95 Date: Fri Oct 14 13:22:55 2022 +0100 gdb: include breakpoint number in testing condition error message The earlier commit extended the error message: Error in testing breakpoint condition: to include the breakpoint number, e.g.: Error in testing breakpoint condition 3: This commit extends takes this further, and includes the location number if the breakpoint has multiple locations, so we might now see: Error in testing breakpoint condition 3.2: Just as with how GDB reports a normal breakpoint stop, if a breakpoint only has a single location then the location number is not included, this keeps things nice and consistent. I've extended one of the tests to cover the new functionality. Approved-By: Pedro Alves <pedro@palves.net>
2023-07-10gdb/testsuite: Testing with the nvfortran compilerRichard Bunt2-8/+22
Currently, the Fortran test suite does not run with NVIDIA's Fortran compiler (nvfortran). The goal here is to get the tests running and preventing further regressions during future work. This change does not do anything to fix existing failures. Teach the compiler detection about nvfortran. There is no underlying information about whether this compiler is related to flang classic or flang, so we cannot reuse the main and type definitions. Therefore, we explicitly record the main method and type information observed when using nvfortran. The main name was extracted by trying to set breakpoints on both MAIN_ and MAIN__. The following mapping of test to type names was used to extract how nvfortran reports types. info-types.exp: fortran_int4, fortran_int8, fortran_real4, fortran_logical4 common-block.exp: fortran_real8 complex.exp: fortran_complex4 fortran_complex8 logical.exp: fortran_character1. Ran ptype on "c". Types defined as fortran_complex16 do not compile with nvfortran, so it was left unset. gdb.fortran regression tests run with GNU, Intel, Intel LLVM and ACfL. No regressions detected. The gdb.fortran test results with nvfortran 23.3 are as follows. Before: # of expected passes 523 # of unexpected failures 107 # of known failures 2 # of unresolved testcases 1 # of untested testcases 7 # of duplicate test names 2 After: # of expected passes 5696 # of unexpected failures 271 # of known failures 12 # of untested testcases 9 # of unsupported tests 5 As can be seen from the above, there are now considerably more passing assertions. Approved-By: Tom Tromey <tom@tromey.com>
2023-07-10Automatic date update in version.inGDB Administrator1-1/+1
2023-07-09PR30592 objcopy: allow --set-section-flags to add or remove SHF_X86_64_LARGEFangrui Song13-10/+155
For example, objcopy --set-section-flags .data=alloc,large will add SHF_X86_64_LARGE to the .data section. Omitting "large" will drop the SHF_X86_64_LARGE flag. The bfd_section flag is named generically, SEC_ELF_LARGE, in case other processors want to follow SHF_X86_64_LARGE. SEC_ELF_LARGE has the same value as SEC_TIC54X_BLOCK used by coff. bfd/ * section.c: Define SEC_ELF_LARGE. * bfd-in2.h: Regenerate. * elf64-x86-64.c (elf_x86_64_section_flags, elf_x86_64_fake_sections, elf_x86_64_copy_private_section_data): New. binutils/ * NEWS: Mention the new feature for objcopy. * doc/binutils.texi: Mention "large". * objcopy.c (parse_flags): Parse "large". (check_new_section_flags): Error if "large" is used with a non-x86-64 ELF target. * testsuite/binutils-all/x86-64/large-sections.d: New. * testsuite/binutils-all/x86-64/large-sections.s: New. * testsuite/binutils-all/x86-64/large-sections-i386.d: New. * testsuite/binutils-all/x86-64/large-sections-2.d: New. * testsuite/binutils-all/x86-64/large-sections-2-x32.d: New.
2023-07-09Automatic date update in version.inGDB Administrator1-1/+1
2023-07-07gdb/cp-namespace.c: Fix assert failure caused by malformed user inputAaron Merey2-2/+9
When debugging C++ programs, it is possible to trigger a spurious assert failure when attempting to set a breakpoint on a malformed symbol name. Names of the form 'A>::B' and 'A)::B' trigger this assert failure in cp_lookup_bare_symbol: $ gdb gdb [...] (gdb) br test>::assert Function "test>::assert" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (test>::assert) pending. (gdb) start [...] cp-namespace.c:181: internal-error: cp_lookup_bare_symbol: Assertion `strstr (name, "::") == NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- 0x5217e2 gdb_internal_backtrace_1 /home/amerey/binutils-gdb/gdb/bt-utils.c:122 0x521885 _Z22gdb_internal_backtracev /home/amerey/binutils-gdb/gdb/bt-utils.c:168 0xaf8303 internal_vproblem /home/amerey/binutils-gdb/gdb/utils.c:396 0xaf86be _Z15internal_verrorPKciS0_P13__va_list_tag /home/amerey/binutils-gdb/gdb/utils.c:476 0xccdb3f _Z18internal_error_locPKciS0_z /home/amerey/binutils-gdb/gdbsupport/errors.cc:58 0x5dded9 cp_lookup_bare_symbol /home/amerey/binutils-gdb/gdb/cp-namespace.c:181 0x5de39d cp_lookup_symbol_in_namespace /home/amerey/binutils-gdb/gdb/cp-namespace.c:328 [...] Currently this assert is skipped if the symbol name contains '<' or '('. Fix this spurious failure by also skipping the assert when the symbol name contains '>' or ')'. Regression tested on F38 x86_64. Approved-By: Tom Tromey <tom@tromey.com>
2023-07-08Automatic date update in version.inGDB Administrator1-1/+1
2023-07-07Fix result of DAP setExpressionTom Tromey2-2/+14
A co-worker, Andry, noticed that the DAP setExpression implementation returned the wrong fields -- it used "result" rather than "value", and included "memoryReference", which isn't in the spec (an odd oversight, IMO). This patch fixes the problems.
2023-07-07Remove unchecked casts to mi_interpTom Tromey3-27/+39
Simon noticed a crash that could be caused via new Python gdb.execute_mi function. Looking into this, I found a few unchecked casts to mi_interp, like: - struct mi_interp *mi = (struct mi_interp *) command_interp (); This patch replaces all such casts with safer variants. For -gdb-exit and mi_load_progress, I chose to have the functions simply not generate any output. It didn't seem useful to do so. Some casts I eliminated by adding a parameter to a function. Then, in mi_execute_command, I changed the code to use gdb::checked_static_cast. This is appropriate because this particular overload can only be called by the MI interpreter. There does not seem to be a very good way to test -gdb-exit. Regression tested on x86-64 Fedora 36.
2023-07-07gdb: check max-value-size when reading strings for printfAndrew Burgess9-5/+100
I noticed that the printf code for strings, printf_c_string and printf_wide_c_string, don't take max-value-size into account, but do load a complete string from the inferior into a GDB buffer. As such it would be possible for an badly behaved inferior to cause GDB to try and allocate an excessively large buffer, potentially crashing GDB, or at least causing GDB to swap lots, which isn't great. We already have a setting to protect against this sort of thing, the 'max-value-size'. So this commit updates the two function mentioned above to check the max-value-size and give an error if the max-value-size is exceeded. If the max-value-size is exceeded, I chose to continue reading inferior memory to figure out how long the string actually is, we just don't store the results. The benefit of this is that when we give the user an error we can tell the user how big the string actually is, which would allow them to correctly adjust max-value-size, if that's what they choose to do. The default for max-value-size is 64k so there should be no user visible changes after this commit, unless the user was previously printing very large strings. If that is the case then the user will now need to increase max-value-size.
2023-07-07gdb: remove last alloca call from printcmd.cAndrew Burgess1-17/+13
This commit removes the last alloca call from printcmd.c. This is similar to the patches I originally posted here: https://inbox.sourceware.org/gdb-patches/cover.1677533215.git.aburgess@redhat.com/ However, this change was not included in that original series. The original series received push back because it was thought that replacing alloca with a C++ container type would introduce unnecessary malloc/free overhead. However, in this case we are building a string, and (at least for GCC), the std::string type has a small string optimisation, where small strings are stored on the stack. And in this case we are building what will usually be a very small string, we're just constructing a printf format specifier for a hex value, so it'll be something like '%#x' -- though it could also have a width in there too -- but still, it should normally fit within GCCs small string buffer. So, in this commit, I propose replacing the use of alloca with a std::string. This shouldn't result (normally) in any additional malloc or free calls, so should be similar in performance to the original approach. There should be no user visible differences after this commit.
2023-07-07gdb: remove two uses of alloca from printcmd.cAndrew Burgess1-27/+22
Remove a couple of uses of alloca from printcmd.c, and replace them with gdb::byte_vector. An earlier variant of this patch was proposed in this thread: https://inbox.sourceware.org/gdb-patches/cover.1677533215.git.aburgess@redhat.com/ however, there was push back on that thread due to it adding extra dynamic allocation, i.e. moving the memory buffers off the stack on to the heap. However, of all the patches originally proposed, I think in these two cases moving off the stack is the correct thing to do. Unlike all the other patches in the original series, where the data being read was (mostly) small in size, a register, or a couple of registers, in this case we are reading an arbitrary string from the inferior. This could be any size, and so should not be placed on the stack. So in this commit I replace the use of alloca with std::byte_vector and simplify the logic a little (I think) to take advantage of the ability of std::byte_vector to dynamically grow in size. Of course, really, we should probably be checking the max-value-size setting as we load the string to stop GDB crashing if a corrupted inferior causes GDB to try read a stupidly large amount of memory... but I'm leaving that for a follow on patch. There should be no user visible changes after this commit.
2023-07-07gdb: fix printf of wchar_t early in a gdb sessionAndrew Burgess5-9/+71
Given this test program: #include <wchar.h> const wchar_t wide_str[] = L"wide string"; int main (void) { return 0; } I observed this GDB behaviour: $ gdb -q /tmp/printf-wchar_t Reading symbols from /tmp/printf-wchar_t... (gdb) start Temporary breakpoint 1 at 0x40110a: file /tmp/printf-wchar_t.c, line 8. Starting program: /tmp/printf-wchar_t Temporary breakpoint 1, main () at /tmp/printf-wchar_t.c:8 25 return 0; (gdb) printf "%ls\n", wide_str (gdb) Notice that the printf results in a blank line rather than the expected 'wide string' output. I tracked the problem down to printf_wide_c_string (in printcmd.c), in this function we do this: struct type *wctype = lookup_typename (current_language, "wchar_t", NULL, 0); int wcwidth = wctype->length (); the problem here is that 'wchar_t' is a typedef. If we look at the comment on type::length() we see this: /* Note that if thistype is a TYPEDEF type, you have to call check_typedef. But check_typedef does set the TYPE_LENGTH of the TYPEDEF type, so you only have to call check_typedef once. Since value::allocate calls check_typedef, X->type ()->length () is safe. */ What this means is that after calling lookup_typename we should call check_typedef in order to ensure that the length of the typedef has been setup correctly. We are not doing this in printf_wide_c_string, and so wcwidth is incorrectly calculated as 0. This is what leads GDB to print an empty string. We can see in c_string_operation::evaluate (in c-lang.c) an example of calling check_typedef specifically to fix this exact issue. Initially I did fix this problem by adding a check_typedef call into printf_wide_c_string, but then I figured why not move the check_typedef call up into lookup_typename itself, that feels like it should be harmless when looking up a non-typedef type, but will avoid bugs like this when looking up a typedef. So that's what I did. I can then remove the extra check_typedef call from c-lang.c, I don't see any other places where we had extra check_typedef calls. This doesn't mean we definitely had bugs -- so long as we never checked the length, or, if we knew that check_typedef had already been called, then we would be fine. I don't see any test regressions after this change, and my new test case is now passing. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-07-07ld: fix build with old glibc / gccJan Beulich1-2/+2
"rename" conflicts with a function of that name, which gcc from that same timeframe then complains about. Use a name matching that of struct input_remap's respective field.
2023-07-07arc: Update/Add ARCv3 support.Claudiu Zissulescu1-2/+28
The ARC HS5x and ARC HS6x processors are based on the new ARCv3 ISA that implements a full range of 32-bit and 64-bit instructions. These processors feature a high-speed 10-stage, dual-issue pipeline that offers increased utilization of functional units with a limited increase in power and area. The HS5x processors feature a 32-bit pipeline that can execute all ARCv3 32-bit instructions, while the HS6x processors feature a full 64-bit pipeline and register file that can execute both 32-bit and 64-bit instructions. In addition, the ARC HS6x supports 64-bit virtual and 52-bit physical address spaces to enable direct addressing of current and future large memories, as well as 128-bit loads and stores for efficient data movement. This readelf patch updates/adds Synopsys ARCv3 machine name fileds and supported relocations. Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>
2023-07-07gdb/testsuite: fix license on recently added fileAndrew Burgess1-3/+2
The license header on a file I recently contributed was incorrect. The file was added in commit: commit 087969169836f802a09b1cd0502d2f22d7a8f7dc Date: Tue May 23 11:25:21 2023 +0100 gdb: handle core files with .reg/0 section names The problems were: - GPLv2 instead of GPLv3, - Use the FSF postal address rather than their URL. Nobody else has touched the file since I merged it, so I don't believe there are any problems with me changing the license, this commit does just that.
2023-07-07Udated Freach and Romainian translations for various sub-directoriesNick Clifton6-10572/+12318
2023-07-07Minor updates to release readmeNick Clifton1-1/+15
2023-07-07Automatic date update in version.inGDB Administrator1-1/+1
2023-07-06Linux: Avoid pread64/pwrite64 for high memory addresses (PR gdb/30525)Pedro Alves2-22/+35
Since commit 05c06f318fd9 ("Linux: Access memory even if threads are running"), GDB prefers pread64/pwrite64 to access inferior memory instead of ptrace. That change broke reading shared libraries on SPARC64 Linux, as reported by PR gdb/30525 ("gdb cannot read shared libraries on SPARC64"). On SPARC64 Linux, surprisingly (to me), userspace shared libraries are mapped at high 64-bit addresses: (gdb) info sharedlibrary Cannot access memory at address 0xfff80001002011e0 Cannot access memory at address 0xfff80001002011d8 Cannot access memory at address 0xfff80001002011d8 From To Syms Read Shared Object Library 0xfff80001000010a0 0xfff8000100021f80 Yes (*) /lib64/ld-linux.so.2 (*): Shared library is missing debugging information. Those addresses are 64-bit addresses with the high bits set. When interpreted as signed, they're negative. The Linux kernel rejects pread64/pwrite64 if the offset argument of type off_t (a signed type) is negative, which happens if the memory address we're accessing has its high bit set. See linux/fs/read_write.c sys_pread64 and sys_pwrite64 in Linux. Thankfully, lseek does not fail in that situation. So the fix is to use the 'lseek + read|write' path if the offset would be negative. Fix this in both native GDB and GDBserver. Tested on a SPARC64 GNU/Linux and x86-64 GNU/Linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30525 Change-Id: I79c724f918037ea67b7396fadb521bc9d1b10dc5
2023-07-06riscv: Ensure LE instruction fetchingBranislav Brzak1-2/+2
Currently riscv gdb code looks at arch byte order when fetching instructions. This works when the target is LE, but on BE arch it will byte swap the instruction, while the riscv spec defines all instructions are LE encoded regardless of system memory endianess.
2023-07-06Fix Solaris regression (PR tdep/30252)Pedro Alves1-21/+25
PR tdep/30252 reports that using GDB on Solaris fails an assertion in target_resume: target.c:2648: internal-error: target_resume: Assertion `inferior_ptid != null_ptid' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) The backtrace, after running it through c++filt, looks like: ----- Backtrace ----- 0xa18914 gdb_internal_backtrace_1 /root/binutils-gdb/gdb/bt-utils.c:122 0xa18914 gdb_internal_backtrace() /root/binutils-gdb/gdb/bt-utils.c:168 0xdec834 internal_vproblem /root/binutils-gdb/gdb/utils.c:401 0xdecad8 internal_verror(char const*, int, char const*, __va_list_tag*) /root/binutils-gdb/gdb/utils.c:481 0xf3638c internal_error_loc(char const*, int, char const*, ...) /root/binutils-gdb/gdbsupport/errors.cc:58 0xd70580 target_resume(ptid_t, int, gdb_signal) /root/binutils-gdb/gdb/target.c:2648 0xc59e85 procfs_target::wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>) /root/binutils-gdb/gdb/procfs.c:2187 0xcf6da7 sol_thread_target::wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>) /root/binutils-gdb/gdb/sol-thread.c:442 0xd73711 target_wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>) /root/binutils-gdb/gdb/target.c:2586 ... The problem is that the procfs backend, while inside target_wait, called target_resume without switching to the leader thread of that resumption. The target_resume interface is: /* Resume execution (or prepare for execution) of the current thread (INFERIOR_PTID), while optionally letting other threads of the current process or all processes run free. ... Thus calling target_resume with inferior_ptid == null_ptid is bogus. target_wait (which leads to procfs_target::wait on Solaris) is called with inferior_ptid == null_ptid on entry exactly to help catch such bogus uses. From the backtrace, it seems that the relevant line in question is procfs.c:2187: 2186 /* How to keep going without returning to wfi: */ 2187 target_continue_no_signal (ptid); 2188 goto wait_again; target_continue_no_signal is a small wrapper around target_resume, which would make sense. The fix is to not call target_resume or go via the target stack at all. Instead, factor out a new proc_resume function out of procfs_target::resume, and call that. The new function does not rely on inferior_ptid. I've not been able to test it myself, but Petr confirmed it fixes the assertion failure with his test case, and Marcel Telka also confirmed it solves the problem. Tested-By: Petr Šumbera <petr.sumbera@oracle.com> Tested-By: Marcel Telka <marcel@telka.sk> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30252 Change-Id: I6213c59b081d400a22e799ee621c2eff6dcafbf3
2023-07-06ld: fix plugin tests for MIPS PICYunQiang Su10-0/+10
On MIPS, for PIC objects, symbols may reference 2 times: once from the caller, and once from GOT. Thus ld may complains 2 times about "undefined reference". So we add a new "#?" line to every effected testsuite.
2023-07-06Use run_host_cmd to run $CC and other no-section-header test fixesAlan Modra7-54/+54
We should be using run_host_cmd everywhere we invoke a compiler in the ld testsuite, if we want to use ld/ld-new just built. run_host_cmd properly inserts $gcc_B_opt in cases where a user wants to test binutils with a newly built compiler, ie. when $CC specifies -B itself. Also, it is not good practice to exclude tests when non-native except of course those tests that run a target binary. Compiling and linking often shows up problems. * testsuite/ld-elf/no-section-header.exp (binutils_run_test): Use run_host_cmd to invoke $CC_FOR_TARGET. Run all tests non-native too, except for attempting to run the binaries. Run tests for ELF in general, not just linux. * testsuite/ld-elf/pr25617-1-no-sec-hdr.rd: Allow localentry symbol decoration, and support either sorting of symbols. * testsuite/ld-elf/pr25617-1a-no-sec-hdr.rd: Likewise. * testsuite/ld-elf/pr25617-1a-sec-hdr.rd: Likewise. * testsuite/ld-elf/pr25617-1a-no-sec-hdr.nd: Accept D function syms. * testsuite/ld-elf/start-shared-noheader-sysv.rd: Accept mips-sgi-irix symbol output. * testsuite/ld-elf/start-shared-noheader.nd: Likewise.
2023-07-06Re: Stop the linker's --dependency-file option from including temporary lto ↵Alan Modra1-0/+2
files. PR 30568 * ldfile.c (ldfile_try_open_bfd): Fix build failure when !BFD_SUPPORTS_PLUGINS.
2023-07-06ld: Use run_host_cmd_yesno in indirect.exp instead of catch execYunQiang Su1-4/+1
Catch "exec $CC_FOR_TARGET" won't use the gas/ld that we just build, and in fact run_host_cmd_yesno is a better choice for it. ld/ChangeLog: * testsuite/ld-elf/indirect.exp: use run_host_cmd_yesno instead of handwrite catch exec $CC_FOR_TARGET.
2023-07-06ld: Use [list ] syntax to define run_tests in indirect.expYunQiang Su1-62/+62
Currently, the var run_tests is defined by syntax {{}}, while in this case, variables cannot be used. Thus $NOPIE_CFLAGS and $NOPIE_LDFLAGS are passed to cmd as names instead of values: gcc ... $NOPIE_CFLAGS -c .../indirect5a.c -o tmpdir/indirect5a.o Let's use [list [list ]] syntax instead. ld/ChangeLog: * testsuite/ld-elf/indirect.exp(run_tests): use [list [list]] syntax instead of {{}}.
generated by cgit v1.1 at 2024-10-11 06:51:30 +0000