From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46722 invoked by alias); 19 Aug 2015 18:01:44 -0000 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 Received: (qmail 46709 invoked by uid 89); 19 Aug 2015 18:01:43 -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 18:01:42 +0000 Received: from svr-orw-fem-02x.mgc.mentorg.com ([147.34.96.206] helo=SVR-ORW-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1ZS7or-0006Sn-4k from Luis_Gustavo@mentor.com ; Wed, 19 Aug 2015 11:10:37 -0700 Received: from [172.30.11.178] (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.3.224.2; Wed, 19 Aug 2015 11:01:38 -0700 Message-ID: <55D4C47F.6080902@codesourcery.com> Date: Wed, 19 Aug 2015 18:01:00 -0000 From: Luis Machado Reply-To: Luis Machado User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Pedro Alves , Subject: Re: [PATCH] Guard compile tests from running when unsupported + harden feature support check References: <1439988825-19754-1-git-send-email-lgustavo@codesourcery.com> <55D48179.2030000@redhat.com> <55D485D1.8040802@codesourcery.com> <55D48891.7050808@redhat.com> In-Reply-To: <55D48891.7050808@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00525.txt.bz2 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.