aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2021-09-07[gdb/testsuite] Handle internal-error in gdb_run_cmdTom de Vries1-0/+3
When reverting commit 5a20fadc841 the test-case gdb.dwarf2/locexpr-data-member-location.exp fails like this: ... FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \ (GDB internal error) ERROR: Could not resync from internal error (eof) ... and takes 1 minute to run. The long running time is caused by running into a timeout in gdb_run_cmd, at this point: ... (gdb) run ^M The program being debugged has been started already.^M Start it from the beginning? (y or n) y^M /home/vries/gdb_versions/devel/src/gdb/gdbtypes.c:5583: internal-error: \ Unexpected type field location kind: 4^M A problem internal to GDB has been detected,^M further debugging may prove unreliable.^M Quit this debugging session? (y or n) ... Fix this by detecting the internal-error in gdb_run_cmd. We don't handle it in gdb_run_cmd, but stash the gdb output back into the buffer using -notransfer, and let the caller proc runto deal with it. After the fix, the test-case just takes 2 seconds. Tested on x86_64-linux.
2021-09-06gdb: rename gdb/testsuite/gdb.arch/riscv64-unwind-prologue-with-ld-lw.cLancelot SIX2-1/+1
A previous commit added the gdb.arch/riscv64-unwind-prologue-with-ld-lw.exp testcase, but one of its associated file was named after a previous version of the test. This commit fixes this and makes sure that all the files linked to this testcase share the same prefix in the name. Tested on riscv64 GNU/Linux.
2021-09-06[gdb/testsuite] Handle eof in gdb_internal_error_resyncTom de Vries1-0/+4
Before commit 5a20fadc841 the test-case gdb.dwarf2/locexpr-data-member-location.exp fails like this: ... FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \ (GDB internal error) ERROR: : spawn id exp9 not open while executing "expect { -i exp9 -timeout 10 -re "Quit this debugging session\\? \\(y or n\\) $" { send_gdb "n\n" answer incr count } -re "Create ..." ("uplevel" body line 1) invoked from within "uplevel $body" NONE : spawn id exp9 not open ERROR: Could not resync from internal error (timeout) ... Fix the: ... ERROR: : spawn id exp9 not open ... by handling eof in gdb_internal_error_resync, such that we have instead: ... FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \ (GDB internal error) ERROR: Could not resync from internal error (eof) ... Tested on x86_64-linux.
2021-09-06Remove some complaints.h includesTom Tromey3-3/+0
There are a few includes of complaints.h that aren't necessary. This patch removes them. Tested by rebuilding.
2021-09-06gdbtypes.c: Add the case for FIELD_LOC_KIND_DWARF_BLOCKAlexandra Hájková1-0/+4
The case for FIELD_LOC_KIND_DWARF_BLOCK was missing for switch TYPE_FIELD_LOC_KIND. Thas caused an internal-error under some circumstances. Fixes bug 28030.
2021-09-04[gdb/testsuite] Check avx support in gdb.arch/amd64-disp-step-avx.expTom de Vries4-83/+103
On a machine on Open Build Service I'm running into a SIGILL for test-case gdb.arch/amd64-disp-step-avx.exp: ... Program received signal SIGILL, Illegal instruction.^M test_rip_vex2 () at gdb.arch/amd64-disp-step-avx.S:40^M 40 vmovsd ro_var(%rip),%xmm0^M (gdb) FAIL: gdb.arch/amd64-disp-step-avx.exp: vex2: \ continue to test_rip_vex2_end ... The SIGILL happens when trying to execute the first avx instruction in the executable. I can't directly access the machine, but looking at the log for test-case gdb.arch/i386-avx.exp, it seems that there's no avx support: ... Breakpoint 1, main (argc=1, argv=0x7fffffffd6b8) at gdb.arch/i386-avx.c:68^M 68 if (have_avx ())^M (gdb) print have_avx ()^M $1 = 0^M ... Fix this by: - adding a gdb_caching_proc have_avx, similar to have_mpx, using the have_avx function from gdb.arch/i386-avx.c - using proc have_avx in both gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp and gdb/testsuite/gdb.arch/i386-avx.exp. Tested on my x86_64-linux laptop with avx support, where both test-cases pass. gdb/testsuite/ChangeLog: 2021-09-04 Tom de Vries <tdevries@suse.de> PR testsuite/26950 * gdb/testsuite/gdb.arch/i386-avx.c (main): Remove call to have_avx. (have_avx): Move ... * gdb/testsuite/lib/gdb.exp (have_avx): ... here. New proc. * gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp: Use have_avx. * gdb/testsuite/gdb.arch/i386-avx.exp: Same.
2021-09-03Use CORE_ADDR as return type from x86_dr_low_get_addrTom Tromey1-1/+1
On a Windows build locally, watchpoints started failing. I tracked this down to x86_dr_low_get_addr returning an 'unsigned long'... in this particular build, this is a 32-bit type, but the inferior is a 64-bit program. This patch fixes the problem by changing the return type. No other change is required, because this matches the function pointer in struct x86_dr_low_type.
2021-09-03Test case reproducing PR28030 bugKevin Buettner4-0/+454
The original reproducer for PR28030 required use of a specific compiler version - gcc-c++-11.1.1-3.fc34 is mentioned in the PR, though it seems probable that other gcc versions might also be able to reproduce the bug as well. This commit introduces a test case which, using the DWARF assembler, provides a reproducer which is independent of the compiler version. (Well, it'll work with whatever compilers the DWARF assembler works with.) To the best of my knowledge, it's also the first test case which uses the DWARF assembler to provide debug info for a shared object. That being the case, I provided more than the usual commentary which should allow this case to be used as a template when a combo shared library / DWARF assembler test case is required in the future. I provide some details regarding the bug in a comment near the beginning of locexpr-dml.exp. This problem was difficult to reproduce; I found myself constantly referring to the backtrace while trying to figure out what (else) I might be missing while trying to create a reproducer. Below is a partial backtrace which I include for posterity. #0 internal_error ( file=0xc50110 "/ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c", line=5575, fmt=0xc520c0 "Unexpected type field location kind: %d") at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdbsupport/errors.cc:51 #1 0x00000000006ef0c5 in copy_type_recursive (objfile=0x1635930, type=0x274c260, copied_types=0x30bb290) at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c:5575 #2 0x00000000006ef382 in copy_type_recursive (objfile=0x1635930, type=0x274ca10, copied_types=0x30bb290) at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c:5602 #3 0x0000000000a7409a in preserve_one_value (value=0x24269f0, objfile=0x1635930, copied_types=0x30bb290) at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/value.c:2529 #4 0x000000000072012a in gdbscm_preserve_values ( extlang=0xc55720 <extension_language_guile>, objfile=0x1635930, copied_types=0x30bb290) at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/guile/scm-value.c:94 #5 0x00000000006a3f82 in preserve_ext_lang_values (objfile=0x1635930, copied_types=0x30bb290) at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/extension.c:568 #6 0x0000000000a7428d in preserve_values (objfile=0x1635930) at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/value.c:2579 #7 0x000000000082d514 in objfile::~objfile (this=0x1635930, __in_chrg=<optimized out>) at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:549 #8 0x0000000000831cc8 in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x1654580) at /usr/include/c++/11/bits/shared_ptr_base.h:348 #9 0x00000000004e6617 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x1654580) at /usr/include/c++/11/bits/shared_ptr_base.h:168 #10 0x00000000004e1d2f in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x190bb88, __in_chrg=<optimized out>) at /usr/include/c++/11/bits/shared_ptr_base.h:705 #11 0x000000000082feee in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x190bb80, __in_chrg=<optimized out>) at /usr/include/c++/11/bits/shared_ptr_base.h:1154 #12 0x000000000082ff0a in std::shared_ptr<objfile>::~shared_ptr ( this=0x190bb80, __in_chrg=<optimized out>) at /usr/include/c++/11/bits/shared_ptr.h:122 #13 0x000000000085ed7e in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x114bc00, __p=0x190bb80) at /usr/include/c++/11/ext/new_allocator.h:168 #14 0x000000000085e88d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x190bb80) at /usr/include/c++/11/bits/alloc_traits.h:531 #15 0x000000000085e50c in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x114bc00, __position= std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x1635930}) at /usr/include/c++/11/bits/stl_list.h:1925 #16 0x000000000085df0e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x114bc00, __position= std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x1635930}) at /usr/include/c++/11/bits/list.tcc:158 #17 0x000000000085c748 in program_space::remove_objfile (this=0x114bbc0, objfile=0x1635930) at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/progspace.c:210 #18 0x000000000082d3ae in objfile::unlink (this=0x1635930) at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:487 #19 0x000000000082e68c in objfile_purge_solibs () at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:875 #20 0x000000000092dd37 in no_shared_libraries (ignored=0x0, from_tty=1) at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/solib.c:1236 #21 0x00000000009a37fe in target_pre_inferior (from_tty=1) at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/target.c:2496 #22 0x00000000007454d6 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/infcmd.c:437 I'll note a few points regarding this backtrace: Frame #1 is where the internal error occurs. It's caused by an unhandled case for FIELD_LOC_KIND_DWARF_BLOCK. The fix for this bug adds support for this case. Frame #22 - it's a partial backtrace - shows that GDB is attempting to (re)run the program. You can see the exact command sequence that was used for reproducing this problem in the PR (at https://sourceware.org/bugzilla/show_bug.cgi?id=28030), but in a nutshell, after starting the program and advancing to the appropriate source line, GDB was asked to step into libstdc++; a "finish" command was issued, returning a value. The fact that a value was returned is very important. GDB was then used to step back into libstdc++. A breakpoint was set on a source line in the library after which a "run" command was issued. Frame #19 shows a call to objfile_purge_solibs. It's aptly named. Frame #7 is a call to the destructor for one of the objfile solibs; it turned out to be the one for libstdc++. Frames #6 thru #3 show various value preservation frames. If you look at preserve_values() in gdb/value.c, the value history is preserved first, followed by internal variables, followed by values for the extension languages (python and guile).
2021-09-03[gdb/testsuite] Add untested case in gdb.gdb/complaints.expTom de Vries1-0/+20
When building gdb with "-Wall -O2 -g -flto=auto", I run into: ... (gdb) call clear_complaints()^M No symbol "clear_complaints" in current context.^M (gdb) FAIL: gdb.gdb/complaints.exp: clear complaints ... The problem is that lto has optimized away clear_complaints, and consequently the selftests cannot run. Fix this by: - using info function to detect presence of clear_complaints - handling the absence of clear_complaints by calling untested ... (gdb) UNTESTED: gdb.gdb/complaints.exp: \ Cannot find clear_complaints, skipping test ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-09-03 Tom de Vries <tdevries@suse.de> * gdb.gdb/complaints.exp: Use untested if clear_complaints cannot be found.
2021-09-03gdb: Enable finish command and inferior calls for _Float16 on amd64 and i386.Felix Willgerodt4-7/+115
Values of type _Float16 and _Float16 _Complex can now be used on CPUs with AVX512-FP16 support. Return values of those types are located in XMM0. Compiler support for gcc and clang is in progress, see e.g.: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574117.html gdb/ChangeLog: 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com> * amd64-tdep.c (amd64_classify): Classify _Float16 and _Float16 _Complex as AMD64_SSE. * i386-tdep.c (i386_extract_return_value): Read _Float16 and _Float16 _Complex from xmm0. gdb/testsuite/ChangeLog: 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com> * gdb.arch/x86-avx512fp16-abi.c: New file. * gdb.arch/x86-avx512fp16-abi.exp: New file.
2021-09-03Add half support for AVX512 register view.Felix Willgerodt10-0/+310
This adds support for the half datatype, FP16, to the AVX512 register printing. gdb/ChangeLog: 2020-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com> * i386-tdep.c (i386_zmm_type) <v32_half>: New field. (i386_ymm_type) <v16_half>: New field. (i386_gdbarch_init): Add set_gdbarch_half_format. * features/i386/64bit-avx512.xml: Add half type. * features/i386/64bit-avx512.c: Regenerated. * features/i386/64bit-sse.xml: Add half type. * features/i386/64bit-sse.c: Regenerated. gdb/testsuite/ChangeLog: 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com> * gdb.arch/x86-avx512fp16.c: New file. * gdb.arch/x86-avx512fp16.exp: New file. * lib/gdb.exp (skip_avx512fp16_tests): New function.
2021-09-03gdb, i386: Enable AVX512-bfloat16 for i386 targets.Felix Willgerodt3-6/+13
Values of type bfloat16 can also be used on 32-bit targets, which was missed in the original enablement. This also adjusts the testcase to pass with "unix/-m32", where only the lower 8 AVX registers are available. gdb/ChangeLog: 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com> * features/i386/32bit-sse.xml: Add bfloat16 type. * features/i386/32bit-sse.c: Regenerated. gdb/testsuite/ChangeLog: 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com> * gdb.arch/x86-avx512bf16.exp: Only use x/z/ymm 0-7.
2021-09-03[gdb/testsuite] Add untested case in selftest_setupTom de Vries1-7/+9
When building gdb with "-Wall -O2 -g -flto=auto", I run into: ... FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \ (got interactive prompt) FAIL: gdb.gdb/python-helper.exp: run until breakpoint at captured_main WARNING: Couldn't test self ... and similar in gdb.gdb/selftest.exp. The first FAIL in more detail: ... (gdb) break captured_main^M Function "captured_main" not defined.^M Make breakpoint pending on future shared library load? (y or [n]) n^M (gdb) FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \ (got interactive prompt) ... The problem is that lto has optimized away the captured_main function and consequently the selftests dependent on that cannot run. Fix this by: - using gdb_breakpoint to detect failure to set the breakpoint - handling the failure to set a breakpoint by calling untested - not emitting the warning if we've already got untested such that we have: ... (gdb) UNTESTED: gdb.gdb/python-helper.exp: Cannot set breakpoint at \ captured_main, skipping testcase. ... gdb/testsuite/ChangeLog: 2021-09-02 Tom de Vries <tdevries@suse.de> * lib/selftest-support.exp: Emit untested when not being able to set breakpoint.
2021-09-01[gdb/testsuite] Fix dwo path in fission-*.STom de Vries8-20/+9
[ Using $build for /home/vries/gdb_versions/devel/build to make things a bit more readable. ] When using make check// to run test-case gdb.dwarf2/fission-base.exp: ... ( cd $build/gdb; make check//unix RUNTESTFLAGS="fission-base.exp" ) ... we run into: ... (gdb) file \ $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base^M Reading symbols from \ $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base...^M warning: Could not find DWO CU \ $build/gdb/testsuite.1/outputs/gdb.dwarf2/fission-base/fission-base.dwo \ (0x807060504030201) referenced by CU at offset 0xc7 [in module \ $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base]^M ... The problem is that the executable refers to the dwo file using path name $build/gdb/testsuite.1/outputs/gdb.dwarf2/fission-base/fission-base.dwo, while the actual dwo file is at $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base.dwo. This is caused by this trick in fission-base.S: ... #define XSTR(s) STR(s) #define STR(s) #s ... .asciz XSTR(DWO) # DW_AT_GNU_dwo_name ... and: ... $ echo | gcc -E -dD - | grep "define unix" ... I used this trick to avoid doing additional_flags=-DDWO=\"$dwo\", since I was concerned that there could be quoting issues. However, I've found other uses of this pattern, f.i. in gdb/testsuite/gdb.base/corefile-buildid.exp: ... additional_flags=-DSHLIB_NAME=\"$dlopen_lib\"] ... So, fix this by: - using additional_flags=-DDWO=\"$dwo\" and - using plain DWO instead of XSTR(DWO) Likewise in other gdb.dwarf2/fission*.exp test-cases. Tested on x86_64-linux, using make check//unix. gdb/testsuite/ChangeLog: 2021-09-01 Tom de Vries <tdevries@suse.de> PR testsuite/28298 * gdb.dwarf2/fission-base.S: Use DWO instead of XSTR(DWO). * gdb.dwarf2/fission-loclists-pie.S: Same. * gdb.dwarf2/fission-loclists.S: Same. * gdb.dwarf2/fission-reread.S: Same. * gdb.dwarf2/fission-base.exp: Use additional_flags=-DDWO=\"$dwo\". * gdb.dwarf2/fission-loclists-pie.exp: Same. * gdb.dwarf2/fission-loclists.exp: Same. * gdb.dwarf2/fission-reread.exp: Same.
2021-09-01[gdb/testsuite] Fix gdb.fortran/call-no-debug.exp symbol searchTom de Vries1-7/+12
On openSUSE Tumbleweed I ran into: ... (gdb) ptype outstring_func.part^M No symbol "outstring_func" in current context.^M (gdb) FAIL: gdb.fortran/call-no-debug.exp: ptype outstring_func.part ... while on openSUSE Leap 15.2 I have instead: ... (gdb) ptype string_func_^M type = <unknown return type> ()^M (gdb) PASS: gdb.fortran/call-no-debug.exp: ptype string_func_ ... The difference is caused by the result for "info function string_func", which is this for the latter: ... (gdb) info function string_func^M All functions matching regular expression "string_func":^M ^M Non-debugging symbols:^M 0x000000000040089c string_func_^M ... but this for the former: ... (gdb) info function string_func^M All functions matching regular expression "string_func":^M ^M Non-debugging symbols:^M 0x00000000004012bb string_func_^M 0x00007ffff7bac5b0 outstring_func.part^M 0x00007ffff7bb1a00 outstring_func.part^M ... The extra symbols are part of glibc: ... $ nm /lib64/libc.so.6 | grep string_func 00000000000695b0 t outstring_func.part.0 000000000006ea00 t outstring_func.part.0 ... If glibc debug info is installed, we get instead: ... (gdb) info function string_func^M All functions matching regular expression "string_func":^M ^M File /usr/src/debug/glibc-2.33-9.1.x86_64/stdio-common/vfprintf-internal.c:^M 236: static int outstring_func(int, size_t, const unsigned int *, FILE *);^M ^M File vfprintf-internal.c:^M 236: static int outstring_func(int, size_t, const unsigned char *, FILE *);^M ^M Non-debugging symbols:^M 0x00000000004012bb string_func_^M ... and the FAIL doesn't trigger. Fix this by calling "info function string_func" before starting the exec, such that only symbols of the exec are taken into account. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-09-01 Tom de Vries <tdevries@suse.de> * gdb.fortran/call-no-debug.exp: Avoid shared lib symbols for find_mangled_name calls.
2021-08-31gdb: remove breakpoint_find_ifSimon Marchi4-44/+15
Remove breakpoint_find_if, replace its sole usage with using all_breakpoints directly instead. At the same time, change return types to use bool. Change-Id: I9ec392236b4804b362d16ab563330b9c07311106
2021-08-30Use gdbfmt for vprintf_filtered.John Baldwin1-17/+9
gdbfmt was already used for printf_filtered, so using it for vprintf_filtered is more consistent. As a result, all callers of vfprintf_maybe_filtered now use gdbfmt, so the function can be simplified to assume the gdbfmt case and remove the associated bool argument. Similary, vprintf_filtered is now a simple wrapper around vfprintf_filtered.
2021-08-30fbsd-nat: Don't use '%jd' and '%ju' with printf_filtered.John Baldwin1-22/+23
The handler for 'info proc status' for native processes on FreeBSD uses the 'j' size modifier along with uintmax_t / intmax_t casts to output integer values for types such as off_t that are not aliases of a basic C type such as 'int' or 'long'. printf_filtered does not support the 'j' modifer, so this resulted in runtime errors in practice: (gdb) info proc stat process 8674 Name: ls State: T (stopped) Parent process: 8673 Process group: 8674 Session id: 2779 Unrecognized format specifier 'j' in printf Instead, use plongest and pulongest to generate the output strings of these integer values.
2021-08-30gdb: fix build error in unittests/parallel-for-selftests.cSimon Marchi1-1/+1
We get this error when building GDB on some platforms. I get it using g++-10 on Ubuntu 20.04 (installed using the distro package). It was also reported by John Baldwin, using a clang that uses libc++. CXX unittests/parallel-for-selftests.o cc1plus: warning: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++ /home/smarchi/src/binutils-gdb/gdb/unittests/parallel-for-selftests.c: In function 'void selftests::parallel_for::test(int)': /home/smarchi/src/binutils-gdb/gdb/unittests/parallel-for-selftests.c:53:30: error: use of deleted function 'std::atomic<int>::atomic(const std::atomic<int>&)' 53 | std::atomic<int> counter = 0; | ^ In file included from /usr/include/c++/9/future:42, from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/thread-pool.h:29, from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/parallel-for.h:26, from /home/smarchi/src/binutils-gdb/gdb/unittests/parallel-for-selftests.c:22: /usr/include/c++/9/atomic:755:7: note: declared here 755 | atomic(const atomic&) = delete; | ^~~~~~ /usr/include/c++/9/atomic:759:17: note: after user-defined conversion: 'constexpr std::atomic<int>::atomic(std::atomic<int>::__integral_type)' 759 | constexpr atomic(__integral_type __i) noexcept : __base_type(__i) { } | ^~~~~~ I haven't dug to know why it does not happen everywhere, but this patch fixes it by using the constructor to initialize the variable, rather than the assignment operator. Change-Id: I6b27958171bf6187f6a875657395fd10441db7e6
2021-08-30Add some parallel_for_each testsTom Tromey2-0/+87
Tom de Vries noticed that a patch in the DWARF scanner rewrite series caused a regression in parallel_for_each -- it started crashing in the case where the number of threads is 0 (there was an unchecked use of "n-1" that was used to size an array). He also pointed out that there were no tests of parallel_for_each. This adds a few tests of parallel_for_each, primarily testing that different settings for the number of threads will work. This test catches the bug that he found in that series.
2021-08-30Add a show function for "maint show worker-threads"Tom Tromey1-1/+17
I wanted to see how many threads gdb thought it was using, but "maint show worker-threads" only reported "unlimited". This patch adds a show function so that it will now report the number of threads gdb has started. Regression tested on x86-64 Fedora 34.
2021-08-30[gdb/cli] Don't assert on empty string for core-fileTom de Vries2-1/+6
With current gdb we run into: ... $ gdb -batch '' '' : No such file or directory. pathstuff.cc:132: internal-error: \ gdb::unique_xmalloc_ptr<char> gdb_abspath(const char*): \ Assertion `path != NULL && path[0] != '\0'' failed. ... Fix this by skipping the call to gdb_abspath in core_target_open in the empty-string case, such that we have instead: ... $ gdb -batch '' '' : No such file or directory. : No such file or directory. $ ... Tested on x86_64-linux. gdb/ChangeLog: 2021-08-30 Tom de Vries <tdevries@suse.de> PR cli/28290 * gdb/corelow.c (core_target_open): Skip call to gdb_abspath in the empty-string case. gdb/testsuite/ChangeLog: 2021-08-30 Tom de Vries <tdevries@suse.de> PR cli/28290 * gdb.base/batch-exit-status.exp: Add gdb '' and gdb '' '' tests.
2021-08-30[gdb/testsuite] Improve argument syntax of proc arangeTom de Vries7-56/+150
The current syntax of proc arange is: ... proc arange { arange_start arange_length {comment ""} {seg_sel ""} } { ... and a typical call looks like: ... arange $start $len ... This style is somewhat annoying because if you want to specify the last parameter, you need to give the default values of all the other optional ones before as well: ... arange $start $len "" $seg_sel ... Update the syntax to: ... proc arange { options arange_start arange_length } { parse_options { { comment "" } { seg_sel "" } } ... such that a typical call looks like: ... arange {} $start $len ... and a call using seg_sel looks like: ... arange { seg_sel $seg_sel } $start $len ... Also update proc aranges, which already has an options argument, to use the new proc parse_options. Tested on x86_64-linux. Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>
2021-08-27[gdb/symtab] Don't write .gdb_index symbol table with empty entriesTom de Vries1-0/+3
When comparing the sizes of the index files generated for shlib outputs/gdb.dwarf2/dw2-zero-range/shr1.sl, I noticed a large difference between .debug_names: ... $ gdb -q -batch $shlib -ex "save gdb-index -dwarf-5 ." $ du -b -h shr1.sl.debug_names shr1.sl.debug_str 61 shr1.sl.debug_names 0 shr1.sl.debug_str ... and .gdb_index: ... $ gdb -q -batch $shlib -ex "save gdb-index ." $ du -b -h shr1.sl.gdb-index 8.2K shr1.sl.gdb-index ... The problem is that the .gdb_index contains a non-empty symbol table with only empty entries. Fix this by making the symbol table empty, such that we have instead: ... $ du -b -h shr1.sl.gdb-index 184 shr1.sl.gdb-index ... Tested on x86_64-linux.
2021-08-27[gdb/testsuite] Generate .debug_aranges in gdb.dlang/watch-loc.expTom de Vries2-41/+8
Before commit 5ef670d81fd "[gdb/testsuite] Add dummy start and end CUs in dwarf assembly" we had in exec outputs/gdb.dlang/watch-loc/watch-loc a D compilation unit at offset 0xc7: ... Compilation Unit @ offset 0xc7: Length: 0x4c (32-bit) Version: 4 Abbrev Offset: 0x64 Pointer Size: 8 <0><d2>: Abbrev Number: 2 (DW_TAG_compile_unit) <d3> DW_AT_language : 19 (D) ... with a corresponding .debug_aranges entry: ... Offset into .debug_info: 0xc7 Pointer Size: 4 Segment Size: 0 Address Length 004004a7 0000000b 00000000 00000000 ... After that commit we have a dummy CU at offset 0xc7 and the D compilation unit at offset 0xd2: ... Compilation Unit @ offset 0xc7: Length: 0x7 (32-bit) Version: 4 Abbrev Offset: 0x64 Pointer Size: 8 Compilation Unit @ offset 0xd2: Length: 0x4c (32-bit) Version: 4 Abbrev Offset: 0x65 Pointer Size: 8 <0><dd>: Abbrev Number: 2 (DW_TAG_compile_unit) <de> DW_AT_language : 19 (D) ... while the .debug_aranges entry still points to 0xc7. The problem is that the test-case uses a hack (quoting from commit 75f06e9dc59): ... [ Note: this is a non-trivial test-case. The file watch-loc-dw.S contains a .debug_info section, but not an .debug_aranges section or any actual code. The file watch-loc.c contains code and a .debug_aranges section, but no other debug section. So, the intent for the .debug_aranges section in watch-loc.c is to refer to a compilation unit in the .debug_info section in watch-loc-dw.S. ] ... and adding the dummy CU caused that hack to stop working. Fix this by moving the generation of .debug_aranges from watch-loc.c to watch-loc.exp, such that we have: ... Offset into .debug_info: 0xd2 Pointer Size: 4 Segment Size: 0 Address Length 004004a7 0000000b 00000000 00000000 ... Tested on x86_64-linux.
2021-08-27[gdb/testsuite] Generate .debug_aranges entry for dummy CUTom de Vries1-1/+5
A best practise for DWARF [1] is to generate .debug_aranges entries for CUs even if they have no address range. Generate .debug_arange entries for the dummy CUs added by the DWARF assembler. Tested on x86_64-linux. [1] http://wiki.dwarfstd.org/index.php?title=Best_Practices
2021-08-27[gdb/testsuite] Add .debug_aranges in more test-casesTom de Vries3-3/+22
A couple of test-cases fail when run with target board cc-with-debug-names due to missing .debug_aranges entries for the CUs added by the dwarf assembler. Add a .debug_aranges entry for those CUs. Tested on x86_64-linux.
2021-08-27[gdb/testsuite] Support .debug_aranges in dwarf assemblyTom de Vries1-0/+153
Add a proc aranges such that we can generate .debug_aranges sections in dwarf assembly using: ... cu { label cu_label } { ... } aranges {} cu_label { arange $addr $len [<comment>] [$segment_selector] } ... Tested on x86_64-linux.
2021-08-27[gdb/testsuite] Add label option to proc cuTom de Vries1-0/+11
We can use current dwarf assembly infrastructure to declare a label that marks the start of the CU header: ... declare_labels header_start_cu_a _section ".debug_info" header_start_cu_a : cu {} { } _section ".debug_info" header_start_cu_b : cu {} { } ... on the condition that we switch to the .debug_info section before, which makes this style of use fragile. Another way to achieve the same is to use the label as generated by the cu proc itself: ... variable _cu_label cu {} { } set header_start_cu_a $_cu_label cu {} { } set header_start_cu_b $_cu_label ... but again that seems fragile given that adding a new CU inbetween will silently result in the wrong value for the label. Add a label option to proc cu such that we can simply do: ... cu { label header_start_cu_a } { } cu { label header_start_cu_b } { } ... Tested on x86_64-linux.
2021-08-26gdb: remove some stray newlines in debug outputAndrew Burgess1-2/+2
I spotted a couple of stray newlines that were left at the end of debug message during conversion to the new debug output scheme. These messages are part of the 'set debug lin-lwp 1' output.
2021-08-24Fix two regressions caused by CU / TU mergingTom Tromey2-39/+85
PR symtab/28160 and PR symtab/27893 concern GDB crashes in the test suite when using the "fission" target board. They are both caused by the patches that merge the list of CUs with the list of TUs (and to a lesser degree by the patches to share DWARF data across objfiles), and the underlying issue is the same: it turns out that reading a DWO can cause new type units to be created. This means that the list of dwarf2_per_cu_data objects depends on precisely which CUs have been expanded. However, because the type units can be created while expanding a CU means that the vector of CUs can expand while it is being iterated over -- a classic mistake. Also, because a TU can be added later, it means the resize_symtabs approach is incorrect. This patch fixes resize_symtabs by removing it, and having set_symtab resize the vector on demand. It fixes the iteration problem by introducing a safe (index-based) iterator and changing the relevant spots to use it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28160 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27893
2021-08-23Fix a latent bug in dw2-ranges-overlap.expTom Tromey2-6/+13
dw2-ranges-overlap.exp creates a program where a psymtab has two address ranges, and a function without debug info whose address is between these two ranges. Then it sets a breakpoint on this function and runs to it, expecting that the language should remain "auto; c" when stopped. However, this test case also has a "main" function described (briefly) in the DWARF, and this function is given language C++. Also, a breakpoint stop sets the current language to the language that was used when setting the breakpoint. My new DWARF scanner decides that this "main" is the main program and sets the current language to C++ at startup, causing this test to fail. This patch fixes the test in a simple way, by introducing a new function that takes the place of "main" in the DWARF. I think this still exercises the original problem, but also avoids problems with my branch. It seemed safe to me to submit this separately.
2021-08-23[gdb] Fix 'not in executable format' error messageTom de Vries2-5/+35
With trying to load a non-executable file into gdb, we run into PR26880: ... $ gdb -q -batch test.c "0x7ffc87bfc8d0s": not in executable format: \ file format not recognized ... The problem is caused by using %ps in combination with the error function (note that confusingly, it does work in combination with the warning function). Fix this by using plain "%s" instead. Tested on x86_64-linux. gdb/ChangeLog: 2021-08-22 Tom de Vries <tdevries@suse.de> PR gdb/26880 * gdb/exec.c (exec_file_attach): Use %s instead of %ps in call to error function. gdb/testsuite/ChangeLog: 2021-08-22 Tom de Vries <tdevries@suse.de> PR gdb/26880 * gdb.base/non-executable.exp: New file.
2021-08-23[gdb/testsuite] Use compiler-generated instead of gas-generated stabsTom de Vries1-12/+3
The test-case gdb.dwarf2/dw2-ranges.exp is the only one in the gdb testsuite that uses gas-generated stabs. While the use seems natural alongside the use of gas-generated dwarf in the same test-case, there are a few known issues, filed on the gdb side as: - PR symtab/12497 - "stabs: PIE relocation does not work" - PR symtab/28221 - "[readnow, stabs] FAIL: gdb.dwarf2/dw2-ranges.exp: \ info line func" and on the gas side as: - PR gas/28233 - "[gas, --gstabs] Generate stabs more similar to gcc" The test-case contains a KFAIL for PR12497, but it's outdated and fails to trigger. The intention of the test-case is to test gas-generated dwarf, and using gcc-generated stabs instead of gas-generated stabs works fine. Supporting compiler-generated stabs is already a corner-case for gdb, and there's no current commitment/incentive to support/workaround gas-generated stabs, which can be considered a corner-case of a corner-case. Work around these problem by using compiler-generated stabs in the test-case. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-08-22 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-ranges.exp: Use compiler-generated stabs.
2021-08-23[gdb/testsuite] Add dummy start and end CUs in dwarf assemblyTom de Vries1-1/+16
Say one compiles a hello.c: ... $ gcc -g hello.c ... On openSUSE Leap 15.2 and Tumbleweed, the CU for hello.c is typically not the first in .debug_info, nor the last, due to presence of debug information in objects for sources like: - ../sysdeps/x86_64/start.S - init.c - ../sysdeps/x86_64/crti.S - elf-init.c - ../sysdeps/x86_64/crtn.S. On other systems, say ubuntu 18.04.5, the CU for hello.c is typically the first and the last in .debug_info. This difference has caused me to find some errors in the dwarf assembly using openSUSE, that didn't show up on other platforms. Force the same situation on other platforms by adding a dummy start and end CU. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-08-22 Tom de Vries <tdevries@suse.de> PR testsuite/28235 * lib/dwarf.exp (Dwarf::dummy_cu): New proc. (Dwarf::assemble): Add dummy start and end CU.
2021-08-23[gdb/testsuite] Fix dw2-ranges-psym.exp with -readnowTom de Vries1-1/+5
When running test-case gdb.dwarf2/dw2-ranges-psym.exp with target board -readnow, I run into: ... (gdb) file dw2-ranges-psym^M Reading symbols from dw2-ranges-psym...^M Expanding full symbols from dw2-ranges-psym...^M (gdb) set complaints 0^M (gdb) FAIL: gdb.dwarf2/dw2-ranges-psym.exp: No complaints ... The problem is that the regexp expects a gdb prompt immediately after the "Reading symbols" line. Fix this by updating the regexp. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-08-22 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_load_no_complaints): Update regexp to allow "Expanding full symbols" Line.
2021-08-19gdb: use bool in notify_command_param_changed_p and do_set_commandSimon Marchi1-16/+16
Trivial patch to use bool instead of int. Change-Id: I9e5f8ee4305272a6671cbaaaf2f0484eff0d1ea5
2021-08-18gdb/solib: Refactor scan_dyntagAaron Merey4-210/+122
scan_dyntag is unnecessarily duplicated in solib-svr4.c and solib-dsbt.c. Move this function to solib.c and rename it to gdb_bfd_scan_elf_dyntag. Also add it to solib.h so it is included in both solib-svr4 and solib-dsbt.
2021-08-18[gdb] [rs6000] Add ppc64_linux_gcc_target_options method.Will Schmidt1-0/+10
Add a method to set the gcc target options for the ppc64 targets. This change sets an empty value, which allows the gcc default values (-mcmodel=medium) be used, instead of -mcmodel=large which is set by the default_gcc_target_options hook.
2021-08-18[gdb] [rs6000] Add ppc64*_gnu_triplet_regexp methods.Will Schmidt1-0/+29
Add methods to set the target triplet so we can find the proper gcc when our gcc is named of the form powerpc64{le}-<foo>-gcc or ppc64{le}-<foo>-gcc.
2021-08-17gdb: fix spacing on CCLD silent rulesMike Frysinger1-1/+1
2021-08-17gdb: fix thread_step_over_chain_lengthSimon Marchi1-1/+1
If I debug a single-thread program and look at the infrun debug logs, I see: [infrun] start_step_over: stealing global queue of threads to step, length = 2 That makes no sense... turns out there's a buglet in thread_step_over_chain_length, "num" should be initialized to 0. I think this bug is a leftover from an earlier version of the code (not merged upstream) that manually walked the list, where the first item was implicitly counted (hence the 1). Change-Id: I0af03aa93509aed36528be5076894dc156a0b5ce
2021-08-17gdb: Don't assume r_ldsomap when r_version > 1 on LinuxH.J. Lu27-32/+97
The r_ldsomap field is specific to Solaris (part of librtld_db), and should never be accessed for Linux. glibc is planning to add a field to support multiple namespaces. But there will be no r_ldsomap when r_version is bumped to 2. Add linux_[ilp32|lp64]_fetch_link_map_offsets to set r_ldsomap_offset to -1 and use them for Linux targets. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28236
2021-08-16Fix register regression in DWARF evaluatorTom Tromey1-1/+3
On an internal test case, using an arm-elf target, commit ba5bc3e5a92 ("Make DWARF evaluator return a single struct value") causes a regression. (It doesn't happen for any of the other cross targets that I test when importing upstream gdb.) I don't know if there's an upstream gdb test case showing the same problem... I can only really run native tests with dejagnu AFAIK. The failure manifests like this: Breakpoint 1, file_1.export_1 (param_1=<error reading variable: Unable to access DWARF register number 64>, str=...) at [...]/file_1.adb:5 Whereas when it works it looks like: Breakpoint 1, file_1.export_1 (param_1=99.0, str=...) at [...]/file_1.adb:5 The difference is that the new code uses the passed-in gdbarch, whereas the old code used the frame's gdbarch, when handling DWARF_VALUE_REGISTER. This patch restores the use of the frame's arch.
2021-08-16Fix Ada regression due to DWARF expression seriesTom Tromey1-1/+3
Commit 0579205aec4 ("Simplify dwarf_expr_context class interface") caused a regression in the internal AdaCore test suite. I didn't try to reproduce this with the GDB test suite, but the test is identical to gdb.dwarf2/dynarr-ptr.exp. The problem is that this change: case DW_OP_push_object_address: /* Return the address of the object we are currently observing. */ - if (this->data_view.data () == nullptr - && this->obj_address == 0) + if (this->m_addr_info == nullptr) ... slightly changes the logic here. In particular, it's possible for the caller to pass in a non-NULL m_addr_info, but one that looks like: (top) p *this.m_addr_info $15 = { type = 0x29b7a70, valaddr = { m_array = 0x0, m_size = 0 }, addr = 0, next = 0x0 } In this case, an additional check is needed. With the current code, what happens instead is that the computation computes an incorrect address -- but one that does not fail in read_memory, due to the precise memory map of the embedded target in question. This patch restores the old logic.
2021-08-16Notify observer of breakpoint auto-disablingPatrick Monnerat3-1/+65
As breakpoint_modified observer is currently notified upon breakpoint stop before handling auto-disabling when enable count is reached, the observer is never notified of the disabling. The problem affects: - The MI interpreter enabled= value when reporting =breakpoint-modified - A Python event handler for breakpoint_modified using the "enabled" member of its parameter - insight: breakpoint GUI window is not properly updated upon auto-disable This patch moves the observer notification after the auto-disabling code and implements corresponding tests for the MI and Python cases. Fixes https://sourceware.org/bugzilla/show_bug.cgi?id=23336 Change-Id: I0c50df4789334071e5390cb46b3ca0d4a7f83c61
2021-08-12gdb: riscv_scan_prologue: handle LD and LW instructionsLancelot SIX4-0/+182
While working on the testsuite, I ended up noticing that GDB fails to produce a full backtrace from a thread waiting in pthread_join. When selecting the waiting thread and using the 'bt' command, the following result can be observed: (gdb) bt #0 0x0000003ff7fccd20 in __futex_abstimed_wait_common64 () from /lib/riscv64-linux-gnu/libpthread.so.0 #1 0x0000003ff7fc43da in __pthread_clockjoin_ex () from /lib/riscv64-linux-gnu/libpthread.so.0 Backtrace stopped: frame did not save the PC On my platform, I do not have debug symbols for glibc, so I need to rely on prologue analysis in order to unwind stack. Here is what the function prologue looks like: (gdb) disassemble __pthread_clockjoin_ex Dump of assembler code for function __pthread_clockjoin_ex: 0x0000003ff7fc42de <+0>: addi sp,sp,-144 0x0000003ff7fc42e0 <+2>: sd s5,88(sp) 0x0000003ff7fc42e2 <+4>: auipc s5,0xd 0x0000003ff7fc42e6 <+8>: ld s5,-2(s5) # 0x3ff7fd12e0 0x0000003ff7fc42ea <+12>: ld a5,0(s5) 0x0000003ff7fc42ee <+16>: sd ra,136(sp) 0x0000003ff7fc42f0 <+18>: sd s0,128(sp) 0x0000003ff7fc42f2 <+20>: sd s1,120(sp) 0x0000003ff7fc42f4 <+22>: sd s2,112(sp) 0x0000003ff7fc42f6 <+24>: sd s3,104(sp) 0x0000003ff7fc42f8 <+26>: sd s4,96(sp) 0x0000003ff7fc42fa <+28>: sd s6,80(sp) 0x0000003ff7fc42fc <+30>: sd s7,72(sp) 0x0000003ff7fc42fe <+32>: sd s8,64(sp) 0x0000003ff7fc4300 <+34>: sd s9,56(sp) 0x0000003ff7fc4302 <+36>: sd a5,40(sp) As far as prologue analysis is concerned, the most interesting part is done at address 0x0000003ff7fc42ee (<+16>): 'sd ra,136(sp)'. This stores the RA (return address) register on the stack, which is the information we are looking for in order to identify the caller. In the current implementation of the prologue scanner, GDB stops when hitting 0x0000003ff7fc42e6 (<+8>) because it does not know what to do with the 'ld' instruction. GDB thinks it reached the end of the prologue but have not yet reached the important part, which explain GDB's inability to unwind past this point. The section of the prologue starting at <+4> until <+12> is used to load the stack canary[1], which will then be placed on the stack at <+36> at the end of the prologue. In order to have the prologue properly handled, this commit proposes to add support for the ld instruction in the RISC-V prologue scanner. I guess riscv32 would use lw in such situation so this patch also adds support for this instruction. With this patch applied, gdb is now able to unwind past pthread_join: (gdb) bt #0 0x0000003ff7fccd20 in __futex_abstimed_wait_common64 () from /lib/riscv64-linux-gnu/libpthread.so.0 #1 0x0000003ff7fc43da in __pthread_clockjoin_ex () from /lib/riscv64-linux-gnu/libpthread.so.0 #2 0x0000002aaaaaa88e in bar() () #3 0x0000002aaaaaa8c4 in foo() () #4 0x0000002aaaaaa8da in main () I have had a look to see if I could reproduce this easily, but in my simple testcases using '-fstack-protector-all', the canary is loaded after the RA register is saved. I do not have a reliable way of generating a prologue similar to the problematic one so I forged one instead. The testsuite have been run on riscv64 ubuntu 21.01 with no regression observed. [1] https://en.wikipedia.org/wiki/Buffer_overflow_protection#Canaries
2021-08-12Update documentation to mention PygmentsTom Tromey1-4/+10
Philippe Blain pointed out that the gdb documentation does not mention that Pygments may be used for source highlighting. This patch updates the docs to reflect how highlighting is actually done.
2021-08-12gdb: make gdbarch_printable_names return a vectorSimon Marchi5-73/+54
I noticed that gdbarch_selftest::operator() leaked the value returned by gdbarch_printable_names. Make gdbarch_printable_names return an std::vector and update callers. That makes it easier for everyone involved, less manual memory management. Change-Id: Ia8fc028bdb91f787410cca34f10bf3c5a6da1498
2021-08-12Improve forward progress test in python.expCarl Love1-1/+16
The test steps into func2 and than does an up to get back to the previous frame. The test checks that the line number you are at after the up command is greater than the line where the function was called from. The assembly/codegen for the powerpc target includes a NOP after the branch-link. func2 (); /* Break at func2 call site. / 10000694: 59 00 00 48 bl 100006ec 10000698: 00 00 00 60 nop return 0; / Break to end. */ 1000069c: 00 00 20 39 li r9,0 The PC at the instruction following the branch-link is 0x10000698 which GDB.find_pc_line() maps to the same line number as the bl instruction. GDB did move past the branch-link location thus making forward progress. The following proposed fix adds an additional PC check to see if forward progress was made. The line test is changed from greater than to greater than or equal.
generated by cgit v1.1 at 2025-09-27 00:11:27 +0000