From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20754 invoked by alias); 25 Apr 2012 22:02:24 -0000 Received: (qmail 20744 invoked by uid 22791); 25 Apr 2012 22:02:23 -0000 X-SWARE-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Apr 2012 22:02:05 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SNAHk-0002FB-9G from Maciej_Rozycki@mentor.com ; Wed, 25 Apr 2012 15:02:04 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Apr 2012 15:02:04 -0700 Received: from [172.30.0.84] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Wed, 25 Apr 2012 23:02:00 +0100 Date: Thu, 26 Apr 2012 00:10:00 -0000 From: "Maciej W. Rozycki" To: Pedro Alves CC: Daniel Jacobowitz , , Richard Sandiford Subject: Re: [RFA] MIPS/GDB: Fix the handling of MIPS16 thunks In-Reply-To: Message-ID: References: <4F916F9E.6040209@redhat.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00894.txt.bz2 Hi, > There's another note, that is even older, by Daniel -- Daniel, would you > mind if I updated the date on your note to the check in date too -- IOW, > do you continue to stand by it? Daniel, thanks for your reply. I'll use the check-in date for your comment then. > > > +gdb_breakpoint inmain > > > +gdb_run_cmd > > > +gdb_expect 30 { > > > + -re "Breakpoint 1.*inmain .*$gdb_prompt $" { > > > + send_gdb "finish\n" > > > + gdb_expect { > > > + -re "Value returned is \\\$\[0-9\]+ = 0\[^0-9\].*$gdb_prompt $" { > > > > Can we use gdb_test_multiple (catching internal errors etc., and dropping > > the default cases) ? (other instances) > > I'm not sure -- I looked at gdb_test_multiple and it appeared to me you > can't avoid scoring failures for cases the test considers to be just > symptoms of an unsupported feature that we want to silently ignore; I'll > recheck. Thanks for your persistence. And good news! I've looked at gdb_test_multiple again and came with the update below. As timeouts and some other odd messages are legitimate for a target (either the processor or e.g. a remote debug stub) that does not support the MIPS16 mode -- the debuggee could go astray and loop indefinitely by chance or do all kinds of weird stuff (SIGSEGV or SIGILL is the usual case however) -- I did keep the override expression clauses in the detection tests such as one you quoted above. This will handle problems with sending a command correctly -- it shouldn't trigger false negatives (I think -- I wonder if a forked process or `gdbserver' would ever terminate prematurely because of an OS kernel refusing to run a binary with the MIPS16 flag set in the ELF header; I think Linux never does that and no other OS supports MIPS16 executables). If it ever does, then we'll have to revert to send_gdb or tweak gdb_test_multiple -- a failure to run an unsupported binary shouldn't score a test failure here. For the test proper I did as you suggested; while at it fixing a problem with a while loop expression where a variable got evaluated at the wrong point (oh joys of TCL!). So I am going to apply the change with the update below shortly. Any objections? Out of curiosity gdb_test_multiple contains this: if { $message == "" } { set message $command } at the very beginning, and then lots of pieces like this: -re "\\*\\*\\* DOSEXIT code.*" { if { $message != "" } { fail "$message"; } gdb_suppress_entire_file "GDB died"; set result -1; } (this has weird indentation too, more cases elsewhere), or this: if ![string match "" $message] then { set errmsg "$message (the program exited)" } else { set errmsg "$command (the program exited)" } or this: timeout { if ![string match "" $message] then { fail "$message (timeout)" } set result 1 } Are these meant to trigger where both the command and the message supplied are empty? Or are they just a leftover from past time? Shouldn't the conditions be made consistent throughout, i.e. no fail invocation where $message is ultimately still empty? Or just removed? Maciej gdb-mips16-thunks-test-fix.diff Index: gdb-fsf-trunk-quilt/gdb/testsuite/gdb.arch/mips16-thunks.exp =================================================================== --- gdb-fsf-trunk-quilt.orig/gdb/testsuite/gdb.arch/mips16-thunks.exp 2012-04-25 22:34:45.535560326 +0100 +++ gdb-fsf-trunk-quilt/gdb/testsuite/gdb.arch/mips16-thunks.exp 2012-04-25 22:34:18.815561164 +0100 @@ -69,10 +69,10 @@ if { [gdb_compile ${objfiles} ${binfile} clean_restart ${testname} gdb_breakpoint inmain gdb_run_cmd -gdb_expect 30 { +gdb_test_multiple "" "check for MIPS16 support in the processor" { -re "Breakpoint 1.*inmain .*$gdb_prompt $" { - send_gdb "finish\n" - gdb_expect { + gdb_test_multiple "finish" \ + "check for MIPS16 support in the processor" { -re "Value returned is \\\$\[0-9\]+ = 0\[^0-9\].*$gdb_prompt $" { verbose "MIPS16 support check successful." } @@ -121,7 +121,7 @@ if { [gdb_compile ${objfiles} ${binfile} clean_restart ${testname} gdb_breakpoint inmain gdb_run_cmd - gdb_expect 30 { + gdb_test_multiple "" "check for PIC support" { -re "Breakpoint 1.*inmain .*$gdb_prompt $" { note "PIC support present, will make additional PIC thunk checks." set picflag additional_flags=-fPIC @@ -232,49 +232,33 @@ proc step_through { id funcs } { # indefinitely in the case something goes wrong, increase as (if) # necessary. set count 8 - while [expr $count > 0] { - send_gdb "backtrace\n" - gdb_expect { + while { $count > 0 } { + if { [gdb_test_multiple "backtrace" "$msg (backtrace)" { -re "${frames}$gdb_prompt $" { - send_gdb "step\n" - gdb_expect { + if { [gdb_test_multiple "step" "$msg (step)" { -re "$gdb_prompt $" { - send_gdb "frame\n" - gdb_expect { + if { [gdb_test_multiple "frame" "$msg (frame)" { -re "${frame}.*$gdb_prompt $" { } -re "${anyframe}.*$gdb_prompt $" { pass "$msg" return $expect_out(1,string) } - -re "$gdb_prompt $" { - fail "$msg (frame)" - return "" - } - default { - fail "$msg (frame)" - return "" - } + }] != 0 } then { + return "" } } - default { - fail "$msg (step)" - return "" - } + }] != 0 } then { + return "" } } - -re "$gdb_prompt $" { - fail "$msg (backtrace)" - return "" - } - default { - fail "$msg (backtrace)" - return - } + }] != 0 } then { + return "" } incr count -1 } fail "$msg (too many steps)" + return "" } # Finish the current function that must be one that is at the head of @@ -290,47 +274,21 @@ proc finish_through { id funcs } { set msg "finishing \"${func}\" ($id)" - send_gdb "backtrace\n" - gdb_expect { + gdb_test_multiple "backtrace" "$msg (backtrace)" { -re "${frames}$gdb_prompt $" { - send_gdb "finish\n" - gdb_expect { + gdb_test_multiple "finish" "$msg (finish)" { -re "Run till exit from ${frame}.*$gdb_prompt $" { - send_gdb "frame\n" - gdb_expect { + gdb_test_multiple "frame" "$msg (frame)" { -re "${anyframe}.*$gdb_prompt $" { pass "$msg" return $expect_out(1,string) } - -re "$gdb_prompt $" { - fail "$msg (frame)" - return "" - } - default { - fail "$msg (frame)" - return "" - } } } - -re "$gdb_prompt $" { - fail "$msg (finish)" - return "" - } - default { - fail "$msg (finish)" - return "" - } } } - -re "$gdb_prompt $" { - fail "$msg (backtrace)" - return "" - } - default { - fail "$msg (backtrace)" - return "" - } } + return "" } # Report PASS if VAL is equal to EXP, otherwise report FAIL, using MSG.