This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Guard compile tests from running when unsupported + harden feature support check
- From: Luis Machado <lgustavo at codesourcery dot com>
- To: Pedro Alves <palves at redhat dot com>, <gdb-patches at sourceware dot org>
- Date: Wed, 19 Aug 2015 15:01:35 -0300
- Subject: Re: [PATCH] Guard compile tests from running when unsupported + harden feature support check
- Authentication-results: sourceware.org; auth=none
- References: <1439988825-19754-1-git-send-email-lgustavo at codesourcery dot com> <55D48179 dot 2030000 at redhat dot com> <55D485D1 dot 8040802 at codesourcery dot com> <55D48891 dot 7050808 at redhat dot com>
- Reply-to: Luis Machado <lgustavo at codesourcery dot com>
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.