Message ID | 1439988825-19754-1-git-send-email-lgustavo@codesourcery.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 55377 invoked by alias); 19 Aug 2015 12:54:01 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 55361 invoked by uid 89); 19 Aug 2015 12:54:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Aug 2015 12:53:59 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1ZS314-0000o4-QX from Luis_Gustavo@mentor.com for gdb-patches@sourceware.org; Wed, 19 Aug 2015 06:02:54 -0700 Received: from opsys.world.mentorg.com (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.3.224.2; Wed, 19 Aug 2015 05:53:55 -0700 From: Luis Machado <lgustavo@codesourcery.com> To: <gdb-patches@sourceware.org> Subject: [PATCH] Guard compile tests from running when unsupported + harden feature support check Date: Wed, 19 Aug 2015 09:53:45 -0300 Message-ID: <1439988825-19754-1-git-send-email-lgustavo@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes |
Commit Message
Luis Machado
Aug. 19, 2015, 12:53 p.m. UTC
In our test environment i noticed a few compile tests, though unsupported, were still being executed and causing spurious FAIL's. The following change adds a missing feature support check to compile-ifunc.exp and also adds one more pattern to the feature support check function. With this change, none of the compile tests run when they're not supposed to. OK? gdb/testsuite/ChangeLog: 2015-08-19 Luis Machado <lgustavo@codesourcery.com> * lib/gdb.exp (skip_compile_feature_tests): Check for unsupported compiler language. * gdb.compile/compile-ifunc.exp (with_test_prefix): Check feature support before running tests. --- gdb/testsuite/gdb.compile/compile-ifunc.exp | 5 +++++ gdb/testsuite/lib/gdb.exp | 3 +++ 2 files changed, 8 insertions(+)
Comments
On 08/19/2015 01:53 PM, Luis Machado wrote: > + if {[skip_compile_feature_tests]} { > + untested "compile command not supported (could not find libcc1 shared library?)" > + return -1 > + } > + > # gnu_ifunc (10): error: too many arguments to function 'gnu_ifunc' > gdb_test_no_output "compile code resultvar = gnu_ifunc_alias (10);" > This one's OK. > diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp > index 56cde7a..fcf9cac 100644 > --- a/gdb/testsuite/lib/gdb.exp > +++ b/gdb/testsuite/lib/gdb.exp > @@ -3005,6 +3005,9 @@ proc skip_compile_feature_tests {} { > -re "Command not supported on this host\\..*\r\n$gdb_prompt $" { > set result 1 > } > + -re "No compiler support for this language\\.\r\n$gdb_prompt $" { > + set result 1 > + } This one I'm not so sure. I'd suspect that that could happen when e.g., gdb connects to gdbserver and finds the program stopped at the entry point, and then the current language ends up set to asm instead of C. But then that would be a test bug and it would be wrong to skip further testing. But please don't make us guess; please expand on when do you see this. Thanks, Pedro Alves
On 08/19/2015 10:15 AM, Pedro Alves wrote: > On 08/19/2015 01:53 PM, Luis Machado wrote: > >> + if {[skip_compile_feature_tests]} { >> + untested "compile command not supported (could not find libcc1 shared library?)" >> + return -1 >> + } >> + >> # gnu_ifunc (10): error: too many arguments to function 'gnu_ifunc' >> gdb_test_no_output "compile code resultvar = gnu_ifunc_alias (10);" >> > > This one's OK. > >> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp >> index 56cde7a..fcf9cac 100644 >> --- a/gdb/testsuite/lib/gdb.exp >> +++ b/gdb/testsuite/lib/gdb.exp >> @@ -3005,6 +3005,9 @@ proc skip_compile_feature_tests {} { >> -re "Command not supported on this host\\..*\r\n$gdb_prompt $" { >> set result 1 >> } >> + -re "No compiler support for this language\\.\r\n$gdb_prompt $" { >> + set result 1 >> + } > > This one I'm not so sure. > > I'd suspect that that could happen when e.g., gdb connects to gdbserver and > finds the program stopped at the entry point, and then the current language > ends up set to asm instead of C. But then that would be a test bug and it > would be wrong to skip further testing. > No stopping at the entry point, we run to main. > But please don't make us guess; please expand on when do you see this. It is related to how the binaries are built, without debug info. That's how GDB reacts to these GCC 5.2-produced binaries. compile-ifunc.exp: #0 0x100007b0 in main () (gdb) show language show language The current source language is "auto; currently asm". compile-ops.exp: Breakpoint 1, 0x10000724 in func (param=268503652, optimized_out=<optimized out>)^M (gdb) compile code -- ;^M No compiler support for this language.^M show language The current source language is "auto; currently asm". Enabling debug info i see the standard error about missing libcc1, which may be an alternate fix, though checking for unsupported languages does sound useful to me.
On 08/19/2015 02:34 PM, Luis Machado wrote: >> But please don't make us guess; please expand on when do you see this. > > It is related to how the binaries are built, without debug info. That's > how GDB reacts to these GCC 5.2-produced binaries. > ... > > Enabling debug info i see the standard error about missing libcc1, which > may be an alternate fix, though checking for unsupported languages does > sound useful to me. I disagree. It's a bug, because the tests are testing C code. > compile-ifunc.exp: > > #0 0x100007b0 in main () > (gdb) show language > show language > The current source language is "auto; currently asm". > This binary has no debug info (by test design), so we should just make the test do "set language c" (with a comment). > compile-ops.exp: > > Breakpoint 1, 0x10000724 in func (param=268503652, > optimized_out=<optimized out>)^M > (gdb) compile code -- ;^M > No compiler support for this language.^M > > show language > The current source language is "auto; currently asm". This one looks like a gdb bug? AFAICS, the test generates debug info, and gdb should have figured out the language is c. At least, from skimming the test's .exp, I see: compile_unit { {name file1.txt} {language @DW_LANG_C} ^^^^^^^^^^^^^^^^^^^ {low_pc func_start addr} {high_pc func_end addr} } { global program BTW, it'd be nice if the "No compiler support for this language" error told us which language is "this"... Thanks, Pedro Alves
On 08/19/2015 10:45 AM, Pedro Alves wrote: > On 08/19/2015 02:34 PM, Luis Machado wrote: >> Enabling debug info i see the standard error about missing libcc1, which >> may be an alternate fix, though checking for unsupported languages does >> sound useful to me. > > I disagree. It's a bug, because the tests are testing C code. > I did a bit more investigation and here's what i found: GDB generally sets the default language to C on top.c:gdb_init. Usually the dynamic loader code is not available, so GDB doesn't switch away from C when connecting to GDBserver. It does for me because it sees real asm code from the dynamic loader, so the starting language is "asm". Now, the testcases have different behaviors. For compile-ifunc.exp, when we run to main, we don't have any kind of debug info that tells GDB what language we are dealing with, so GDB doesn't switch away from the previously selected "asm". Forcing the language to C would fix this. For compile-ops.exp, on the other hand, we run to "func" and it has debug info, but the source file is named "file1.txt". Not sure if this was on purpose, but it seems to throw GDB off when trying to find the source language, even though the DIE states it is C. If i rename the source file to file1.c, then GDB correctly selects C as the current source language. It could be either a GDB bug for not honoring the language in the DIE itself or a testcase issue for not naming the source file with the correct language extension. > BTW, it'd be nice if the "No compiler support for this language" > error told us which language is "this"... > Indeed it would be useful.
diff --git a/gdb/testsuite/gdb.compile/compile-ifunc.exp b/gdb/testsuite/gdb.compile/compile-ifunc.exp index 026c62f..80d7bb4 100644 --- a/gdb/testsuite/gdb.compile/compile-ifunc.exp +++ b/gdb/testsuite/gdb.compile/compile-ifunc.exp @@ -46,6 +46,11 @@ with_test_prefix "debug" { return -1 } + if {[skip_compile_feature_tests]} { + untested "compile command not supported (could not find libcc1 shared library?)" + return -1 + } + # gnu_ifunc (10): error: too many arguments to function 'gnu_ifunc' gdb_test_no_output "compile code resultvar = gnu_ifunc_alias (10);" diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 56cde7a..fcf9cac 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -3005,6 +3005,9 @@ proc skip_compile_feature_tests {} { -re "Command not supported on this host\\..*\r\n$gdb_prompt $" { set result 1 } + -re "No compiler support for this language\\.\r\n$gdb_prompt $" { + set result 1 + } -re "\r\n$gdb_prompt $" { } }