Re: [PATCH] Restrict gdb.base/gcore-relro-pie.exp to native/linux targets

[Pedro Alves <palves at redhat dot com>]

On 02/23/2017 03:10 PM, Luis Machado wrote:
> On 02/23/2017 08:54 AM, Pedro Alves wrote:
>> On 02/23/2017 02:47 PM, Luis Machado wrote:
>>
>>> I still think it doesn't make much sense to run these tests if we're not
>>> sure gcore will support them.
>>
>> I don't understand what you're saying.  We can't be sure up
>> front.  The "gcore" that is run is GDB's "gcore" command.  If that
>> doesn't work, gdb_gcore_cmd calls unsupported, and the rest of the
>> testcase is skipped.
>>
> 
> The point is that we are indeed sure this isn't supported, unless we
> officially support core files on bare-metal targets (i don't think we
> do). 

There's been talks / patches about adding that for years.
Unfortunately it hasn't happened yet, but I think it'd
be quite reasonable to have.

> See below.

Note your patch did not skip the test on bare metal targets. 
That's not even what the subject says.  You've skipped it
everywhere but Linux.  It's not quite the same thing.

> 
>>> They may run a few early tests/setup
>>> tests, but that won't translate into meaningful PASSes. But i'm ok
>>> keeping it as-is if others think the early test PASSes are useful.
>>
>> Looks like it's been useful to catch a startup code problem.  ;-)
> 
> Don't you agree this is a clear sign we are really testing something
> else other than core file support? 

Not really.  It's a sign that the test is missing a predicate, but
it's not "cores work", IMO.  The testcase has a few requirements.
At least:

#1 - PIEs make sense for this target.
#2 - gcore works

To me this is a clear sign a predicate for #1 is missing.
We already detect #2.  Other tests build PIEs too.

IOW, IMO, all this talk about core files is a distraction
from the real issue.

But then I wonder why does compilation, linking, loading all
succeed without something realizing the binary can't run on
this target.  It may well be that PIEs do make sense for this
target.  It's not uncommon to call things "bare-metal" when
they're really pretty sophisticated RTOSs.

> It just means a proper standalone
> test doesn't exist to catch such a problem and we got lucky crashing
> when doing a core file test on a target that doesn't support it. It is
> not like the test was designed to catch this.
> 
> I find it a bit messy. A proper test would attempt to run pie
> executables to completion (and i can contribute that to verify this
> particular problem).

How would that help, if it'd crash and loop the board too?

> I just don't like the concept of running a test that is unsupported on a
> particular target (core files) only to test a side-effect during
> pre-test/setup phases. It only adds to artificial PASSes that don't
> necessarily translate to robustness.
> 
> But i understand if this is not acceptable. I just want to clean this
> target up, and seeing core file tests being executed is just confusing. :-)

Thanks,
Pedro Alves