aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2021-09-24Fix 'FAIL: gdb.perf/disassemble.exp: python Disassemble().run()'Pedro Alves1-3/+4
We currently have one FAIL while running "make check-perf": PerfTest::assemble, run ... python Disassemble().run() Traceback (most recent call last): File "<string>", line 1, in <module> File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 64, in run self.warm_up() File "<string>", line 25, in warm_up gdb.error: No symbol "ada_evaluate_subexp" in current context. Error while executing Python code. (gdb) FAIL: gdb.perf/disassemble.exp: python Disassemble().run() ... The gdb.perf/disassemble.exp testcase debugs GDB with itself, runs to main, and then disassembles a few GDB functions. The problem is that most(!) functions it is trying to disassemble are now gone... This commit fixes the issue by simply picking some other functions to disassemble. It would perhaps be better to come up with some test program to disassemble, one that would stay the same throughout the years, instead of disassembling GDB itself. I don't know why that wasn't done to begin with. I'll have to leave that for another rainy day, though. gdb/testsuite/ yyyy-mm-dd Pedro Alves <pedro@palves.net> * gdb.perf/disassemble.py (Disassemble::warm_up): Disassemble evaluate_subexp_do_call instead of ada_evaluate_subexp. (Disassemble::warm_up): Disassemble "captured_main", "run_inferior_call" and "update_global_location_list" instead of "evaluate_subexp_standard" and "c_parse_internal". Change-Id: I89d1cca89ce2e495dea5096e439685739cc0d3df
2021-09-24Fix all PATH problems in testsuite/gdb.perf/Pedro Alves1-3/+9
Currently "make check-perf" triggers ~40 PATH messages in gdb.sum: ... PATH: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build/gdb/../../src/gdb/testsuite/gdb.perf/lib")) PATH: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ()) ... This commit fixes them. E.g. before/after gdb.sum diff: -PASS: gdb.perf/backtrace.exp: python import os, sys -PASS: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build-master/gdb/../../src/gdb/testsuite/gdb.perf/lib")) -PATH: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build-master/gdb/../../src/gdb/testsuite/gdb.perf/lib")) -PASS: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build-master/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ()) -PATH: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build-master/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ()) +PASS: gdb.perf/backtrace.exp: setup perftest: python import os, sys +PASS: gdb.perf/backtrace.exp: setup perftest: python sys.path.insert(0, os.path.abspath("${srcdir}/gdb.perf/lib")) +PASS: gdb.perf/backtrace.exp: setup perftest: python exec (open ('${srcdir}/gdb.perf/backtrace.py').read ()) gdb/testsuite/ yyyy-mm-dd Pedro Alves <pedro@palves.net> * lib/perftest.exp (PerfTest::_setup_perftest): Use with_test_prefix. Add explicit test names to python invocations, with "$srcdir" not expanded. Change-Id: I50a31b04b7abdea754139509e4a34ae9263118a4
2021-09-24Fix all DUPLICATE problems in testsuite/gdb.perf/Pedro Alves1-3/+6
Currently running "make check-perf" shows: ... # of duplicate test names 6008 ... All those duplicate test names come from gdb.perf/skip-command.exp. This commit fixes them, using with_test_prefix. gdb/testsuite/ yyyy-mm-dd Pedro Alves <pedro@palves.net> * gdb.perf/skip-command.exp (run_skip_bench): Wrap each for iteration in with_test_prefix. Change-Id: I38501cf70bc6b60306ee7228996ee7bcd858dc1b
2021-09-24Fix handling of DW_AT_data_bit_offsetTom Tromey3-17/+114
A newer version of GCC will now emit member locations using just DW_AT_data_bit_offset, like: <3><14fe>: Abbrev Number: 1 (DW_TAG_member) <14ff> DW_AT_name : (indirect string, offset: 0x215e): nb_bytes <1503> DW_AT_decl_file : 1 <1503> DW_AT_decl_line : 10 <1504> DW_AT_decl_column : 7 <1505> DW_AT_type : <0x150b> <1509> DW_AT_bit_size : 31 <150a> DW_AT_data_bit_offset: 64 whereas earlier versions would emit something like: <3><164f>: Abbrev Number: 7 (DW_TAG_member) <1650> DW_AT_name : (indirect string, offset: 0x218d): nb_bytes <1654> DW_AT_decl_file : 1 <1655> DW_AT_decl_line : 10 <1656> DW_AT_decl_column : 7 <1657> DW_AT_type : <0x165f> <165b> DW_AT_byte_size : 4 <165c> DW_AT_bit_size : 31 <165d> DW_AT_bit_offset : 1 <165e> DW_AT_data_member_location: 8 That is, DW_AT_data_member_location is not emitted any more. This is a change due to the switch to DWARF 5 by default. This change pointed out an existing bug in gdb, namely that the attr_to_dynamic_prop depends on the presence of DW_AT_data_member_location. This patch moves the handling of DW_AT_data_bit_offset into handle_data_member_location, and updates attr_to_dynamic_prop to handle this new case. A new test case is included. This test fails with GCC 11, but passes with an earlier version of GCC.
2021-09-24[gdb/testsuite] Don't leave gdb instance running after function_rangeTom de Vries2-3/+9
A typical dwarf assembly test-case start like this: ... standard_testfile .c -debug.S set asm_file [standard_output_file $srcfile2] Dwarf::assemble $asm_file { ... } if { [prepare_for_testing "failed to prepare" ${testfile} \ [list $srcfile $asm_file] {nodebug}] } { return -1 } ... When accidentally using build_for_executable instead of prepare_for_testing (or intentionally using it but forgetting to add clean_restart $binfile or some such) the mistake may not be caught, because another gdb instance is still running, and we may silently end up testing compiler-generated DWARF. This can be caused by something relatively obvious, like an earlier prepare_for_testing or clean_restart, but also by something more obscure like function_range, which may even be triggered by dwarf assembly like this: ... {MACRO_AT_func {main}} ... Fix this by calling gdb_exit at the end of function_range. Also fix the fallout of that in test-case gdb.dwarf2/dw2-bad-elf.exp, where a get_sizeof call used the gdb instance left lingering by function_range. [ A better and more complete fix would add a new proc get_exec_info, that would be called at the start of the dwarf assembly body: ... Dwarf::assemble $asm_file { get_exec_info {main foo} {int void*} ... that would: - do a prepare_for_testing with $srcfile (roughtly equivalent to what MACRO_AT_func does, - call function_range for all functions main and foo, without starting a new gdb instance - set corresponding variables at the call-site: main_start, main_len, main_end, foo_start, foo_len, foo_end. - get size for types int and void* - set corresponding variables at the call-site: int_size, void_ptr_size. - do a gdb_exit. ] Tested on x86_64-linux.
2021-09-24[gdb/testsuite] Use pie instead of -fpie/-pieTom de Vries2-2/+4
I noticed two test-cases where -fpie is used. Using the canonical pie option will usually get one -fPIE instead. That choice is justified here in gdb_compile: ... # For safety, use fPIE rather than fpie. On AArch64, m68k, PowerPC # and SPARC, fpie can cause compile errors due to the GOT exceeding # a maximum size. On other architectures the two flags are # identical (see the GCC manual). Note Debian9 and Ubuntu16.10 # onwards default GCC to using fPIE. If you do require fpie, then # it can be set using the pie_flag. set flag "additional_flags=-fPIE" ... There is no indication that using -fpie rather than -fPIE is on purpose, so use pie instead. Tested on x86_64-linux.
2021-09-24[gdb/testsuite] Factor out dump_info in gdb.testsuite/dump-system-info.expTom de Vries1-26/+16
Factor out new proc dump_info in test-case gdb.testsuite/dump-system-info.exp, and in the process: - fix a few typos - remove unnecessary "test -r /proc/cpuinfo" Tested on x86_64-linux. Co-Authored-By: Pedro Alves <pedro@palves.net>
2021-09-24gdb/testsuite: Make it possible to use TCL variables in DWARF assembler loclistsPedro Alves1-0/+4
It is currently not possible to use variables in locations lists. For example, with: diff --git a/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp b/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp index 6b4f5c8cbb8..cdbf948619f 100644 --- a/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp +++ b/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp @@ -30,6 +30,8 @@ if {![dwarf2_support]} { return 0 } +set myconst 0x123456 + # Test with 32-bit and 64-bit DWARF. foreach_with_prefix is_64 {false true} { if { $is_64 } { @@ -49,6 +51,7 @@ foreach_with_prefix is_64 {false true} { global func1_addr func1_len global func2_addr func2_len global is_64 + global myconst # The CU uses the DW_FORM_loclistx form to refer to the .debug_loclists # section. @@ -107,7 +110,7 @@ foreach_with_prefix is_64 {false true} { list_ { # When in func1. start_length $func1_addr $func1_len { - DW_OP_constu 0x123456 + DW_OP_constu $myconst DW_OP_stack_value } we get: $ make check TESTS="*/loclists-multiple-cus.exp" ... gdb compile failed, build/gdb/testsuite/outputs/gdb.dwarf2/loclists-multiple-cus/loclists-multiple-cus-dw32.S: Assembler messages: build/gdb/testsuite/outputs/gdb.dwarf2/loclists-multiple-cus/loclists-multiple-cus-dw32.S:78: Error: leb128 operand is an undefined symbol: $myconst ... That means $myconst was copied literally to the generated assembly file. This patch fixes it, by running subst on the location list body, in the context of the caller. The fix is applied to both Dwarf::loclists::table::list_::start_length and Dwarf::loclists::table::list_::start_end. Reported-by: Zoran Zaric <Zoran.Zaric@amd.com> Change-Id: I615a64431857242d9f477d5699e3732df1b31322
2021-09-24[gdb/testsuite] Fix DUPLICATEs in gdb.dwarf2/implptr-64bit.expTom de Vries1-4/+18
When running test-case gdb.dwarf2/implptr-64bit.exp with target board unix/-m32, I noticed: ... DUPLICATE: gdb.dwarf2/implptr-64bit.exp: failed to prepare ... Fix this by using with_test_prefix. Tested on x86_64-linux.
2021-09-24[gdb/testsuite] Fix DUPLICATEs gdb.dwarf2/dw2-is-stmt.expTom de Vries1-46/+54
Fix these DUPLICATEs by using with_test_prefix: ... DUPLICATE: gdb.dwarf2/dw2-is-stmt.exp: ensure we saw a valid line pattern, 1 DUPLICATE: gdb.dwarf2/dw2-is-stmt.exp: ensure we saw a valid line pattern, 2 ... Tested on x86_64-linux.
2021-09-24[gdb/testsuite] Fix set $var val in gdb.dwarf2/dw2-is-stmt.expTom de Vries1-2/+2
When doing a testrun with: ... $ make check RUNTESTFLAGS=$(cd $src/gdb/testsuite/; echo gdb.dwarf2/*.exp) ... I ran into: ... ERROR: tcl error sourcing gdb.dwarf2/dw2-is-stmt.exp. ERROR: expected integer but got "dw2-abs-hi-pc-world.c" while executing "incr i" ... The variable i is set in gdb.dwarf2/dw2-abs-hi-pc.exp, and leaks to gdb.dwarf2/dw2-is-stmt.exp. It's not removed by gdb_cleanup_globals because i is set as global variable by runtest.exp, which does: ... for { set i 0 } { $i < $argc } { incr i } { ... at toplevel but forgets to unset the variable. Fix this by removing '$' in front of the variable name when doing set: ... -set $i 0 +set i 0 ... Tested on x86_64-linux.
2021-09-24[gdb/testsuite] Fix DUPLICATE in gdb.base/load-command.expTom de Vries1-5/+9
Fix this duplicate: ... DUPLICATE: gdb.base/load-command.exp: check initial value of the_variable ... by using with_test_prefix. Tested on x86_64-linux.
2021-09-24[gdb/testsuite] Use pie/nopie instead of ldflags=-pie/-no-pieTom de Vries2-2/+2
I noticed two test-case that use ldflags=-pie and ldflags-no-pie, instead of the canonical pie and nopie options, which would typically also add additional_flags=-fPIE respectively additional_flags=-fno-pie. There is no indication that this is on purpose, so replace these with pie and nopie. Tested on x86_64-linux.
2021-09-24[gdb/testsuite] Add gdb.testsuite/dump-system-info.expTom de Vries1-0/+48
When interpreting the testsuite results, it's often relevant what kind of machine the testsuite ran on. On a local machine one can just do /proc/cpuinfo, but in case of running tests using a remote system that distributes test runs to other remote systems that are not directly accessible, that's not possible. Fix this by dumping /proc/cpuinfo into the gdb.log, as well as lsb_release -a and uname -a. We could do this at the start of each test run, by putting it into unix.exp or some such. However, this might be too verbose, so we choose to put it into its own test-case, such that it get triggered in a full testrun, but not when running one or a subset of tests. We put the test-case into the gdb.testsuite directory, which is currently the only place in the testsuite where we do not test gdb. [ Though perhaps this could be put into a new gdb.info directory, since the test-case doesn't actually test the testsuite. ] Tested on x86_64-linux.
2021-09-23Change pointer_type to a method of struct typeTom Tromey17-60/+44
I noticed that pointer_type is declared in language.h and defined in language.c. However, it really has to do with types, so it should have been in gdbtypes.h all along. This patch changes it to be a method on struct type. And, I went through uses of TYPE_IS_REFERENCE and updated many spots to use the new method as well. (I didn't update ones that were in arch-specific code, as I couldn't readily test that.)
2021-09-23[gdb/testsuite] Support -fPIE/-fno-PIE/-pie/-no-pie in gdb_compile_rustTom de Vries1-3/+44
When running gdb.rust/*.exp test-cases with target board unix/-fPIE/-pie, I run into: ... builtin_spawn -ignore SIGHUP rustc --color never gdb.rust/watch.rs \ -g -lm -fPIE -pie -o outputs/gdb.rust/watch/watch^M error: Unrecognized option: 'f'^M ^M compiler exited with status 1 ... The problem is that -fPIE and -fpie are gcc options, but for rust we use rustc, which has different compilation options. Fix this by translating the gcc options to rustc options in gdb_compile_rust, similar to how that is done for ada in target_compile_ada_from_dir. Likewise for unix/-fno-PIE/-no-pie. Tested on x86_64-linux, with: - native - unix/-fPIE/-pie - unix/-fno-PIE/-no-pie specifically, on openSUSE Leap 15.2 both with package gcc-PIE: - installed (making gcc default to PIE) - uninstalled (making gcc default to non-PIE). and rustc 1.52.1.
2021-09-23[gdb/testsuite] Use pie instead of -fPIE -pieTom de Vries8-22/+16
Replace {additional_flags=-fPIE ldflags=-pie} with {pie}. This makes sure that the test-cases properly error out when using target board unix/-fno-PIE/-no-pie. Tested on x86_64-linux.
2021-09-23[gdb/testsuite] Fix probe test in gdb.base/break-interp.expTom de Vries1-1/+33
When running test-case gdb.base/break-interp.exp on ubuntu 18.04.5, we have: ... (gdb) bt^M #0 0x00007eff7ad5ae12 in ?? () from break-interp-LDprelinkNOdebugNO^M #1 0x00007eff7ad71f50 in ?? () from break-interp-LDprelinkNOdebugNO^M #2 0x00007eff7ad59128 in ?? () from break-interp-LDprelinkNOdebugNO^M #3 0x00007eff7ad58098 in ?? () from break-interp-LDprelinkNOdebugNO^M #4 0x0000000000000002 in ?? ()^M #5 0x00007fff505d7a32 in ?? ()^M #6 0x00007fff505d7a94 in ?? ()^M #7 0x0000000000000000 in ?? ()^M (gdb) FAIL: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: \ first backtrace: dl bt ... Using the backtrace, the test-case tries to establish that we're stopped in dl_main. However, the backtrace only shows an address, because: - the dynamic linker contains no minimal symbols and no debug info, and - gdb is build without --with-separate-debug-dir so it can't find the corresponding .debug file, which does contain the mimimal symbols and debug info. As in "[gdb/testsuite] Improve probe detection in gdb.base/break-probes.exp", fix this by doing info probes and grepping for the address. Tested on x86_64-linux.
2021-09-23[gdb/testsuite] Improve probe detection in gdb.base/break-probes.expTom de Vries1-13/+19
When running test-case gdb.base/break-probes.exp on ubuntu 18.04.5, we have: ... (gdb) run^M Starting program: break-probes^M Stopped due to shared library event (no libraries added or removed)^M (gdb) bt^M #0 0x00007ffff7dd6e12 in ?? () from /lib64/ld-linux-x86-64.so.2^M #1 0x00007ffff7dedf50 in ?? () from /lib64/ld-linux-x86-64.so.2^M #2 0x00007ffff7dd5128 in ?? () from /lib64/ld-linux-x86-64.so.2^M #3 0x00007ffff7dd4098 in ?? () from /lib64/ld-linux-x86-64.so.2^M #4 0x0000000000000001 in ?? ()^M #5 0x00007fffffffdaac in ?? ()^M #6 0x0000000000000000 in ?? ()^M (gdb) UNSUPPORTED: gdb.base/break-probes.exp: probes not present on this system ... Using the backtrace, the test-case tries to establish that we're stopped in dl_main, which is used as proof that we're using probes. However, the backtrace only shows an address, because: - the dynamic linker contains no minimal symbols and no debug info, and - gdb is build without --with-separate-debug-dir so it can't find the corresponding .debug file, which does contain the mimimal symbols and debug info. Fix this by instead printing the pc and grepping for the value in the info probes output: ... (gdb) p /x $pc^M $1 = 0x7ffff7dd6e12^M (gdb) info probes^M Type Provider Name Where Object ^M ... stap rtld init_start 0x00007ffff7dd6e12 /lib64/ld-linux-x86-64.so.2 ^M ... (gdb) ... Tested on x86_64-linux.
2021-09-23[gdb/testsuite] Handle failing probe detection in gdb.base/break-probes.expTom de Vries1-1/+3
When running test-case gdb.base/break-probes.exp on ubuntu 18.04.5, we have: ... (gdb) bt^M #0 0x00007ffff7dd6e12 in ?? () from /lib64/ld-linux-x86-64.so.2^M #1 0x00007ffff7dedf50 in ?? () from /lib64/ld-linux-x86-64.so.2^M #2 0x00007ffff7dd5128 in ?? () from /lib64/ld-linux-x86-64.so.2^M #3 0x00007ffff7dd4098 in ?? () from /lib64/ld-linux-x86-64.so.2^M #4 0x0000000000000001 in ?? ()^M #5 0x00007fffffffdaac in ?? ()^M #6 0x0000000000000000 in ?? ()^M (gdb) FAIL: gdb.base/break-probes.exp: ensure using probes ... The test-case intends to emit an UNTESTED in this case, but fails to do so because it tries to do it in a regexp clause in a gdb_test_multiple, which doesn't trigger. Instead, a default clause triggers which produces the FAIL. Also the use of UNTESTED is not appropriate, and we should use UNSUPPORTED instead. Fix this by silencing the FAIL, and emitting an UNSUPPORTED after the gdb_test_multiple: ... if { ! $using_probes } { + unsupported "probes not present on this system" return -1 } ... Tested on x86_64-linux.
2021-09-23[gdb/testsuite] Use early-out style in gdb.base/break-probes.expTom de Vries1-25/+27
Reduce indentation and improve readability in test-case gdb.base/break-probes.exp by replacing: ... if { <cond> } { <lots-of-code> } ... with: ... if { ! <cond> } { return -1 } <lots-of-code> ... Tested on x86_64-linux.
2021-09-23Test that frame info/IDs are stable/consistentPedro Alves1-0/+136
This adds a testcase that tests that the unwinder produces consistent frame info and frame IDs by making sure that "info frame" shows the same result when stopped at a function (level == 0), compared to when we find the same frame in the stack at a level > 0. E.g., on x86-64, right after running to main, we see: (gdb) info frame Stack level 0, frame at 0x7fffffffd340: rip = 0x555555555168 in main (gdb.base/backtrace.c:41); saved rip = 0x7ffff7dd90b3 source language c. Arglist at 0x7fffffffd330, args: Locals at 0x7fffffffd330, Previous frame's sp is 0x7fffffffd340 Saved registers: rbp at 0x7fffffffd330, rip at 0x7fffffffd338 (gdb) and then after continuing to a function called by main, and selecting the "main" frame again, we see: (gdb) info frame Stack level 3, frame at 0x7fffffffd340: rip = 0x555555555172 in main (gdb.base/backtrace.c:41); saved rip = 0x7ffff7dd90b3 caller of frame at 0x7fffffffd330 source language c. Arglist at 0x7fffffffd330, args: Locals at 0x7fffffffd330, Previous frame's sp is 0x7fffffffd340 Saved registers: rbp at 0x7fffffffd330, rip at 0x7fffffffd338 (gdb) The only differences should be in the stack level, the 'rip = ' address, and the presence of the "caller of frame at" info. All the rest should be the same. If it isn't, it probably means that the frame base, the frame ID, etc. aren't stable & consistent. The testcase exercises both the DWARF and the heuristic unwinders, using "maint set dwarf unwinder on/off". Tested on {x86-64 -m64, x86-64 -m32, Aarch64, Power8} GNU/Linux. Change-Id: I795001c82cc70d543d197415e3f80ce5dc7f3452
2021-09-23Change get_ada_task_ptid parameter typeTom Tromey13-29/+29
get_ada_task_ptid currently takes a 'long' as its 'thread' parameter type. However, on some platforms this is actually a pointer, and using 'long' can sometimes end up with the value being sign-extended. This sign extension can cause problems later, if the tid is then later used as an address again. This patch changes the parameter type to ULONGEST and updates all the uses. This approach preserves sign extension on the targets where it is apparently intended, while avoiding it on others. Co-Authored-By: John Baldwin <jhb@FreeBSD.org>
2021-09-23Change ptid_t::tid to ULONGESTTom Tromey6-15/+18
The ptid_t 'tid' member is normally used as an address in gdb -- both bsd-uthread and ravenscar-thread use it this way. However, because the type is 'long', this can cause problems with sign extension. This patch changes the type to ULONGEST to ensure that sign extension does not occur.
2021-09-23Remove defaulted 'tid' parameter to ptid_t constructorTom Tromey8-23/+22
I wanted to find, and potentially modify, all the spots where the 'tid' parameter to the ptid_t constructor was used. So, I temporarily removed this parameter and then rebuilt. In order to make it simpler to search through the "real" (nonzero) uses of this parameter, something I knew I'd have to do multiple times, I removed any ", 0" from constructor calls. Co-Authored-By: John Baldwin <jhb@FreeBSD.org>
2021-09-23Style the "XXX" text in ptype/oTom Tromey3-4/+35
This patch changes gdb to use the 'highlight' style on the "XXX" text in the output of ptype/o.
2021-09-22[gdb/testsuite] Fix gdb.python/py-events.expTom de Vries1-2/+6
With test-case gdb.python/py-events.exp on ubuntu 18.04.5 we run into: ... (gdb) info threads^M Id Target Id Frame ^M * 1 Thread 0x7ffff7fc3740 (LWP 31467) "py-events" do_nothing () at \ src/gdb/testsuite/gdb.python/py-events-shlib.c:19^M (gdb) FAIL: gdb.python/py-events.exp: get current thread ... The info thread commands uses "Thread" instead of "process" because libpthread is already loaded: ... new objfile name: /lib/x86_64-linux-gnu/libdl.so.2^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".^M event type: new_objfile^M new objfile name: /lib/x86_64-linux-gnu/libpthread.so.0^M ... and consequently thread_db_target::pid_to_str is used. Fix this by parsing the "Thread" expression. Tested on x86_64-linux.
2021-09-22[gdb] Add maint selftest -verbose optionTom de Vries3-8/+9
The print_one_insn selftest in gdb/disasm-selftests.c contains: ... /* If you want to see the disassembled instruction printed to gdb_stdout, set verbose to true. */ static const bool verbose = false; ... Make this parameter available in the maint selftest command using a new option -verbose, such that we can do: ... (gdb) maint selftest -verbose print_one_insn ... Tested on x86_64-linux.
2021-09-21[gdb/testsuite] Handle supports_memtag in gdb.base/gdb-caching-proc.expTom de Vries1-3/+2
In test-case gdb.base/gdb-caching-proc.exp, we run all procs declared with gdb_caching_proc. Some of these require a gdb instance, some not. We could just do a clean_restart every time, but that would amount to 44 gdb restarts. We try to minimize this by doing this only for the few procs that need it, and hardcoding those in the test-case. For those procs, we do a clean_restart, execute the proc, and then do a gdb_exit, to make sure the gdb instance doesn't linger such that we detect procs that need a gdb instance but are not listed in the test-case. However, that doesn't work in the case of gnat_runtime_has_debug_info. This proc doesn't require a gdb instance because it starts its own. But it doesn't clean up the gdb instance, and since it's not listed, the test-case doesn't clean up the gdb instance eiter. Consequently, the proc supports_memtag (which should be listed, but isn't) uses the gdb instance started by gnat_runtime_has_debug_info rather than throwing an error. Well, unless gnat_runtime_has_debug_info fails before starting a gdb instance, in which case we do run into the error. Fix this by: - doing gdb_exit unconditionally - fixing the resulting error by adding supports_memtag in the test-case to the "needing gdb instance" list Tested on x86_64-linux.
2021-09-21gdb, doc: Add ieee_half and bfloat16 to list of predefined target types.Felix Willgerodt1-0/+6
For some reason these two weren't added to the list when they were orginally added to GDB. gdb/doc/ChangeLog: 2021-09-21 Felix Willgerodt <felix.willgerodt@intel.com> * gdb.texinfo (Predefined Target Types): Mention ieee_half and bfloat16.
2021-09-21[gdb/testsuite] Fix gdb.ada/interface.exp with gcc-9Tom de Vries1-5/+5
When running test-case gdb.ada/interface.exp with gcc-9, we run into: ... (gdb) info locals^M s = (x => 1, y => 2, w => 3, h => 4)^M r = (x => 1, y => 2, w => 3, h => 4)^M (gdb) FAIL: gdb.ada/interface.exp: info locals ... The failure is caused by the regexp expecting variable r followed by variable s. Fix this by allowing variable s followed by variable r as well. Tested on x86_64-linux.
2021-09-21[gdb/testsuite] Fix gdb.ada/mi_prot.expTom de Vries1-1/+1
When running test-case gdb.ada/mi_prot.exp with gcc 8.5.0, we run into: ... (gdb) ^M Expecting: ^(-stack-list-arguments --no-frame-filters 1[^M ]+)?(\^done,stack=.*[^M ]+[(]gdb[)] ^M [ ]*) -stack-list-arguments --no-frame-filters 1^M ^done,stack-args=[frame={level="0",args=[{name="<_object>",value="(ceiling_priority =\ > 97, local => 0)"},{name="v",value="5"},{name="<_objectO>",value="true"}]},frame={le\ vel="1",args=[{name="v",value="5"},{name="<_objectO>",value="true"}]},frame={level="2\ ",args=[]}]^M (gdb) ^M FAIL: gdb.ada/mi_prot.exp: -stack-list-arguments --no-frame-filters 1 (unexpected out\ put) ... Fix this by updating the regexp to expect "^done,stack-args=" instead of "^done,stack=". Tested on x86_64-linux.
2021-09-21[gdb/testsuite] Register test for each arch separately in ↵Tom de Vries1-60/+45
register_test_foreach_arch In gdb/disasm-selftests.c we have: ... selftests::register_test_foreach_arch ("print_one_insn", selftests::print_one_insn_test); ... and we get: ... $ gdb -q -batch -ex "maint selftest print_one_insn" 2>&1 \ | grep ^Running Running selftest print_one_insn. $ ... Change the semantics register_test_foreach_arch such that a version of print_one_insn is registered for each architecture, such that we have: ... $ gdb -q -batch -ex "maint selftest print_one_insn" 2>&1 \ | grep ^Running Running selftest print_one_insn::A6. Running selftest print_one_insn::A7. Running selftest print_one_insn::ARC600. ... $ ... This makes it f.i. possible to do: ... $ gdb -q -batch a.out -ex "maint selftest print_one_insn::armv8.1-m.main" Running selftest print_one_insn::armv8.1-m.main. Self test failed: self-test failed at src/gdb/disasm-selftests.c:165 Ran 1 unit tests, 1 failed ... Tested on x86_64-linux with an --enable-targets=all build.
2021-09-21[gdb] Change register_test to use std::function argTom de Vries1-3/+3
Change register_test to use std::function arg, such that we can do: ... register_test (test_name, [=] () { SELF_CHECK (...); }); ... Tested on x86_64-linux.
2021-09-20[gdb/testsuite] Fix gdb.ada/big_packed_array.exp xfail for -m32Tom de Vries1-0/+10
With test-case gdb.ada/big_packed_array.exp and target board unix/-m32 I run into: ... (gdb) print bad^M $2 = (0 => 0 <repeats 24 times>, 160)^M (gdb) FAIL: gdb.ada/big_packed_array.exp: scenario=minimal: print bad ... The problem is that while the variable is an array of 196 bits (== 24.5 bytes), the debug information describes it as 25 unsigned char. This is PR gcc/101643, and the test-case contains an xfail for this, which catches only: ... (gdb) print bad^M $2 = (0 => 0 <repeats 25 times>)^M ... Fix this by updating the xfail pattern. Tested on x86_64-linux.
2021-09-19gdb: manual: update @inforef to @xrefMike Frysinger1-2/+2
The @inforef command is deprecated, and @xref does the samething. Also had to update the text capitalization to match current manual. Verified that info & HTML links work.
2021-09-18CTF: multi-CU and archive supportWeimin Pan17-154/+471
Now gdb is capable of debugging executable, which consists of multiple compilation units (CUs) with the CTF debug info. An executable could potentially have one or more archives, which, in CTF context, contain conflicting types. all changes were made in ctfread.c in which elfctf_build_psymtabs was modified to handle archives, via the ctf archive iterator and its callback build_ctf_archive_member and scan_partial_symbols was modified to scan archives, which are treated as subfiles, to build the psymtabs. Also changes were made to handle CTF's data object section and function info section which now share the same format of their contents - an array of type IDs. New functions ctf_psymtab_add_stt_entries, which is called by ctf_psymtab_add_stt_obj and ctf_psymtab_add_stt_func, and add_stt_entries, which is called by add_stt_obj and add_stt_func when setting up psymtabs and full symtab, respectively.
2021-09-18[gdb/testsuite] Fix gdb.server/server-kill.exp with -m32Tom de Vries1-4/+6
When running test-case gdb.server/server-kill.exp with target board unix/-m32, I run into: ... 0xf7fd6b20 in _start () from /lib/ld-linux.so.2^M (gdb) Executing on target: kill -9 13082 (timeout = 300) builtin_spawn -ignore SIGHUP kill -9 13082^M bt^M (gdb) FAIL: gdb.server/server-kill.exp: kill_pid_of=server: test_unwind_syms: bt ... The test-case expects the backtrace command to trigger remote communication, which then should result in a "Remote connection closed" or similar. However, no remote communication is triggered, because we hit the "Check that this frame is unwindable" case in get_prev_frame_always_1. We don't hit this problem in the kill_pid_of=inferior case, because there we run to main before doing the backtrace. Fix this by doing the same in the kill_pid_of=server case. Tested on x86_64-linux.
2021-09-18[gdb/ada] Handle artificial local symbolsTom de Vries6-1/+45
With current master and gcc 7.5.0/8.5.0, we have this timeout: ... (gdb) print s^M Multiple matches for s^M [0] cancel^M [1] s at src/gdb/testsuite/gdb.ada/interface/foo.adb:20^M [2] s at src/gdb/testsuite/gdb.ada/interface/foo.adb:?^M > FAIL: gdb.ada/interface.exp: print s (timeout) ... [ The FAIL doesn't reproduce with gcc 9.3.1. This difference in behaviour bisects to gcc commit d70ba0c10de. The FAIL with earlier gcc bisects to gdb commit ba8694b650b. ] The FAIL is caused by gcc generating this debug info describing a named artificial variable: ... <2><1204>: Abbrev Number: 31 (DW_TAG_variable) <1205> DW_AT_name : s.14 <1209> DW_AT_type : <0x1213> <120d> DW_AT_artificial : 1 <120d> DW_AT_location : 5 byte block: 91 e0 7d 23 18 \ (DW_OP_fbreg: -288; DW_OP_plus_uconst: 24) ... An easy way to fix this would be to simply not put named artificial variables into the symbol table. However, that causes regressions for Ada. It relies on being able to get the value from such variables, using a named reference. Fix this instead by marking the symbol as artificial, and: - ignoring such symbols in ada_resolve_variable, which fixes the FAIL - ignoring such ada symbols in do_print_variable_and_value, which prevents them from showing up in "info locals" Note that a fix for the latter was submitted here ( https://sourceware.org/pipermail/gdb-patches/2008-January/054994.html ), and this patch borrows from it. Tested on x86_64-linux. Co-Authored-By: Joel Brobecker <brobecker@adacore.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28180
2021-09-17Fix segfault when running ia16-elf-gdbHenry Castro1-0/+5
"A problem internal to GDB has been detected, further debugging may prove unreliable." Segmentation fault
2021-09-16[gdb/testsuite] Fix interrupted sleep in multi-threaded test-casesTom de Vries3-3/+14
When running test-case gdb.threads/continue-pending-status.exp with native, I have: ... (gdb) continue^M Continuing.^M PASS: gdb.threads/continue-pending-status.exp: attempt 0: continue for ctrl-c ^C^M Thread 1 "continue-pendin" received signal SIGINT, Interrupt.^M [Switching to Thread 0x7ffff7fc4740 (LWP 1276)]^M 0x00007ffff758e4c0 in __GI___nanosleep () at nanosleep.c:27^M 27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M (gdb) PASS: gdb.threads/continue-pending-status.exp: attempt 0: caught interrupt ... but with target board unix/-m32, I run into: ... (gdb) continue^M Continuing.^M PASS: gdb.threads/continue-pending-status.exp: attempt 0: continue for ctrl-c [Thread 0xf74aeb40 (LWP 31957) exited]^M [Thread 0xf7cafb40 (LWP 31956) exited]^M [Inferior 1 (process 31952) exited normally]^M (gdb) Quit^M ... The problem is that the sleep (300) call at the end of main is interrupted, which causes the inferior to exit before the ctrl-c can be send. This problem is described at "Interrupted System Calls" in the docs, and the suggested solution (using a sleep loop) indeed fixes the problem. Fix this instead using the more prevalent: ... alarm (300); ... while (1) sleep (1); ... which is roughly equivalent because the sleep is called at the end of main, but slightly better because it guards against hangs from the start rather than from the end of main. Likewise in gdb.base/watch_thread_num.exp. Likewise in gdb.btrace/enable-running.exp, but use the sleep loop there, because the sleep is not called at the end of main. Tested on x86_64-linux.
2021-09-16gdb: manual: fix werrors typoMike Frysinger1-1/+1
2021-09-15[gdb/testsuite] Use function_range in gdb.dwarf2/dw2-abs-hi-pc.expTom de Vries5-18/+41
When I run test-case gdb.dwarf2/dw2-abs-hi-pc.exp with gcc, we have: ... (gdb) break hello^M Breakpoint 1 at 0x4004c0: file dw2-abs-hi-pc-hello.c, line 24.^M (gdb) PASS: gdb.dwarf2/dw2-abs-hi-pc.exp: break hello ... but with clang, I run into: ... (gdb) break hello^M Breakpoint 1 at 0x4004e4^M (gdb) FAIL: gdb.dwarf2/dw2-abs-hi-pc.exp: break hello ... The problem is that the CU and function both have an empty address range: ... <0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit) <108> DW_AT_name : dw2-abs-hi-pc-hello.c <123> DW_AT_low_pc : 0x4004e0 <127> DW_AT_high_pc : 0x4004e0 <1><12f>: Abbrev Number: 2 (DW_TAG_subprogram) <131> DW_AT_name : hello <13a> DW_AT_low_pc : 0x4004e0 <13e> DW_AT_high_pc : 0x4004e0 ... The address ranges are set like this in dw2-abs-hi-pc-hello-dbg.S: ... .4byte .hello_start /* DW_AT_low_pc */ .4byte .hello_end /* DW_AT_high_pc */ ... where the labels refer to dw2-abs-hi-pc-hello.c: ... extern int v; asm (".hello_start: .globl .hello_start\n"); void hello (void) { asm (".hello0: .globl .hello0\n"); v++; asm (".hello1: .globl .hello1\n"); } asm (".hello_end: .globl .hello_end\n"); ... Using asm labels in global scope is a known source of problems, as explained in the comment of proc function_range in gdb/testsuite/lib/dwarf.exp. Fix this by using function_range instead. Tested on x86_64-linux with gcc and clang-7 and clang-12.
2021-09-15[gdb/doc] Fix typo in maint selftest entryTom de Vries1-1/+1
Fix typo "will by" -> "will be".
2021-09-14[gdb/testsuite] Fix gdb_load_no_complaints with gnu-debuglinkTom de Vries1-2/+2
When running test-case gdb.dwarf2/dw2-ranges-psym-warning.exp with target board gnu-debuglink I run into: ... (gdb) file dw2-ranges-psym-warning^M Reading symbols from dw2-ranges-psym-warning...^M Reading symbols from .debug/dw2-ranges-psym-warning.debug...^M (gdb) FAIL: gdb.dwarf2/dw2-ranges-psym-warning.exp: No complaints ... Fix this by updating the regexp in gdb_load_no_complaints. Tested on x86_64-linux.
2021-09-14[gdb/symtab] Fix function range handling in psymtabsTom de Vries4-8/+246
Consider the test-case from this patch. We run into: ... (gdb) PASS: gdb.dwarf2/dw2-ranges-psym-warning.exp: continue bt^M warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M ^M warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M ^M warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M ^M warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M ^M warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M ^M warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M ^M read in psymtab, but not in symtab.)^M ^M )^M (gdb) FAIL: gdb.dwarf2/dw2-ranges-psym-warning.exp: bt ... This happens as follows. The function foo: ... <1><31>: Abbrev Number: 4 (DW_TAG_subprogram) <33> DW_AT_name : foo <37> DW_AT_ranges : 0x0 ... has these ranges: ... 00000000 00000000004004c1 00000000004004d2 00000000 00000000004004ae 00000000004004af 00000000 <End of list> ... which have a hole at at [0x4004af,0x4004c1). However, the address map of the partial symtabs incorrectly maps addresses in the hole (such as 0x4004b6 in the backtrace) to the foo CU. The address map of the full symbol table of the foo CU however does not contain the addresses in the hole, which is what the warning / internal error complains about. Fix this by making sure that ranges of functions are read correctly. The patch adds a bit to struct partial_die_info, in this hole (shown for x86_64-linux): ... /* 11: 7 | 4 */ unsigned int canonical_name : 1; /* XXX 4-byte hole */ /* 16 | 8 */ const char *raw_name; ... So there's no increase in size for 64-bit, but AFAIU there will be an increase for 32-bit. Tested on x86_64-linux. gdb/ChangeLog: 2021-08-10 Tom de Vries <tdevries@suse.de> PR symtab/28200 * dwarf2/read.c (struct partial_die_info): Add has_range_info and range_offset field. (add_partial_subprogram): Handle pdi->has_range_info. (partial_die_info::read): Set pdi->has_range_info. gdb/testsuite/ChangeLog: 2021-08-10 Tom de Vries <tdevries@suse.de> PR symtab/28200 * gdb.dwarf2/dw2-ranges-psym-warning-main.c: New test. * gdb.dwarf2/dw2-ranges-psym-warning.c: New test. * gdb.dwarf2/dw2-ranges-psym-warning.exp: New file.
2021-09-14[gdb/symtab] Fix CU list in .debug_names for dummy CUsTom de Vries1-12/+8
With current trunk and target board cc-with-debug-names we have: ... (gdb) file dw2-ranges-psym^M Reading symbols from dw2-ranges-psym...^M warning: Section .debug_names in dw2-ranges-psym has abbreviation_table of \ size 1 vs. written as 28, ignoring .debug_names.^M (gdb) set complaints 0^M (gdb) FAIL: gdb.dwarf2/dw2-ranges-psym.exp: No complaints ... The executable has 8 compilation units: ... $ readelf -wi dw2-ranges-psym | grep @ Compilation Unit @ offset 0x0: Compilation Unit @ offset 0x2e: Compilation Unit @ offset 0xa5: Compilation Unit @ offset 0xc7: Compilation Unit @ offset 0xd2: Compilation Unit @ offset 0x145: Compilation Unit @ offset 0x150: Compilation Unit @ offset 0x308: ... of which the ones at 0xc7 and 0x145 are dummy CUs (that is, they do not contain a single DIE), which were added by recent commit 5ef670d81fd "[gdb/testsuite] Add dummy start and end CUs in dwarf assembly". The .debug_names section contains this CU table: ... [ 0] 0x0 [ 1] 0x2e [ 2] 0xa5 [ 3] 0xd2 [ 4] 0x150 [ 5] 0x308 [ 6] 0x1 [ 7] 0x0 ... The last two entries are incorrect, and the entries for the dummy CUs are missing. The last two entries are incorrect because here in write_debug_names we write the dimension of the CU list as 8: ... /* comp_unit_count - The number of CUs in the CU list. */ header.append_uint (4, dwarf5_byte_order, per_objfile->per_bfd->all_comp_units.size () - per_objfile->per_bfd->tu_stats.nr_tus); ... while the actual dimension of the CU list is 6. The discrepancy is caused by this code which skips the dummy CUs: ... for (int i = 0; i < per_objfile->per_bfd->all_comp_units.size (); ++i) { ... /* CU of a shared file from 'dwz -m' may be unused by this main file. It may be referenced from a local scope but in such case it does not need to be present in .debug_names. */ if (psymtab == NULL) continue; ... because they have a null partial symtab. We can fix this by writing the actual dimension of the CU list, but that still leaves the dummy CUs out of the CU list. The purpose of having these is to delimit the end of preceding CUs. So, fix this by: - removing the code that skips the dummy CUs (note that the same change was done for .gdb_index in commit efba5c2319d '[gdb/symtab] Handle PU without import in "save gdb-index"'. - verifying that all units are represented in the CU/TU lists - using the actual CU list size when writing the dimension of the CU list (and likewise for the TU list). Tested on x86_64-linux with native and target board cc-with-debug-names. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28261
2021-09-14[gdb/testsuite] Generate .debug_aranges in ↵Tom de Vries1-1/+6
gdb.dwarf2/locexpr-data-member-location.exp When running test-case gdb.dwarf2/locexpr-data-member-location.exp with target board cc-with-debug-names, all tests pass but we run into PR28261: ... (gdb) run ^M Starting program: locexpr-data-member-location ^M warning: Section .debug_names in locexpr-data-member-location-lib.so has \ abbreviation_table of size 1 vs. written as 37, ignoring .debug_names.^M ... Using a patch that fixes PR28261, the warning is gone, but we run into: ... FAIL: gdb.dwarf2/locexpr-data-member-location.exp: step into foo ... This is due a missing .debug_aranges contribution for the CU declared in gdb.dwarf2/locexpr-data-member-location.exp. Fix this by adding the missing .debug_aranges contribution. Tested on x86_64-linux.
2021-09-13Remove use of __CYGNUSCLIB__Tom Tromey1-4/+0
I found a check of __CYGNUSCLIB__ in dbxread.c. I think this is dead code. This patch removes it.
2021-09-13[gdb/testsuite] Check for valid test nameTom de Vries1-0/+9
When running gdb.base/batch-exit-status.exp I noticed that the test name contains a newline: ... PASS: gdb.base/batch-exit-status.exp: : No such file or directory\.^M : No such file or directory\.: [lindex $result 2] == 0 ... Check for this in ::CheckTestNames::check, such that we have a warning: ... PASS: gdb.base/batch-exit-status.exp: : No such file or directory\.^M : No such file or directory\.: [lindex $result 2] == 0 WARNING: Newline in test name ... Tested on x86_64-linux.
generated by cgit v1.1 at 2025-04-13 15:09:42 +0000