[llvm-commits] [llvm] r75665-/llvm/trunk/tools/bugpoint/ToolRunner.cpp

[Viktor Kutuzov]

> If #2 is non-zero have RemoteRunSafely.sh print a message and return
> 127.
> Otherwise have it return #1.

I have been thinking of it and decided to not go that way because of the following reasons.
This tied up the bugpoint to the script (this dependency does not exist yet, and user could use any remote client which deliver the 
test program to a target, run it and deliver the result back). Any other remote client will not be aware of this cconvention and 
could miss-lead the bugpoint returning "reserved" codes.
This is a hack.
It still have overlapped status codes - 127 (and 126) which makes the original problem remain open. Nothing prevents the test 
program returning 127 (126, or any other status code). In this case bugpoint will miss-handle the result.

However we could end up with this. :)

It is obvious that we need to make some convention unless we want to implement/control a remote client inside the bugpoint (I don't 
think this is a good idea).
But we should not enforce this convention and act reasonably if the remote client does not follow it.

There is another option (I'm not crazy about it either, but it solves some problems the above option has).
We could require the test program exit code to be optionally placed at the end of the output in "exit <return code>" format.
In this case the test program status code could be extracted from there (it will be removed from the output so the output itself 
will look exactly like the test program produces it) and returned back as a result of the run.
Any error code the remote client returns will be escalated. The missing return code will be defaulted to 0.
This seems reasonable convention to me.

What do you think?

By the way, I'm going to re-factor the ToolRunner.cpp a bit to add a new RunProgramRemotelyWithTimeout in addition to the 
RunProgramWithTimeout routine.
And will put everything related to the subject there to make sure we have just one place to alter if later we will want to change 
the behavior.
I'll be sending the patch for review shortly.

Thanks,
Viktor

----- Original Message ----- 
From: "Dan Gohman" <gohman at apple.com>
To: "Commit Messages and Patches for LLVM" <llvm-commits at cs.uiuc.edu>
Sent: Wednesday, July 15, 2009 11:27 AM
Subject: Re: [llvm-commits] [llvm] r75665-/llvm/trunk/tools/bugpoint/ToolRunner.cpp


>
> On Jul 14, 2009, at 6:58 PM, Viktor Kutuzov wrote:
>
>
>> There are 2 different types of status codes we could get there:
>>
>> 1. The test status code, which bugpoint uses to narrow down the
>> problem;
>> 2. The remote client status code (for example if it cannot connect
>> to a remote target and such).
>>
>> As it was before, the remote client status code was returned, which
>> made bugpoint handle remote client errors as test program
>> errors - it assumes that something is wrong with the test program
>> and tries to narrow down the problem.
>>
>> As it is now (thanks Evan for fixing that warning for me), the test
>> status code got appended to the output file and participates at
>> the diffProgram step.
>> The remote client errors get reported and 0 always returned. The
>> same behavior we have in the test suite.
>>
>> Ideally, we need to have 2 separate ranges/namespaces for these 2
>> different types of status codes, in this case we can return test
>> program status code from GCC::ExecuteProgram and escalate remote
>> client errors with llvm_report_error.
>> Does anyone have a good idea how to do this?
>
> If #2 is non-zero have RemoteRunSafely.sh print a message and return
> 127.
> Otherwise have it return #1.
>
> Then make bugpoint recognize 127 (and 126) as fatal errors, so that it
> bails immediately instead of trying to reduce a problem. In all other
> cases,
> bugpoint could then handle the exit code from RemoteRunSafely.sh the
> same
> way as it handles the exit code from a regular local execution. And
> RemoteRunSafely.sh doesn't have to print the exit code.
>
> Dan
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>