Re: [PATCH] Guard compile tests from running when unsupported + harden feature support check

[Pedro Alves <palves@redhat.com>]

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