The proxy-type issue is indeed the one wart in this project. I know that Chrome (at least on Windows, and probably everywhere) has decided not to enforce strict aliasing, but V8 may not have given up on that.
The proxy types are rarely if ever read from or written to using the proxy type, but I'm not sure if that makes them legal or if that just means that every reference is UB - I suspect every reference is UB. And, I can't guarantee that they are only read/written using the real type - object copying would necessarily copy the bits using the proxy type. I don't think that windows.h can be removed without using this technique (not unless every one of these becomes a pointer to an allocated object). In the Chromium code-base I decided that the ugliness of the aliasing was less than the ugliness of windows-h-everywhere. V8 may, of course, come to a different conclusion. I updated my CL which uses the proxy technique on a couple of types so that it will build. That will let us see what the UBSan bots think of it. Is the regular dry run sufficient? On Thu, Jul 22, 2021 at 11:55 AM Leszek Swirski <[email protected]> wrote: > Hi Bruce, > > Thanks for looking into this, I'd be happy to do code reviews and give > advice if you're ok with the EMEA timezone delay - otherwise we've a couple > of people in PST too. > > One question about the proxy types: are we at risk of triggering undefined > behaviour by reinterpret casting between the proxy types and the Windows > types? We've gone to some lengths to be UBSan clean and I wouldn't want to > regress that. > > Cheers, > Leszek > > > On Thu, 22 Jul 2021, 19:57 'Bruce Dawson' via v8-dev, < > [email protected]> wrote: > >> To make this more concrete I created a V8 CL >> <https://chromium-review.googlesource.com/c/v8/v8/+/3042215> that >> demonstrates what is involved, >> using obj/v8/v8_libbase/condition-variable.obj as the test case. That file >> builds. Other files do not. >> >> Some of the files are just hacked into compliance, but it gives a sense >> of how it would work. >> >> >> >> On Thu, Jul 22, 2021 at 10:23 AM Bruce Dawson <[email protected]> >> wrote: >> >>> I'm a Chrome developer and I've been working on reducing how frequently >>> windows.h is included in source files when building Chrome for Windows. It >>> used to be (2018) that more than 78% of Chrome's translation units included >>> windows.h When I picked up this project again in June this had been reduced >>> and about half of Chrome's translation units pulled in windows.h. Since >>> June I have reduced this to less than 22%. About 9% of the remaining uses >>> of windows.h (2% of source files used when building Chrome) are in v8 - 761 >>> translation units. >>> >>> The advantages of reducing usage of windows.h are (very slightly) >>> reduced compile times, reduced namespace pollution (no more #define >>> DrawText DrawTextW), reduced warning-flag manipulation, etc. Mostly it's >>> about avoiding those macro definitions. >>> >>> So... >>> >>> I'm looking at getting v8 to use windows.h less. The techniques are well >>> understood and proven and are best summarized in the contents of >>> windows_types.h >>> <https://source.chromium.org/chromium/chromium/src/+/main:base/win/windows_types.h;l=9?q=windows_types.h&sq=>. >>> This creates the minimal set of typedefs and defines needed to compile >>> Chrome's header files and portable code. In a few cases >>> (CONDITION_VARIABLE, for instance) it is necessary to define Chrome proxy's >>> for Windows types, and cast between them when calling Windows functions >>> <https://source.chromium.org/chromium/chromium/src/+/main:base/win/windows_types.h;l=299?q=windows_types.h> >>> . >>> >>> This is a medium sized project that will require landing lots of small >>> CLs. I've done enough investigation to get a sense of the scope. I'll need >>> to create V8 proxy-types for CONDITION_VARIABLE, SRWLOCK, and >>> CRITICAL_SECTION, create typedefs for HANDLE (this is easy - there's no >>> casting required), and explicitly include windows.h in a few source files >>> that actually need it. And I'll need to fix whatever other issues pop up, >>> but I'm not expecting anything worse than what I've seen before. I think >>> that the vast majority of v8 files will be able to compile without >>> windows.h. >>> >>> The overall project is tracked by crbug.com/796644 and the bugs which >>> block it. >>> >>> Is this a project that V8 would support? If so, can I get a >>> volunteer/sponsor who I can work with for advice and some code reviews? >>> >>> >> >> -- >> Bruce Dawson, he/him >> >> -- >> -- >> v8-dev mailing list >> [email protected] >> http://groups.google.com/group/v8-dev >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/v8-dev/CAE5mQiMF_Yx4cvVKtfhw1bGxqdKCx0U7%3DEz%2BMqGm%2BO%2BBG47U7w%40mail.gmail.com >> <https://groups.google.com/d/msgid/v8-dev/CAE5mQiMF_Yx4cvVKtfhw1bGxqdKCx0U7%3DEz%2BMqGm%2BO%2BBG47U7w%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to a topic in the > Google Groups "v8-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/v8-dev/MbE-A6QBOCM/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/v8-dev/CAGRskv-kw1aFXyK%2BQwmOffvh3TVZvWgHHw6MBpoRMeGhGTJ2Hg%40mail.gmail.com > <https://groups.google.com/d/msgid/v8-dev/CAGRskv-kw1aFXyK%2BQwmOffvh3TVZvWgHHw6MBpoRMeGhGTJ2Hg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Bruce Dawson, he/him -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAE5mQiMsatJLmHW9Aufq5EVob3DYQCYa8h_xs7-bfVBLXngOjA%40mail.gmail.com.
