Availability of the Sandboxes through Machine

[nofiv]

Hello, what are your thoughts on making the Sanboxes available through Machine? I think that architecture dependent classes such as Sandbox_Linux_x86_32 could be moved to a separate file such as sandbox.py under the respective arch directory and objects which are currently acquired through Machine in the sandbox file (gdbserver and jitter) would be supplied directly. Then it could work in a similar way as the dis_engine from Machine. Is there a disadvantage that I'm missing?

[serpilliere]

The problem is that the sandbox is also linked to an ABI: fastcall, stdcall, cdecl, ... So we also have to add another class that can describe them all. The design with everything put in the arch may not be a good idea to me.

[nofiv]

I'm not sure to understand the problem with the ABI, could you elaborate on it please? I'm aware only of those prepare_cb lines such as this one being ABI related and thought that ABI can be determined by OS that could be supplied as a parameter. And I didn't mean moving everything, the OS* and Sandbox classes would stay in the current sanbox file, only those architecture dependent ones would be moved, but it's not necessary.

[serpilliere]

Hi @nofiv The problem is a a problem of code location: If we put the sandbox in the arch directory, we may create loop dependencies. As the sandbox uses the jitter, the arch and the ABI, maybe the sandbox module has nothing to do in the arch directory.

[serpilliere]

Ho, ok, maybe I see what you propose at first. Maybe we could have a sandbox class somewhere in analysis or in it's own direcotyr, and implement it in the arch directory. Sorry for this. This could be a solution, I have to think about it.

[nofiv]

Just to clarify my thoughts a bit more I think that all the problematic dependencies originate on this line and that each specific jitter and gdbserver (I don't see any other uses of Sandbox.machine right now) could be imported by the derived classes instead. For example Arch_x86_32 would contain an init which would initialize self.jitter and self.gdbserver and then call super init.