No rush, I don't have any pressing need for a fix. I was just curious.
May 16 2019
May 13 2019
Apr 26 2019
I've confirmed that this fixes the Firefox repro, thanks!
Mar 12 2019
Are there any bugs/reviews/etc. that I can subscribe to for the implementation of this in COFF?
Feb 27 2019
Oh you know what, I bet it's https://reviews.llvm.org/D53540#1326473. Rust has an LLVM roll in progress as I write this, so this should just sort itself out.
The function that I'm interested in (a Rust function, on arm64, if it matters) is apparently failing the IMAGE_SYM_DTYPE_FUNCTION test. Is there any other category of thing that it could be?
So after some further digging I was wrong, and my particular bug isn't to do with S->kind(). :(
Feb 25 2019
@rnk would you be able to test this out on the nacl browser_tests before landing?
Feb 12 2019
Feb 11 2019
Feb 4 2019
Do you care much about this? The naming here might be somewhat unconventional, but it's more flexible (consider the completely hypothetical case of a build having both "chrome.exe" and "chorme.dll" – if you call the pdb for both "chrome.dll" they'll get in each other's way, but with this scheme it works fine) and ever so slightly less code. So I weakly prefer what we currently have, but I almost never do debug builds so I don't care all that much. I'll accept this so that you can land it if you want, but I'd weakly prefer if you didn't :-)
Feb 1 2019
I wouldn't personally request cherrypicking that change at this point because it's not a regression from 7.0 and doesn't seem like a big issue. But if you feel otherwise, feel free to submit a cherrypick request.
Jan 22 2019
That's fair; we can just cherry-pick it to our 8.0 branch internally if it doesn't end up merged here :) It's early in the release cycle though, so I figured it was okay for small-ish changes like this which result in big improvements to go in.
Jan 18 2019
Even better -- thanks!
Jan 16 2019
The updated patch works for Firefox too.
I've confirmed that I can build Firefox successfully with this patch on top of latest trunk. Thank you @ssijaric!
Jan 9 2019
Jan 8 2019
I'd be interested in feedback from more people if anyone has any (e.g. "don't care").
Nov 19 2018
Thanks! I applied the patch and confirmed that it fixes the problematic Firefox DLL. (I don't know if I'm allowed to formally approve it though...)
Nov 9 2018
Nov 8 2018
Nov 2 2018
Oct 22 2018
Will abandon this patch since I have implementations of these which I will upstream soon.
The intent of noinline in LLVM's IR is to block inlining, not all interprocedural optimizations. So I don't think this is actually a bug
Oct 15 2018
Oct 8 2018
Oct 3 2018
Relanded in r343606.
Oct 2 2018
Sep 26 2018
Sep 25 2018
After writing the last comment and thinking about this some more, I convinced myself that this is more of a problem with interceptors than exception handlers.
@rnk, do I guess correctly that the runtime pretty deeply assumes that it will never be unloaded? Interceptions, exception handlers, etc. never get cleaned up? If that's the case then I don't feel too bad about this hack. But if unloading is supported by the design, then maybe we should do something more graceful than this.
Sep 20 2018
Sep 14 2018
Sep 7 2018
This isn't strictly necessary for anything; I was just debugging something and noticed that a hook fell back to Trampoline rather than Hotpatch because the prefix nop was only 8 bytes.
Aug 16 2018
This broke Windows debug builds where MemalignFromLocalPool becomes an unresolved external. (I guess in optimized builds the call within the if(0) gets optimized away.)
Jun 5 2018
I don't know this code well enough to be a proper reviewer, but I want to offer moral support for this change. Not having atime updates on NTFS can be frustrating at times.
May 11 2018
May 4 2018
May 1 2018
Fixed AddrIsInMidShadow too.
Hmm, come to think of it, AddrIsInMidShadow has the same bug, right?
Apr 30 2018
Dec 14 2017
Anyway, I'm just venting. If rnk@ wants to lgtm this, I'm fine.
Dec 6 2017
@ruiu Does this patch look ok?
Nov 22 2017
While writing a test I found a problem: the code that infers /entry should not run if we've previously defined one in a drectve. (In Mozilla's build, it worked by accident because the drectve was redundantly specifying the same function that got inferred.) Updated the patch.
Nov 20 2017
Added a test. If this looks OK, do you mind landing it for me?