[fpc-devel] MIPS big-endian program starts but does nothing

[Tomas Hajny]

On Tue, September 9, 2014 12:00, Mark Morgan Lloyd wrote:
> Tomas Hajny wrote:
>> On Tue, September 9, 2014 10:20, Mark Morgan Lloyd wrote:
>>  .
>>  .
>>> I was wondering whether a completely empty program would be a better
>>> test than a "Hello, World!". Could a completely empty program be
>>> recognised by the compiler etc. as a special case and built with only
>>> minimal RTL initialisation, specifically as a test that a program will
>>> load and terminate in good order i.e. that FPC and the OS are
>>> compatible? Or is there a set of portable options that will already do
>>> this, which could be documented prominently?
>>>
>>> After all, there's been comparable issues on ARM, and there might be
>>> more on various platforms in the future.
>>
>> Isn't there a risk that behaviour of a program not doing anything might
>> look the same as behaviour of a program failing/crashing before doing
>> what
>> it was asked to do?
>>
>> In addition, what is the supposed difference between an "empty program"
>> and program "built with only minimal RTL initialisation"?
>
> I don't see why something like this
>
> program test;
> begin
> end.
>
> should use anything other than the absolute minimum that's needed to
> terminate in good order. At that point gdb (or strace etc.) should be
> able to confirm that it's terminated rather than crashing, and that
> would be useful confirmation that as far as the OS and system libraries
> were concerned the binary format (ELF header etc.) was OK.
>
> After all, when this sort of problem has been raised in the past we've
> usually started off by scratching our heads over whether the user had
> somehow screwed the file, or had built it with the wrong endianness or
> for an inappropriate CPU. It would be useful to be able to eliminate
> some of these possible conditions.

If you compile an empty program, the compiler doesn't add anything except
for initialization of standard RTL features included in unit System. As
pointed out by Sven, it's possible to disable various RTL features
(obviously including their initialization) using IFDEFs. Asking for the
compiler to detect that your program isn't using certain RTL features and
thus bypass initialization of such features looks very tricky to me.

Regarding gdb or strace as means for confirmation of properly loading and
running binaries - I wouldn't assume that all devices used for running FPC
programs need to have these installed and sometimes it's really matter of
finding out why something doesn't work on that particular device.
Obviously, it's still an option, but I wouldn't say that it's a better one
unless there's some doubt that the issue may indeed be related to
initialization of a specific RTL feature (but even then one still needs to
find out which particular one it is).

Tomas