[PATCH] Fix for bugpoint -remote-client

Hello everyone,

Please find the patch attached.
This fixes the bugpoint -remote-client and adds a helper script for a remote run.

-Viktor

ToolRunner.diff (4.12 KB)

Thanks Viktor.

+ std::cout << "<run locally>" << std::flush;

This should use std::cerr and make sure it is wrapped inside the DEBUG macro.

Also, we don't want RemoteRunSafely.sh to be under utils/bugpoint. Can you move it to test-suite? Are you planning to change the llvm test suite makefile to make use of RemoteRunSafely.sh?

Thanks,

Evan

Hello Evan,

Thanks for looking at the patch.

This should use std::cerr and make sure it is wrapped inside the DEBUG macro.

Will do.

Also, we don't want RemoteRunSafely.sh to be under utils/bugpoint. Can you move it to test-suite? Are you planning to change the llvm test suite makefile to make use of RemoteRunSafely.sh?

I thought about bugpoint remote mode and the RemoteRunSafely.sh script more as a manual tool rather than a part of the test suit.
Unless I'm missing something, getting it there will add some dependencies which are not for a regular build system.
This is why I have placed the script under utils/bugpoint.

But it sounds like you have an idea how to do this. Would you explain your thoughts, please?

Best regards,
Viktor

Hello Evan,

Thanks for looking at the patch.

This should use std::cerr and make sure it is wrapped inside the DEBUG
macro.

Will do.

Also, we don't want RemoteRunSafely.sh to be under utils/bugpoint.
Can you move it to test-suite? Are you planning to change the llvm
test suite makefile to make use of RemoteRunSafely.sh?

I thought about bugpoint remote mode and the RemoteRunSafely.sh script more as a manual tool rather than a part of the test suit.
Unless I'm missing something, getting it there will add some dependencies which are not for a regular build system.
This is why I have placed the script under utils/bugpoint.

But it sounds like you have an idea how to do this. Would you explain your thoughts, please?

I guess I don't understand the point of RemoteRunSafely.sh then. I thought it's meant to be a script that parallel RunSafely.sh for bugpoint'ing miscompilations of llvm test suite.

bugpoint should be a standalone tool. It should not require a separate script to handle remote execution. Why is the script needed?

Evan

bugpoint should be a standalone tool. It should not require a separate
script to handle remote execution. Why is the script needed?

Bugpoint is a standalone too and does not require any separate script.
The script is a helper for using ssh as a remote client.

Bugpoint should not be aware of any details how the test program will be delivered to a remote target, get executed there, and how the result of execution will be returned back to the host.
So, it expects the "remote client" - whatever it is - take care of those 3 things.
The RemoteRunSafely.sh does all these by using ssh.

Viktor

bugpoint should be a standalone tool. It should not require a separate
script to handle remote execution. Why is the script needed?

Bugpoint is a standalone too and does not require any separate script.
The script is a helper for using ssh as a remote client.

Ok.

Bugpoint should not be aware of any details how the test program will be delivered to a remote target, get executed there, and how
the result of execution will be returned back to the host.
So, it expects the "remote client" - whatever it is - take care of those 3 things.
The RemoteRunSafely.sh does all these by using ssh.

Alright. But then the script probably should be named bugpoint_rexec.sh or something. Also, can you enhance it so it supports ssh (also takes a -p option)?

Chris, what do you think? I am not crazy about it living under tools/bugpoint. But I don't see a more sensible place.

Evan

bugpoint should be a standalone tool. It should not require a
separate
script to handle remote execution. Why is the script needed?

Bugpoint is a standalone too and does not require any separate script.
The script is a helper for using ssh as a remote client.

Ok.

Bugpoint should not be aware of any details how the test program
will be delivered to a remote target, get executed there, and how
the result of execution will be returned back to the host.
So, it expects the "remote client" - whatever it is - take care of
those 3 things.
The RemoteRunSafely.sh does all these by using ssh.

Alright. But then the script probably should be named
bugpoint_rexec.sh or something. Also, can you enhance it so it
supports ssh (also takes a -p option)?

Chris, what do you think? I am not crazy about it living under tools/
bugpoint. But I don't see a more sensible place.

Ah, right. Chris pointed out llvm/utils is where we put scripts like these.

Evan

Oh. I missed this one. Sorry.

Alright. But then the script probably should be named bugpoint_rexec.sh or something.

I don't have any strong idea about any particular name. This one looks fine.
Should I go ahead and rename it?

Best regards,
Viktor