[PATCH] Guard compile tests from running when unsupported + harden feature support check
Pedro Alves
palves@redhat.com
Wed Aug 19 13:46:00 GMT 2015
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
More information about the Gdb-patches
mailing list