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

[Luis Machado <lgustavo@codesourcery.com>]

On 02/23/2017 09:43 AM, Pedro Alves wrote:
> 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.

I find it reasonable too, but it is not here yet.

> 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.

This is just a stack pointer startup problem, so not a matter of 
supporting PIE's or not.

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

The test would need to be tweaked. The assumption that these targets can 
handle a crash is not always valid as it is with OS-based targets.

I remember i addressed problems with these assumptions in the past. It 
is similar to assuming reading 0x0 would error out or that it is a bad 
address. We are much more aware of that problem these days.

Unfortunately not a lot of bare-metal/RTOS testing going on for gdb at 
the moment. I think even QEMU shields these tests from problems sometimes.

Anyway, i know what i have to do to get this FAIL fixed!

The discussion about how focused/robust a particular gdb test is/needs 
to be can be rather long. At this point i don't think there is a lot of 
benefit from that, but maybe a worthy discussion in the future about how 
to improve gdb's testsuite, or not!