summaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.base
Commit message (Collapse)AuthorAgeFilesLines
* Update comments for the gdb/24331 fix.Paul Pluzhnikov2023-05-161-1/+4
| | | | Approved-by: Andrew Burgess <aburgess@redhat.com>
* gdb/testsuite: fix regressions in break-main-file-remove-fail.expAndrew Burgess2023-05-161-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After this commit: commit a68f7e9844208ad8cd498f89b5100084ece7d0f6 Date: Tue May 9 10:28:42 2023 +0100 gdb/testsuite: extend special '^' handling to gdb_test_multiple buildbot notified me of a regression on s390 in the test: gdb.base/break-main-file-remove-fail.exp the failure looks like this: print /d ((int (*) (void *, size_t)) munmap) (16781312, 4096) warning: Error removing breakpoint 0 $2 = 0 (gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: get integer valueof "((int (*) (void *, size_t)) munmap) (16781312, 4096)" On the mailing list it has been reported that this failure also impacts arm, aarch64, and possibly ppc/ppc64 too. The above commit changed get_integer_valueof so that no output is expected between the command and the '$2 = 0' line. In this case the 'warning: Error removing breakpoint 0' output is causing the get_integer_valueof call to fail. The reason for this warning is that this test deliberately calls munmap on a page of the inferior's code. The test is checking that GDB can handle the situation where a s/w breakpoint can't be removed (due to the page no longer being readable/writable). The test that is supposed to trigger the warning is later in the test script when we delete a breakpoint. So why do some targets trigger the warning earlier during the inferior call? The impacted targets use AT_ENTRY_POINT as their strategy for handling inferior calls, that is, the trampoline that calls the inferior function is placed at the program's entry point, e.g. often the _start label. If this location happens to be on the same page as the page that the test script unmaps then, when the inferior function call returns, GDB will not be able to remove the temporary breakpoint that is inserted to catch the inferior function call returning! As a result we end up seeing the warning earlier than expected. I did wonder if this means I should relax the pattern in get_integer_valueof - just accept that there might be additional output from GDB which we should ignore. However, I don't think this the right way to go. With the change in a68f7e984420 we are now stricter for GDB emitting additional, unexpected, output, and I think that is a good thing. So, I think, in this case, in order to handle the possible extra output, we should implement something like get_integer_valueof directly in the gdb.base/break-main-file-remove-fail.exp test script. This local version will handle the possible warning output. After this the test should pass again on the impacted targets.
* Fix bad interaction between element limit and repeated values (BZ#24331).Paul Pluzhnikov2023-05-131-0/+15
| | | | | | | | | | | | Currently print -elements=3 -- "AAAAAA" prints complete string, which is not what the user asked for. Fix two buggy tests exposed by the fix, and add a new test. Reviewed-by: Keith Seitz <keiths@redhat.com>
* gdb/testsuite: extend special '^' handling to gdb_test_multipleAndrew Burgess2023-05-124-13/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commit: commit 08ec06d6440745ef9204d39197aa1e732df41056 Date: Wed Mar 29 10:41:07 2023 +0100 gdb/testsuite: special case '^' in gdb_test pattern Added some special handling of '^' to gdb_test -- a leading '^' will cause the command regexp to automatically be included in the expected output pattern. It was pointed out that the '-wrap' flag of gdb_test_multiple is supposed to work in the same way as gdb_test, and that the recent changes for '^' had not been replicated for gdb_test_multiple. This patch addresses this issue. So, after this commit, the following two constructs should have the same meaning: gdb_test "command" "^output" "test name" gdb_test_multiple "command" "test name" { -re -wrap "^output" { pass $gdb_test_name } } In both cases the '^' will case gdb.exp to inject a regexp that matches 'command' after the '^' and before the 'output', this is in addition to adding the $gdb_prompt pattern after 'output' in the normal way. The special '^' handling is only applied when '-wrap' is used, as this is the only mode that aims to mimic gdb_test. While working on this patch I realised that I could actually improve the logic for the special '^' handling in the case where the expected output pattern is empty. I replicated these updates for both gdb_test and gdb_test_multiple in order to keep these two paths in sync. There were a small number of tests that needed adjustment after this change, mostly just removing command regexps that are now added automatically, but the gdb.base/settings.exp case was a little weird as it turns out trying to match a single blank line is probably harder now than it used to be -- still, I suspect this is a pretty rare case, so I think the benefits (improved anchoring) outweigh this small downside (IMHO).
* gdb: fix error message for $_gdb_maint_settingAndrew Burgess2023-05-121-0/+15
| | | | | | | | | | | | | | | | | I spotted this behaviour: (gdb) p $_gdb_maint_setting("xxx") First argument of $_gdb_maint_setting must be a valid setting of the 'show' command. Notice that GDB claims I need to use a setting from the 'show' command, which isn't correct for $_gdb_maint_setting, in this case I need to use a setting from 'maintenance show'. This same issue is present for $_gdb_maint_setting_str. This commit fixes this minor issue. Approved-By: Simon Marchi <simon.marchi@efficios.com>
* [gdb/cli] Fix wrapping for TERM=ansiTom de Vries2023-05-121-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I. Auto-detected width (xterm vs. ansi) Say we have a terminal with a width of 40 chars: ... $ echo $COLUMNS 40 ... With TERM=xterm, we report a width of 40 chars: ... $ TERM=xterm gdb (gdb) show width Number of characters gdb thinks are in a line is 40. ... And with TERM=ansi, a width of 39 chars: ... $ TERM=ansi gdb (gdb) show width Number of characters gdb thinks are in a line is 39. ... Gdb uses readline to auto-detect screen size, and readline decides in the TERM=ansi case that the terminal does not have reliable auto-wrap, and consequently decides to hide the last terminal column from the readline user (in other words GDB), hence we get 39 instead of 40. II. Types of wrapping Looking a bit more in detail inside gdb, it seems there are two types of wrapping: - readline wrapping (in other words, prompt edit wrapping), and - gdb output wrapping (can be observed by issuing "info sources"). This type of wrapping attempts to wrap some of the gdb output earlier than the indicated width, to not break lines in inconvenient places. III. Readline wrapping, auto-detected screen size Let's investigate readline wrapping with the auto-detected screen widths. First, let's try with xterm: ... $ TERM=xterm gdb (gdb) 7890123456789012345678901234567890 123 ... That looks as expected, wrapping occurs after 40 chars. Now, let's try with ansi: ... $ TERM=ansi gdb (gdb) 78901234567890123456789012345678 90123 ... It looks like wrapping occurred after 38, while readline should be capable of wrapping after 39 chars. This is caused by readline hiding the last column, twice. In more detail: - readline detects the screen width: 40, - readline hides the last column, setting the readline screen width to 39, - readline reports 39 to gdb as screen width, - gdb sets its width setting to 39, - gdb sets readline screen width to 39, - readline hides the last column, again, setting the readline screen width to 38. This is reported as PR cli/30346. IV. gdb output wrapping, auto-detected screen size Say we set the terminal width to 56. With TERM=xterm, we have: ... /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c, /data/vries/hello.c, ... but with TERM=ansi: ... /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c, / data/vries/hello.c, ... So what happened here? With TERM=ansi, the width setting is auto-detected to 55, and gdb assumes the terminal inserts a line break there, which it doesn't because the terminal width is 56. This is reported as PR cli/30411. V. Fix PRs Fix both mentioned PRs by taking into account the hidden column when readline reports the screen width in init_page_info, and updating chars_per_line accordingly. Note that now we report the same width for both TERM=xterm and TERM=ansi, which is much clearer. The point where readline respectively expects or ensures wrapping is still indicated by "maint info screen", for xterm: ... Number of characters readline reports are in a line is 40. ... and ansi: ... Number of characters readline reports are in a line is 39. ... VI. Testing PR cli/30346 is covered by existing regression tests gdb.base/wrap-line.exp and gdb.tui/wrap-line.exp, so remove the KFAILs there. I didn't manage to come up with a regression test for PR cli/30411. Perhaps that would be easier if we had a maintenance command that echoes its arguments while applying gdb output wrapping. Tested on x86_64-linux. PR cli/30346 PR cli/30411 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30346 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30411
* gdb: Avoid warning for the jump command inside an inline function.Felix Willgerodt2023-05-082-0/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | When stopped inside an inline function, trying to jump to a different line of the same function currently results in a warning about jumping to another function. Fix this by taking inline functions into account. Before: Breakpoint 1, function_inline (x=510) at jump-inline.cpp:22 22 a = a + x; /* inline-funct */ (gdb) j 21 Line 21 is not in `function_inline(int)'. Jump anyway? (y or n) After: Breakpoint 2, function_inline (x=510) at jump-inline.cpp:22 22 a = a + x; /* inline-funct */ (gdb) j 21 Continuing at 0x400679. Breakpoint 1, function_inline (x=510) at jump-inline.cpp:21 21 a += 1020 + a; /* increment-funct */ This was regression-tested on X86-64 Linux. Co-Authored-by: Cristian Sandu <cristian.sandu@intel.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
* gdb/testsuite: more newline pattern cleanupAndrew Burgess2023-05-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After this commit: commit e2f620135d92f7cd670af4e524fffec7ac307666 Date: Thu Mar 30 13:26:25 2023 +0100 gdb/testsuite: change newline patterns used in gdb_test It was pointed out in PR gdb/30403 that the same patterns can be found in other lib/gdb.exp procs and that it would probably be a good idea if these procs remained in sync with gdb_test. Actually, the bug specifically calls out gdb_test_multiple when using with '-wrap', but I found a couple of other locations in gdb_continue_to_breakpoint, gdb_test_multiline, get_valueof, and get_local_valueof. In all these locations one or both of the following issues are addressed: 1. A leading pattern of '[\r\n]*' is pointless. If there is a newline it will be matched, but if there is not then the testsuite doesn't care. Also, as expect is happy to skip non-matched output at the start of a pattern, if there is a newline expect is happy to skip over it before matching the rest. As such, this leading pattern is removed. 2. Using '\[\r\n\]*$gdb_prompt' means that we will swallow unexpected blank lines at the end of a command's output, but also, if the pattern from the test script ends with a '\r', '\n', or '.' then these will partially match the trailing newline, with the remainder of the newline matched by the pattern from gdb.exp. This split matching doesn't add any value, it's just something that has appeared as a consequence of how gdb.exp was originally written. In this case the '\[\r\n\]*' is replaced with '\r\n'. I've rerun the testsuite and fixed the regressions that I saw, these were places where GDB emits a blank line at the end of the command output, which we now need to explicitly match in the test script, this was for: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp gdb.guile/guile.exp gdb.python/python.exp Or a location where the test script was matching part of the newline sequence, while gdb.exp was previously matching the remainder of the newline sequence. Now we rely on gdb.exp to match the complete newline sequence, this was for: gdb.base/commands.exp Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30403
* [gdb/testsuite] Generate long string in gdb.base/page.expTom de Vries2023-05-051-1/+1
| | | | | | | | | | | | | | | | | | I noticed in gdb.base/page.exp: ... set fours [string repeat 4 40] ... but then shortly afterwards: ... [list 1\r\n 2\r\n 3\r\n 444444444444444444444444444444] ... Summarize the long string in the same way using string repeat: ... [list 1\r\n 2\r\n 3\r\n [string repeat 4 30]] ... Tested on x86_64-linux.
* [gdb/testsuite] Add gdb.base/wrap-line.expTom de Vries2023-05-051-0/+169
| | | | | | | | | | Add a test-case that tests prompt edit wrapping in CLI, both for TERM=xterm and TERM=ansi, both with auto-detected and hard-coded width. In the TERM=ansi case with auto-detected width we run into PR cli/30346, so add a KFAIL for that failure mode. Tested on x86_64-linux.
* gdb.base/watchpoint-unaligned.exp: Always initialize wpoffset_to_wpnumAlexandra Hájková2023-05-021-1/+2
| | | | | | | | | | | | | | | | Initialize wpoffset_to_wpnumto avoid TCL error which happens in some aarch64 types. ERROR: in testcase /root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp ERROR: can't read "wpoffset_to_wpnum(1)": no such element in array ERROR: tcl error code TCL READ VARNAME ERROR: tcl error info: can't read "wpoffset_to_wpnum(1)": no such element in array while executing Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30340 Reviewed-by: Luis Machado <luis.machado@arm.com> Reviewed-By: Andrew Burgess <aburgess@redhat.com>
* [gdb/testsuite] Fix gdb.base/readline.exp with stub-termcapTom de Vries2023-04-291-22/+35
| | | | | | | | | | | | | | | | | | | When doing a build which uses stub-termcap, we run into: ... (gdb) set width 7 <b) FAIL: gdb.base/readline.exp: set width 7 (timeout) ... Since readline can't detect very basic terminal support, it falls back on horizontal scrolling. Fix this by detecting the horizontal scrolling case, and skipping the subsequent test. Tested on x86_64-linux. PR testsuite/30400 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30400
* gdb: make set/show inferior-tty work with $_gdb_setting_strAndrew Burgess2023-04-281-0/+9
| | | | | | | | | | | | | | Like the previous two commits, this commit fixes set/show inferior-tty to work with $_gdb_setting_str. Instead of using a scratch variable which is then pushed into the current inferior from a set callback, move to the API that allows for getters and setters, and store the value directly within the current inferior. Update an existing test to check the inferior-tty setting. Reviewed-By: Tom Tromey <tom@tromey.com>
* Allow strings with printf/evalKeith Seitz2023-04-282-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PR 13098 explains that if a user attempts to use a string with either `printf' (or `eval'), gdb returns an error (inferior not running): (gdb) printf "%s\n", "hello" evaluation of this expression requires the target program to be active However, the parser can certainly handle this case: (gdb) p "hello" $1 = "hello" This discrepancy occurs because printf_c_string does not handle this specific case. The passed-in value that we are attempting to print as a string is TYPE_CODE_ARRAY but it's lval type is not_lval. printf_c_string will only attempt to print a string from the value's contents when !TYPE_CODE_PTR, lval is lval_internalvar, and the value's type is considered a string type: if (value->type ()->code () != TYPE_CODE_PTR && value->lval () == lval_internalvar && c_is_string_type_p (value->type ())) { ... } Otherwise, it attempts to read the value of the string from the target's memory (which is what actually generates the "evaluation of this ..." error message).
* gdb/testsuite: special case '^' in gdb_test patternAndrew Burgess2023-04-279-31/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In this commit I propose that we add special handling for the '^' when used at the start of a gdb_test pattern. Consider this usage: gdb_test "some_command" "^command output pattern" I think the intention here is pretty clear - run 'some_command', and the output from the command should be exactly 'command output pattern'. After the previous commit which tightened up how gdb_test matches the final newline and prompt we know that the only thing after the output pattern will be a single newline and prompt, and the leading '^' ensures that there's no output before 'command output pattern', so this will do what I want, right? ... except it doesn't. The command itself will also needs to be matched, so I should really write: gdb_test "some_command" "^some_command\r\ncommand output pattern" which will do what I want, right? Well, that's fine until I change the command and include some regexp character, then I have to write: gdb_test "some_command" \ "^[string_to_regexp some_command]\r\ncommand output pattern" but this all gets a bit verbose, so in most cases I simply don't bother anchoring the output with a '^', and a quick scan of the testsuite would indicate that most other folk don't both either. What I propose is this: the *only* thing that can appear immediately after the '^' is the command converted into a regexp, so lets do that automatically, moving the work into gdb_test. Thus, when I write: gdb_test "some_command" "^command output pattern" Inside gdb_test we will spot the leading '^' in the pattern, and inject the regexp version of the command after the '^', followed by a '\r\n'. My hope is that given this new ability, folk will be more inclined to anchor their output patterns when this makes sense to do so. This should increase our ability to catch any unexpected output from GDB that appears as a result of running a particular command. There is one problem case we need to consider, sometime people do this: gdb_test "" "^expected output pattern" In this case no command is sent to GDB, but we are still expecting some output from GDB. This might be a result of some asynchronous event for example. As there is no command sent to GDB (from the gdb_test) there will be no command text to parse. In this case my proposed new feature injects the command regexp, which is the empty string (as the command itself is empty), but still injects the '\r\n' after the command regexp, thus we end up with this pattern: ^\r\nexpected output pattern This extra '\r\n' is not what we should expected here, and so there is a special case inside gdb_test -- if the command is empty then don't add anything after the '^' character. There are a bunch of tests that do already use '^' followed by the command, and these can all be simplified in this commit. I've tried to run all the tests that I can to check this commit, but I am certain that there will be some tests that I manage to miss. Apologies for any regressions this commit causes, hopefully fixing the regressions will not be too hard. Reviewed-By: Tom Tromey <tom@tromey.com>
* gdb/testsuite: change newline patterns used in gdb_testAndrew Burgess2023-04-2713-29/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit makes two changes to how we match newline characters in the gdb_test proc. First, for the newline pattern between the command output and the prompt, I propose changing from '[\r\n]+' to an explicit '\r\n'. The old pattern would spot multiple newlines, and so there are a few places where, as part of this commit, I've needed to add an extra trailing '\r\n' to the pattern in the main test file, where GDB's output actually includes a blank line. But I think this is a good thing. If a command produces a blank line then we should be checking for it, the current gdb_test doesn't do that. But also, with the current gdb_test, if a blank line suddenly appears in the output, this is going to be silently ignored, and I think this is wrong, the test should fail in that case. Additionally, the existing pattern will happily match a partial newline. There are a strangely large number of tests that end with a random '.' character. Not matching a literal period, but matching any single character, this is then matching half of the trailing newline sequence, while the \[\r\n\]+ in gdb_test is matching the other half of the sequence. I can think of no reason why this would be intentional, I suspect that the expected output at one time included a period, which has since been remove, but I haven't bothered to check on this. In this commit I've removed all these unneeded trailing '.' characters. The basic rule of gdb_test after this is that the expected pattern needs to match everything up to, but not including the newline sequence immediately before the GDB prompt. This is generally how the proc is used anyway, so in almost all cases, this commit represents no significant change. Second, while I was cleaning up newline matching in gdb_test, I've also removed the '[\r\n]*' that was added to the start of the pattern passed to gdb_test_multiple. The addition of this pattern adds no value. If the user pattern matches at the start of a line then this would match against the newline sequence. But, due to the '*', if the user pattern doesn't match at the start of a line then this group doesn't care, it'll happily match nothing. As such, there's no value to it, it just adds more complexity for no gain, so I'm removing it. No tests will need updating as a consequence of this part of the patch. Reviewed-By: Tom Tromey <tom@tromey.com>
* gdb/testsuite: use 'return' in gdb_test_no_outputAndrew Burgess2023-04-271-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | A TCL proc will return the return value of the last command executed within the proc's body if there is no explicit return call, so gdb_test_no_output is already returning the return value of gdb_test_multiple. However, I'm not a fan of (relying on) this implicit return value behaviour -- I prefer to be explicit about what we are doing. So in this commit I have extended the comment on gdb_test_no_output to document the possible return values (just as gdb_test does), and explicitly call return. This should make no different to our testing, but I think it's clearer now what the gdb_test_no_output proc is expected to do. The two tests gdb.base/auxv.exp and gdb.base/list.exp both rely on the return value of gdb_test_no_output, and continue to pass after this change. I also spotted that gdb.base/watchpoint.exp could be updated to make use of gdb_test_no_output, so I did that. Reviewed-By: Tom Tromey <tom@tromey.com>
* gdb/testsuite: fix occasional failure in gdb.base/clear_non_user_bp.expAndrew Burgess2023-04-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed that the gdb.base/clear_non_user_bp.exp test would sometimes fail when run from a particular directory. The test tries to find the number of the first internal breakpoint using this proc: proc get_first_maint_bp_num { } { gdb_test_multiple "maint info break" "find first internal bp num" { -re -wrap "(-\[0-9\]).*" { return $expect_out(1,string) } } return "" } The problem is, at the time we issue 'maint info break' there are both internal breakpoint and non-internal (user created) breakpoints in place. The user created breakpoints include the path to the source file. Sometimes, I'll be working from a directory that includes a number, like '/tmp/blah-1/gdb/etc', in which case the pattern above actually matches the '-1' from 'blah-1'. In this case there's no significant problem as it turns out that -1 is the number of the first internal breakpoint. Sometimes my directory name might be '/tmp/blah-4/gdb/etc', in which case the above pattern patches '-4' from 'blah-4'. It turns out this is also not a problem -- the test doesn't actually need the first internal breakpoint number, it just needs the number of any internal breakpoint. But sometimes my directory name might be '/tmp/blah-0/gdb/etc', in which case the pattern above matches '-0' from 'blah-0', and in this case the test fails - there is no internal breakpoint '-0'. Fix this by spotting that the internal breakpoint numbers always occurs after a '\r\n', and that they never start with a 0. Our pattern becomes: -re -wrap "\r\n(-\[1-9\]\[0-9\]*).*" { return $expect_out(1,string) } After this I'm no longer seeing any failures. Reviewed-By: Tom Tromey <tom@tromey.com>
* [gdb/testsuite] Require GCC >= 5.x.x in gdb.base/utf8-identifiers.expTom de Vries2023-04-241-0/+5
| | | | | | | Test-case gdb.base/utf8-identifiers.exp compiles starting with GCC 5, so require this. Tested on x86_64-linux.
* Remove some Ada parser helper functionsTom Tromey2023-04-171-0/+2
| | | | | | | | These helper functions in the Ada parser don't seem all that worthwhile to me, so this patch removes them.
* Add 128-bit integer support to the Rust parserTom Tromey2023-04-171-3/+4
| | | | | | | | | This adds support for 128-bit integers to the Rust parser. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21185
* gdb/testsuite: Skip dump ihex for 64-bit address in gdb.base/dump.expHui Li2023-04-141-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (1) Description of problem In the current code, when execute the following test on LoongArch: $make check-gdb TESTS="gdb.base/dump.exp" ``` FAIL: gdb.base/dump.exp: dump array as value, intel hex FAIL: gdb.base/dump.exp: dump struct as value, intel hex FAIL: gdb.base/dump.exp: dump array as memory, ihex FAIL: gdb.base/dump.exp: dump struct as memory, ihex ``` These tests passed on the X86_64, (2) Root cause On LoongArch, variable intarray address 0x120008068 out of range for IHEX, so dump ihex test failed. gdb.base/dump.exp has the following code to check 64-bit address ``` # Check the address of a variable. If it is bigger than 32-bit, # assume our target has 64-bit addresses that are not supported by SREC, # IHEX and TEKHEX. We skip those tests then. set max_32bit_address "0xffffffff" set data_address [get_hexadecimal_valueof "&intarray" 0x100000000] if {${data_address} > ${max_32bit_address}} { set is64bitonly "yes" } ``` We check the "&intarray" on different target as follow: ``` $gdb gdb/testsuite/outputs/gdb.base/dump/dump ... (gdb) start ... On X86_64: (gdb) print /x &intarray $1 = 0x404060 On LoongArch: (gdb) print /x &intarray $1 = 0x120008068 ``` The variable address difference here is due to the link script of linker. ``` On X86_64: $ld --verbose ... PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000)); . = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS; On LoongArch: $ld --verbose ... PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x120000000)); . = SEGMENT_START("text-segment", 0x120000000) + SIZEOF_HEADERS; ``` (3) How to fix Because 64-bit variable address out of range for IHEX, it's not an functional problem for LoongArch. Refer to the handling of 64-bit targets in this testsuite, use the "is64bitonly" flag to skip those tests for the target has 64-bit addresses. Signed-off-by: Hui Li <lihui@loongson.cn> Approved-By: Tom Tromey <tom@tromey.com> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
* gdb: warn when converting h/w watchpoints to s/wAndrew Burgess2023-04-111-12/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On amd64 (at least) if a user sets a watchpoint before the inferior has started then GDB will assume that a hardware watchpoint can be created. When the inferior starts there is a chance that the watchpoint can't actually be create as a hardware watchpoint, in which case (currently) GDB will silently convert the watchpoint to a software watchpoint. Here's an example session: (gdb) p sizeof var $1 = 4000 (gdb) watch var Hardware watchpoint 1: var (gdb) info watchpoints Num Type Disp Enb Address What 1 hw watchpoint keep y var (gdb) starti Starting program: /home/andrew/tmp/watch Program stopped. 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 (gdb) info watchpoints Num Type Disp Enb Address What 1 watchpoint keep y var (gdb) Notice that before the `starti` command the watchpoint is showing as a hardware watchpoint, but afterwards it is showing as a software watchpoint. Additionally, note that we clearly told the user we created a hardware watchpoint: (gdb) watch var Hardware watchpoint 1: var I think this is bad. I used `starti`, but if the user did `start` or even `run` then the inferior is going to be _very_ slow, which will be unexpected -- after all, we clearly told the user that we created a hardware watchpoint, and the manual clearly says that hardware watchpoints are fast (at least compared to s/w watchpoints). In this patch I propose adding a new warning which will be emitted when GDB downgrades a h/w watchpoint to s/w. The session now looks like this: (gdb) p sizeof var $1 = 4000 (gdb) watch var Hardware watchpoint 1: var (gdb) info watchpoints Num Type Disp Enb Address What 1 hw watchpoint keep y var (gdb) starti Starting program: /home/andrew/tmp/watch warning: watchpoint 1 downgraded to software watchpoint Program stopped. 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 (gdb) info watchpoints Num Type Disp Enb Address What 1 watchpoint keep y var (gdb) The important line is: warning: watchpoint 1 downgraded to software watchpoint It's not much, but hopefully it will be enough to indicate to the user that something unexpected has occurred, and hopefully, they will not be surprised when the inferior runs much slower than they expected. I've added an amd64 only test in gdb.arch/, I didn't want to try adding this as a global test as other architectures might be able to support the watchpoint request in h/w. Also the test is skipped for extended-remote boards as there's a different set of options for limiting hardware watchpoints on remote targets, and this test isn't about them. Reviewed-By: Lancelot Six <lancelot.six@amd.com>
* [gdb/testsuite] Add -q to INTERNAL_GDBFLAGSTom de Vries2023-04-074-10/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Whenever we start gdb in the testsuite, we have the rather verbose: ... $ gdb GNU gdb (GDB) 14.0.50.20230405-git Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) ... This makes gdb.log longer than necessary and harder to read. We do need to test that the output is produced, but that should be limited to one or a few test-cases. Fix this by adding -q to INTERNAL_GDBFLAGS, such that we simply have: ... $ gdb -q (gdb) ... Tested on x86_64-linux.
* Fix gdb.base/align-*.exp and Clang + LTO and AIX GCCPedro Alves2023-04-061-2/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang with LTO (clang -flto) garbage collects unused global variables, Thus, gdb.base/align-c.exp and gdb.base/align-c++.exp fail with hundreds of FAILs like so: $ make check \ TESTS="gdb.*/align-*.exp" \ RUNTESTFLAGS="CC_FOR_TARGET='clang -flto' CXX_FOR_TARGET='clang++ -flto'" ... FAIL: gdb.base/align-c.exp: get integer valueof "a_char" FAIL: gdb.base/align-c.exp: print _Alignof(char) FAIL: gdb.base/align-c.exp: get integer valueof "a_char_x_char" FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_char_x_char) FAIL: gdb.base/align-c.exp: get integer valueof "a_char_x_unsigned_char" ... AIX GCC has the same issue, and there the easier way of adding __attribute__((used)) to globals does not help. So add explicit uses of all globals to the generated code. For the C++ test, that reveals that the static variable members of the generated structs are not defined anywhere, leading to undefined references. Fixed by emitting initialization for all static members. Lastly, I noticed that CXX_FOR_TARGET was being ignored -- that's because the align-c++.exp testcase is compiling with the C compiler driver. Fixed by passing "c++" as option to prepare_for_testing. Change-Id: I874b717afde7b6fb1e45e526912b518a20a12716
* gdb: don't always print breakpoint location after failed condition checkAndrew Burgess2023-04-031-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider the following session: (gdb) list some_func 1 int 2 some_func () 3 { 4 int *p = 0; 5 return *p; 6 } 7 8 void 9 foo () 10 { (gdb) break foo if (some_func ()) Breakpoint 1 at 0x40111e: file bpcond.c, line 11. (gdb) r Starting program: /tmp/bpcond Program received signal SIGSEGV, Segmentation fault. 0x0000000000401116 in some_func () at bpcond.c:5 5 return *p; Error in testing condition for breakpoint 1: The program being debugged stopped while in a function called from GDB. Evaluation of the expression containing the function (some_func) will be abandoned. When the function is done executing, GDB will silently stop. Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5 5 return *p; (gdb) What happens here is the breakpoint condition includes a call to an inferior function, and the inferior function segfaults. We can see that GDB reports the segfault, and then gives an error message that indicates that an inferior function call was interrupted. After this GDB appears to report that it is stopped at Breakpoint 1, inside some_func. I find this second stop report a little confusing. While it is true that GDB stopped as a result of hitting breakpoint 1, I think the message GDB currently prints might give the impression that GDB is actually stopped at a location of breakpoint 1, which is not the case. Also, I find the second stop message draws attention away from the "Program received signal SIGSEGV, Segmentation fault" stop message, and this second stop might be thought of as replacing in someway the earlier message. In short, I think things would be clearer if the second stop message were not reported at all, so the output should, I think, look like this: (gdb) list some_func 1 int 2 some_func () 3 { 4 int *p = 0; 5 return *p; 6 } 7 8 void 9 foo () 10 { (gdb) break foo if (some_func ()) Breakpoint 1 at 0x40111e: file bpcond.c, line 11. (gdb) r Starting program: /tmp/bpcond Program received signal SIGSEGV, Segmentation fault. 0x0000000000401116 in some_func () at bpcond.c:5 5 return *p; Error in testing condition for breakpoint 1: The program being debugged stopped while in a function called from GDB. Evaluation of the expression containing the function (some_func) will be abandoned. When the function is done executing, GDB will silently stop. (gdb) The user can still find the number of the breakpoint that triggered the initial stop in this line: Error in testing condition for breakpoint 1: But there's now only one stop reason reported, the SIGSEGV, which I think is much clearer. To achieve this change I set the bpstat::print field when: (a) a breakpoint condition evaluation failed, and (b) the $pc of the thread changed during condition evaluation. I've updated the existing tests that checked the error message printed when a breakpoint condition evaluation failed.
* gdb: avoid repeated signal reporting during failed conditional breakpointAndrew Burgess2023-04-032-0/+233
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider the following case: (gdb) list some_func 1 int 2 some_func () 3 { 4 int *p = 0; 5 return *p; 6 } 7 8 void 9 foo () 10 { (gdb) break foo if (some_func ()) Breakpoint 1 at 0x40111e: file bpcond.c, line 11. (gdb) r Starting program: /tmp/bpcond Program received signal SIGSEGV, Segmentation fault. 0x0000000000401116 in some_func () at bpcond.c:5 5 return *p; Error in testing breakpoint condition: The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on". Evaluation of the expression containing the function (some_func) will be abandoned. When the function is done executing, GDB will silently stop. Program received signal SIGSEGV, Segmentation fault. Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5 5 return *p; (gdb) Notice that this line: Program received signal SIGSEGV, Segmentation fault. Appears twice in the output. The first time is followed by the current location. The second time is a little odd, why do we print that? Printing that line is controlled, in part, by a global variable, stopped_by_random_signal. This variable is reset to zero in handle_signal_stop, and is set if/when GDB figures out that the inferior stopped due to some random signal. The problem is, in our case, GDB first stops at the breakpoint for foo, and enters handle_signal_stop and the stopped_by_random_signal global is reset to 0. Later within handle_signal_stop GDB calls bpstat_stop_status, it is within this function (via bpstat_check_breakpoint_conditions) that the breakpoint condition is checked, and, we end up calling the inferior function (some_func in our example above). In our case above the thread performing the inferior function call segfaults in some_func. GDB catches the SIGSEGV and handles the stop, this causes us to reenter handle_signal_stop. The global variable stopped_by_random_signal is updated, this time it is set to true because the thread stopped due to SIGSEGV. As a result of this we print the first instance of the line (as seen above in the example). Finally we unwind GDB's call stack, the inferior function call is complete, and we return to the original handle_signal_stop. However, the stopped_by_random_signal global is still carrying the value as computed for the inferior function call's stop, which is why we now print a second instance of the line, as seen in the example. To prevent this, I propose adding a scoped_restore before we start an inferior function call. This will save and restore the global stopped_by_random_signal value. With this done, the output from our example is now this: (gdb) list some_func 1 int 2 some_func () 3 { 4 int *p = 0; 5 return *p; 6 } 7 8 void 9 foo () 10 { (gdb) break foo if (some_func ()) Breakpoint 1 at 0x40111e: file bpcond.c, line 11. (gdb) r Starting program: /tmp/bpcond Program received signal SIGSEGV, Segmentation fault. 0x0000000000401116 in some_func () at bpcond.c:5 5 return *p; Error in testing condition for breakpoint 1: The program being debugged stopped while in a function called from GDB. Evaluation of the expression containing the function (some_func) will be abandoned. When the function is done executing, GDB will silently stop. Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5 5 return *p; (gdb) We now only see the 'Program received signal SIGSEGV, ...' line once, which I think makes more sense. Finally, I'm aware that the last few lines, that report the stop as being at 'Breakpoint 1', when this is not where the thread is actually located anymore, is not great. I'll address that in the next commit.
* gdbserver: allow agent expressions to fail with invalid memory accessAndrew Burgess2023-04-031-15/+7
| | | | | | | | | | | | | | | | | This commit extends gdbserver to take account of a failed memory access from agent_mem_read, and to return a new eval_result_type expr_eval_invalid_memory_access. I have only updated the agent_mem_read calls related directly to reading memory, I have not updated any of the calls related to tracepoint data collection. This is just because I'm not familiar with that area of gdb/gdbserver, and I don't want to break anything, so leaving the existing behaviour untouched seems like the safest approach. I've then updated gdb.base/bp-cond-failure.exp to test evaluating the breakpoints on the target, and have also extended the test so that it checks for different sizes of memory access.
* gdb: include breakpoint number in testing condition error messageAndrew Burgess2023-04-034-2/+144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When GDB fails to test the condition of a conditional breakpoint, for whatever reason, the error message looks like this: (gdb) break foo if (*(int *) 0) == 1 Breakpoint 1 at 0x40111e: file bpcond.c, line 11. (gdb) r Starting program: /tmp/bpcond Error in testing breakpoint condition: Cannot access memory at address 0x0 Breakpoint 1, foo () at bpcond.c:11 11 int a = 32; (gdb) The line I'm interested in for this commit is this one: Error in testing breakpoint condition: In the case above we can figure out that the problematic breakpoint was #1 because in the final line of the message GDB reports the stop at breakpoint #1. However, in the next few patches I plan to change this. In some cases I don't think it makes sense for GDB to report the stop as being at breakpoint #1, consider this case: (gdb) list some_func 1 int 2 some_func () 3 { 4 int *p = 0; 5 return *p; 6 } 7 8 void 9 foo () 10 { (gdb) break foo if (some_func ()) Breakpoint 1 at 0x40111e: file bpcond.c, line 11. (gdb) r Starting program: /tmp/bpcond Program received signal SIGSEGV, Segmentation fault. 0x0000000000401116 in some_func () at bpcond.c:5 5 return *p; Error in testing breakpoint condition: The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on". Evaluation of the expression containing the function (some_func) will be abandoned. When the function is done executing, GDB will silently stop. Program received signal SIGSEGV, Segmentation fault. Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5 5 return *p; (gdb) Notice that, the final lines of output reports the stop as being at breakpoint #1, even though the inferior in not located within some_func, and it's certainly not located at the breakpoint location. I find this behaviour confusing, and propose that this should be changed. However, if I make that change then every reference to breakpoint #1 will be lost from the error message. So, in this commit, in preparation for the later commits, I propose to change the 'Error in testing breakpoint condition:' line to this: Error in testing condition for breakpoint NUMBER: where NUMBER will be filled in as appropriate. Here's the first example with the updated error: (gdb) break foo if (*(int *) 0) == 0 Breakpoint 1 at 0x40111e: file bpcond.c, line 11. (gdb) r Starting program: /tmp/bpcond Error in testing condition for breakpoint 1: Cannot access memory at address 0x0 Breakpoint 1, foo () at bpcond.c:11 11 int a = 32; (gdb) The breakpoint number does now appear twice in the output, but I don't see that as a negative. This commit just changes the one line of the error, and updates the few tests that either included the old error in comments, or actually checked for the error in the expected output. As the only test that checked the line I modified is a Python test, I've added a new test that doesn't rely on Python that checks the error message in detail. While working on the new test, I spotted that it would fail when run with native-gdbserver and native-extended-gdbserver target boards. This turns out to be due to a gdbserver bug. To avoid cluttering this commit I've added a work around to the new test script so that the test passes for the remote boards, in the next few commits I will fix gdbserver, and update the test script to remove the work around.
* [gdb/testsuite] Fix gdb.base/trace-commands.exp with editing offTom de Vries2023-03-311-27/+40
| | | | | | | | | | | | | With test-case gdb.base/trace-commands.exp and editing off, I run into fails because multi-line commands are issued using gdb_test_sequence, which doesn't handle them correctly. Fix this by using gdb_test instead. Tested on x86_64-linux. PR testsuite/30288 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30288
* [gdb/testsuite] Fix quoting issue in gdb.base/index-cache.expTom de Vries2023-03-271-1/+1
| | | | | | | | | | | | | | | | | | | For test-case gdb.base/index-cache.exp and remote host, this: ... lassign [remote_exec host sh "-c \"rm $cache_dir/*.gdb-index\""] ret ... gives us: ... Executing on host: sh -c rm /tmp/tmp.m3L7m2AVkL/*.gdb-index (timeout = 300) builtin_spawn -ignore SIGHUP sh -c rm /tmp/tmp.m3L7m2AVkL/*.gdb-index^M rm: missing operand^M Try 'rm --help' for more information.^M FAIL: gdb.dwarf2/per-bfd-sharing.exp: couldn't remove files in temporary cache dir ... Fix this using quote_for_host. Likewise in gdb.dwarf2/per-bfd-sharing.exp. Tested on x86_64-linux.
* gdb/testsuite: adjust test cases to previous "maintenance info line-table" ↵Simon Marchi2023-03-221-4/+4
| | | | | | | | | | | | | | | | | change Commit 904d9b02a185 ("gdb: make "maintenance info line-table" show relocated addresses again") changed the format of that command, but failed to adjust some test cases that relied on it. This patch fixes it. The failures fixed are: FAIL: gdb.base/maint.exp: maint info line-table w/o a file name FAIL: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: END with address 1 eliminated FAIL: gdb.dwarf2/dw2-ranges-base.exp: count END markers in line table Change-Id: I946580d5e100f1beeac99a9e90d7819c6bb4ac6c
* gdb: don't use the global thread-id in the saved breakpoints fileAndrew Burgess2023-03-201-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed that breakpoint::print_recreate_thread was printing the global thread-id. This function is used to implement the 'save breakpoints' command, and should be writing out suitable CLI commands for recreating the current breakpoints. The CLI does not use global thread-ids, but instead uses the inferior specific thread-ids, e.g. "2.1". After some discussion on the mailing list it was suggested that the most consistent solution would be for the saved breakpoints file to always contain the inferior-qualified thread-id, so the file would include "thread 1.1" instead of just "thread 1", even when there is only a single inferior. So, this commit adds print_full_thread_id, which is just like the existing print_thread_id, only it always prints the inferior-qualified thread-id. I then update the existing print_thread_id to make use of this new function, and finally, I update breakpoint::print_recreate_thread to also use this new function. There's a multi-inferior test that confirms the saved breakpoints file correctly includes the fully-qualified thread-id, and I've also updated the single inferior test gdb.base/save-bp.exp to have it validate that the saved breakpoints file includes the inferior-qualified thread-id, even for this single inferior case.
* [gdb/testsuite] Handle unbuffer_output.c for remote hostTom de Vries2023-03-1823-26/+73
| | | | | | Handle $srcdir/lib/unbuffer_output.c using lappend_include_file. Tested on x86_64-linux.
* [gdb/testsuite] Handle attributes.h for remote hostTom de Vries2023-03-189-10/+36
| | | | | | Handle $srcdir/lib/attributes.h using lappend_include_dir. Tested on x86_64-linux.
* gdb/testsuite: Add support for LoongArch in gdb.base/float.expHui Li2023-03-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test results on LoongArch as follows: Without this patch: ``` $ make check-gdb TESTS="gdb.base/float.exp" === gdb Summary === # of expected passes 2 # of unexpected failures 1 ``` With this patch: ``` $ make check-gdb TESTS="gdb.base/float.exp" === gdb Summary === # of expected passes 3 ``` Signed-off-by: Hui Li <lihui@loongson.cn> Reviewed-By: Tom Tromey <tom@tromey.com> Approved-By: Simon Marchi <simon.marchi@efficios.com> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
* Use require with test_compiler_infoTom Tromey2023-03-101-4/+1
| | | | | | | | One spot that checks test_compiler_info can be switched to use 'require'.
* More uses of require with istargetTom Tromey2023-03-108-25/+8
| | | | | | | | I found a few more spots that check istarget that can be switched to use 'require'.
* Use require with gdb_skip_stdio_testTom Tromey2023-03-101-3/+1
| | | | | | | One use of gdb_skip_stdio_test can use 'require'.
* Use require with target_infoTom Tromey2023-03-1047-216/+58
| | | | | | | | | | This changes many tests to use 'require' when checking target_info. In a few spots, the require is hoisted to the top of the file, to avoid doing any extra work when the test is going to be skipped anyway.
* Ensure index cache entry written in testTom Tromey2023-03-071-1/+7
| | | | | | | | | | | | Now that index cache files are written in the background, one test in index-cache.exp is racy -- it assumes that the cache file will have been written during startup. This patch fixes the problem by introducing a new maintenance command to wait for all pending writes to the index cache. Approved-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
* [gdb/testsuite] Fix gdb.base/skip-solib.exp for remote targetTom de Vries2023-03-071-0/+2
| | | | | | | Fix test-case gdb.base/skip-solib.exp for target board remote-gdbserver-on-localhost using gdb_load_shlib. Tested on x86_64-linux.
* [gdb/testsuite] Use shlib gdb_compile option in gdb.base/skip-solib.expTom de Vries2023-03-071-3/+1
| | | | | | | | | | | | | | | | | | In test-case gdb.base/skip-solib.exp the linking against a shared library is done manually: ... if {[gdb_compile "${binfile_main}.o" "${binfile_main}" executable \ [list debug "additional_flags=-L$testobjdir" \ "additional_flags=-l${test}" \ "ldflags=-Wl,-rpath=$testobjdir"]] != ""} { ... Instead, use the shlib gdb_compile option such that we simply have: ... [list debug shlib=$binfile_lib]] != ""} { ... Tested on x86_64-linux.
* [gdb/testsuite] Fix gdb.base/fork-no-detach-follow-child-dlopen.exp for ↵Tom de Vries2023-03-071-2/+4
| | | | | | | | | remote target Fix test-case gdb.base/fork-no-detach-follow-child-dlopen.exp for target board remote-gdbserver-on-localhost.exp by using gdb_download_shlib and gdb_locate_shlib. Tested on x86_64-linux.
* [gdb/testsuite] Fix gdb.base/break-probes.exp for remote targetTom de Vries2023-03-071-3/+9
| | | | | | | | | | With test-case gdb.base/break-probes.exp and target board remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some failures. Fix these by adding the missing gdb_download_shlib and gdb_locate_shlib. Tested on x86_64-linux.
* [gdb/testsuite] Fix gdb.base/signals-state-child.exp for ↵Tom de Vries2023-03-071-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | remote-gdbserver-on-localhost With test-case gdb.base/signals-state-child.exp on target board remote-gdbserver-on-localhost I run into: ... builtin_spawn /usr/bin/ssh -t -l remote-target localhost \ $outputs/gdb.base/signals-state-child/signals-state-child-standalone^M bash: $outputs/gdb.base/signals-state-child/signals-state-child-standalone: \ Permission denied^M Connection to localhost closed.^M^M FAIL: gdb.base/signals-state-child.exp: collect standalone signals state ... The problem is that we're trying to run an executable on the target board using a host path. After fixing this by downloading the exec to the target board, we run into: ... builtin_spawn /usr/bin/ssh -t -l remote-target localhost \ signals-state-child-standalone^M bash: signals-state-child-standalone: command not found^M Connection to localhost closed.^M^M FAIL: gdb.base/signals-state-child.exp: collect standalone signals state ... Fix this by using an absolute path name for the exec on the target board. The dejagnu proc standard_file does not support op == "absolute" for target boards, so add an implementation in remote-gdbserver-on-localhost.exp. Also: - fix a PATH-in-test-name issue - cleanup gdb.txt and standalone.txt on target board Tested on x86_64-linux.
* gdb.base/catch-syscall.exp: Remove some Linux-only assumptions.John Baldwin2023-03-062-4/+48
| | | | | | | | | | | | | - Some OS's use a different syscall for exit(). For example, the BSD's use SYS_exit rather than SYS_exit_group. Update the C source file and the expect script to support SYS_exit as an alternative to SYS_exit_group. - The cross-arch syscall number tests are all Linux-specific with hardcoded syscall numbers specific to Linux kernels. Skip these tests on non-Linux systems. FreeBSD kernels for example use the same system call numbers on all platforms, so the test is also not relevant on FreeBSD.
* [gdb/testsuite] Move gdb.base/gdb-caching-proc.exp to gdb.testsuiteTom de Vries2023-03-061-122/+0
| | | | | | | | | | | | | | Test-case gdb.base/gdb-caching-proc.exp doesn't really test gdb, but it tests the gdb_caching_procs in the testsuite, so it belongs in gdb.testsuite rather than gdb.base. Move test-case gdb.base/gdb-caching-proc.exp to gdb.testsuite, renaming it to gdb.testsuite/gdb-caching-proc-consistency.exp to not clash with recently added gdb.testsuite/gdb-caching-proc.exp. Tested on x86_64-linux. Reviewed-By: Tom Tromey <tom@tromey.com>
* [gdb/testsuite] Allow args in gdb_caching_procTom de Vries2023-03-061-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Test-case gdb.base/morestack.exp contains: ... require {have_compile_flag -fsplit-stack} ... and I want to cache the result of have_compile_flag. Currently gdb_caching_proc doesn't allow args, so I could add: ... gdb_caching_proc have_compile_flag_fsplit_stack { return [have_compile_flag -fsplit-stack] } ... and then use that proc instead, but I find this cumbersome and maintenance-unfriendly. Instead, allow args in a gdb_caching_proc, such that I can simply do: ... -proc have_compile_flag { flag } { +gdb_caching_proc have_compile_flag { flag } { ... Note that gdb_caching_procs with args do not work with the gdb.base/gdb-caching-procs.exp test-case, so those procs are skipped. Tested on x86_64-linux. Reviewed-By: Tom Tromey <tom@tromey.com>
* gdb/testsuite: use `kill -FOO` instead of `kill -SIGFOO`Simon Marchi2023-03-032-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When running gdb.base/bg-exec-sigint-bp-cond.exp when SHELL is dash, rather than bash, I get: c&^M Continuing.^M (gdb) sh: 1: kill: Illegal option -S^M ^M Breakpoint 2, foo () at /home/jenkins/smarchi/binutils-gdb/build/gdb/testsuite/../../../gdb/testsuite/gdb.base/bg-exec-sigint-bp-cond.c:23^M 23 return 0;^M FAIL: gdb.base/bg-exec-sigint-bp-cond.exp: no force memory write: SIGINT does not interrupt background execution (timeout) This is because it uses the kill command built-in the dash shell, and using the SIG prefix with kill does not work with dash's kill. The difference is listed in the documentation for bash's POSIX-correct mode [1]: The kill builtin does not accept signal names with a ‘SIG’ prefix. Replace SIGINT with INT in that test. By grepping, I found two other instances (gdb.base/sigwinch-notty.exp and gdb.threads/detach-step-over.exp). Those were not problematic on my system though. Since they are done through remote_exec, they don't go through the shell and therefore invoke /bin/kill. On my Arch Linux, it's: $ /bin/kill --version kill from util-linux 2.38.1 (with: sigqueue, pidfd) and on my Ubuntu: $ /bin/kill --version kill from procps-ng 3.3.17 These two implementations accept "-SIGINT". But according to the POSIX spec [2], the kill utility should recognize the signal name without the SIG prefix (if it recognizes them with the SIG prefix, it's an extension): -s signal_name Specify the signal to send, using one of the symbolic names defined in the <signal.h> header. Values of signal_name shall be recognized in a case-independent fashion, without the SIG prefix. In addition, the symbolic name 0 shall be recognized, representing the signal value zero. The corresponding signal shall be sent instead of SIGTERM. -signal_name [XSI] [Option Start] Equivalent to -s signal_name. [Option End] So, just in case some /bin/kill implementation happens to not recognize the SIG prefixes, change these two other calls to remove the SIG prefix. [1] https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html [2] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/kill.html Change-Id: I81ccedd6c9428ab63b9261813f1905a18941f8da Reviewed-By: Tom Tromey <tom@tromey.com>
View Lorry Controller Status