race updating shared ibt tables

Enabling -shared_bb_ibt_tables and running an app with many threads and a lot of code, I see crashes where a bogus non-code address was targeted. It looks like a race updating the tables.

Looking closely: hashtable_ibl_add just does a struct copy of the fragment_entry_t which copies the tag first and then the entry pc. Another thread could read the new tag but the old (uninitialized or bogus) entry pc. When I reverse the order the observed crashes disappear.

I'm quite surprised at this and thought it must be a regression, because in other parts of the code handling these tables we have careful update orders, such as with the table and mask or when invalidating entries. But looking at the code history when these tables were moved from a "lookuptable" auxiliary to a primary table, this order was always there. We never really used shared tables so I suppose this bug was always there.