| Summary: | [gdb/testsuite] FAIL: gdb.base/examine-backward.exp: char-width=1, print-max=20: take 6 strings backward (pattern 1) | ||
|---|---|---|---|
| Product: | gdb | Reporter: | Tom de Vries <vries> |
| Component: | testsuite | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | HEAD | ||
| Target Milestone: | 15.1 | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
The master branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=42ffc15774fc791f2ac9a719e81589c8e91bdb98 commit 42ffc15774fc791f2ac9a719e81589c8e91bdb98 Author: Tom de Vries <tdevries@suse.de> Date: Tue Nov 21 13:15:29 2023 +0100 [gdb/testsuite] Fix spurious FAILs with examine-backward.exp, again Commit 59a561480d5 ("Fix spurious FAILs with examine-backward.exp") describes the problem that: ... The test case examine-backward.exp issues the command "x/-s" after the end of the first string in TestStrings, but without making sure that this string is preceded by a string terminator. Thus GDB may spuriously print some random characters from before that string, and then the test fails. ... The commit fixes the problem by adding a Barrier variable before the TestStrings variable: ... +const char Barrier[] = { 0x0 }; const char TestStrings[] = { ... There is however no guarantee that Barrier is placed immediately before TestStrings. Before recent commit 169fe7ab54b ("Change gdb.base/examine-backwards.exp for AIX.") on x86_64-linux, I see: ... 0000000000400660 R Barrier 0000000000400680 R TestStrings ... So while the Barrier variable is the first before the TestStrings variable, it's not immediately preceding TestStrings. After commit 169fe7ab54b: ... 0000000000402259 B Barrier 0000000000402020 D TestStrings ... they're not even in the same section anymore. Fix this reliably by adding the zero in the array itself: ... char TestStringsBase[] = { 0x0, ... }; char *TestStrings = &TestStringsBase[1]; ... and do likewise for TestStringsH and TestStringsW. Tested on x86_64-linux. PR testsuite/31064 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31064 Fixed. |
On a pinebook I run into: ... (gdb) PASS: gdb.base/examine-backward.exp: char-width=1, print-max=20: take 1 char backward gdb_expect_list pattern: /"ABCDEFGHIJKLMNOPQRST".../ x/-6s^M 0xaaabb03c: "<\260\253\252ABCDEFGHIJKLMNOP"...^M 0xaaabb050 <TestStrings+16>: "QRSTUVWXYZ"^M 0xaaabb05b <TestStrings+27>: ""^M 0xaaabb05c <TestStrings+28>: ""^M 0xaaabb05d <TestStrings+29>: "\343\201\273\343\201\222\343\201\273\343\201\222"^M 0xaaabb06a <TestStrings+42>: "01234567890123456789"...^M (gdb) FAIL: gdb.base/examine-backward.exp: char-width=1, print-max=20: take 6 strings backward (pattern 1) ... It's clear that this: ... /* This is here just to ensure we have a null character before TestStrings, to avoid showing garbage when we look for strings backwards from TestStrings. */ unsigned char Barrier[] = { 0x00, }; ... is not working: ... $ nm outputs/gdb.base/examine-backward/examine-backward | egrep "TestStrings|Barrier" 00011250 B Barrier 00011040 D TestStrings 00011094 D TestStringsH 00011128 D TestStringsW ...