U tweetove putem weba ili aplikacija drugih proizvođača možete dodati podatke o lokaciji, kao što su grad ili točna lokacija. Povijest lokacija tweetova uvijek možete izbrisati. Saznajte više
Ok, rewind to early 2017. My team was going to write a SPIR-V backend to DXC, lovingly called Spiregg https://github.com/microsoft/DirectXShaderCompiler/blob/master/docs/SPIR-V.rst ….
Question was: how were we going to test it?
#ossfuzz
Well, LIT and FileCheck are a fantastic combination for compiler testing. Pattern matching FTW! But there was a bit of a problem. That combo is fine for Linux, but a reasonably sized test set will spawn a LOT of processes, like 5 per test, and you'll have thousands of tests.
At the time DXC only built on Windows. And slow Windows process startup times meant your dev/test cycle is way slower with LIT+FileCheck. So much that in real life, fellow devs at a previous company regularly skipped testing on their machines when working in Windows. Not good.
Microsoft's DXC team was using their own Windows-only test framework https://docs.microsoft.com/en-us/windows-hardware/drivers/taef/ … But my team wanted to the portability and beauty of LIT+FileCheck. What to do, short of forcibly porting all of DXC to Linux?
(Yeah, we did port DXC to Linux, but that was a year later. We didn't want to rock the boat too early with Microsoft. We felt we needed to step more lightly in the early days, and earn trust.)
So I made a side project to replicate the core matching functionality of FileCheck but in a small minimal-dependency C++ library. Thus was born Effcee. https://github.com/google/effcee . I couldn't think of a good name, so you just say the letters "F" "C".
I wanted to do more in Effcee too. Like, in FileCheck it bugged me that it was a pain to write a regexp to match the LLVM IR identifier syntax. In my last job I hacked our copy of FileCheck so that [[FOO:%%]] meant "Define FOO var to an LLVM local id".
In any case, Effcee worked really well, and is the matcher for all of DXC's SPIR-V codegen tests. Awesome. We also started using it for SPIRV-Tools optimizer tests.
Forward to today, Effcee is stable. The news is the OSS-Fuzz team started fuzzing it. https://github.com/google/effcee/issues/29 … 100% cool with me.
They've found some bugs in Effcee, so I'm going to start fixing them.
#ossfuzz
I hadn't been concerned about fuzzing Effcee because my uses were for testing other tools, and the inputs to Effcee were trusted, intentionally constructed by a benevolent developer. But we can do better.
Forgot to mention: Effcee uses RE2 for regexp parsing. Really nice library!
Also, this story brings together some really nice things about Google: - RE2 is contributed & lying around so I can use it - I have the freedom to decide to write and open-source my own niche lib - some other random team decides to fuzz my code, out of the blue
Ok, first fix of a fuzzer bug is: https://github.com/google/effcee/pull/32 …
When parsing the checks string, there are cases where a string intended as a regexp isn't a valid RE2 regexp.
The fix is to check those cases and fail early. Prevents a heap-buffer-overflow later on
#ossfuzz
That was for cases where you've written something like: CHECK: {{blah\}} When the regexp is bad like this one (trailing slash is not a valid for RE2), Effcee should bail out with an error.
Turns out we need the same fix for variable definitions, like this: CHECK: [[FOO:?]] This says match and create/redefine variable FOO to match regexp '?', but ? alone is invalid because '?' quantifies..nothing. So we need this fix too:https://github.com/google/effcee/pull/33 …
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.
