indirect branch lookup should have barriers for either both mask and table or neither?

[derekbruening]

Looking at the arm and aarch64 emit_indirect_branch_lookup() they both have synchronization to handle a concurrently updated hash mask, but nothing when loading the lookuptable address. update_lookuptable_tls() uses a store-release when updating the mask -- but not the lookuptable. I'm not understanding that. Since these tables are all private anyway (-shard_{bb,trace}_ibt_tables are false by default) it doesn't matter in default runs?? But if they're private why don't we avoid the barrier for the mask under those options? Shouldn't we either have barriers for both the mask and table or for neither?

[ksco]

Should we put the barrier on the lookuptable instead of the mask? e.g. for AArch64:

# emit_indirect_branch_lookup

ldr xx, [x28, hash_mask]
ldar xx, [x28, hash_table]

# update_lookuptable_tls

stlr xx, [x28, hash_table]
str xx, [x28, hash_mask]