Euphoria
Ticket #111:
Callbacks should be simple machine call
-
Reported by
mattlewis
Oct 29, 2009
The callback code in std/dll.e needs to be moved to the back end. The current implementation breaks eu.ex. There is no reason for it to be in the front end.
Details
1. Comment by jimcbrown
Nov 03, 2009
The callback code in std/dll.e needs to be moved to the back end. The current
implementation breaks eu.ex. There is no reason for it to be in the front end.
Even if std/dll.e's DEP callback code was moved to the backend, the current implementation of callback in eu.ex would break. It still requires modifying and then executing the same block of memory, which can't be done as easily when DEP is on.
So we actually have three bugs in this ticket:
a) move the entirety of DEP code from the front end to the back end (I agree with this change, as I told Shawn, but it really has nothing fundamental to do with eu.ex breaking)
b) implementing DEP-compatible callbacks (and other misc related DEP functions and DEP support) in eu.ex
c) fixing eu.ex so that callbacks work on Windows when DEP is not in use (the real issue that was posted on the forum that lead to this ticket)
2. Comment by jimcbrown
Nov 03, 2009
r2986 and r2987 fix c). (Yes, if DEP is really on, eu.ex will crash, but that would have always happened anyways.) I noticed that there is a d) - having a function that allows the user to explicitly disable (turn off) DEP support.
3. Comment by jimcbrown
Nov 05, 2009
Ok, d) is now done in r2989
To deal with b), we need to call the DEP functions in the backend (in do_callback() of execute.e) but we don't need to support the "naked" format that the C backend uses. We can do everything in execute.e and then return a "normal" callback to the front end.
4. Comment by jimcbrown
Nov 05, 2009
I have implemented b) in 2990 but I am not able to test it. Please confirm if it works or not.
5. Comment by DerekParnell
Nov 05, 2009
The translated t_dep.e is failing on Windows.
translating, compiling, and executing executable: t_dep.e
..................................................................................
passed: allocate code memory
passed: allocate data memory
passed: Is memory allocated by allocate_code() executable?
failed: create forced cdecl callback, expected: "anything but '0'" but got: {4361408,13,80}
failed: create regular callback, expected: "anything but '0'" but got: {4361504,13,80}
Fatal run-time error:
: an integer was expected, not a sequence
failed: unittesting crashed, expected: 1 but got: 0
6 tests run, 3 passed, 3 failed, 50.0% success
FAILURE: t_dep EUPHORIA error with status 1
Test results summary:
FAIL: translated t_dep.exe
6. Comment by jimcbrown
Nov 05, 2009
I just committed a fix that should unbreak translation (unless you try translating eu.ex or execute.e) but this seems like a lower level bug is being exposed. We are clearly returning a sequence from M_CALL_BACK but apparently the "not sequence(s)" test in call_back() is failing anyways (and then returning the sequence).
7. Comment by DerekParnell
Nov 05, 2009
t_dep.e is no longer failing.
8. Comment by jimcbrown
Nov 05, 2009
I'll wait for Matt to comment before opening up a new ticket for the "not sequence(s)" bug (I want to make sure it really is a bug and not expected behavior). It might not be a big deal, as it simply means that callbacks may not work with a translated eu.ex
The need for the workaround that exposed this will go away once a) (moving all the DEP stuff to the C backend) is done.
9. Comment by SDPringle
Feb 03, 2010
machine_func(M_CALLBACK,...) would normally return a 4kB section of memory for the 92byte callback routine. The EUPHORIA wrapping around it saved memory.
10. Comment by jimcbrown
Feb 03, 2010
But the level of complexity required to make this work (all the workarounds in place in eu.ex and elsewhere) make me think it is worth losing a single page of memory, simply to simplify the code.
11. Comment by mattlewis
Feb 03, 2010
It seems like we'd save even more memory if we allocated the pages in the backend and used them up like we're currently doing in std/dll.e.
This seems like a good opportunity to refactor the C callback function, so that it simply asks another function for a new pointer to some executable memory. And that new function would worry about allocating new pages, etc, plus all the platform requirements, so for some platforms, it's a simple malloc() maybe.
12. Comment by jimcbrown
Feb 03, 2010
The only platforms I'm aware of that supports DEP that we don't support yet are amd64 linux and amd64 FreeBSD... I think to take advantage of DEP in these cases we'd neede a native 64bit binary as well (so it could allocate and manipulate the real page table).
13. Comment by SDPringle
Feb 04, 2010
I have moved the memory saving code from the EUPHORIA in dll.e to the C code in be_machine.c.
14. Comment by SDPringle
Feb 04, 2010
I have moved the memory saving code in dll.e to the C code r3075.
GitHub