aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite
AgeCommit message (Collapse)AuthorFilesLines
2024-11-11gdb/testsuite: fix typo 'unsupport' to 'unsupported'Andrew Burgess1-1/+1
I noticed that in commit: commit 5cabc8098e65ac22d4245232ad20b19fa4729802 Date: Wed Jul 31 15:55:57 2024 +0100 gdb/python: implement Python find_exec_by_build_id hook I managed to typo 'unsupported' as 'unsupport'. If you run the test on a target that doesn't support core file creation then you'll get a TCL error. Fixed in this commit.
2024-11-11gdb/testsuite: fix failure in gdb.base/info_sources.expAndrew Burgess1-10/+50
I ran into an unexpected failure in gdb.base/info_sources.exp. The test in question runs this command: (gdb) info sources -d -- -d That is, list all the source files whose directory name matches the regexp '-d'. The expectation is that no source files will be listed. Unfortunately, when I ran the test some source files are listed; the directory I am running in contains the pattern '-d', and so the test fails. As we cannot control where the developer is building and testing GDB, I propose that instead of just testing with '-d' we should search through all the letters a-z and find one that isn't present in the source file directory name. I'm still including the leading '-' character in the regexp. So now, unless GDB is being built in a directory that contains '-a', '-b', '-c', .... '-z', the test will find one letter which isn't present, and use that for the test. To avoid test names changing between runs in different directories I've had to tweak the test name to something more generic, but there should be no change in which parts of GDB are actually being tested. Approved-By: Tom Tromey <tom@tromey.com>
2024-11-11[gdb/testsuite] Reduce quoting in gdb.base/annota1.expTom de Vries1-7/+11
Reduce quoting in gdb.base/annota1.exp, mostly using string_to_regexp. Tested on arm-linux and x86_64-linux.
2024-11-11[gdb/testsuite] Fix gdb.base/annota1.exp on arm-linuxTom de Vries1-0/+2
On arm-linux, gdb.base/annota1.exp fails: ... PASS: gdb.base/annota1.exp: breakpoint info run^M ^M ^Z^Zpost-prompt^M Starting program: /home/linux/gdb/build/gdb/testsuite/outputs/gdb.base/annota1/annota1 ^M ^M ^Z^Zbreakpoints-invalid^M ^M ^Z^Zframes-invalid^M ^M ^Z^Zstarting^M ^M ^Z^Zframes-invalid^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".^M ^M ^Z^Zbreakpoints-invalid^M ^M ^Z^Zbreakpoint 1^M ^M Breakpoint 1, ^M ^Z^Zframe-begin 0 0x40054a^M ^M ^Z^Zframe-function-name^M main^M ^Z^Zframe-args^M ()^M ^Z^Zframe-source-begin^M at ^M ^Z^Zframe-source-file^M /home/linux/gdb/src/gdb/testsuite/gdb.base/annota1.c^M ^Z^Zframe-source-file-end^M :^M ^Z^Zframe-source-line^M 15^M ^Z^Zframe-source-end^M ^M ^M ^Z^Zsource /home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.base/annota1.c:15:103:beg:0x40054a^M ^M ^Z^Zframe-end^M ^M ^Z^Zstopped^M ^M ^Z^Zpre-prompt^M (gdb) ^M ^Z^Zprompt^M FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout) ... because the regexp doesn't match the first frames-invalid annotation. Fix this by adding an optional frames-invalid annotation in the regexp. Tested on arm-linux and x86_64-linux.
2024-11-11[gdb/testsuite] Avoid intermittent failures on another debuginfod testTom de Vries1-1/+1
With test-case gdb.debuginfod/solib-with-soname.exp on aarch64-linux, I ran into: ... (gdb) core-file solib-with-soname.core^M Downloading 197.86 K file libfoo_1.so...^M [New LWP 997314]^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M Core was generated by `solib-with-soname'.^M Program terminated with signal SIGABRT, Aborted.^M (gdb) FAIL: $exp: load core file, use debuginfod: load core file ... The test-case doesn't expect the "197.86 K" part. The same problem was fixed for another test-case in commit a723c56efb0 ("gdb/testsuite: avoid intermittent failures on a debuginfod test"). Fix this in the same way: by updating the regexp. Tested on aarch64-linux. PR testsuite/32354 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32354
2024-11-11Add setting to control frame language mismatch warningTom Tromey2-4/+4
A customer noted that there is no way to prevent the "current language does not match this frame" warning. This patch adds a new setting to allow this warning to be suppressed. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-11-11Re-run isortTom Tromey1-1/+1
pre-commit pointed out that one file needed a change to satisfy isort. This patch is the result.
2024-11-11gdb/dwarf2/read.c: Handle empty CU nameLancelot SIX2-0/+70
I recently came across a case where a compiler would emit a CU with an empty name. In such case, the attribute object constructed by GDB will return nullptr when as_string is called. One place is not checking for this possibility. As a result, loading such binary results in a GDB crash: $ gdb -q a.out Reading symbols from a.out... Fatal signal: Segmentation fault ----- Backtrace ----- [...] 0x742f4dd8afab __strcmp_avx2 ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283 0x58593704a0bc prepare_one_comp_unit ../../gdb/dwarf2/read.c:21842 0x585937053fd9 process_psymtab_comp_unit ../../gdb/dwarf2/read.c:4633 0x585937053fd9 _ZN23cooked_index_debug_info11process_cusEmN9__gnu_cxx17__normal_iteratorIPSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterESt6vectorIS5_SaIS5_EEEESA_ ../../gdb/dwarf2/read.c:4943 [...] --------------------- A fatal error internal to GDB has been detected, further debugging is not possible. GDB will now terminate. This is a bug, please report it. For instructions, see: <https://www.gnu.org/software/gdb/bugs/>. Segmentation fault (core dumped) This seems to be a regression introduced by the following commit: commit 00105aa1c4d9933fe3cfe9bc1be0daefe9f8ca36 Date: Tue Sep 24 10:24:22 2024 +0200 [gdb/symtab] Don't expand non-Ada CUs for info exceptions This patch fixes this issue by checking if attr->as_string returns nullptr. Change-Id: I78fe7a090f0bd1045b8cb2f8d088a8d6cf57fe1c Approved-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
2024-11-10gdb/python: implement Python find_exec_by_build_id hookAndrew Burgess4-0/+816
Implement extension_language_ops::find_objfile_from_buildid within GDB's Python API. Doing this allows users to write Python extensions that can help locate missing objfiles when GDB opens a core file. A handler might perform some project- or site-specific actions to find a missing objfile. Or might provide some project- or site-specific advice to the user on how they can obtain the missing objfile. The implementation is very similar to the approach taken in: commit 8f6c452b5a4e50fbb55ff1d13328b392ad1fd416 Date: Sun Oct 15 22:48:42 2023 +0100 gdb: implement missing debug handler hook for Python The following new commands are added as commands implemented in Python, this is similar to how the Python missing debug and unwinder commands are implemented: info missing-objfile-handlers enable missing-objfile-handler LOCUS HANDLER disable missing-objfile-handler LOCUS HANDLER To make use of this extension hook a user will create missing objfile handler objects, and registers these handlers with GDB. When GDB opens a core file and encounters a missing objfile each handler is called in turn until one is able to help. Here is a minimal handler that does nothing useful: import gdb import gdb.missing_objfile class MyFirstHandler(gdb.missing_objfile.MissingObjfileHandler): def __init__(self): super().__init__("my_first_handler") def __call__(self, pspace, build_id, filename): # This handler does nothing useful. return None gdb.missing_objfile.register_handler(None, MyFirstHandler()) Returning None from the __call__ method tells GDB that this handler was unable to find the missing objfile, and GDB should ask any other registered handlers. Possible return values from a handler: - None: This means the handler couldn't help. GDB will call other registered handlers to see if they can help instead. - False: The handler has done all it can, but the objfile couldn't be found. GDB will not call any other handlers, and will continue without the objfile. - True: The handler has installed the objfile into a location where GDB would normally expect to find it. GDB should repeat its normal lookup process and the objfile should now be found. - A string: The handler can return a filename, which is the missing objfile. GDB will load this file. Handlers can be registered globally, or per program space. GDB checks the handlers for the current program space first, and then all of the global handles. The first handler that returns a value that is not None, has "handled" the missing objfile, at which point GDB continues. The implementation of this feature is mostly straight forward. I have reworked some of the missing debug file related code so that it can be shared with this feature. E.g. gdb/python/lib/gdb/missing_files.py is mostly content moved from gdb/python/lib/gdb/missing_debug.py, but updated to be more generic. Now gdb/python/lib/gdb/missing_debug.py and the new file gdb/python/lib/gdb/missing_objfile.py both call into the missing_files.py file. For gdb/python/lib/gdb/command/missing_files.py this is even more extreme, gdb/python/lib/gdb/command/missing_debug.py is completely gone now and gdb/python/lib/gdb/command/missing_files.py provides all of the new commands in a generic way. I have made one change to the existing Python API, I renamed the attribute Progspace.missing_debug_handlers to Progspace.missing_file_handlers. I don't see this as too problematic. This attribute was only used to implement the missing debug feature and was never documented beyond the fact that it existed. There was no reason for users to be touching this attribute. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2024-11-10gdb: use mapped file information to improve debuginfod textAndrew Burgess2-2/+2
When opening a core-file GDB is able to use debuginfod to download the executable that matches the core-file if GDB can find a build-id for the executable in the core-file. In this case GDB calls debuginfod_exec_query to download the executable and GDB prints a message like: Downloading executable for /path/to/core-file... which makes sense in that case. For a long time GDB has also had the ability to download memory-mapped files and shared libraries when opening a core-file. However, recent commits have made these cases more likely to trigger, which is a good thing, but the messaging from GDB in these cases is not ideal. When downloading a memory-mapped file GDB prints: Downloading executable for /path/to/memory-mapped-file And for a shared library: Downloading executable for /path/to/libfoo.so These last two messages could, I think, be improved. I propose making two changes. First, I suggest instead of using /path/to/core-file in the first case, we use the name of the executable that GDB is fetching. This makes the messaging consistent in that we print the name of the file we're fetching rather than the name of the file we're fetching something for. I further propose that we replace 'executable for' with the more generic word 'file'. The messages will then become: Downloading file /path/to/exec-file... Downloading file /path/to/memory-mapped-file... Downloading file /path/to/libfoo.so... I think these messages are clearer than what we used to have, and they are consistent in that we name the thing being downloaded in all cases. There is one tiny problem. The first case relies on GDB knowing the name of the executable it wants to download. The only place we can currently get that from is, I think, the memory-mapped file list. [ ASIDE: There is `bfd_core_file_failing_command` which reports the executable and argument list from the core file, but this information is not ideal for this task. First, the executable and arguments are merged into a single string, and second, the string is a relatively short, fixed length string, so the executable name is often truncated. For these reasons I don't consider fetching the executable name using this bfd function as a solution. ] We do have to consider the case that the core file does not have any mapped file information. This shouldn't ever be the case for a Linux target, but it's worth considering. [ ASIDE: I mention Linux specifically because this only becomes a problem if we try to do a lookup via debuginfod, which requires that we have build-ids available. Linux has special support for embedding build-ids into the core file, but I'm not sure if other kernels do this. ] For the unlikely edge case of a core-file that has build-ids, but doesn't have any mapped file information then I propose that we synthesis a filename like: 'with build-id xxxxxx'. We would then see a message like: Downloading file with build-id xxxxxx... Where 'xxxxxx' would be replaced by the actual build-id. This isn't ideal, but I think is good enough, and, as I said, I think this case is not going to be hit very often, or maybe at all. We already had some tests that emitted two of the above messages, which I've updated, these cover the mapped-file and shared library case. The message about downloading the exec for the core-file is actually really hard to trigger now as usually the exec will also appear in the memory-mapped file list and GDB will download the file at this stage. Then when GDB needs the executable for loading the symbols it'll ask debuginfod, and debuginfod will find the file in its cache, and so no message will be printed. If anyone has any ideas about how to trigger this case then I'm happy to add additional tests. Approved-By: Tom Tromey <tom@tromey.com>
2024-11-08Add dw2-aranges.expAlexandra Hájková3-2/+77
This test checks that GDB is able to load DWARF information when .debug_aranges has a section address size that is set to 0. This test was originally written by Jan Kratochvil to test commit 927aa2e778d from 2017, titled "DWARF-5: .debug_names index consumer". This test was originally written using a static .S file and has been present in the Fedora tree for a long time. If dwarf2/aranges.c is modified to turn off the address_size check, GDB will crash with SIGFPE when loading the executable with address size set to zero. I modified the DWARF assembler to make it possible to set the address size to zero in a .debug_aranges section and used the DWARF assembler to produce the assembly file. Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com> Approved-by: Kevin Buettner <kevinb@redhat.com>
2024-11-08gdb/testsuite: fix gdb.base/basic-edit-cmd.exp testAndrew Burgess1-1/+4
In the recent commit: commit 31ada87f91b4c5306d81c8a896df9764c32941f3 Date: Wed Nov 6 22:18:55 2024 +0000 gdb: fixes and tests for the 'edit' command the new gdb.base/basic-edit-cmd.exp was added. The Linaro CI highlighted an issue with the test which I failed to address before pushing the above commit. Part of the test loads a file into GDB and then uses the 'edit' command with no arguments to edit the default location. This default location is expected to be the 'main' function. On my local machine the line reported is the opening '{' of main, and that is what the test checks for. The Linaro CI though appears to see the first code line of main. I think either result is fine as far as this test is concerned, so I've expanded the test regexp to check for either line number. This should make the CI testing happy again.
2024-11-08gdb: fixes and tests for the 'edit' commandAndrew Burgess2-0/+209
This commit was inspired by this mailing list post: https://inbox.sourceware.org/gdb-patches/osmtfvf5xe3yx4n7oirukidym4cik7lehhy4re5mxpset2qgwt@6qlboxhqiwgm When reviewing that patch, the first thing I wanted to do was add some tests for the 'edit' command because, as far as I can tell, there are no real tests right now. The approach I've taken for testing is to override the EDITOR environment variable, setting this to just 'echo'. Now when the 'edit' command is run, instead of entering an interactive editor, the shell instead echos back the arguments that GDB is trying to pass to the editor. The output might look like this: (gdb) edit +22 /tmp/gdb/testsuite/gdb.base/edit-cmd.c (gdb) We can then test this like any other normal command. I then wrote some basic tests covering a few situations like, using 'edit' before the inferior is started. Using 'edit' without any arguments, and using 'edit' with a line number argument. There are plenty of cases that are still not tested, for example, the test program only has a single source file for example. But we can always add more tests later. I then used these tests to validate the fix proposed in the above patch. The patch above does indeed fix some cases, specifically, when GDB stops at a location (e.g. a breakpoint location) and then the 'edit' command without any arguments is fixed. But using the 'list' command to show some other location, and then 'edit' to edit the just listed location broken before and after the above patch. I am instead proposing this alternative patch which I think fixes more cases. When GDB stops at a location then 'edit' with no arguments should correctly edit the current line. And using 'list XX' to list a specific location, followed by 'edit' should also now edit the just listed location. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17669 Co-Authored-By: Lluís Batlle i Rossell <viric@viric.name> Approved-By: Tom Tromey <tom@tromey.com>
2024-11-04gdb: add filename option supportAndrew Burgess2-7/+95
This commit adds support for filename options to GDB's option sub-system (see cli/cli-option.{c,h}). The new filename options support quoted and escaped filenames, and tab completion is fully supported. This commit adds the new option, and adds these options to the 'maintenance test-options' command as '-filename', along with some tests that exercise this new option. I've split the -filename testing into two. In gdb.base/options.exp we use the -filename option with some arbitrary strings. This tests that GDB can correctly extract the value from a filename option, and that GDB can complete other options after a filename option. However, these tests don't actually pass real filenames, nor do they test filename completion. In gdb.base/filename-completion.exp I have added some tests that test the -filename option with real filenames, and exercise filename tab completion. This commit doesn't include any real uses of the new filename options, that will come in the next commit.
2024-11-04gdb/testsuite: spring clean the gdb.stabs/gdb11479.exp testAndrew Burgess1-24/+30
I had reason to look at the gdb.stabs/gdb11479.exp test script and figured it could do with a small clean up. I've: - Made use of standard_testfile and the variables it defines. - Made use of with_test_prefix and removed the prefix from the end of each test name. - Avoid overwriting the test binary when we recompile, instead use a different name for each recompilation. - Add '.' at the end of each comment. There should be no changes in what is tested with this commit. Reviewed-By: Keith Seitz <keiths@redhat.com>
2024-11-01Add gdb.events.tui_enabledTom Tromey2-0/+19
This adds a new event source so that Python scripts can track whether or not the TUI is presently enabled. v2 of the patch renames "status" -> "enabled". Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32162 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-by: Keith Seitz <keiths@redhat.com>
2024-10-29[gdb/testsuite] Add read1 and readmore to make-check-all.shTom de Vries1-3/+42
There are two useful ways to run a test-case, that are not represented by a board file in gdb/testsuite/boards: check-read1 and check-readmore. Consequently, they're not run either by make-check-all.sh. Fix this by adding check-read1 and check-readmore to make-check-all.sh. Tested on x86_64-linux. Verified with shellcheck. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-10-29[gdb/symtab] Handle multiple .debug_info sectionsTom de Vries2-0/+76
When compiling dw2-multiple-debug-info.c using -gdwarf-5 -fdebug-types-section, we end with two .debug_info sections in the object file: ... $ g++ gdb.dwarf2/dw2-multiple-debug-info.c -c -g \ -gdwarf-5 \ -fdebug-types-section $ readelf -WS dw2-multiple-debug-info.o | grep -v RELA | grep .debug_info [10] .debug_info PROGBITS 0 000128 0000cd 00 GC 0 0 8 [12] .debug_info PROGBITS 0 0001f8 0000ad 00 C 0 0 8 ... One of them contains the CU for dw2-multiple-debug-info.c, the other contains the TU for the type of variable a. When trying to print the type of variable a, we get: ... $ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a" 'a' has unknown type; cast it to its declared type ... because the TU hasn't been read. Fix this by adding support for reading multiple .debug_info sections, similar to how that is done for multiple .debug_types sections, getting us instead: ... $ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a" type = class sp1::A { ... } ... Tested on x86_64-linux. PR symtab/32223 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32223
2024-10-29fortran: Fix arrays of variable length strings for FORTRANIjaz, Abdul B4-3/+108
Before this change resolve_dynamic_array_or_string was called for all TYPE_CODE_ARRAY and TYPE_CODE_STRING types, but, in the end, this function always called create_array_type_with_stride, which creates a TYPE_CODE_ARRAY type. Suppose we have subroutine vla_array (arr1, arr2) character (len=*):: arr1 (:) character (len=5):: arr2 (:) print *, arr1 ! break-here print *, arr2 end subroutine vla_array The "print arr1" and "print arr2" command at the "break-here" line gives the following output: (gdb) print arr1 $1 = <incomplete type> (gdb) print arr2 $2 = ('abcde', 'abcde', 'abcde') (gdb) ptype arr1 type = Type End Type (gdb) ptype arr2 type = character*5 (3) Dwarf info using Intel® Fortran Compiler for such case contains following: <1><fd>: Abbrev Number: 12 (DW_TAG_string_type) <fe> DW_AT_name : (indirect string, offset: 0xd2): .str.ARR1 <102> DW_AT_string_length: 3 byte block: 97 23 8 (DW_OP_push_object_address; DW_OP_plus_uconst: 8) After this change resolve_dynamic_array_or_string now calls create_array_type_with_stride or create_string_type, so if the incoming dynamic type is a TYPE_CODE_STRING then we'll get back a TYPE_CODE_STRING type. Now gdb shows following: (gdb) p arr1 $1 = ('abddefghij', 'abddefghij', 'abddefghij', 'abddefghij', 'abddefghij') (gdb) p arr2 $2 = ('abcde', 'abcde', 'abcde') (gdb) ptype arr1 type = character*10 (5) (gdb) ptype arr2 type = character*5 (3) In case of GFortran, compiler emits DW_TAG_structure_type for string type arguments of the subroutine and it has only DW_AT_declaration tag. This results in <incomplete type> in gdb. So, following issue is raised in gcc bugzilla "https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101826". Fixing above issue introduce regression in gdb.fortran/mixed-lang-stack.exp, i.e. the test forces the language to C/C++ and print a Fortran string value. The string value is a dynamic type with code TYPE_CODE_STRING. Before this commit the dynamic type resolution would always convert this to a TYPE_CODE_ARRAY of characters, which the C value printing could handle. But now after this commit we get a TYPE_CODE_STRING, which neither the C value printing, or the generic value printing code can support. And so, I've added support for TYPE_CODE_STRING to the generic value printing, all characters of strings are printed together till the first null character. Lastly, in gdb.opt/fortran-string.exp and gdb.fortran/string-types.exp tests it expects type of character array in 'character (3)' format but now after this change we get 'character*3', so tests are updated accordingly. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28gdb/record: add support to vzeroupper instructionGuinevere Larsen2-0/+56
This commit adds recording support for the AVX instruction vzeroupper, which zeroes the high bits of ymm registers 0..15. In the programmer's manual, it is explicitly states that ymm registers 16..31 won't be affected if present, so we only need to record the first 16 registers. We record ymm_h registers since only the higher bits are touched, and that reduces the memory footprint of the instruction. This instruction is tested differently as we want to confirm we're only saving the relevant registers, and we want to ensure we're saving all of them, so it makes use of "maint print record-instruction" to see exactly what was recorded. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28gdb/record: support AVX instructions VMOVDQ(U|A) when recordingGuinevere Larsen2-4/+66
This commit adds support for the instructions VMOVDQU and VMOVDQA, used to move values to/from 256 bit registers. Unfortunately, the programmer's manual is very incomplete (if not wrong) about these instructions, so the logic had to be reverse engineered from how gcc actually encodes the instruction. This commit also changes the memory regions from the test to store 256 bits, so its easier to test the instructions and that we're recording ymm registers correctly. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28gdb/record: Add recording support to vpbroadcast instructionsGuinevere Larsen2-0/+58
This commit adds recording support to all AVX and AVX2 instructions of the form vpbroadcast. GDB is not yet concerned about AVX512 in recording mode, so for now we only support the AVX2 registers and instructions. This commit also updates the gdb.reverse/i386-avx-reverse.exp to test broadcast instructions. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28gdb/record: add support to AVX unpack instructionsGuinevere Larsen2-1/+105
This commit adds support to recording instructions to unpack high or low data from XMM registers, identified by the mnemonics in the form: VPUNPCK [L|H] [BW|WD|DQ|QDQ]. All these instructions are encoded the exact same way, and only affect the destination register, making them trivial to implement together. It also updates the test gdb.reverse/i386-avx-reverse.exp to test these new instructions. The test always uses ymm because the vpunpck instructions overwrite the high bits, so we have to be able to record the full ymm register, not just the output size. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28gdb/record: add support to vmovd and vmovq instructionsGuinevere Larsen3-1/+288
This commit adds support to the x86_64 AVX instructions vmovd and vmovq. The programmers manuals for Intel and AMD describe these 2 instructions as being almost the same, but my local testing, using gcc 13.2 on Fedora 39, showed several differences and inconsistencies. The instruction is supposed to always use the 3-byte VEX prefix, but I could only find 2-byte versions. The instructions aren't differentiated by the VEX.w bit, but by opcodes and VEX.pp. This patch adds a test with many different uses for both vmovd and vmovq. It also updates the test gdb.reverse/step-precsave.exp to reference the generic "missing avx support" bug open in the bug tracker (17346), instead of pointing to one that specifically calls out to vmovd instructions. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23188 Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28gdb: Start supporting AVX instructionGuinevere Larsen1-1/+1
This patch introduces the information needed to properly identify the VEX prefix, used to signal an AVX and AVX2 instruction, and introduces a helper function to handle all AVX instruction, instead of adding to the 3000 line long recording function. This new function will temporarily set the current thread as "not executing" so that it can read from pseudo registers as we record, since most AVX/AVX2 instructions would benefit from recording ymm registers. The new helper also handles unsupported instructions so that the largest part of the i386_process_record doesn't have to be shifted by 2 spaces, which made an unreadably big patch file. The only expected difference to the end user added by this patch is a small change to the unsupported message. This patch also updates the test gdb.reverse/step-precsave.exp, by recognizing the new output. As a note for the future, we don't handle xmm16-31 and ymm16-31 because those require the EVEX prefix, meaning avx512 support. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-27gdb/testsuite: avoid intermittent failures on a debuginfod testAndrew Burgess1-1/+1
I saw a failure in gdb.debuginfod/build-id-no-debug-warning.exp which I could only produce one time. Normally the test output looks like this: file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug... Downloading separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug... Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo... (gdb) PASS: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no war But one time I saw this: file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug... Downloading 6.77 K separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug... Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo... (gdb) FAIL: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no warnings The difference is the "Downloading separate debug info for ..." line has gained an extra '6.77 K' component. When I got the FAIL the machine was under heavy load, so I suspect everything was running pretty slow. I think the size is only added when the debuginfod download is taking its time. Anyway, the test in question is not expecting to see a size, which is why it failed. Every other debuginfod test does allow for an optional size being printed, so lets update this test to also accept an optional size, this should prevent failures like this in the future.
2024-10-26[gdb/testsuite] Fix gdb.dwarf2/dwp-symlink.exp with target board fission-dwpTom de Vries1-6/+11
There are two test-cases that only run when the target board produces .dwp files, gdb.dwarf2/dwp-sepdebug.exp and gdb.dwarf2/dwp-symlink.exp. When running those test-cases with target board fission-dwp, I run into: ... (gdb) ptype main^M warning: Could not find DWO CU dwp-symlink0.dwo(0x496f1a7405c37a61) \ referenced by CU at offset 0xa6 [in module dwp-symlink]^M type = <unknown return type> ()^M (gdb) FAIL: gdb.dwarf2/dwp-symlink.exp: binary default, dwp at symlink ... coming from: ... # This case cannot work. gdb_test "ptype main" {type = int \(\)} "binary default, dwp at symlink" ... I had a bit of difficulty understanding what the test-case does/tries to do, so to build some understanding I reproduced the behaviour outside of the test-case: ... $ cat start.c void _start (void) {} $ gcc -gsplit-dwarf start.c -nostdlib $ gdb -q -batch a.out -ex "print _start" $1 = {void (void)} 0x400144 <_start> $ dwp -e a.out $ rm start.dwo $ gdb -q -batch a.out -ex "print _start" $1 = {void (void)} 0x400144 <_start> $ ln -s a.out b.out $ gdb -q -batch b.out -ex "print _start" $1 = {void (void)} 0x400144 <_start> $ mv a.out.dwp b.out.dwp $ gdb -q -batch b.out -ex "print _start" $1 = {void (void)} 0x400144 <_start> $ gdb -q -batch a.out -ex "print _start" During symbol reading: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \ referenced by CU at offset 0x0 [in module a.out] warning: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \ referenced by CU at offset 0x0 [in module a.out] $1 = {<text variable, no debug info>} 0x400144 <_start> ... and agreed, that cannot work: the DWO CU required in a.out is in b.out.dwp, and there's no way to find b.out.dwp starting from a.out. The fact that a FAIL is produced is incorrect, gdb does nothing wrong. Fix this by checking for the warning text instead. While we're at it, fix this PATH as well: ... (gdb) cd /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink^M Working directory /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink.^M (gdb) PASS: gdb.dwarf2/dwp-symlink.exp: cd \ /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink PATH: gdb.dwarf2/dwp-symlink.exp: cd \ /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink ... While we're at it, use string_to_regexp to simplify the test-case. Tested on x86_64-linux, with target board fission-dwp.
2024-10-26gdb/testsuite: fix test pattern after switch to -lbl matchingAndrew Burgess1-3/+3
After commit: commit a1ccc78ea7ba8cad3ff37cbde9b5d3bba0194796 Date: Fri Oct 25 06:14:03 2024 +0200 [gdb/testsuite] Fix some test-cases for check-read1 (-lbl) I notice that gdb.base/sect-cmd.exp would sometimes fail. The problem is that by switching to line by line matching we now need to ensure that the gdb_test_multiple patterns match up to the end of the line, but don't actually include the trailing \r\n (yeah, our line by line matching is weird). We need to be especially careful anywhere '.*' is used as this can potentially match content on a subsequent line. I have replaced '.*' with '\[^\r\n\]*(?=\r\n)', matching everything up to the end of the line, but not the end of line itself, and I've made use of '(?=\r\n)' in a couple of other places to ensure we match up to the end of the line, but don't match the line terminator itself.
2024-10-25[gdb/testsuite] Fix gdb.cp/exceptprint.exp with check-read1Tom de Vries1-1/+2
Fix test-case gdb.cp/exceptprint.exp with make target check-read1 by limiting the output of skip_libstdcxx_probe_tests_prompt by making the used command more precise: using "info probes stap libstdcxx" instead of "info probes". Tested on x86_64-linux.
2024-10-25[gdb/testsuite] Fix gdb.threads/ia64-sigill.exp with check-read1Tom de Vries1-4/+19
Fix test-case gdb.threads/ia64-sigill.exp with make target check-read1 by using a custom line-by-line exp_continue clause: ... -re "\r\n\[^\r\n\]*(?=\r\n\[^\r\n\]*\r\n)" { exp_continue } ... which drops a line each time it finds two lines in the buffer. This allows the other clauses to use two-line patterns. Tested on x86_64-linux.
2024-10-25[gdb/testsuite] Fix some test-cases for check-read1 (-lbl)Tom de Vries1-7/+14
I ran the testsuite in an environment simulating a stressed system in combination with check-read1. This exposes a few more FAILs. Fix some by using -lbl. Tested on x86_64-linux.
2024-10-25[gdb/testsuite] Fix some test-cases for check-read1 (pipe/grep)Tom de Vries6-15/+34
I ran the testsuite in an environment simulating a stressed system in combination with check-read1. This exposes a few more FAILs. Fix some by using pipe / grep to filter out unnecessary output. Tested on x86_64-linux.
2024-10-25[gdb/testsuite] Fix some test-cases for check-read1 (gdb_test_lines)Tom de Vries7-88/+80
I ran the testsuite in an environment simulating a stressed system in combination with check-read1. This exposes a few more FAILs. Fix some by using gdb_test_lines, as well as related gdb_get_lines. Tested on x86_64-linux.
2024-10-23gdb/testsuite: introduce dwarf5 option to gdb_compileGuinevere Larsen5-5/+12
A few tests on the testsuite require dwarf5 to work. Up until now, the way to do this was to explicitly add the command line flag -gdwarf-5. This isn't very portable, in case a compiler requires a different flag to emit dwarf5. This commit adds a new option to gdb_compile that would be able to add the correct flag (if known) or error out in case we are unable to tell which flag to use. It also changes the existing tests to use this general option instead of hard coding -gdwarf-5. Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
2024-10-22Implement 'Object_SizeTom Tromey6-0/+202
This patch started as an attempt to allow the 'Size attribute to be applied to types, and not just objects. However, that turns out to be difficult due to the Ada semantcs of 'Size. In particular, Ada requires 'Size to denote the size of the representation of the value, so for example Boolean'Size must be 1. Implementing this properly requires information not readily available to gdb... and while we could synthesize this information in many cases, it also seemed to me that this wasn't strictly very useful when debugging. So instead, this patch adds support for the 'Object_Size attribute, which is somewhat closer to 'sizeof'. Note also that while 'Object_Size is defined for some dynamic types, I chose not to implement this here, as again this information is not readily available -- and I think it's preferable to error than to print something that might be incorrect. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2024-10-22[gdb/testsuite] Handle maint set dwarf synchronous off defaultTom de Vries3-3/+19
I ran the testsuite with a patch setting dwarf_synchronous to false by default, and ran into FAILs in test-cases gdb.dwarf2/dw2-inter-cu-error.exp and gdb.dwarf2/dw2-inter-cu-error-2.exp, because the expected DWARF errors did not show up as a result of the file command. Fix this by forcing "maint set dwarf synchronous on". Add the same in gdb.base/index-cache.exp, where this is also required. Tested on aarch64-linux.
2024-10-22[gdb/testsuite] Improve class name in gdb.dwarf2/self-spec.expTom de Vries1-3/+3
I ran into: ... (gdb) pipe maint print objfiles self-spec | grep c1^M name: c1^M canonical: c1^M qualified: c1^M [3] ((addrmap *) 0xfffedfc1f010)^M (gdb) FAIL: gdb.dwarf2/self-spec.exp: class c1 in cooked index ... Fix this by renaming the class from c1 to class1. Tested on aarch64-linux.
2024-10-21[gdb/symtab] Fix incorrect filenames with inter-CU refsTom de Vries2-0/+96
With target board unix we get: ... $ gdb -q -batch outputs/gdb.cp/cplusfuncs/cplusfuncs \ -ex "info function operator\*" All functions matching regular expression "operator\*": File /home/vries/gdb/src/gdb/testsuite/gdb.cp/cplusfuncs.cc: 72: void foo::operator*(foo&); 85: void foo::operator*=(foo&); ... but with target board cc-with-dwz-m: ... All functions matching regular expression "operator\*": File /usr/lib/gcc/aarch64-redhat-linux/14/include/stddef.h: 72: void foo::operator*(foo&); 85: void foo::operator*=(foo&); ... The first operator: ... $ c++filt _ZN3foomlERS_ foo::operator*(foo&) ... matches address 0x410250 which is defined here in the CU in the exec: ... <1><10f1>: Abbrev Number: 13 (DW_TAG_subprogram) <10f2> DW_AT_specification: <alt 0x93> <10f6> DW_AT_decl_line : 72 <10f7> DW_AT_decl_column : 7 <10f7> DW_AT_object_pointer: <0x1106> <10f9> DW_AT_low_pc : 0x410250 <1101> DW_AT_high_pc : 32 <1102> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <1104> DW_AT_call_all_calls: 1 ... and declared here in the PU in the .dwz file: ... <2><93>: Abbrev Number: 20 (DW_TAG_subprogram) <94> DW_AT_external : 1 <94> DW_AT_name : operator* <98> DW_AT_decl_file : 2 <98> DW_AT_decl_line : 10 <99> DW_AT_decl_column : 9 <9a> DW_AT_linkage_name: _ZN3foomlERS_ <9e> DW_AT_accessibility: 1 (public) <9e> DW_AT_declaration : 1 <9e> DW_AT_object_pointer: <0xa2> ... When creating a new symbol for the operator, the DW_AT_decl_file attribute is looked up, and found to be 2. The 2 is supposed to be mapped using the PU, which has this file name table: ... The File Name Table (offset 0x78, lines 3, columns 2): Entry Dir Name 0 0 <dwz> 1 1 stddef.h 2 2 cplusfuncs.cc ... Instead, it's mapped using the CU, which has this file name table: ... The File Name Table (offset 0x34, lines 3, columns 2): Entry Dir Name 0 1 cplusfuncs.cc 1 1 cplusfuncs.cc 2 2 stddef.h ... This is PR symtab/30814. There's a similar PR for lto, PR symtab/25771, where the same problem happens for two CUs. Fix this by using the correct file name table. Add a dwarf assembly test-case for PR25771. Tested on aarch64-linux. Reviewed-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25771 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30814
2024-10-21[gdb/contrib] Handle dot in spellcheck.shTom de Vries5-6/+6
Add handling of '.' in gdb/contrib/spellcheck.sh. While we're at, simplify the sed invocation by using a single s command instead of 3 s commands. Also introduce sed_join and grep_join. Fix the following common misspellings: ... bandwith -> bandwidth emmitted -> emitted immediatly -> immediately suprize -> surprise thru -> through transfered -> transferred ... Verified with shellcheck.
2024-10-21gdb/guile: add get-basic-typeAndrew Burgess2-0/+9
A question was asked on stackoverflow.com about the guile function get-basic-type[1] which is mentioned in the docs along with an example of its use. The problem is, the function was apparently never actually added to GDB. But it turns out that it's pretty easy to implement, so lets add it now. Better late than never. The implementation mirrors the Python get_basic_type function. I've added a test which is a copy of the documentation example. One issue is that the docs suggest that the type will be returned as just "int", however, I'm not sure what this actually means. It makes more sense that the function return a gdb:type object which would be represented as "#<gdb:type int>", so I've updated the docs to show this output. [1] https://stackoverflow.com/questions/79058691/unbound-variable-get-basic-type-in-gdb-guile-session Reviewed-By: Kevin Buettner <kevinb@redhat.com>
2024-10-20gdb: fix 'maint info inline-frames' after 'stepi'Andrew Burgess1-0/+14
There is an invalid assumption within 'maint info inline-frames' which triggers an assert: (gdb) stepi 0x000000000040119d 18 printf ("Hello World\n"); (gdb) maintenance info inline-frames ../../src/gdb/inline-frame.c:554: internal-error: maintenance_info_inline_frames: Assertion `it != inline_states.end ()' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- ... etc ... The problem is this assert: /* Stopped threads always have cached inline_state information. */ gdb_assert (it != inline_states.end ()); If you check out infrun.c and look in handle_signal_stop for the call to skip_inline_frames then you'll find a rather large comment that explains that we don't always compute the inline state information for performance reasons. So the assertion is not valid. I've updated the code so that if there is cached information we use that, but if there is not then we just create our own information for the current $pc of the current thread. This means that, if there is cached information, GDB still correctly shows which frame the inferior is in (it might not be in the inner most frame). If there is no cached information we will always display the inferior as being in the inner most frame, but that's OK, because if skip_inline_frames has not been called then GDB will have told the user they are in the inner most frame, so everything lines up. I've extended the test to check 'maint info inline-frames' after a stepi which would previously have triggered the assertion.
2024-10-19[gdb/symtab] Skip local variables in cooked indexTom de Vries2-0/+49
Consider test-case gdb.dwarf2/local-var.exp. The corresponding source contains a function with a local variable: ... program test logical :: local_var local_var = .TRUE. end ... Currently, the local variable shows up in the cooked index: ... [2] ((cooked_index_entry *) 0xfffec40063b0) name: local_var canonical: local_var qualified: local_var DWARF tag: DW_TAG_variable flags: 0x2 [IS_STATIC] DIE offset: 0xa3 parent: ((cooked_index_entry *) 0xfffec4006380) [test] ... making the cooked index larger than necessary. Fix this by skipping it in cooked_indexer::index_dies. Tested on aarch64-linux. PR symtab/32276 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32276
2024-10-18Require a command argument in gdb.execute_miTom Tromey1-0/+4
Hannes pointed out that gdb.execute_mi() will crash. This patch fixes the bug. Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
2024-10-17[gdb/testsuite] Fix gdb.ada/fixed_points.exp for gcc < 10Tom de Vries1-1/+1
When running test-case gdb.ada/fixed_points.exp with system gcc 7, I run into: ... (gdb) PASS: gdb.ada/fixed_points.exp: scenario=all: print fp4_var / 1 get_compiler_info: gcc-7-5-0 p Float(Another_Fixed) = Float(Another_Delta * 5)^M No definition of "another_delta" in current context.^M (gdb) FAIL: gdb.ada/fixed_points.exp: scenario=all: value of another_fixed ... This is a regression since commit 1411185a57e ("Introduce and use gnat_version_compare"), which did: ... # This failed before GCC 10. - if {$scenario == "all" && [test_compiler_info {gcc-10-*}]} { + if {$scenario == "all" && [gnat_version_compare < 10]} { gdb_test "p Float(Another_Fixed) = Float(Another_Delta * 5)" "true" \ "value of another_fixed" } ... Fix this by using gnat_version_compare >= 10 instead. Tested on x86_64-linux, with gcc 7 - 13.
2024-10-15Introduce and use gnat_version_compareTom Tromey15-25/+55
While testing a modified GNAT, I found that this test in fun_renaming.exp was returning 0 for GCC 13: if {[test_compiler_info {gcc-6*}]} This patch introduces a new, more robust way to check the GNAT compiler version, and changes the gda.ada tests to use it. A small update to version_compare was also needed. Note that, in its current form, this new code won't really interact well with non-GCC compilers (specifically gnat-llvm). This doesn't seem like a major issue at this point, though, because gnat-llvm doesn't properly emit debuginfo yet, and when it does, more changes will be needed in these tests anyway. Reviewed-by: Keith Seitz <keiths@redhat.com>
2024-10-14gdb/testsuite: fix gdb.multi/inferior-specific-bp.expGuinevere Larsen1-1/+2
A recent commit, "16a6f7d2ee3 gdb: avoid breakpoint::clear_locations calls in update_breakpoint_locations", started checking if GDB correctly relocates a breakpoint from inferior 1's declaration of the function "bar" to inferior 2's declaration. Unfortunately, inferior 2 never calls bar in its regular execution, and because of that, clang would optimize that whole function away, making it so there is no location for the breakpoint to be relocated to. This commit changes the .c file so that the function is not optimized away and the test fully passes with clang. It is important to actually call bar instead of using __attribute__((used)) because the latter causes the breakpoint locations to be inverted, 3.1 belongs to inferior 2 and 3.2 belongs to inferior 1, which will cause an unrelated failure. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-10-10[gdb/breakpoints] Fix gdb.base/scope-hw-watch-disable.exp on arm-linuxTom de Vries1-0/+18
On arm-linux, with test-case gdb.base/scope-hw-watch-disable.exp I run into: ... (gdb) awatch a^M Can't set read/access watchpoint when hardware watchpoints are disabled.^M (gdb) PASS: $exp: unsuccessful attempt to create an access watchpoint rwatch b^M Can't set read/access watchpoint when hardware watchpoints are disabled.^M (gdb) PASS: $exp: unsuccessful attempt to create a read watchpoint continue^M Continuing.^M ^M Program received signal SIGSEGV, Segmentation fault.^M 0xf7ec82c8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M (gdb) FAIL: $exp: continue until exit ... Using "maint info break", we can see that the two failed attempts to set a watchpoint each left behind a stale "watchpoint scope" breakpoint: ... -5 watchpoint scope del y 0xf7ec569a inf 1 -5.1 y 0xf7ec569a inf 1 stop only in stack frame at 0xfffef4f8 -6 watchpoint scope del y 0xf7ec569a inf 1 -6.1 y 0xf7ec569a inf 1 stop only in stack frame at 0xfffef4f8 ... The SIGSEGV is a consequence of the stale "watchpoint scope" breakpoint: the same happens if we: - have can-use-hw-watchpoints == 1, - set one of the watchpoints, and - continue to exit. The problem is missing symbol info on libc which is supposed to tell which code is thumb. After doing "set arm fallback-mode thumb" the SIGSEGV disappears. Extend the test-case to check the "maint info break" command before and after the two failed attempts, to make sure that we catch the stale "watchpoint scope" breakpoints also on x86_64-linux. Fix this in watch_command_1 by moving creation of the "watchpoint scope" breakpoint after the call to update_watchpoint. Tested on x86_64-linux. PR breakpoints/31860 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31860
2024-10-10[gdb/testsuite] Fix gdb.dwarf2/enum-type-c++.exp with clangTom de Vries2-31/+78
When running test-case gdb.dwarf2/enum-type-c++.exp with clang, we get: ... FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::A::val1 FAIL: gdb.dwarf2/enum-type-c++.exp: val2 has correct parent FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::ec::val2 ... The problem is that the debug info produced by clang does not contain any references to enumerators val1 and val2, or the corresponding enumeration types. Instead, the variables u1 and u2 are considered to be simply of type int: ... <1><fb>: Abbrev Number: 2 (DW_TAG_variable) <fc> DW_AT_name : u1 <fd> DW_AT_type : <0x106> <101> DW_AT_external : 1 <103> DW_AT_location : (DW_OP_addrx <0>) <1><106>: Abbrev Number: 3 (DW_TAG_base_type) <107> DW_AT_name : int <108> DW_AT_encoding : 5 (signed) <109> DW_AT_byte_size : 4 <1><10a>: Abbrev Number: 2 (DW_TAG_variable) <10b> DW_AT_name : u2 <10c> DW_AT_type : <0x106> <110> DW_AT_external : 1 <112> DW_AT_location : (DW_OP_addrx <0x1>) ... Fix this by checking whether val1 and val2 are present in the cooked index before checking whether they have the correct parent. This cannot be expressed efficiently with gdb_test_lines, so factor out gdb_get_lines and use that instead. The test-case still calls "maint print objfiles" twice, but the first time is for have_index. We should probably use a gdb_caching_proc for this. Tested on aarch64-linux. Reported-By: Guinevere Larsen <guinevere@redhat.com> Reviewed-By: Keith Seitz <keiths@redhat.com> Tested-By: Guinevere Larsen <guinevere@redhat.com>
2024-10-10[gdb/testsuite] Fix some gdb.dwarf2 test-cases for check-read1Tom de Vries5-6/+15
I ran the testsuite in an environment simulating a stressed system in combination with check-read1. This exposes a few more FAILs. Fix the gdb.dwarf2 ones by using pipe / grep to filter out unnecessary output. Tested on x86_64-linux.
2024-10-09[gdb/testsuite] Fix gdb.base/reggroups.exp with check-read1Tom de Vries1-7/+21
On aarch64-linux, with make target check-read1, I run into: ... (gdb) info reg vector^M ... d19 {f = 0x0, u = 0x0, s = 0x0} {f =FAIL: gdb.base/reggroups.exp: fetch reggroup regs vector (timeout) 0, u = 0, s = 0}^M ... The problem is that while (as documented) the corresponding gdb_test_multiple doesn't work for vector registers, it doesn't skip them either. This causes the timeout, and it also causes the registers after a vector register not to be found. Fix this by using -lbl style matching. Make which reggroups and registers are found more explicit using verbose -log, which makes us notice that regnames with underscores are skipped, so fix that as well. While we're at it, this: ... set invalid_register_re "Invalid register .*" ... and this: ... -re $invalid_register_re { fail "$test (unexpected invalid register response)" } ... means that the prompt may or may not be consumed. Fix this by limiting the regexp to one line, and using exp_continue. While we're at it, improve readability of the complex regexp matching a single register by factoring out regexps. Tested on aarch64-linux and x86_64-linux.
generated by cgit v1.1 at 2025-03-07 04:33:58 +0000