[committed][gdb/testsuite] Update psym-external-decl.exp for gcc-10/clang

[Pedro Alves]

On 6/28/20 11:50 AM, Tom de Vries wrote:
> On 6/26/20 11:37 AM, Gary Benson wrote:
>> Tom de Vries wrote:
>>> On 6/19/20 4:00 PM, Gary Benson wrote:
>>>> Tom de Vries wrote:
>>>>> On 6/18/20 6:10 PM, Gary Benson wrote:
>>>>>> Tom de Vries wrote:
>>>>>>> On 6/17/20 2:24 PM, Gary Benson wrote:
>>>>>>>> Tom, I'd like this testcase to not fail silently.  Is the
>>>>>>>> functionality under test something that isn't ever
>>>>>>>> expected to work with clang, or is this a test that should
>>>>>>>> pass with clang (but it currently doesn't, for whatever
>>>>>>>> reason)?
>>>>>>>
>>>>>>> I'm not sure.  The test can pass with clang, provided it
>>>>>>> generates the required debug info.  It currently doesn't.
>>>>>>> Why that is the case, I have no idea.
>>>>>>
>>>>>> I think that means the test should work but it doesn't.  Would
>>>>>> you object if I push a patch removing the test-skipping logic?
>>>>>> It will mean an extra FAIL when tested using clang
>>>>>
>>>>> I don't think having a fail for a compiler bug/missing-feature
>>>>> is a good idea.
>>>>>
>>>>> If this is due to a bug/missing-feature in clang, then we need to:
>>>>> - xfail the test,
>>>>> - file the PR in clang, and
>>>>> - reference the PR at the xfail.
>>>>
>>>> Is this a bug/missing feature in clang though?
>>>> How sure are you GDB isn't at fault?
>>>
>>> Clang emits less debug info than GCC.  Whether that's a bug, a
>>> missing feature or an explicit unsupported feature in clang, I
>>> don't known.
>>>
>>> I known that gdb isn't at fault.  It can't do anything without the
>>> missing debug info.  The test was specifically written to use that
>>> debug info.
>>
>> I'm not really sure what's the right thing to do here.
>>
>> On the one hand, my current task is ensuring GDB can debug
>> clang-compiled with clang as well as it can debug GCC-compiled
>> code.  From that perspective the skip-if-clang logic in this
>> test is hiding a failure I need to investigate.
>>
>> On the other hand, I'm an engineer working on GDB, and from that
>> perspective I want to be able to run the GDB testsuite and see
>> 100% pass, on whatever setup I test it on.  And yes, I know it
>> doesn't... but it *should*.
>>
>> Is there a way to pass a "don't skip clang failures" flag to the
>> testcases, such that people running the testsuite normally would
>> see tests like these return UNSUPPORTED, but I could run the
>> testsuite with the flag so it'd not skip but FAIL wherever the
>> problem is?
> 
> I think the following is a good way of dealing with this.
> 
> We introduce a proc in gdb.exp called debug_info_for_decl or some such,
> that returns false by default for clang.

I think it would be useful to include an intro description to

 gdb.base/psym-external-decl.exp

since it currently doesn't describe what it is testing.  Looking
at the commit log of the patch that introduced it helps, but
one shouldn't have to do that.

So the difference between gcc and clang AFAIU is that gcc emits
debug info for the extern variable declaration (and with newer GCCs,
only if there's a reference to the variable in the CU, otherwise
not even so), while seemingly clang would only emit debug info for
the variable's definition, which isn't compiled with -g, so we
end up with no debug info for the variable.

I would suggest filing a bug with clang, to confirm whether
this is intentional, or whether they see it as a bug.  I would
think it is a bug, but I'm not sure.  If indeed a bug, we would
XFAIL the test.

> 
> Instead of testing for a specific compiler in the test-case,  we call
> this new proc, and mark the test-case UNSUPPORTED if it returns false.
> 
> Then if you want to see how clang performs if we expect it to have that
> feature, you comment out the clang-specific code in the proc.
> 
> Thanks,
> - Tom
>