diff mbox

[testsuite] Fix recent GCC FAIL: gdb.arch/i386-signal.exp

Message ID 20161003203500.GA2251@host1.jankratochvil.net
State New, archived
Headers

Commit Message

Jan Kratochvil Oct. 3, 2016, 8:35 p.m. UTC 
  Hi,

gcc-6.2.1-2.fc24.x86_64

(gdb) backtrace 10^M
#0  func () at .../gdb/testsuite/gdb.arch/i386-signal.c:26^M
#1  <signal handler called>^M
#2  0x0000000000400588 in main () at .../gdb/testsuite/gdb.arch/i386-signal.c:31^M
(gdb) FAIL: gdb.arch/i386-signal.exp: backtrace 10

(gdb) disas/s
Dump of assembler code for function main:
.../gdb/testsuite/gdb.arch/i386-signal.c:
30      {
   0x000000000040057f <+0>:     push   %rbp
   0x0000000000400580 <+1>:     mov    %rsp,%rbp
31        setup ();
   0x0000000000400583 <+4>:     callq  0x400590 <setup>
=> 0x0000000000400588 <+9>:     mov    $0x0,%eax
32      }
   0x000000000040058d <+14>:    pop    %rbp
   0x000000000040058e <+15>:    retq
End of assembler dump.

The two attached patch chunks each fixes the FAIL on its own.

The .exp patch is an obvious typo fix I think.  The regex was written to
accept "ADDR in main" and I find it OK as checking .debug_line validity is not
the purpose of this testfile.

The .c patch will properly create a new corresponding source line .debug_line
entry for the 'mov $0x0,%eax' instruction and I also do not think it is
relevant to the purpose of this testfile.

gcc-4.8.5-11.el7.x86_64 did not put the 'mov $0x0,%eax' instruction there at
all so there was no problem with .debug_line.

Tested on {x86_64,x86_64-m32}-fedora24-linux-gnu.

OK to check it in?


Thanks,
Jan
gdb/testsuite/ChangeLog
2016-10-03  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* gdb.arch/i386-signal.c (main): Add return 0.
	* gdb.arch/i386-signal.exp (backtrace 10): Fix #2 typo.

Comments

Yao Qi Oct. 4, 2016, 4:07 p.m. UTC | #1 
On Mon, Oct 3, 2016 at 9:35 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> The two attached patch chunks each fixes the FAIL on its own.
>
> The .exp patch is an obvious typo fix I think.  The regex was written to
> accept "ADDR in main" and I find it OK as checking .debug_line validity is not
> the purpose of this testfile.
>

This is reasonable to me.

> The .c patch will properly create a new corresponding source line .debug_line
> entry for the 'mov $0x0,%eax' instruction and I also do not think it is
> relevant to the purpose of this testfile.
>

Why do we need the second one?
Jan Kratochvil Oct. 4, 2016, 4:19 p.m. UTC | #2 
On Tue, 04 Oct 2016 18:07:56 +0200, Yao Qi wrote:
> > The .c patch will properly create a new corresponding source line .debug_line
> > entry for the 'mov $0x0,%eax' instruction and I also do not think it is
> > relevant to the purpose of this testfile.
> 
> Why do we need the second one?

I find it more cleaner but that is up to you.


Jan
Jan Kratochvil Oct. 4, 2016, 4:39 p.m. UTC | #3 
On Tue, 04 Oct 2016 18:19:00 +0200, Jan Kratochvil wrote:
> On Tue, 04 Oct 2016 18:07:56 +0200, Yao Qi wrote:
> > > The .c patch will properly create a new corresponding source line .debug_line
> > > entry for the 'mov $0x0,%eax' instruction and I also do not think it is
> > > relevant to the purpose of this testfile.
> > 
> > Why do we need the second one?
> 
> I find it more cleaner but that is up to you.

To make that my reason more explanatory - given the testcase expected output
is affected by that missing "return 0;" and its .debug_line record I find it
more clear for this testcase to put there the source line "return 0;"
explicitly than to depend on such implicit line by compiler as then the debug
info is unclear for that line - even among different compilers.


Jan
Yao Qi Oct. 5, 2016, 8:15 a.m. UTC | #4 
On Tue, Oct 4, 2016 at 5:39 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Tue, 04 Oct 2016 18:19:00 +0200, Jan Kratochvil wrote:
>> On Tue, 04 Oct 2016 18:07:56 +0200, Yao Qi wrote:
>> > > The .c patch will properly create a new corresponding source line .debug_line
>> > > entry for the 'mov $0x0,%eax' instruction and I also do not think it is
>> > > relevant to the purpose of this testfile.
>> >
>> > Why do we need the second one?
>>
>> I find it more cleaner but that is up to you.
>
> To make that my reason more explanatory - given the testcase expected output
> is affected by that missing "return 0;" and its .debug_line record I find it
> more clear for this testcase to put there the source line "return 0;"
> explicitly than to depend on such implicit line by compiler as then the debug
> info is unclear for that line - even among different compilers.
>

We need the first chunk "($hex in )?main" because the unwind pc may point
to the first instruction of a source line or the non-first instruction
of a line.
Either is possible.   It doesn't matter that "callq  setup" and
"mov    $0x0,%eax" are mapped to the same line or not.

Change in gdb.arch/i386-signal.exp is good to me, but change
in gdb.arch/i386-signal.c is not necessary.
diff mbox

Patch

diff --git a/gdb/testsuite/gdb.arch/i386-signal.c b/gdb/testsuite/gdb.arch/i386-signal.c
index c5a311e..c168d56 100644
--- a/gdb/testsuite/gdb.arch/i386-signal.c
+++ b/gdb/testsuite/gdb.arch/i386-signal.c
@@ -29,6 +29,7 @@  int
 main (void)
 {
   setup ();
+  return 0;
 }
 
 /* Create an imitation signal frame.  This will work on any x86 or
diff --git a/gdb/testsuite/gdb.arch/i386-signal.exp b/gdb/testsuite/gdb.arch/i386-signal.exp
index 276b7c0..51a3a25 100644
--- a/gdb/testsuite/gdb.arch/i386-signal.exp
+++ b/gdb/testsuite/gdb.arch/i386-signal.exp
@@ -35,6 +35,6 @@  gdb_load ${binfile}
 
 runto func
 gdb_test "backtrace 10" \
-    "#0  ($hex in )?func.*\r\n#1  <signal handler called>\r\n#2  ($hex in)?main.*"
+    "#0  ($hex in )?func.*\r\n#1  <signal handler called>\r\n#2  ($hex in )?main.*"
 
 gdb_test "finish" "Run till exit from \#0  func.*<signal handler called>"