Add more atomic support: 64-bit add for 32-bit code; atomic reads and writes for aarchxx

[derekbruening]

We have several use cases where we want better atomic support from DR:

• 32-bit support for dr_atomic_add64()
• 32-bit support for DRX_COUNTER_LOCK for 64-bit counters in drx_insert_counter_update()
• atomic and relatively prompt loads and stores for aarchxx for global flags accessed from gencode

[derekbruening]

Adding:

• Implement DRX_COUNTER_LOCK in the first place for aarchxx

[derekbruening]

For the aarchxx xref #2502 where DR core needs such utilities.

[derekbruening]

For gencode load/store: in drx, or in core? Thinking of in DR core b/c DR needs it for #2502.
Some are multi-instr (incl loop!) so should model after instrlist_insert_mov_immed_ptrsz().
So sthg like:

instrlist_insert_atomic_load64(void *drcontext, opnd_t memref, 
                               reg_id_t dst, IF_NOT_X64_(reg_id_t dst_hi)
                               instrlist_t *ilist, instr_t *where, 
                               instr_t **first OUT, instr_t **last OUT);

For 32-bit it takes 2 dest reg params.
Might need a temp reg too for LDREX?

[johnfxgalea]

How many registers will be needed for instrlist_insert_atomic_load32 and instrlist_insert_atomic_load64 for x86 and arm please?

[derekbruening]

For the data size equaling the pointer size, for plain load and for plain store (i.e., no add or other read-modify-write), just one data register in all cases (often the address is in a separate register though).

32-bit arm dealing with 64-bit data: load needs a second register; store needs several and needs a loop.

32-bit x86 and 64-bit data: there are choices to make. cmpxchg8b needs all 4 of eax,ebx,ecx,edx while using fildll and fistpll messes w/ floating state.

Maybe limit your interface to not support the data size being larger than the pointer size if you need constraints on registers.

[derekbruening]

Xref #4264 about using C11 atomics. For C++ clients, we should document that std::atomic is safe for clients so long as is_lock_free().

[derekbruening]

Another question is whether to try to adapt the x86 LOCK() wrapper, allowing for granular use around various loads and stores. It would only work for single-instr constructs, and it would have to support changing the opcode: sthg like from LDR to LDAR on AArch64.