Always allow linking AFL-instrumented modules #10107
Conversation
| @@ -15,6 +15,11 @@ | |||
| /* Runtime support for afl-fuzz */ | |||
| #include "caml/config.h" | |||
|
|
|||
| /* Values used by the instrumentation logic (see cmmgen.ml) */ | |||
| static unsigned char afl_area_initial[1 << 16]; | |||
There was a problem hiding this comment.
So, every OCaml program is 64 Kbytes bigger, just in case AFL is applied to it?
I know this is orthogonal to the issue at hand, but I'd really like to see on-demand allocation here.
There was a problem hiding this comment.
Ah, it wasn't just me bothered by this! I'll open an issue to track it...
No longer at Inria's CI. It takes too long given the limited number of cores we can throw at the 6 Windows ports... We (@shindere) could try to get more cores. Or, we could have a different CI job, "other-windows-configs", say, that runs once every night, say, and that tests flambda and other less common configurations on Windows. |
|
On a related note: I'm not sure no-naked-pointers mode is tested much under Windows, too. |
|
Perhaps GitHub actions can help out here (they're quite generous with Windows runners, it seems). Alternatively, could the mingw64 worker build flambda? |
|
David Allsopp (2021/01/03 14:08 -0800):
Perhaps GitHub actions can help out here (they're quite generous with Windows runners, it seems).
Alternatively, could the mingw64 worker build flambda?
Probably it could, but why are you suggesting that one in particular?
|
No, because mingw64 is the slowest Windows build already (50+ minutes vs. 30 min for msvc32). |
|
I picked mingw64 since it's the closest to the default Linux flambda build (i.e. it's gcc and 64-bit) so if you see a failure on just mingw64+flambda you could be fairly you're looking at an flambda issue, and not an MSVC/32-bit/etc. However, the disparity in speed is much more important than that - I'd pick the fastest native Windows build to do it |
|
This work was mentioned in the 4.12 milestone, and its Changes entry is in the 4.12 section, but as far as I can tell it was never cherry-picked in the 4.12 branch. (cc @dra27 @Octachron) My current understanding is that this change will not be part of 4.12.0, so I will fix the Changes by moving it to the trunk section. |
|
(Note: this fixes a bug in a test that was added in 4.12~dev; if the fix is not backported, maybe it would make sense to disable the test from 4.12 to avoid future annoyance for people testing 4.12.) |
Always allow linking AFL-instrumented modules (cherry picked from commit 15c5679)
|
Sorry, this appears have to been lost in the lockdown 3 fog here in the UK... I have just cherry-picked this to 4.12, but moved it from the 4.12.0 to the top of |
Always allow linking AFL-instrumented modules (cherry picked from commit 15c5679)
#9998 added
testsuite/tests/flambda/afl_lazy.ml. This test fails to link on platforms which don't support AFL (like Windows).This has been wrong forever, but as the test itself was added in 4.12, I propose including this bug fix in 4.12.
More detail: AFL support is always built in the runtime if the required shared memory support is available. The
--with-afloption simply controls whether the-afl-instrumentoption is the default. So ocamlopt always requires thecaml_afl_area_ptrandcaml_afl_prev_locdata areas and alsocaml_setup_aflto be a valid function. The fix is therefore easy - always define the two data values and include a dummy stub forcaml_setup_aflreturningVal_unit(this is whatcaml_setup_aflnormally does when an instrumented program is run without AFL).More seriously: we appear to be no longer continuously testing Windows flambda anywhere?