aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2021-10-19[gdb/testsuite] Reimplement gdb.gdb/python-interrupts.exp as unittestTom de Vries4-50/+57
The test-case gdb.gdb/python-interrupts.exp: - runs to captured_command_loop - sets a breakpoint at set_active_ext_lang - calls a python command - verifies the command triggers the breakpoint - sends a signal and verifies the result The test-case is fragile, because (f.i. with -flto) it cannot be guaranteed that captured_command_loop and set_active_ext_lang are available for setting breakpoints. Reimplement the test-case as unittest, using: - execute_command_to_string to capture the output - try/catch to catch the "Error while executing Python code" exception - a new hook selftests::hook_set_active_ext_lang to raise the signal Tested on x86_64-linux.
2021-10-19Check index in type::fieldTom Tromey3-2/+3
This changes gdb to check the index that is passed to type::field. This caught one bug in the Ada code when running the test suite (actually I found the bug first, then realized that the check would have helped), so this patch fixes that as well. Regression tested on x86-64 Fedora 34.
2021-10-19Fix Rust lex selftest when using libiconvTom Tromey1-3/+10
The Rust lex selftest fails on our Windows build. I tracked this down to a use of UTF-32 as a parameter to convert_between_encodings. Here, iconv_open succeeds, but the actual conversion of a tab character fails with EILSEQ. I suspect that "UTF-32" is being interpreted as big-endian, as changing the call to use "UTF-32LE" makes it work. This patch implements this fix.
2021-10-19Fix format_pieces selftest on WindowsTom Tromey3-72/+57
The format_pieces selftest currently fails on Windows hosts. The selftest doesn't handle the "%ll" -> "%I64" rewrite that the formatter may perform, but also gdbsupport was missing a configure check for PRINTF_HAS_LONG_LONG. This patch fixes both issues.
2021-10-19Fix bug in dynamic type resolutionTom Tromey3-3/+35
A customer-reported problem led us to a bug in dynamic type resolution. resolve_dynamic_struct will recursively call resolve_dynamic_type_internal, passing it the sub-object for the particular field being resolved. While it offsets the address here, it does not also offset the "valaddr" -- the array of bytes describing the memory. This patch fixes the bug, by offsetting both. A test case is included that can be used to reproduce the bug.
2021-10-19Fix PR gdb/17917 Lookup build-id in remote binariesDaniel Black1-9/+12
GDB doesn't support loading debug files using build-id from remote target filesystems. This is the case when gdbserver attached to a process and a gdb target remote occurs over tcp. With this change we make build-id lookups possible: (gdb) show debug-file-directory The directory where separate debug symbols are searched for is "/usr/local/lib/debug". (gdb) set debug-file-directory /usr/lib/debug (gdb) show sysroot The current system root is "target:". (gdb) target extended-remote :46615 Remote debugging using :46615 warning: Can not parse XML target description; XML support was disabled at compile time Reading /usr/sbin/mariadbd from remote target... warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. Reading /usr/sbin/mariadbd from remote target... Reading symbols from target:/usr/sbin/mariadbd... Reading /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target... Reading /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target... Reading symbols from target:/usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug... Reading /lib/x86_64-linux-gnu/libpcre2-8.so.0 from remote target... ... Before this change, the lookups would have been (GNU gdb (GDB) Fedora 10.2-3.fc34): (gdb) target extended-remote :46615 Remote debugging using :46615 Reading /usr/sbin/mariadbd from remote target... warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. Reading /usr/sbin/mariadbd from remote target... Reading symbols from target:/usr/sbin/mariadbd... Reading /usr/sbin/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target... Reading /usr/sbin/.debug/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target... Reading /usr/lib/debug//usr/sbin/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target... Reading /usr/lib/debug/usr/sbin//0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target... Reading target:/usr/lib/debug/usr/sbin//0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target... Missing separate debuginfo for target:/usr/sbin/mariadbd Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug (No debugging symbols found in target:/usr/sbin/mariadbd) Observe it didn't look for /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug on the remote target (where it is) and expected them to be installed locally. As a minor optimization, this also changes the build-id lookup such that if sysroot is empty, no second lookup of the same location is performed. Change-Id: I5181696d271c325a25a0805a8defb8ab7f9b3f55 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17917
2021-10-18CTF: incorrect underlying type setting for enumeration typesWeimin Pan6-36/+42
A bug was filed against the incorrect underlying type setting for an enumeration type, which was caused by a copy and paste error. This patch fixes the problem by setting it by calling objfile_int_type, which was originally dwarf2_per_objfile::int_type, with ctf_type_size bits. Also add error checking on ctf_func_type_info call.
2021-10-14Powerpc: Add support for openat and fstatat syscallsCarl Love1-2/+11
[gdb] update ppc-linux-tdep.c Add argument to ppc_canonicalize_syscall for the wordsize. Add syscall entries for the openat and fstatat system calls.
2021-10-14[gdb/testsuite] Add .debug_loc support in dwarf assemblerTom de Vries3-0/+257
Add .debug_loc support in the dwarf assembler, and use it in new test-case gdb.dwarf2/loc-sec-offset.exp (which is based on gdb.dwarf2/loclists-sec-offset.exp). Tested on x86_64-linux.
2021-10-13[gdb/exp] Improve <error reading variable> messageTom de Vries3-1/+75
When printing a variable x in a subroutine foo: ... subroutine foo (x) integer(4) :: x (*) x(3) = 1 end subroutine foo ... where x is an array with unknown bounds, we get: ... $ gdb -q -batch outputs/gdb.fortran/array-no-bounds/array-no-bounds \ -ex "break foo" \ -ex run \ -ex "print x" Breakpoint 1 at 0x4005cf: file array-no-bounds.f90, line 18. Breakpoint 1, foo (x=...) at array-no-bounds.f90:18 18 x(3) = 1 $1 = <error reading variable> ... Improve the error message by printing the details of the error, such that we have instead: ... $1 = <error reading variable: failed to get range bounds> ... This is a change in gdb/valprint.c, and grepping through the sources reveals that this is a common pattern. Tested on x86_64-linux.
2021-10-13PPC fix for stfiwx instruction (and additional stores with primary opcode of 31)Carl Love1-4/+4
[gdb] Fix address being recorded in rs6000-tdep.c, ppc_process_record_op31. The GDB record function was recording the variable addr that was passed in rather than the calculated effective address (ea) by the ppc_process_record_op31 function.
2021-10-13gdb: improve error reporting from the disassemblerAndrew Burgess2-6/+15
If the libopcodes disassembler returns a negative value then this indicates that the disassembly failed for some reason. In disas.c, in the function gdb_disassembler::print_insn we can see how this is handled; when we get a negative value back, we call the memory_error function, which throws an exception. The problem here is that the address used in the memory_error call is gdb_disassembler::m_err_memaddr, which is set in gdb_disassembler::dis_asm_memory_error, which is called from within the libopcodes disassembler through the disassembler_info::memory_error_func callback. However, for this to work correctly, every time the libopcodes disassembler returns a negative value, the libopcodes disassembler must have first called the memory_error_func callback. My first plan was to make m_err_memaddr a gdb::optional, and assert that it always had a value prior to calling memory_error, however, a quick look in opcodes/*-dis.c shows that there _are_ cases where a negative value is returned without first calling the memory_error_func callback, for example in arc-dis.c and cris-dis.c. Now, I think that a good argument can be made that these disassemblers must therefore be broken, except for the case where we can't read memory, we should always be able to disassemble the memory contents to _something_, even if it's just '.word 0x....'. However, I certainly don't plan to go and fix all of the disassemblers. What I do propose to do then, is make m_err_memaddr a gdb::optional, but now, instead of always calling memory_error, I add a new path which just calls error complaining about an unknown error. This new path is only used if m_err_memaddr doesn't have a value (indicating that the memory_error_func callback was not called). To test this I just augmented one of the disassemblers to always return -1, before this patch I see this: Dump of assembler code for function main: 0x000101aa <+0>: Cannot access memory at address 0x0 And after this commit I now see: Dump of assembler code for function main: 0x000101aa <+0>: unknown disassembler error (error = -1) This doesn't really help much, but that's because there's no way to report non memory errors out of the disasembler, because, it was not expected that the disassembler would ever report non memory errors.
2021-10-13[gdb/testsuite] Fix gdb.fortran/call-no-debug.exp with native-gdbserverTom de Vries1-1/+3
When running test-case gdb.fortran/call-no-debug.exp with target board native-gdbserver, I run into: ... (gdb) PASS: gdb.fortran/call-no-debug.exp: print string_func_ (&'abcdefg', 3) call (integer) string_func_ (&'abcdefg', 3)^M $2 = 0^M (gdb) FAIL: gdb.fortran/call-no-debug.exp: call (integer) string_func_ (&'abcdefg', 3) ... The problem is that gdb_test is used to match inferior output. Fix this by using gdb_test_stdio. Tested on x86_64-linux.
2021-10-13[gdb/testsuite] Require use_gdb_stub == 0 where appropriateTom de Vries6-17/+35
When running with target board native-gdbserver, we run into a number of FAILs due to use of the start command (and similar), which is not supported when use_gdb_stub == 1. Fix this by: - requiring use_gdb_stub == 0 for the entire test-case, or - guarding some tests in the test-case with use_gdb_stub == 0. Tested on x86_64-linux.
2021-10-13[gdb/testsuite] Fix test name in gdb.python/python.expTom de Vries1-4/+11
When running test-case gdb.python/python.exp, we have: ... PASS: gdb.python/python.exp: starti via gdb.execute, not from tty PASS: gdb.python/python.exp: starti via interactive input ... The two tests are instances of the same test, with different values for starti command argument from_tty, so it's strange that the test names are so different. This is due to using a gdb_test nested in a gdb_test_multiple, with the inner one using a different test name than the outer one. [ That could still make sense if both produced passes, but that's not the case here. ] Fix this by using $gdb_test_name, such that we have: ... PASS: gdb.python/python.exp: starti via gdb.execute, not from tty PASS: gdb.python/python.exp: starti via gdb.execute, from tty ... Also make this more readable by using variables. Tested on x86_64-linux.
2021-10-13[gdb/testsuite] Fix gdb.base/batch-exit-status.exp with native-gdbserverTom de Vries1-1/+1
When running test-case gdb.base/batch-exit-status.exp with target board native-gdbserver, I run into (added missing double quotes for clarity): ... builtin_spawn $build/gdb/testsuite/../../gdb/gdb -nw -nx \ -data-directory $build/gdb/testsuite/../data-directory \ -iex "set height 0" -iex "set width 0" \ -ex "set auto-connect-native-target off" \ -iex "set sysroot" -batch ""^M : No such file or directory.^M PASS: gdb.base/batch-exit-status.exp: 1x: \ No such file or directory: [lindex $result 2] == 0 FAIL: gdb.base/batch-exit-status.exp: 1x: \ No such file or directory: [lindex $result 3] == $expect_status ... As in commit a02a90c114c "[gdb/testsuite] Set sysroot earlier in local-board.exp", the problem is the use of -ex for "set auto-connect-native-target off", which makes that the last command to be executed, and consequently determines the return status. Fix this by using -iex instead. Tested on x86_64-linux.
2021-10-13[gdb/testsuite] Remove quit in gdb.arch/i386-mpx.expTom de Vries1-2/+0
When running test-case gdb.arch/i386-mpx.exp with target board native-gdbserver, I run into: ... (gdb) PASS: gdb.arch/i386-mpx.exp: verify size for bnd0 Remote debugging from host ::1, port 42328^M quit^M A debugging session is active.^M ^M Inferior 1 [process 19679] will be killed.^M ^M Quit anyway? (y or n) monitor exit^M Please answer y or n.^M A debugging session is active.^M ^M Inferior 1 [process 19679] will be killed.^M ^M Quit anyway? (y or n) WARNING: Timed out waiting for EOF in server after monitor exit ... The problem is that the test-case sends a quit at the end (without verifying the result of this in any way): ... send_gdb "quit\n" ... Fix this by removing the quit. Tested on x86_64-linux.
2021-10-11[ARM] Add support for M-profile MVE extensionSrinath Parvathaneni9-4/+206
This patch adds support for the M-profile MVE extension, which includes the following: - New M-profile XML feature m-profile-mve - MVE vector predication status and control register (VPR) - p0 pseudo register (contained in the VPR) - q0 ~ q7 pseudo vector registers - New feature bits - Documentation update Pseudo register p0 is the least significant bits of vpr and can be accessed as $p0 or displayed through $vpr. For more information about the register layout, please refer to [1]. The q0 ~ q7 registers map back to the d0 ~ d15 registers, two d registers per q register. The register dump looks like this: (gdb) info reg all r0 0x0 0 r1 0x0 0 r2 0x0 0 r3 0x0 0 r4 0x0 0 r5 0x0 0 r6 0x0 0 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x0 0 sp 0x0 0x0 <__Vectors> lr 0xffffffff -1 pc 0xd0c 0xd0c <Reset_Handler> xpsr 0x1000000 16777216 d0 0 (raw 0x0000000000000000) d1 0 (raw 0x0000000000000000) d2 0 (raw 0x0000000000000000) d3 0 (raw 0x0000000000000000) d4 0 (raw 0x0000000000000000) d5 0 (raw 0x0000000000000000) d6 0 (raw 0x0000000000000000) d7 0 (raw 0x0000000000000000) d8 0 (raw 0x0000000000000000) d9 0 (raw 0x0000000000000000) d10 0 (raw 0x0000000000000000) d11 0 (raw 0x0000000000000000) d12 0 (raw 0x0000000000000000) d13 0 (raw 0x0000000000000000) d14 0 (raw 0x0000000000000000) d15 0 (raw 0x0000000000000000) fpscr 0x0 0 vpr 0x0 [ P0=0 MASK01=0 MASK23=0 ] s0 0 (raw 0x00000000) s1 0 (raw 0x00000000) s2 0 (raw 0x00000000) s3 0 (raw 0x00000000) s4 0 (raw 0x00000000) s5 0 (raw 0x00000000) s6 0 (raw 0x00000000) s7 0 (raw 0x00000000) s8 0 (raw 0x00000000) s9 0 (raw 0x00000000) s10 0 (raw 0x00000000) s11 0 (raw 0x00000000) s12 0 (raw 0x00000000) s13 0 (raw 0x00000000) s14 0 (raw 0x00000000) s15 0 (raw 0x00000000) s16 0 (raw 0x00000000) s17 0 (raw 0x00000000) s18 0 (raw 0x00000000) s19 0 (raw 0x00000000) s20 0 (raw 0x00000000) s21 0 (raw 0x00000000) s22 0 (raw 0x00000000) s23 0 (raw 0x00000000) s24 0 (raw 0x00000000) s25 0 (raw 0x00000000) s26 0 (raw 0x00000000) s27 0 (raw 0x00000000) s28 0 (raw 0x00000000) s29 0 (raw 0x00000000) s30 0 (raw 0x00000000) s31 0 (raw 0x00000000) q0 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q1 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q2 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q3 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q4 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q5 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q6 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q7 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} p0 0x0 0 Built and regtested with a simulator. [1] https://developer.arm.com/documentation/ddi0553/bn Co-Authored-By: Luis Machado <luis.machado@linaro.org>
2021-10-11[ARM] Refactor pseudo register numberingLuis Machado2-45/+115
The pseudo register handling for ARM uses some hardcoded constants to determine types and names. In preparation to the upcoming MVE support patch (that will add another pseudo register), this patch refactors and reorganizes things in order to simplify handling of future pseudo registers. We keep track of the first pseudo register number in a group and the number of pseudo registers in that group. Right now we only have the S and Q pseudo registers.
2021-10-11[ARM] Small refactoring of arm gdbarch initializationLuis Machado1-11/+11
This is in preparation to MVE support, where we will define another pseudo register. We need to define the pseudo register numbers *after* accounting for all the registers in the XML description, so move the call to tdesc_use_registers up. If we don't do it, GDB's register count won't consider registers contained in the XML but ignored by GDB, throwing the register numbering off.
2021-10-11[ARM] Refactor some constantsLuis Machado1-4/+10
In preparation for the MVE extension patch, this one refactors some of the register-related constants we have for ARM. Basically I'm separating counting constants from numbering constants. For example, ARM_A1_REGNUM is a numbering constant, whereas ARM_NUM_ARG_REGS is a counting constant.
2021-10-11[gdb/testsuite] Fix FAIL in gdb.mi/mi-var-child-f.expTom de Vries7-0/+41
When running test-case gdb.mi/mi-var-child-f.exp on openSUSE Tumbleweed (with glibc 2.34) I run into: ... (gdb) ^M PASS: gdb.mi/mi-var-child-f.exp: mi runto prog_array Expecting: ^(-var-create array \* array[^M ]+)?(\^done,name="array",numchild="[0-9]+",value=".*",type=.*,has_more="0"[^M ]+[(]gdb[)] ^M [ ]*) -var-create array * array^M &"Attempt to use a type name as an expression.\n"^M ^error,msg="-var-create: unable to create variable object"^M (gdb) ^M FAIL: gdb.mi/mi-var-child-f.exp: create local variable array (unexpected output) ... The problem is that the name array is used both: - as the name for a local variable - as the name of a type in glibc, in file malloc/dynarray-skeleton.c, as included by nss/nss_files/files-hosts.c. Fix this by ignoring the shared lib symbols. Likewise in a couple of other fortran tests. Tested on x86_64-linux.
2021-10-11[gdb/testsuite] Fix double debug info in gdb.dwarf2/dw2-ref-missing-frame.expTom de Vries1-3/+5
A mistake slipped in in commit a5ea23036d8 "[gdb/testsuite] Use function_range in gdb.dwarf2/dw2-ref-missing-frame.exp". Before the commit the main file was compiled with debug info, and the two others not: ... if {[prepare_for_testing_full "failed to prepare" \ [list $testfile {} $srcfile {} $srcfuncfile {} \ $srcmainfile debug]]} { ... After the commit, all were compiled with debug info, and consequently, there are two versions of debug info for $srcfuncfile. This shows up as a FAIL when running the test-case with target boards readnow and cc-with-debug-names. Fix this by using prepare_for_testing_full, as before. Tested on x86_64-linux. Fixes: a5ea23036d8 ("[gdb/testsuite] Use function_range in gdb.dwarf2/dw2-ref-missing-frame.exp")
2021-10-11[gdb/testsuite] Use require for ensure_gdb_indexTom de Vries6-15/+9
Replace: ... if { [ensure_gdb_index $binfile] == -1 } { return -1 } ... with: ... require {ensure_gdb_index $binfile} != -1 ... and consequently, add a missing UNTESTED message. Tested on x86_64-linux, both with native and target board readnow.
2021-10-11[gdb/testsuite] Handle readnow in ensure_gdb_indexTom de Vries1-0/+9
When running test-case gdb.base/with-mf.exp with target board readnow, I run into: ... FAIL: gdb.base/with-mf.exp: check if index present ... This is since commit 6010fb0c49e "[gdb/testsuite] Fix full buffer in gdb.rust/dwindex.exp". Before that commit, the proc ensure_gdb_index would treat the line: ... .gdb_index: faked for "readnow"^M ... as proof that an index is already present (which is incorrect). Now, instead it generates aforementioned FAIL and continues to generate an index. Fix this by explicitly handling the readnow case in proc ensure_gdb_index, such that we bail out instead. Tested on x86_64-linux.
2021-10-11[gdb/testsuite] Fix gdb.dwarf2/gdb-add-index-symlink.expTom de Vries1-0/+13
The test-case gdb.dwarf2/gdb-add-index-symlink.exp interpretes a failure to add an index as a failure to add an index for a symlink: ... if { [ensure_gdb_index $symlink] == -1 } { fail "Unable to call gdb-add-index with a symlink to a symfile" return -1 } ... However, it's possible that the gdb-add-index also fails with a regular file. Add a check for that situation. Tested on x86_64-linux.
2021-10-11[gdb/testsuite] Add proc require in lib/gdb.expTom de Vries5-20/+38
Add a new proc require in lib/gdb.exp, and use it to shorten: ... if { [gdb_skip_xml_test] } { # Valgrind gdbserver requires gdb with xml support. untested "missing xml support" return 0 } ... into: ... require gdb_skip_xml_test 0 ... Tested on x86_64-linux, both with and without a trigger patch that forces gdb_skip_xml_test to return 1.
2021-10-09[gdb] Make execute_command_to_string return string on throwTom de Vries7-20/+50
The pattern for using execute_command_to_string is: ... std::string output; output = execute_fn_to_string (fn, term_out); ... This results in a problem when using it in a try/catch: ... try { output = execute_fn_to_string (fn, term_out) } catch (const gdb_exception &e) { /* Use output. */ } ... If an expection was thrown during execute_fn_to_string, then the output remains unassigned, while it could be worthwhile to known what output was generated by gdb before the expection was thrown. Fix this by returning the string using a parameter instead: ... execute_fn_to_string (output, fn, term_out) ... Also add a variant without string parameter, to support places where the function is used while ignoring the result: ... execute_fn_to_string (fn, term_out) ... Tested on x86_64-linux.
2021-10-09[gdb/testsuite] Add check-readmoreTom de Vries5-21/+166
Consider the gdb output: ... 27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M (gdb) ^M Thread 2 "run-attach-whil" stopped.^M ... When trying to match the gdb prompt using gdb_test which uses '$gdb_prompt $', it may pass or fail. This sort of thing needs to be fixed (see commit b0e2f96b56b), but there's currently no way to reliably find this type of FAILs. We have check-read1, but that one actually make the test pass reliably. We need something like the opposite of check-read1: something that makes expect read a bit slower, or more exhaustively. Add a new test target check-readmore that implements this. There are two methods of implementing this in read1.c: - the first method waits a bit before doing a read - the second method does a read and then decides whether to return or to wait a bit and do another read, and so on. The second method is potentially faster, has less risc of timeout and could potentially detect more problems. The first method has a simpler implementation. The second method is enabled by default. The default waiting period is 10 miliseconds. The first method can be enabled using: ... $ export READMORE_METHOD=1 ... and the waiting period can be specified in miliseconds using: ... $ export READMORE_SLEEP=9 ... Also a log file can be specified using: ... $ export READMORE_LOG=$(pwd -P)/LOG ... Tested on x86_64-linux. Testing with check-readmore showed these regressions: ... FAIL: gdb.base/bp-cmds-continue-ctrl-c.exp: run: stop with control-c (continue) FAIL: gdb.base/bp-cmds-continue-ctrl-c.exp: attach: stop with control-c (continue) ... I have not been able to find a problem in the test-case, and I think it's the nature of both the test-case and readmore that makes it run longer. Make these pass by increasing the alarm timeout from 60 to 120 seconds. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27957
2021-10-09[gdb/testsuite] Fix fortran module tests with stressed cpuTom de Vries3-0/+17
When running these test-cases: - gdb.fortran/info-modules.exp - gdb.fortran/module.exp - gdb.mi/mi-fortran-modules.exp in conjunction with: ... $ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1)) ... I run into timeouts. Fix this by using: - "set auto-solib-add off" to avoid symbols of shared libs (which doesn't work for libc, now that libpthread_name_p has been updated to match libc) - "nosharedlibrary" to avoid symbols of libc Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28133
2021-10-09[gdb/testsuite] Fix gdb.base/info-types-c++.exp with stressed cpuTom de Vries1-0/+1
When running test-case gdb.base/info-types-c++.exp in conjunction with: ... $ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1)) ... we get: ... FAIL: gdb.base/info-types-c++.exp: info types (timeout) ... Fix this by setting auto-solib-add to off. Tested on x86_64-linux.
2021-10-08[gdb/testsuite] Fix gdb.base/info_sources_2.exp with check-read1Tom de Vries1-4/+12
When running test-case gdb.base/info_sources_2.exp with check-read1, I run into: ... FAIL: gdb.base/info_sources_2.exp: args: : info sources (timeout) ... Fix this by consuming a "$src1, $src2, ..., $srcn: line bit by bit rather than as one whole line. Also add the missing handling of "Objfile has no debug information". Tested on x86_64-linux.
2021-10-08[gdb/testsuite] Fix gdb.mi/gdb2549.exp with check-read1Tom de Vries1-25/+21
When running test-case gdb.mi/gdb2549.exp with check-read1, I run into: ... FAIL: gdb.mi/gdb2549.exp: register values x (timeout) ... Fix this by applying the same fix as for "register values t" in commit 478e490a4df "[gdb/testsuite] Fix gdb.mi/gdb2549.exp with check-read1". Tested on x86_64-linux.
2021-10-08[gdb/testsuite] Fix gdb.base/bt-on-error-and-warning.exp with check-read1Tom de Vries1-2/+2
When running test-case gdb.base/bt-on-error-and-warning.exp with check-read1, I run into: ... (gdb) maint internal-error foobar^M src/gdb/maint.c:82: internal-error: foobar^M A problem internal to GDB has been detectedFAIL: \ gdb.base/bt-on-error-and-warning.exp: problem=internal-error, mode=on: \ scan for backtrace (GDB internal error) Resyncing due to internal error. ,^M ... The corresponding gdb_test_multiple in the test-case contains: ... -early -re "^A problem internal to GDB has been detected,\r\n" { incr header_lines exp_continue } ... but instead this one triggers in gdb_test_multiple: ... -re ".*A problem internal to GDB has been detected" { fail "$message (GDB internal error)" gdb_internal_error_resync set result -1 } ... Fix this by likewise shortening the regexp to before the comma. Tested on x86_64-linux.
2021-10-08[gdb/testsuite] Add nopie in two test-casesTom de Vries2-1/+4
When running test-case gdb.dwarf2/dw2-restrict.exp on openSUSE Leap 15.2 with gcc-PIE installed (switching compiler default to -fPIE/-pie), I get: ... gdb compile failed, ld: outputs/gdb.dwarf2/dw2-restrict/dw2-restrict0.o: \ warning: relocation in read-only section `.text' ld: warning: creating DT_TEXTREL in a PIE UNTESTED: gdb.dwarf2/dw2-restrict.exp: failed to prepare ... This is due to using a hardcoded .S file that was generated with -fno-PIE. Fix this by adding the missing nopie. Likewise in gdb.arch/amd64-tailcall-noret.exp. Tested on x86_64-linux.
2021-10-07[gdb/testsuite] Fix gdb.threads/check-libthread-db.exp with glibc 2.34Tom de Vries1-1/+3
When running test-case gdb.threads/check-libthread-db.exp on openSUSE Tumbleweed (with glibc 2.34) I get: ... (gdb) continue^M Continuing.^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M Stopped due to shared library event:^M Inferior loaded /lib64/libm.so.6^M /lib64/libc.so.6^M (gdb) FAIL: gdb.threads/check-libthread-db.exp: user-initiated check: continue ... The check expect the inferior to load libpthread, but since glibc 2.34 libpthread has been integrated into glibc, and consequently it's no longer a dependency: ... $ ldd outputs/gdb.threads/check-libthread-db/check-libthread-db linux-vdso.so.1 (0x00007ffe4cae4000) libm.so.6 => /lib64/libm.so.6 (0x00007f167c77c000) libc.so.6 => /lib64/libc.so.6 (0x00007f167c572000) /lib64/ld-linux-x86-64.so.2 (0x00007f167c86e000) ... Fix this by updating the regexp to expect libpthread or libc. Tested on x86_64-linux.
2021-10-07[gdb/testsuite] Fix gdb.guile/scm-type.exp with gcc 4.8Tom de Vries1-1/+1
With gcc 7.5.0, I get: ... (gdb) guile (print (type-range (field-type (type-field (value-type \ (value-dereference f)) "items"))))^M = (0 0)^M (gdb) PASS: gdb.guile/scm-type.exp: lang_cpp: test_range: \ on flexible array member: $cmd ... but with gcc 4.8.5, I get instead: ... (gdb) guile (print (type-range (field-type (type-field (value-type \ (value-dereference f)) "items"))))^M = (0 -1)^M (gdb) FAIL: gdb.guile/scm-type.exp: lang_cpp: test_range: \ on flexible array member: $cmd ... There's a difference in debug info. With gcc 4.8.5, we have: ... <2><224>: Abbrev Number: 15 (DW_TAG_member) <225> DW_AT_name : items <22b> DW_AT_type : <0x231> <1><231>: Abbrev Number: 4 (DW_TAG_array_type) <232> DW_AT_type : <0x105> <2><23a>: Abbrev Number: 16 (DW_TAG_subrange_type) <23b> DW_AT_type : <0x11a> <23f> DW_AT_upper_bound : 0xffffffffffffffff ... and with gcc 7.5.0, we have instead: ... <2><89f>: Abbrev Number: 12 (DW_TAG_member) <8a0> DW_AT_name : items <8a6> DW_AT_type : <0x8ac> <1><8ac>: Abbrev Number: 17 (DW_TAG_array_type) <8ad> DW_AT_type : <0x29d> <2><8b5>: Abbrev Number: 41 (DW_TAG_subrange_type) <2><8b6>: Abbrev Number: 0 ... As mentioned in commit 858c8f2c1b9 "gdb/testsuite: adjust gdb.python/flexible-array-member.exp expected pattern": ... Ideally, GDB would present a consistent and documented value for an array member declared with size 0, regardless of how the debug info looks like. ... As in gdb.python/flexible-array-member.exp, change the test to accept the two values. Tested on x86_64-linux.
2021-10-07gdb: add accessors for field (and call site) locationSimon Marchi14-105/+189
Add accessors for the various location values in struct field. This lets us assert that when we get a location value of a certain kind (say, bitpos), the field's location indeed contains a value of that kind. Remove the SET_FIELD_* macros, instead use the new setters directly. Update the FIELD_* macros used to access field locations to go through the getters. They will be removed in a subsequent patch. There are places where the FIELD_* macros are used on call_site_target structures, because it contains members of the same name (loc_kind and loc). For now, I have replicated the getters/setters in call_site_target. But we could perhaps eventually factor them in a "location" structure that can be used at both places. Note that the field structure, being zero-initialized, defaults to a bitpos location with value 0. While writing this patch, I tried to make it default to an "unset" location, to catch places where we would miss setting a field's location. However, I found that some places relied on the default being "bitpos 0", so I left it as-is. This change could always be done as follow-up work, making these places explicitly set the "bitpos 0" location. I found two issues to fix: - I got some failures in the gdb.base/infcall-nested-structs-c++.exp test. They were caused by two functions in amd64-tdep.c using TYPE_FIELD_BITPOS before checking if the location is of the bitpos kind, which they do indirectly through `field_is_static`. Simply move getting the bitpos below the field_is_static call. - I got a failure in gdb.xml/tdesc-regs.exp. It turns out that in make_gdb_type_enum, we set enum field values using SET_FIELD_BITPOS, and later access them through FIELD_ENUMVAL. Fix that by using set_loc_enumval to set the value. Change-Id: I53d3734916c46457576ba11dd77df4049d2fc1e8
2021-10-07[gdb/testsuite] Fix FAIL in gdb.base/annota1.expTom de Vries1-1/+5
On openSUSE tumbleweed I run into: ... FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout) ... due to a message related to libthread_db: ... ^Z^Zstarting^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M ^M ^Z^Zframes-invalid^M ... which is not matched by the regexp. Fix this by updating the regexp. Tested on x86_64-linux.
2021-10-07[gdb/testsuite] Refactor regexp in gdb.base/annota1.expTom de Vries1-21/+35
Refactor regexp in gdb.base/annota1.exp to reduce indentation and repetition. Tested on x86_64-linux.
2021-10-06gdb/doc: improve 'show print elements' descriptionAndrew Burgess1-1/+0
The documentation for 'show print elements' contains the line: If the number is 0, then the printing is unlimited. However, this line is now out of date as can be seen by this GDB session: (gdb) set print elements 0 (gdb) show print elements Limit on string chars or array elements to print is unlimited. The value 0 does indeed mean unlimited, and this is described in the 'set print elements' section, however, for 'show print elements' the user will never see the value 0, so lets just remove that bit from the docs.
2021-10-06[gdb/testsuite] Fix FAIL in gdb.tui/corefile-run.expTom de Vries2-1/+2
When running test-case gdb.tui/corefile-run.exp on openSUSE Tumbleweed, I run into: ... PASS: gdb.tui/corefile-run.exp: load corefile FAIL: gdb.tui/corefile-run.exp: run until the end ... What's going on is easier to see when also doing dump_screen if check_contents passes, and inspecting state at the preceding PASS: ... +-------------------------------------------------------------------------+ exec No process In: L?? PC: ?? [New LWP 16629] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/data/gdb_versions/devel/build/gdb/testsuite/output s/gdb.tui/corefile-run/corefi'. Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 main () --Type <RET> for more, q to quit, c to continue without paging-- ... The problem is that we're getting a pagination prompt, and the subsequent run command is interpreted as an answer to that prompt. Fix this by: - detecting the gdb prompt in response to "load corefile", such that we detect the failure earlier, and - doing a "set pagination off" in Term::clean_restart. Tested on x86_64-linux.
2021-10-06[gdb/testsuite] Make tui testing less verboseTom de Vries1-9/+7
Currently, tui testing is rather verbose. When using these RUNTESTFLAGS to pick up all tui tests (17 in total): ... rtf=$(echo $(cd src/gdb/testsuite/; find gdb.* -type f -name *.exp* \ | xargs grep -l tuiterm_env) ) ... we have: ... $ wc -l gdb.log 120592 gdb.log ... Most of the output is related to controlling the tui screen, but that does not give a top-level sense of how the test-case progresses. Put differently: a lot of bandwith is used to describe how we arrive at a certain tui screen state. But we don't actually always show the state we arrive at, unless there's a FAIL. And if there's say, a PASS that should actually be FAILing, it's hard to detect. Fix this by: - dropping the -log on the call to verbose in _log. We still can get the same info back using runtest -v. - dumping the screen or box that we're checking, also when the test passes. Brings down verbosity to something more reasonable: ... $ wc -l gdb.log 3221 gdb.log ... Tested on x86_64-linux.
2021-10-06[gdb/testsuite] Add Term::dump_box in lib/tuiterm.expTom de Vries1-9/+33
Factor out new proc Term::get_region and use it to implement a new proc Term::dump_box, similar to Term::dump_screen. Tested on x86_64-linux.
2021-10-05gdb: Remove deprecated assertion in setting::getLancelot SIX1-1/+0
The commit 702991711a91bd47b209289562843a11e7009396 (gdb: Have setter and getter callbacks for settings) makes it possible for a setting not to be backed by a memory buffer but use callback functions instead to retrieve or set the setting's value. An assertion was not properly updated to take into account that the m_var member (which points to a memory buffer, if used) might be nullptr if the setting uses callback functions. If the setting is backed by a memory buffer, the m_var has to be non nullptr, which is already checked before the pointer is dereferenced. This commit removes this assertion as it is not valid anymore.
2021-10-05Remove 'varsize-limit'Tom Tromey7-63/+33
This makes the Ada-specific "varsize-limit" a synonym for "max-value-size", and removes the Ada-specific checks of the limit. I am not certain of the history here, but it seems to me that this code is fully obsolete now. And, removing this makes it possible to index large Ada arrays without triggering an error. A new test case is included to demonstrate this.
2021-10-05Allow lazy 'zero' valueTom Tromey2-12/+23
This changes value_zero to create a lazy value. In many cases, value_zero is called in expression evaluation to wrap a type in a non-eval context. It seems senseless to allocate a buffer in these cases. A new 'is_zero' flag is added so we can preserve the existing assertions in value_fetch_lazy. A subsequent patch will add a test where creating a zero value would fail, due to the variable size check. However, the contents of this value are never needed, and so creating a lazy value avoids the error case.
2021-10-05Add lval_funcs::is_optimized_outTom Tromey5-15/+66
This adds an is_optimized_out function pointer to lval_funcs, and changes value_optimized_out to call it. This new function lets gdb determine if a value is optimized out without necessarily fetching the value. This is needed for a subsequent patch, where an attempt to access a lazy value would fail due to the value size limit -- however, the access was only needed to determine the optimized-out state.
2021-10-05[gdb/testsuite] Fix FAIL in gdb.mi/mi-nsmoribund.expTom de Vries1-1/+5
Since commit e36788d1354 "[gdb/testsuite] Fix handling of nr_args < 3 in mi_gdb_test" we run into: ... PASS: gdb.mi/mi-nsmoribund.exp: print done = 1 Expecting: ^(.*[^M ]+)?([^ ]*^M \*running,thread-id="[0-9]+"^M \*running,thread-id="[0-9]+"^M \*running,thread-id="[0-9]+"^M \*running,thread-id="[0-9]+"^M \*running,thread-id="[0-9]+"^M \*running,thread-id="[0-9]+"^M \*running,thread-id="[0-9]+"^M \*running,thread-id="[0-9]+"^M \*running,thread-id="[0-9]+"^M \*running,thread-id="[0-9]+"[^M ]+[(]gdb[)] ^M [ ]*) 103-exec-continue --all^M =library-loaded,id="/lib64/libgcc_s.so.1",target-name="/lib64/libgcc_s.so.1",\ host-name="/lib64/libgcc_s.so.1",symbols-loaded="0",thread-group="i1",\ ranges=[{from="0x00007ffff22a5010",to="0x00007ffff22b6365"}]^M 103^running^M *running,thread-id="5"^M (gdb) ^M FAIL: gdb.mi/mi-nsmoribund.exp: 103-exec-continue --all (unexpected output) ... The regexp expect running messages for all threads, but we only get one for thread 5. The test-case uses non-stop mode, and when the exec-continue --all command is issued, thread 5 is stopped and all other threads are running. Consequently, only thread 5 is resumed, and reported as running. Fix this by updating the regexp. Tested on x86_64-linux.
2021-10-05gdb/python: fix memory leak in python inferior codeAndrew Burgess4-4/+176
When a user creates a gdb.Inferior object for the first time a new Python object is created. This object is then cached within GDB's inferior object using the registry mechanism (see inferior_to_inferior_object in py-inferior.c, specifically the calls to inferior_data and set_inferior_data). The Python Reference to the gdb.Inferior object held within the real inferior object ensures that the reference count on the Python gdb.Inferior object never reaches zero while the GDB inferior object continues to exist. At the same time, the gdb.Inferior object maintains a C++ pointer back to GDB's real inferior object. We therefore end up with a system that looks like this: Python Reference | | .----------. | .--------------. | |------------------->| | | inferior | | gdb.Inferior | | |<-------------------| | '----------' | '--------------' | | C++ Pointer When GDB's inferior object is deleted (say the inferior exits) then py_free_inferior is called (thanks to the registry system), this function looks up the Python gdb.Inferior object and sets the C++ pointer to nullptr and finally reduces the reference count on the Python gdb.Inferior object. If at this point the user still holds a reference to the Python gdb.Inferior object then nothing happens. However, the gdb.Inferior object is now in the non-valid state (see infpy_is_valid in py-inferior.c), but otherwise, everything is fine. However, if there are no further references to the Python gdb.Inferior object, or, once the user has given up all their references to the gdb.Inferior object, then infpy_dealloc is called. This function currently checks to see if the inferior pointer within the gdb.Inferior object is nullptr or not. If the pointer is nullptr then infpy_dealloc immediately returns. Only when the inferior point in the gdb.Inferior is not nullptr do we (a) set the gdb.Inferior reference inside GDB's inferior to nullptr, and (b) call the underlying Python tp_free function. There are a number things wrong here: 1. The Python gdb.Inferior reference within GDB's inferior object holds a reference count, thus, setting this reference to nullptr without first decrementing the reference count would leak a reference, however... 2. As GDB's inferior holds a reference then infpy_dealloc will never be called until GDB's inferior object is deleted. Deleting a GDB inferior ohject calls py_free_inferior, and so gives up the reference. At this point there is no longer a need to call set_inferior_data to set the field back to NULL, that field must have been cleared in order to get the reference count to zero, which means... 3. If we know that py_free_inferior must be called before infpy_dealloc, then we know that the inferior pointer in gdb.Inferior will always be nullptr when infpy_dealloc is called, this means that the call to the underlying tp_free function will always be skipped. Skipping this call will cause Python to leak the memory associated with the gdb.Inferior object, which is what we currently always do. Given all of the above, I assert that the C++ pointer within gdb.Inferior will always be nullptr when infpy_dealloc is called. That's what this patch does. I wrote a test for this issue making use of Pythons tracemalloc module, which allows us to spot this memory leak.
generated by cgit v1.1 at 2024-12-17 19:53:22 +0000