I don't see a problem-- the FB tool rearranges the code any way it likes, but the property being checked at this line won't be affected, it's not like the binary is getting rewritten on the fly
-
-
Replying to @johnregehr @fbOpenSource
Reorder __cp_end before __cp_begin and add a jump. Logically __cp_end is anchored to the "end of the insn before it", but there's no way a tool can see this.
1 reply 0 retweets 1 like -
Worse, CSE some of the code between __cp_begin and the syscall insn, with a call out to it. Now (1) the range check gets a false negative, and (2) if cancellation is acted upon, SP is wrong when control transfers to __cp_cancel.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @fbOpenSource
well, I'd assume they're using something like -ffunction-sections and that's the granularity for rearrangement, I agree there's a world of hurt if they make the kind of changes you suggest here
2 replies 1 retweet 0 likes -
Replying to @johnregehr @fbOpenSource
Did you read the article? It seems they convert it to some kind of LLVM IR ("LLVM’s MCInst format"?) and let LLVM have at it...
1 reply 0 retweets 1 like -
They operate on machine code, don't have any metadata about function boundaries etc. So I doubt they could even make the pc range check work at all.
1 reply 0 retweets 1 like -
Too much information was already thrown away.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @fbOpenSource
well, good luck with that musl code then!
2 replies 0 retweets 1 like -
In my mind, "I wonder how they solve X" is a healthier conversation starter compared to "I'm sure they got it all wrong by not taking X into account", to begin with.
1 reply 0 retweets 0 likes
I'd like to be pleasantly surprised, but what they describe sounds impossible to do safely.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.