aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-10-02Automatic date update in version.inGDB Administrator1-1/+1
2021-10-01Automatic date update in version.inGDB Administrator1-1/+1
2021-09-30Automatic date update in version.inGDB Administrator1-1/+1
2021-09-29Automatic date update in version.inGDB Administrator1-1/+1
2021-09-28Automatic date update in version.inGDB Administrator1-1/+1
2021-09-27Automatic date update in version.inGDB Administrator1-1/+1
2021-09-26Automatic date update in version.inGDB Administrator1-1/+1
2021-09-25Automatic date update in version.inGDB Administrator1-1/+1
2021-09-24Automatic date update in version.inGDB Administrator1-1/+1
2021-09-23Automatic date update in version.inGDB Administrator1-1/+1
2021-09-22Automatic date update in version.inGDB Administrator1-1/+1
2021-09-21Automatic date update in version.inGDB Administrator1-1/+1
2021-09-20Automatic date update in version.inGDB Administrator1-1/+1
2021-09-19Automatic date update in version.inGDB Administrator1-1/+1
2021-09-18Automatic date update in version.inGDB Administrator1-1/+1
2021-09-17Automatic date update in version.inGDB Administrator1-1/+1
2021-09-16Automatic date update in version.inGDB Administrator1-1/+1
2021-09-15Automatic date update in version.inGDB Administrator1-1/+1
2021-09-14Automatic date update in version.inGDB Administrator1-1/+1
2021-09-12Bump GDB version number to 11.1.90.DATE-git.Joel Brobecker4-2/+10
gdb/ChangeLog: * version.in: Set GDB version number to 11.1.90.DATE-git. gdb/testsuite/ChangeLog: * gdb.base/default.exp: Change $_gdb_minor to 2.
2021-09-12Document the GDB 11.1 release in gdb/ChangeLogJoel Brobecker1-0/+4
gdb/ChangeLog: GDB 11.1 released.
2021-09-12Set GDB version number to 11.1.gdb-11.1-releaseJoel Brobecker2-1/+5
gdb/ChangeLog: * version.in: Set GDB version number to 11.1.
2021-09-13Automatic date update in version.inGDB Administrator1-1/+1
2021-09-12Automatic date update in version.inGDB Administrator1-1/+1
2021-09-11Automatic date update in version.inGDB Administrator1-1/+1
2021-09-10[gdb/testsuite] Handle unrecognized command line option in gdb_compile_testTom de Vries2-11/+29
When running the gdb testsuite with gnatmake-4.8, I get many fails of the following form: ... gcc: error: unrecognized command line option '-fgnat-encodings=all'^M gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error^M compiler exited with status 1 compilation failed: gcc ... gdb.ada/O2_float_param/foo.adb gcc: error: unrecognized command line option '-fgnat-encodings=all' gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error FAIL: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb ... Fix this by marking the test unsupported instead, such that we have: ... UNSUPPORTED: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb \ (unsupported option '-fgnat-encodings=all') ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-09-10 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_compile_test): Handle unrecognized command line option.
2021-09-10Automatic date update in version.inGDB Administrator1-1/+1
2021-09-09Add ChangeLog entry for previous patchTom Tromey1-0/+15
I forgot to 'git commit' the ChangeLog for the previous patch. 2021-09-08 Tom Tromey <tom@tromey.com> * dwarf2/read.h (dwarf2_per_objfile::resize_symtabs): Remove. * dwarf2/read.c (all_comp_units_iterator, all_comp_units_range): New classes. (dwarf2_per_objfile::symtab_set_p) (dwarf2_per_objfile::get_symtab, dwarf2_per_objfile::set_symtab): Adjust to resizeable vectors. (dwarf2_gdb_index::expand_symtabs_matching) (dwarf2_base_index_functions::map_symbol_filenames) (dwarf2_debug_names_index::expand_symtabs_matching): Use all_comp_units_range. (dwarf2_initialize_objfile, dwarf2_build_psymtabs) (add_type_unit): Don't call resize_symtabs.
2021-09-09[gdb/testsuite] Fix gdb.base/coredump-filter-build-id.exp with older eu-unstripTom de Vries2-1/+6
On openSUSE Leap 42.3 with eu-unstrip 0.158, we run into: ... (gdb) PASS: gdb.base/coredump-filter-build-id.exp: save corefile First line of eu-unstrip: \ 0x400000+0x202000 f4ae8502bd6a14770182382316bc595e9dc6f08b@0x400284 - - [exe] FAIL: gdb.base/coredump-filter-build-id.exp: gcore dumped mapping with build-id ... The test expects an actual file name instead of '[exe]', but that only got introduced with eu-unstrip 0.161. Before it printed '[exe]' or '[pie]'. Fix this by updating the regexp. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-09-09 Tom de Vries <tdevries@suse.de> * gdb.base/coredump-filter-build-id.exp: Handle older eu-unstrip.
2021-09-09[gdb/testsuite] Fix various issues in gdb.mi/mi-sym-info.expTom de Vries2-13/+39
I noticed this failure in gdb.mi/mi-sym-info.exp with gcc-4.8: ... FAIL: gdb.mi/mi-sym-info.exp: -symbol-info-functions --max-results 1 \ (unexpected output) ... due to function f2 instead of f3 being listed. AFAICT, this is caused by a difference in debug info: ... $ readelf -wi outputs/gdb.mi/mi-sym-info/mi-sym-info1.o \ | egrep "DW_AT_name.*: f[1-3]" <72> DW_AT_name : f1 <a1> DW_AT_name : f2 <d0> DW_AT_name : f3 ... vs: ... $ readelf -wi outputs/gdb.mi/mi-sym-info/mi-sym-info1.o \ | egrep "DW_AT_name.*: f[1-3]" <f4> DW_AT_name : f3 <123> DW_AT_name : f2 <152> DW_AT_name : f1 ... and the command documentation does not mention an imposed order, so fix this by allowing f2 as well. Doing this fix, it made sense to do a refactoring of adding f2_re and f3_re variables, in order to write (?:$f2_re|$f3_re), and I applied the same pattern overall. Furthermore, I found a silent FAIL due to calling mi_gdb_proc with 2 args, fix by updating the regexp. Then I ran with clang and found another FAIL, fix by updating the regexp. Tested on x86_64-linux with gcc-4.8.5, gcc-7.5.0, gcc-11.2.1, clang-7.0.1 and clang-12.0.1. gdb/testsuite/ChangeLog: 2021-09-09 Tom de Vries <tdevries@suse.de> * gdb.mi/mi-sym-info.exp: Fix regexps. Add missing message argument to mi_gdb_test. Factor out regexps for functions and variables.
2021-09-09Automatic date update in version.inGDB Administrator1-1/+1
2021-09-08Fix two regressions caused by CU / TU mergingTom Tromey2-38/+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 (cherry picked from commit d58e54bd277b90d847be09ae4b18bfdbc0dc2066)
2021-09-08Revert: [AArch64] MTE corefile supportLuis Machado6-27/+26
bfd * elf.c (elfcore_make_memtag_note_section): New function. (elfcore_grok_note): Handle NT_MEMTAG note types. binutils* readelf.c (get_note_type): Handle NT_MEMTAG note types. include * elf/common.h (NT_MEMTAG): New constant. (NT_MEMTAG_TYPE_AARCH_MTE): New constant.
2021-09-08Automatic date update in version.inGDB Administrator1-1/+1
2021-09-07fbsd-nat: Don't use '%jd' and '%ju' with printf_filtered.John Baldwin2-22/+28
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. gdb/ChangeLog: * fbsd-nat.c (fbsd_nat_target::info_proc): Use plongest and pulongest instead of %j.
2021-09-07Automatic date update in version.inGDB Administrator1-1/+1
2021-09-06Automatic date update in version.inGDB Administrator1-1/+1
2021-09-05Automatic date update in version.inGDB Administrator1-1/+1
2021-09-04[gdb/testsuite] Check avx support in gdb.arch/amd64-disp-step-avx.expTom de Vries5-83/+112
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-04Automatic date update in version.inGDB Administrator1-1/+1
2021-09-03[gdb/testsuite] Add untested case in gdb.gdb/complaints.expTom de Vries2-0/+25
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-03[gdb/testsuite] Add untested case in selftest_setupTom de Vries2-7/+14
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-03 Tom de Vries <tdevries@suse.de> * lib/selftest-support.exp: Emit untested when not being able to set breakpoint.
2021-09-03Automatic date update in version.inGDB Administrator1-1/+1
2021-09-02Automatic date update in version.inGDB Administrator1-1/+1
2021-09-01[gdb/testsuite] Fix dwo path in fission-*.STom de Vries9-20/+21
[ 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 Vries2-7/+17
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-09-01Automatic date update in version.inGDB Administrator1-1/+1
2021-08-31Automatic date update in version.inGDB Administrator1-1/+1
2021-08-30[gdb/cli] Don't assert on empty string for core-fileTom de Vries4-1/+17
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-30Automatic date update in version.inGDB Administrator1-1/+1
generated by cgit v1.1 at 2025-09-20 23:19:26 +0000